Ard-Type - an R-Type tribute

Share your games and programs with the community.

Re: Ard-Type - an R-Type tribute

Postby Limited » Tue Jul 29, 2014 9:47 pm

annyfm wrote:
Limited wrote:Out of curiosity is there a reason why you use floats for positions and velocities for bullets rather than bytes? (Bytes usage is better)


Ignorance :lol:

edit: will expand on that a little... I'm not really a C or Arduino programmer, I actually come from a predominantly PHP background (which is how I make my living) and while I understand static tying in principle and casting, working in a dynamically typed language leaves me somewhat at a loss for the pros and cons of certain types (like I know float is more computationally expensive than int, but not a lot more than that!)

edit 2: on that note, any chance you could elucidate the benefits of byte over int/float?

Thats fair enough, first stage is what you've done, get the thing working first, then plan out improving.

The short answer is bytes take up less room, there are 8 bits in a byte, 16 in an int and 32 in a float - the more bits it takes up more memory, but does allow you to store larger numbers.

Floats are very bad for low processor powered devices because multiplying but more importantly dividing is extremely costly computationally, float numbers allow for decimal places, for like 3.14 etc, the program would also have to cast/convert these into ints as that is what the screen uses for pixel rendering for instance.
Limited
 
Posts: 13
Joined: Sat May 31, 2014 7:25 pm

Re: Ard-Type - an R-Type tribute

Postby annyfm » Tue Jul 29, 2014 10:02 pm

Alright that makes sense, but I guess using bytes might have an impact on the precision of my calculations? For instance, I want the player ship to have slightly different movement speeds for X and Y axes - fast moving on Y, but a bit slower on X, by a fractional rather than whole amount. Also, I want the velocity/direction modification on individual bullets to only have a fractional effect, rather than adopting the same movement values as the ship itself.

So I guess bytes would have to be integers, given their smaller size than ints; to achieve the same effect as I am currently getting, would I have to refactor other values/calculations to higher starting values and use larger divisors, casting the result to float to preserve granularity? Ergo storing only one float in memory, rather than several (and also presumably resulting in faster calculations). So for instance, this line which currently reads (with relevant variables pasted in):

Code: Select all
const float bullet_xv = 2;
const float bullet_xv_mod_pship = 0.5;

typedef struct {
...
   float xv;
...
} PlayerShip;

float bxv = bullet_xv + (bullet_xv_mod_pship*pship.xv);


Might be implemented with bytes a bit differently:

Code: Select all
const byte bullet_xv = 2;
const byte bullet_xv_div_pship = 2;

typedef struct {
...
   byte xv; // with xv having an integer value only, requiring further division in the relevant movement code
...
} PlayerShip;

float bxv = bullet_xv + (pship.xv/bullet_xv_mod_pship);


Have I understood the concept or am I way off the mark? If so, could you suggest another implementation using bytes?

On the one hand I agree with the principle of "get it working, optimise later" - but I suspect that while this works OK now, it could become problematic later if I start adding 5 enemies and 50 bullets to the screen simultaneously (particularly as I'm using arrays in a fairly relaxed manner to track 'active' bullets). Premature optimisation maybe wouldn't be such a bad thing in this instance...
User avatar
annyfm
 
Posts: 22
Joined: Sat Jul 19, 2014 1:31 pm
Location: London, UK

Re: Ard-Type - an R-Type tribute

Postby rodot » Tue Jul 29, 2014 10:14 pm

Mmh, floats are "really slow"... but remember it's still a matter of microseconds so don't worry if you're no doing thousands of operations per frame. Look at Myndale's 3D engine, it's all based on floats and runs very smoothly.

In your game floats are necessary to allow this precise control of the bullet speed. As long as you don't have 200 bullets flying around it should be ok.

I've wrote down some random thoughts about optimimization and performances on the wiki. You might want to give it a look, and why not improve it (I wrote it some time ago and didn't spend much time on it, it's faaaar from being perfect. Plus my bad english).
User avatar
rodot
Site Admin
 
Posts: 1290
Joined: Mon Nov 19, 2012 11:54 pm
Location: France

Re: Ard-Type - an R-Type tribute

Postby 94k » Tue Jul 29, 2014 10:18 pm

I've seen a couple of demos (demos as in demo scene, not game demos) on limited hardware where they used ints as would be floats. Say you want to store some distance in meters, instead of representing 5 meters with the value 5 you'd represent it with 50000, essentially shifting the the value to gain more precision while still being able to use integer operations.
User avatar
94k
 
Posts: 44
Joined: Sun Jul 27, 2014 9:41 pm
Location: Germany

Re: Ard-Type - an R-Type tribute

Postby annyfm » Tue Jul 29, 2014 10:24 pm

Thanks for that wiki link rodot, I appreciate the table of data types. I'll give it a closer read when I have a little more time.

94k wrote:I've seen a couple of demos (demos as in demo scene, not game demos) on limited hardware where they used ints as would be floats. Say you want to store some distance in meters, instead of representing 5 meters with the value 5 you'd represent it with 50000, essentially shifting the the value to gain more precision while still being able to use integer operations.


Yeah that's what I was thinking about although you put it more succintly and clearly than my example. So I guess if I need a granularity of 1/100 (or to put it another way, accuracy to 0.01) I could use bytes with a divisor of 100, given that they have a range of 0-255. Then if I needed values > 2.55 I'd have to change up to an int. But dividing int by (int)byte would be cheaper than dividing float by float anyway, right?
User avatar
annyfm
 
Posts: 22
Joined: Sat Jul 19, 2014 1:31 pm
Location: London, UK

Re: Ard-Type - an R-Type tribute

Postby rodot » Tue Jul 29, 2014 10:27 pm

94k wrote:shifting the the value to gain more precision while still being able to use integer operations

Yeah that's why the battery voltage is expressed in millivolts instead of volts for examples. But for coordinates and velocity it's not going to be really readable if you have to divide your values by 100 each time you want to print them to the screen. BTW it would be wiser to use a ratio which is a power of 2 (like 1024 instead of 1000) because when you divide by a constant power of 2, it's replaced by a bitshift right operation at compilation time (which is waaaay faster).

My 2 cents: if you need 0.01 accuracy, use floats. Then, and only then, if you struggle with memory and speed limitations try what 94k suggested. But I think you should avoid "premature optimization" and "sacrificing code clarity for the sake of speed or space".

Aarh, I struggle with my English level here, not sure I'm clear.
User avatar
rodot
Site Admin
 
Posts: 1290
Joined: Mon Nov 19, 2012 11:54 pm
Location: France

Re: Ard-Type - an R-Type tribute

Postby annyfm » Tue Jul 29, 2014 10:42 pm

In a production context I would agree with you, but my primary objective with these projects and Gamebuino in general is to learn more about the underlying code so I can apply it to other, bigger projects. Making complete games is secondary (though also nice!)

I'll try to be careful not to let optimisation get in the way of readable code, at least. I know what it's like to wade through reams of unintelligible code - I recently spent six months completely rewriting a contractor's code from scratch cause it was nonsense, total spaghetti...
User avatar
annyfm
 
Posts: 22
Joined: Sat Jul 19, 2014 1:31 pm
Location: London, UK

Re: Ard-Type - an R-Type tribute

Postby ripper121 » Wed Jul 30, 2014 9:04 am

Looks great :)
User avatar
ripper121
 
Posts: 224
Joined: Fri Apr 04, 2014 2:02 pm
Location: Germany

Re: Ard-Type - an R-Type tribute

Postby annyfm » Sun Aug 17, 2014 6:24 am

Just pushed some minor updates - I changed the position/speed calculations to work using integers rather than floats, and fixed a bug with top/left boundaries introduced by that change.

Also note that binaries are now in an orphan bin branch in github, as opposed to master, because I don't like those files polluting diffs...

I haven't done very much with this since I got back from my holiday, but I hope to get stuck in soon!
User avatar
annyfm
 
Posts: 22
Joined: Sat Jul 19, 2014 1:31 pm
Location: London, UK

Previous

Return to Games Gallery

Who is online

Users browsing this forum: No registered users and 25 guests