GP2X Arm And Thumb. Which To Use?

[Insanemal]

this is the way i envisioned it being done on the gp2x... as it helps to maxamise usage of both cpus but still keep them semi in sync..

im still looking into things.. as all my coding experence has been at the object orentated level.. and not the nuts and bolts level but im learning

 

[no_skill]

A better bet would be something like -

CORE A
Runs the game loop, physics, AI, input etc. It is basically everything apart from the graphics. It updates the positions of the sprites (but doesn't render them) and changes render values (such as alpha, tints, rotations etc)

CORE B
Runs as fast as it can actually rendering the scene independent of CORE A. So it takes the sprite information, does the blitting, the manipulation, the blending and outputs it to the screen. Maybe it does the sound too.

​

of course this is smart and efficient. but not efficient to port. i think few will take the challenge to split a complete game (ie: quake) in a seperate render and game logic thread.

i think dual core is great if you develop directly for it, but sucks for porting. and as the gp2x is sold as a "play your favorite ports and emulators" device i wonder why they throw sticks in our way (i guess the term sounds wrong, but in german it's right).

and floating point capable processors would've saved us an additional ammount of pain.

 

[Insanemal]

well from memory games like quake are very suited to this kind of thing.. cus they are modular... hell i rember reading an interview with MR.ID himself saying he once coded a voxel render for q1 cus he was bored.. quake is a bad example as its probalby the easest to port to this kind of setup because you would simply recode the render module and plug that in hey presto it uses the dual core.. ok hey presto is a little easy but its easyer than say a snes emu that was coded for one cpu and doesnt have the same modular design.. in that case quite a large recode could be on the cards...
tho mulit-threaded apps would port with ease..