#26950 - getch - Thu Sep 30, 2004 2:06 am
Since scores are going to have to be displayed in decimal format, drawing them will involve lots of divisions.
This probably doesn't make much of a difference unless the score changes frequently.
One way around this would be to make sure scores always increase or decrease by powers of 2. That was you could just use faster bit shifting to display them.
Just how slow are divisions on the GBA? Is there any need for what I just suggested?
#26951 - sajiimori - Thu Sep 30, 2004 2:18 am
#26953 - yaustar - Thu Sep 30, 2004 2:54 am
He has an impressive resume :)
_________________
[Blog] [Portfolio]
#26967 - poslundc - Thu Sep 30, 2004 1:58 pm
Yet he works for an Internet dating website... :P
Dan.
#26971 - jma - Thu Sep 30, 2004 3:25 pm
| poslundc wrote: |
| Yet he works for an Internet dating website... |
Hehe, I'd be careful posting information like that on a "geeky programmer" website -- you might get hit up for free accounts :)
Jeff
_________________
massung@gmail.com
http://www.retrobyte.org
#26972 - poslundc - Thu Sep 30, 2004 3:29 pm
Accounts are already free... http://www.okcupid.com
Only 100% free playah in the biz...
Now if only we made video games as well...
Dan.
#26984 - sgeos - Thu Sep 30, 2004 8:17 pm
Dating sims are evil.
-Brendan
#26988 - Touchstone - Thu Sep 30, 2004 11:29 pm
Well, you'd want the smallest "score" unit to be 100 so using power of two's as scores just won't cut it. Given that the score is no more than 6 figures you wouldn't have more than 6 divisions per frame, and even then you'd only do these divisions when the player increase his scores.
Hmmmmm, if you think about it a little there's another way to do it. A pretty long way around the problem but it could be interesting for more than just int->str converting numbers. Anyways, you could probably restructuring the bits in the "player-score" integer to make it easier for you to int->str convert them. Like so (I'm using shorts for this example): | Code: |
| Bit structure of a 16 bit short: 0cccccbb bbbaaaaa |
All the 'a' bits belong to the least significant digit of your score. Uhm, look at this: | Code: |
The player has score 7194 somethings. Instead of storing this information like we're used to in a short, like this:
00011100 00011010 or 0x1c1a
we store it with each digit of the score in a separate nibble, like so:
01110001 10010100 or 0x7194 |
Now we have the score stored in a way that's easy to int->str convert. Of course, if we just look at the int it won't say 719, like it will after the int->str conversion, but that doesn't matter because the bits are still ordered the same so we can do the regular compares like we're used to, to keep track of high scores and stuff.
Now, if you want to reward the player with a score of 20 for example, the actual short that you are adding to the previous score short looks like this: | Code: |
00000000 00100000 or 0x0020
and when added to the previous score it will look like this:
01110001 10110100 or 0x71b4 |
What you want to do now is to make sure that that no nibble is more than 9, like the second one is now, so you'd have to make sure that every nibble, starting with the lowest one and working your way up, is never more than 9 and if it is, you'll wrap it by ten and add one to the next most significant nibble and so on. If you do this part in assembler using conditional executions of instructions you won't have to do a jump so this might not be that slow. Although it is an odd way of solving it I must say. :-)
I haven't done this my self so I can't tell if it's a good way of solving your problem but there's one thing that would stop me from using this method and that's the fact that the scores the player is rewarded cannot be more than 7 per digit (16 - 9) because that would make one digit interfere with the next most significant nibble. And if you are often increasing the score this might be slower since you'd have to make sure it doesn't wrap. Would you could do to prevent this is give each digit a couple of extra bits, that way it won't interfere with the next significant digit as soon.
In conclusion, there are ways to avoid divisions, and I'm a bit of a retard thank you very much.
_________________
You can't beat our meat
#26989 - poslundc - Thu Sep 30, 2004 11:37 pm
You are describing binary coded decimal. Someone once posted a routine on here involving a LUT for fast conversion from regular ints to BCD. It seemed like an interesting/novel approach, although I don't think there's probably a tremendous speed difference between it and the shift-add method used in posprintf.
Dan.
#26991 - sgeos - Fri Oct 01, 2004 12:45 am
siprintf()ing to a buffer will not be a bottleneck in your program. How often are you going to do it? Every time the score changes. Once every frame is the worst case scenario.
Programmer time is often more valuable than execution speed.
-Brendan