Cobra Forums

I encountered this error while working on the same roguelike library project from before. Here's the bit of code:

Code: Select all

.offConsole.blit(0, 0, .sampleScreenWidth // 2, .sampleScreenHeight // 2, .sampleConsole, off_x, off_y, 1.0f, 0.75f)


I get the error "Main.cobra(294): error: Argument "8": cannot convert from "float" to "float"" and the same error for argument 8. After a bit of experimentation, I resolved the issue, which was that the library call wanted a Float32 type. Changing my last two arguments to 1.0_f32 and 0.75_f32 allow it to compile.

I just wanted to suggest that if the error message could be made more explicit, that would be groovy.

Yeah that error message definitely needs improvement. Thanks for the report.

If all your fractional numbers are going to be float32, then slap this in one of your files:
And then just write "1.0".

Thanks for the reply, glad to contribute a bit to the language. I may have to consider the @number change. Seems like I'm using a majority of floats and Cobra wants to use decimals. That float32 thing was just an oddity, I'm guessing that maps to C#'s double type. Thanks for the suggestion!

C# "double" is a 64-bit float. C# "float" is a 32-bit float.

Cobra has "float32" and "float64". It also has "float" which, like Python and unlike C#, is a float64.

I poked around the libcodt classes via the Google code browser for that project and it's a weird mishmash of both "double" and "float", sometimes in the same method signature! Not sure why they don't pick one size, such as 64-bit, and just stick to it.

Btw another fun project would be to port the original libcodt to Cobra.

There are a number of odd idiosyncrasies to the library. It was written in C, but then there's a C++ wrapper on top of that. On top of one of those, a different person did the .NET wrapper. So the low-level wrapper is full of C language hacks like manipulating enum values as ints and using arrays for all kinds of things. The .NET wrapper appears to follow suit in many places, even where .NET features probably would have been more readable or useful, like using arrays instead of generic lists. And yeah, the floating point types are all over the place, along with implicit casting to stuff floats into ints. Cobra appears to be a lot pickier about that kind of thing (which I actually prefer) so a number of errors were type checking on that.


It would be kind of interesting to see a port of something graphic like libtcod up to the cobra level. I think it's just using SDL to render everything, so it should be doable. Be interesting to see if Cobra can hook into XNA as well.

I fixed the error message that spawned this thread.

I have some problems with @number float32. It works fine when numbers are positive, but when I try put for example -1.0 compiler says "...expects type float32, but the call is supplying type float."

example code:

.scale(-1.0, 1.0)

def scale(x as number, y as number)
GL.scale(x, y, 0.0)

- Gekko

Gekko wrote:I have some problems with @number float32. It works fine when numbers are positive, but when I try put for example -1.0 compiler says "...expects type float32, but the call is supplying type float."

example code:

.scale(-1.0, 1.0)

def scale(x as number, y as number)
GL.scale(x, y, 0.0)

Gekko, I'm sorry I missed your message from earlier. I have tried to reproduce your problem with the latest Cobra and cannot. If you are still having problems, let us know.

I downloaded the newest version of the Cobra and still the same result.

The whole project is here if you want to test. There is a file named OpenGL.cobra and the line 214 gives the error (GraphicsGL.cobra(214): error: Argument 1 of method "scale" expects type float32, but the call is supplying type float.)
It works if you put -1 instead of -1.0.

http://personal.inet.fi/peli/laurilagam ... roject.zip

OS is Windows 7 64bit

- Gekko

Thanks. I get the error too, but still not with my smaller test case that basically does the same thing. But I'm whittling down your code til I figure it out.

In the mean time, you can use a cast as a workaround:...for those cases that can't be handled by simple ints.

I'll post again when this is fixed.