Sorry your browser is not supported!

If the game is not aiming to be particularly 'perfect' what are the advantages and possible disadvantages of using floats over integers for sprites?

I can imagine that as per normal floats are heavy for processing and as such are they really necessary?

Sorry for the noob question if it is stupid!

Adam

You only use floats for coordinates if using the percentage system. If using actual pixels, no need for floats.

So the question is more, percentage or pixels?

Main advantage of percentage coordinates is that it is easy to adjust for different screen sizes and aspects without screwing up relative positions - in app even for auto-adjusting.

Pixel coordinates are better for raw speed. But with the plethora of resolutions and aspects out there in the wild, your app will look quite odd on a lot of them - assuming they get accepted by the app store curators at all for not utilizing the entire screen. Though there are work-arounds to avoid the black-bars syndrome.

I'm more into making apps than games per-se, so I tend to just stick to the percentage system. It's a bit unusual to work with at first, but one soon get the hang of it.

Using integers over floats will be a tiny bit faster. But the impact will be so small it wont have any effect on your FPS at all. The thing that slows down a game the most is drawing too many sprites at the same time. Physics simulations are probably a close second. There's no real reason to use floats over integers for sprite coordinates and it make sprite movement look considerably worse.

The only time I'd ever use integers for sprite coordinates is if the sprite doesn't move. Whenever a sprite moves, it's essential to use floats, not just for smooth movement, but it also lets you move slower than 1 unit per frame (which, depending on your virtual resolution, might be a minimum speed of half the screen per second).

EDIT: I see my answer is different to the one above (posted at the same time). I have a few reasons for disagreeing with Dybing.
1. AppGameKit doesn't necessarily use the actual pixel size for it's coordinates. I never recommend you use percentage based since it just stretches the game to fit a device. Instead the best way I've found to setup your layout is like this:


The width of the screen is 100 units (in portrait mode). But you should never position an object absolutely. To place a sprite in the top left use SetSpritePosition(id, sbL,sbT). The centre of the screen will always be 50,75 of course. But the top and bottom might be -20 or 170 or something, depending on the size of the phone.
The benefit of this is that it lets your game work on any aspect ratio, and scaling is really easy since it's scaled based on 100 (so the middle of the screen is 50, not something like 720/2). So using this method (which I do for all my games), you pretty much never call SetSpritePosition() with absolute coordinates, you always do something like sbL+2, sbcX-10, sbR-5 etc

2. If you do any type of "simulated physics" on a sprite, you want to move is as precisely as possible. If you use integers, the maximum precision you can use is the resolution of your device.
For example, my new game Alpine Ski Adventure simulates the physics of the ski using 4 vectors (target direction, current direction, current physical speed, current location). If I were to use integers for any of these it would massively limit the precision with which you could move as well as limiting how slow you can move or turn.

So I still stand by my assertion that you should only use integers for sprite location when the sprite doesn't have to move at all

Wow thanks both of you! There's a whole lot of things you casually mentioned that I will have to read up on!

Thank you for your time/patience and for being so clear about the info! I am glad you disagree a bit because it gives more food for thought and to realize it depends what/where it is/going!

Thanks again!

I have to agree with that. I don't know exactly why, but I found my moving sprites more predictable using pixel based movement. And I did notice everything moves much smoother using floats. So I would use floats, unless you're perhaps making a turn based game where the in between stuff matters less, however knowing most games still have animations and movement from one tile to the next, you would probably still want that as accurate as possible using floats anyway.



Yes! Very true indeed. In fact, in combination with using GetVirtualWidth() and GetVirtualHeight() and dividing or multiplying by sprite size and/or adding / subtracting smaller amounts it is quite possible to get a good UI going that works on a larger range of mobile screens. I found GetDeviceHeight() and GetDeviceWidth() less reliable, as they seem to mess up things whenever the screen was rotated or rotated briefly before your app starts up if I recall correctly (I suppose this is because the values stay the same when the device is rotated? Don't recall exactly).

Percentage system will only stretch everything to fit the device screen if you also use SetDisplayAspect(-1). I like using a 100x100 virtual resolution in conjunction with the GetScreenBounds commands to position stuff outside the central 100x100 area.

I use floats because they provide much more precision fine control over velocities for movement but I use floor to convert a sprites position from float to integer when actually using SetSpritePosition. This is because with modern games basically everything is rendered in 3D and fractional positions can cause artifacts. So just use floats in your sprite type or other variables for positions then convert to floor when actually updating the sprite object's position itself (SetSpritePosition) so it is always on a whole pixel position and not a fraction. Maybe AGK2 does this for us automatically...I don't know. I only know this problem exists in others I have used such as Monkey X and Unity. So I got in the habit of converting to whole integer position values while internally using floats.

floats = pixel perfect precision
integers - blocky precision

Too add a bit more to what has already been stated, floats are essential once you start getting into programming advanced movement systems such as sin, orbital, tracking, predictive, etc..

Yeah and that doesn't have to be even that advanced at all. I had a issue with 3D movement that became twitchy and seemed like it was skipping frames or something, but it turned out it was caused by integer values which should have been floats. As for the performance difference, I'm honestly not really buying the idea that integers are faster. These types of calculations are so fast nowadays, I'd be extremely surprised if you would get a tangible difference.

I agree @PHeMoX it used to be true long ago that integer values were faster processing than floating point values but cpus got floating point units (dedicated math co-processors) best as I remember many years back and floating point actually became as fast or even faster than integers. I suppose ints could be faster in AppGameKit Tier 1 if the bytecode interpreter was written in a way to cause that.