GP2X Compiling For The Gp2x On Linux?

[reiboul]

So i don't think i'm using floats all i'm doing is integer division, which is OK for what they're supposed to do!

I have done a quick compil with the command you gave me, but got black screen Unfortunately I don't have time yet to play around with that
Thanks for your help and don't hesitate to put much if you find something... I don't know much about compilling

 

[charlieb]

Maybe this thread will help. Poddy found a combination of commands that statically compiles, with SDL, uses float and doesn't do the whole black and white banding thing.

Enjoy!
Charlie

 

[gmiller1018]

The rules for C and C++ are the same for mixed expressions (float(real number) with integer) is evaluated as real.

On the divide front remember that the ARM family does not have a hardware divide instruction (has to be done in software) so try to avoid them in tight loops.

 

[reiboul]

The rules for C and C++ are the same for mixed expressions (float(real number) with integer) is evaluated as real.

On the divide front remember that the ARM family does not have a hardware divide instruction (has to be done in software) so try to avoid them in tight loops.

So far I don't need to use floats, all is declared int but for easier programming I do some divisions, like HEIGHT/2 to indicate middle of the screen, or % for generating random numbers...
I will try to compile my game for the GP2X, I think it will soon be ready for a first release (if I manage to compile it correctly)

Thank you for your link charlieb, I'll try this evening! Hope it will work because so far I haven't achieved to compile something right, it always had display bugs :s I gave up compiling to focus on programming this week...

 

[Blah]

In tight loops, remember its faster to multiply by the reciprocal than to divide. Also loops that count down rather than count up are faster because subtraction is faster than addition. And use the unroll optimization tag "-funroll-loops".

 

[reiboul]

At the moment i'm trying to compile a working version at least then comes optimisation...
That said, the game is already at a playable state on my PC build, just needs a few user-friendly stuff

 

[gmiller1018]

In tight loops, remember its faster to multiply by the reciprocal than to divide. Also loops that count down rather than count up are faster because subtraction is faster than addition. And use the unroll optimization tag "-funroll-loops".

Well addition and subtraction are the same speed but the count down to zero is faster because the comparison to zero just needs to check the condition flags. So to check a variable after a computation to see it it is zero is "free". All comparisons are against zero so:

if (x > 5) ...

Becomes:

if ((x - 5) > 0) ....

Of course this is at the assembly level and I kept the example at the C level. This is true for almost all machines because they keep status flags on computations that indicate zero, negative and positive (the ARM can conditionally set these flags). The ARM only has zero and negative flags (as well as carryand overflow) though so it's micro code need to check 2 flags for positive but it does not appear to effect the instruction timing.

 

[Blah]

I must've been thinking of the AVR microcontrollers, which don't have an ADD instruction.

 

[gmiller1018]

They all sort of merge after a while, or at least they do for me.

 

[ldesnogu]

This is true for almost all machines because they keep status flags on computations that indicate zero, negative and positive (the ARM can conditionally set these flags).

Amongst RISC processors ARM is almost the only one having condition flags. Of course when talking CISC such as x86 they all have condition flags
The problem is that condition flags create dependencies between the instruction that sets them and the one that needs them. IIRC even on recent x86 you have to pay this price: if an instruction needs condition flags, it may stall the pipeline waiting for the flags to be computed.

The ARM only has zero and negative flags (as well as carryand overflow) though so it's micro code need to check 2 flags for positive but it does not appear to effect the instruction timing.

There is no microcode in ARM processors. The fact that an instruction needing condition flags may has to wait is due to the pipeline structure: if instruction i1 sets the flags, and instruction i2 reads the flags, then i2 has to wait for i1 to compute the flags (remember that in a pipelined processor i2 can start just after i1 even though i1 has not completed).

 

[gmiller1018]

The ARM and most RISC machines also have "branch" delay issues as well but I did not know the audience so I tried to keep it simple. I had forgotten the SPARC (etc...) had these issues. I have been doing PPC, ARM and x86 for the last (number suppressed do to being an old fart). I have done a lot of Motorola, RS6000, VAX (I don't want to remember) work and the restrictions tend to merge. I apologize for the error (the micro code one just slipped in) but data dependencies and other issues with the CICS side are very familiar to me. Of course I tried to hedge my statement with "almost" but that "almost" is a lot of machines since there are a lot of RISC machines.

 

[reiboul]

I uploaded sources for my game here

http://membres.lycos.fr/reiboul/tower.rar
(left click to go to download page)

It is almost finished but I haven't managed to compile it, and haven't got much time to find how

If someone succeed in compiling it, please tell me how (and he will be the first to try the game h34r: )

I also need to find better graphics

 

[reiboul]

I started a new thread here
http://www.gp32x.de/board/index.php?showtopic=34800

Its title will certainly attract more poeple