That "accurate to 3 decimal places thing" is ... well ... it is a rule of thumb for beginners. In practice it is sufficiently exact. 22.599609375 is close enough to 22.6, unless you start to do direct comparisons, which is always a bad idea, except for integers.

The manual wouldn't do better giving an introduction to binary representations of fractional numbers, would it? While the 22.10 fixed format is rather easy to understand - if you have basic knowledge about numbers represented to different bases - it gets complicated with IEEE floating point numbers. Talking just about variables this would make things more complicated than they need to be, especially for those beginners.

This problem is by the way not specific to GameStudio. You will see the same issues in C++, Java etc. It is easy to see for me. I'm a software engineering student. It may look strange and unexplainable to people with a less technical background, that is no doubt.

The manual wouldn't do better giving an introduction to binary representations of fractional numbers, would it? While the 22.10 fixed format is rather easy to understand it gets complicated with IEEE floating point numbers. Talking just about variables this would make things more complicated than they need to be.

Mercuryus, I think JustSid summarizes the things perfectly fine in his post. I'd suggest you lean back and relax. Seriously, nobody wanted to offend you. You thought you found a bug, but you didn't and JCL gave one of his "special" answers. I personally like this style of answers, others might find them offending because sometimes they are "furz-trocken" (Can someone translate that?). Get some distance to this this and then start again. :-) Don't get discouraged by just a little misunderstanding. And keep in mind that you're and old and experienced member of this community. Hence expectations are very high when you post in the showcase forums.

Fustrating?
I don't agree with this so much. He's here to represent the product and team and provide support where necessary. I'm less inclined to report bugs and happy for them to sit in the engine and significantly reduce the chances of being mocked in the process. Maybe the forum description for 'Ask the Developers' should be changed from 'If your questions aren't answered elsewhere' to 'Free mocking and ridicule, and that's only if we can bother answering at all'

While different engines on the market are greatly superior to GameStudio [insert reasons here... we all know them] developers should be trying to keep their ever decreasing number of users (a great 310 forum users since the start of 2012) and this isn't the way to go about it.

I'm only loyal to GS to warrant spending the money from A6 thro A8 though on more than a few occassions I've looked at Unity and wondered why I'm still here. Many other members continue to use this forum while developing on different platforms and even JCL chose a different renderer and MP system when developing a game for a client which also puts him in this category. (I digress)

That's true, I still play 7Castles (thank god for mute though )

this isn't really one of the usual floating point problems. this special trap only occurs in lite-c.

why are number literals int and double in lite-c? this seems to be a bit inconsequent to me. wouldn't it be more user friendly if all numbers were treated as vars?

(but actually, in my opinion vars should be scrapped. they have a lot more disadvantages than advantages.)

That is simply not true. The same problem would arise in standard c as well. When you convert floating point numbers to fixed point numbers a loss of precision will most likely occur - regardless of the language.

Literals are interpreted in Lite-C exactly as in Standard C. Lite-C was always designed to be 100% C compatible. Besides that: Doing things different than a standard suggests will in most cases cause even more confusion.

And last but not least: The fixed data type has advantages over float. It's faster and does not compute odd results like in "1f / 0f == +Infinity".

in standard c you don't have built-in fixed point variables with implicit casts so it can't happen in exactly this way.

fixed point was faster when cpus didn't have floating point units. on modern hardware they aren't faster.

and the biggest disadvantage is that fixed point variables require quants as unit. quants are totally counterintuitive. in all other engines you can use meters as unit.

but it isn't.

It's correct, that standard c does not have built in fixed point types. But that does not change the overall problem. When you write a constant in decimal notation you cannot be sure the corresponding computer representation is precise. This is the reason why you should never compare floats with an equals sign.

I agree with you though that the speed reasons becomes less important nower days. The question is if and when to switch for compatibility reasons.


"quants" is just a word. You can also define that 1 unit (i.e. quant) represents 1 meter or 1 centimeter in your game and you're good to go. If you're in a funny mood you can call those quants also "ventilator", or "schokoflocken". This has nothing to do with the data type. It's just a name for the units.


Unfortunately. I'd be the first to sign a petition to make it 100% compatible at this very moment. Adding even more exceptions to the number of incompatibilities is at least from my point of view not the way to go.

if you use exactly the same literal two times then you can be sure that the representation is the same. so his example would work perfectly fine if the var conversion weren't involved. that's why i said that it isn't a typical floating point problem. if you don't compare literals but some calculated values then you have to be more cautious of course.

no, you are not good to go with quants. if you use 1 quant = 1 meter you will get precision problems. if you use 1 quant = 1 centimeter then your world size will be limited.

If you use 2 literals you can compare them in lite-c as well as in c without problems, I agree. On the other hand, comparing two literals is pretty pointless. And as soon as any calculation is involved comparing for equality gets dangerous, regardless if that calculation is a simple expression or a function call. You don't need a cast to f*** things up.

Long story short: From my perspective the above error is clearly a programmer's mistake and may not be excused by saying the language is not well designed.

The trade-off problem between world size and precision is the same for floats with the difference that you can have larger worlds but the calculations done for larger values get more error prone. But as long as I can remember no user ever had a problem with exceeding the current coordinate system. But in general I totally share your opinion: on the long run GS should switch to float. Maybe when a new major version comes out?