GP2X Are These Numbers Correct?


Dingo_aus

Member
Joined
Jan 4, 2006
Messages
133
Age
41
Location
Brisbane, Australia
Website
www.users.on.net
I don't have a GP2X yet to play with but was just considering the numbers, have I got it right?

Framebuffer is 320x240x16 == 1228800 bits (153600 bytes)

x2 for double buffering

Assuming one core (presumably the 920T with it's 16kb) is handling just the graphics and assuming the best case scenario of 1.1 MIPS / MHz we have just 220000000 instructions per second to play with.

@ 20 FPS....@ 320x240

..... 220000000 / (20 * 76800) == ~143 instructions per pixel.

Now the best idea of a fixed point devide for the ARM9 is 20-140 so that isn't much help :(

Presuming 143 is correct, is that enough for OGL @ 20 FPS?

Thanks,

Dingo_aus

I know I haven't allowed for overhead but didn't know what to allocate.
 
153600 is indeed correct for the fb, but don't forget that the frame buffers are in uncached ram.
 
I don't have a GP2X yet to play with but was just considering the numbers, have I got it right?

Framebuffer is 320x240x16 == 1228800 bits (153600 bytes)

x2 for double buffering

Assuming one core (presumably the 920T with it's 16kb) is handling just the graphics and assuming the best case scenario of 1.1 MIPS / MHz we have just 220000000 instructions per second to play with.

@ 20 FPS....@ 320x240

..... 220000000 / (20 * 76800) == ~143 instructions per pixel.

Now the best idea of a fixed point devide for the ARM9 is 20-140 so that isn't much help :(

Presuming 143 is correct, is that enough for OGL @ 20 FPS?

20fps of what? Blinear filtered pixels with z-buffer and alphablending at depth complexity of 3? Then no. For flat shaded triangles filling half of screen - why not?

Try mesa on PC and divide its perfomance by factor of 10. You will get an idea.

OpenGL is too general and bulky to get any realtime rendering from gp2x. If gp2x had an 3d accelerator then it'd be another story but it hasn't. The best bet is custom made 3d software engine. Then it would be possible to get decent realtime 3d from gp2x. The quake1 port already is pretty good and Duke3d is even better (thought some might say a "2.5d" doesn't count).
 
Last edited by a moderator:
Well, all we need is for someone to find out how the DS's software rendering works, then BOOM, the 2x is almost 4x the processor speed (Just on 1 processor), let alone the second one. If only :D
 
The only problem is that the DS has the help of it's co-processors (namely the geometry engine and rasterizer), so floating point and matrix calculations can be done in hardware, along with other stuff very useful for 3D games.
 
The only problem is that the DS has the help of it's co-processors (namely the geometry engine and rasterizer), so floating point and matrix calculations can be done in hardware, along with other stuff very useful for 3D games.

What do you think about using alternate frame rendering? I have in a mind situation where first cpu is rendering one frame and the second is working on next. Once one of them finish it takes another one waiting in a queue. This way cores utilisation should be close to full with drawback of added latency of one frame. But with +20fps it should not be too visible to bother.

EDIT: something to add...

Why limit rendering options just to textured triangles?

For an example we have other techniques like voxels and raycasting. The voxels were used to good effect in Commanche1 and this game wasn't that bad on 386DX/40. The more advanced raycasting engines had theirs fame in Duke3D, ShadowWarrior and Blood. Knowing that gp2x has many times of resources of 486 era PC it should be possible to make even more advanced version of those.

Yeah and why sprites are considered so "bad"? With 64MB of ram in the gp2x (and possible compresion) they could be more impressive than before. And after all the gp2x's controls aren't so suited to full 3d games anyway. I can play the Duke3D port very well on this machine but "full 3d" Quake it's not so comfortable.
 
Last edited by a moderator:
Good points. Furthermore though, 3d isn't just about First Person Shooters. Lots of other genres that would benefit from 3D.

With the idea of dual core utilisation for 3d, what is left for game logic and sound etc? This is always a prob.

Also, the 920T has the MMU and therefore must incur a greater overhead than the 940T. ie they can't be symmetrical, you'd have to limit both of them to the fastest that the slowest could go. well sort of.
 
Back
Top