Skip to content
This repository has been archived by the owner on Apr 19, 2022. It is now read-only.

Remove most instances of float usage #341

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Remove most instances of float usage #341

wants to merge 3 commits into from

Conversation

dxxb
Copy link
Contributor

@dxxb dxxb commented Jan 20, 2018

This PR is not intended for merging as-is. It could be but at a minimum the game needs to be tested and constants / computation may need to be re-tuned. With a bit more effort the last instances of float could be removed (and fixed point trigonometric function used).

Aside from freed up RAM and flash, the speed gain is likely large.

Before:

Program:   28562 bytes (87.2% Full)
(.text + .data + .bootloader)

Data:       1929 bytes (75.4% Full)
(.data + .bss + .noinit)

After (with logo enabled):

Program:   25092 bytes (76.6% Full)
(.text + .data + .bootloader)

Data:       1715 bytes (67.0% Full)
(.data + .bss + .noinit)

@mschwartz
Copy link
Contributor

mschwartz commented Jan 20, 2018

I tried this early on.

The rounding errors were only part of the problem. 16 bit ints simply do no hold a large enough number. If the joystick Left is held long enough, camera x wraps and enemies and bullets think they’re very far away from the camera. It’s a worse effect in z because all you have to do is survive long enough.

@mschwartz
Copy link
Contributor

mschwartz commented Jan 20, 2018

Also, as fixed point gets more resolution, the less integer portion and the more costly it is to shift out the fraction.

Moving to longs migh only be a bit better performance, but perhaps the gains in program and RAM minimal, if at all.

@dxxb
Copy link
Contributor Author

dxxb commented Jan 20, 2018

Also, as fixed point gets more resolution, the less integer portion and the more costly it is to shift out the fraction.

Q8.8 are used so in most cases there is no shift involved. Anyway, regardless of the size of the integer portion, 16bit fixed point beats floats on the AVR.

16 bit ints simply do no hold a large enough number.

The game seems mostly fine to me. If something wasn't right I'd try looking for a workaround without sacrificing integer math. One could even say that a glitch once in a while is not that bad compared with what memory/speed gains can allow you to do. About wraparound, if I recall correctly objects in the game world and the camera can never be very far from each other (256 units?). My guess is that we could take advantage of this to prevent glitches caused by wraparound.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants