Zeenginegp2x Preview


Un-be-freaking-leavable.

Excellent Demo. It is smarter to demo for consoles as their hardware is frozen, PC's keep changing and so much hardware is out there that it is hard to optimize because no-one is fully compliant.

I think with that many polys at that speed all we need is a way to texture and we will be gold.

It would be interesting to see what comes of this, have you posted this in the Dev forum topic under 3D?



He was likely using fbGrab, Here, this one has a German? frontend with selectable timeouts from 5-120 seconds

and Here, this is the original
 
Just tried that demo for the PC you had up, is that all Processor or is the 3D card doing anything?

It is amazing to say the least, that is a fairly lame Porsche however, it should display wonderfully on the GP2X but it is terrible for the PC, especially considering the quality of the other models in that demo.

Have you seen the Porsche techdemo from nVidia? The Rabbit is the same quality as that Porsche, I am sure you could do it. The porsche in theirs was around 120,000 polys if I recall correctly, but you could for sure run their high-poly wheel from the Porsche on the GP2X (trust me, it would be worth it)

Quick question, can I drop .3do files in the directory and veiw them?

Also, does, or will the GP2X demo support custom ones, assuming the clipping bug you mentioned doesn't crash the program, or have you put the polys into the executible itself. I see, inside the executable then.

Very very cool though, it will be a nice techdemo to show off to PSPers and the DS fans (DS fans seem to be more knowledgable on the whole and smarter in a general fashion, they would likely appreciate this techdemo more. Not to say there aren't smart and educated PSP owners, but due to its status symbol quality and widespread use they are the minority.)

Have you tried it on the TV-Out cable? The Yeti demo performed perfectly on the TV so I am going to bet your demo will too if it is just straight SDL output and not left-over GP32 screen optimizations like the emulators.

Could you code a TV-Res one specially so we can see what effect the differing amount of pixels rendered has on the speed of the program? Maybe just change the output size to something larger and just run it.
 
I don't want to sound too skeptical but this demo may not mean that complex games are possible. For one there is no game code there. No AI, no enemies moving around etc. Then there is the fact that these objects are small only taking up part of the screen. Now try zooming in so a polygon fills the screen or go in something. The polygon fill rate will tank when you do that. Good luck though, it is a cool demo at least.
 
Would be nice to have an accessible 3d lib for the 2X. There was some work a while back on SDLgl (?spelling?) and TinyGL, not sure how they ended up though.
 
I don't want to sound too skeptical but this demo may not mean that complex games are possible. For one there is no game code there. No AI, no enemies moving around etc. Then there is the fact that these objects are small only taking up part of the screen. Now try zooming in so a polygon fills the screen or go in something. The polygon fill rate will tank when you do that. Good luck though, it is a cool demo at least.
Clearly you wouldn't be able to have such high-quality images in a game, but it should be able to manage at least the quality of Starwing on the SNES.
 
Last edited by a moderator:
I don't want to sound too skeptical but this demo may not mean that complex games are possible. For one there is no game code there. No AI, no enemies moving around etc. Then there is the fact that these objects are small only taking up part of the screen. Now try zooming in so a polygon fills the screen or go in something. The polygon fill rate will tank when you do that. Good luck though, it is a cool demo at least.
Clearly you wouldn't be able to have such high-quality images in a game, but it should be able to manage at least the quality of Starwing on the SNES.
Come on guys, does anyone remember the quality of the top-of-the line games we were playing on the 120mhz pentiums with 16MB of ram, and not even high-speed SDRAM like this console?

I don't mean technologically advanced games by any means, but that doesn't mean I am not expecting at least PSX quality games out of this unit.

A Metal Gear Solid type game, or a port of Need For Speed:Hot Pursuit (NFS 3) would be plenty for a 320x240 pixel screen, enjoyable and quite playable.

We aren't dealing with very many pixels here, I am sure we can cope with a few polygons and some rudimentary AI and physics.

Also note that he basically just compiled this for the GP2X, not optimised. A "preview" of his engine, as the title of this post says.

I agree that we won't be seeing anything completely revolutionary with graphics for a PC or the last generation of consoles. But I am sure we can best the PSX by a long shot with our far superior hardware.

In fact the small screen is a bonus because the games will look all that much better, I know the PSX games I tried looked great, no stretching or tearing or pixelating or "jumpy" polys or textures were noticed by me like you could see on a PC emulator at 640x480 or 800x600.

I am optimistic that we will see some good games, once the architecture is better known and optimisations are in place it can be very good.

Look at what Gran Turismo 2 accomplished on the console that started life as the SNES CD add-on, only to be turned into a full-fledged, albeit weak, console.

I would expect to see games with graphics and level sizes and textures far superior to the PSX, and with the power for AI and physics a bit beyond that.
 
Last edited by a moderator:
The PSX had built-in 3-D hardware acceleration that is quite possibly beyond (or at least close to the limit of) what we'll be able to get out of the gp2x. The specs I've seen for the PSX are 360,000 polygons per second.

I agree that we can put 3D to good use on the gp2x though!
 
screenshot_cow.png


This is a preview of my 3d engine ported from GP32 to my new GP2X. I originally started coding it for a GP32 demo that is not yet released (maybe inside July ;P) and decided to port it in my brand new GP2X to check the speed improvement (it was 2X ;). Still, it can be optimized much more I believe. This is just a quite small showcase of the true GP2X power imho. Enjoy!

Links:

http://www.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,38,1619
http://www.freewebs.com/optimus6128/ZeEngineGP2X.htm

p.s. More to come in the near future B)


Is there a way that you could add controls to zoom in and out plus rotate it manually with the stick? Also you could play a MOD file in the background. Kind of like an interactive scene demo, would be cool.
 
Last edited by a moderator:
Well ... if it has controls and plays music like this other movie I made, yeah, that'd be cool!
http://www.youtube.com/watch?v=ZEgaQeEYL04

Here's the demo I made where you can't really hear the music:
http://www.youtube.com/watch?v=Rua0Q7VEqSc


Oh - just to clarify - I'm not an Optimus or ZeEngine fanboi, I'm a fanboi of the community who performs random contributions. Ask Dzz ;) He was surprised, yet happily so.
 
Last edited by a moderator:
Well ... if it has controls and plays music like this other movie I made, yeah, that'd be cool!
http://www.youtube.com/watch?v=ZEgaQeEYL04

Here's the demo I made where you can't really hear the music:
http://www.youtube.com/watch?v=Rua0Q7VEqSc


Oh - just to clarify - I'm not an Optimus or ZeEngine fanboi, I'm a fanboi of the community who performs random contributions. Ask Dzz ;) He was surprised, yet happily so.

Wow, thanks! It's so great to see it in YouTube. This motivates me more to continue working on the engine.

As for music, controls requests, etc. Maybe in a next demo, engine release, etc.
 
Last edited by a moderator:
Just tried that demo for the PC you had up, is that all Processor or is the 3D card doing anything?

Yep, pure software rendering :)

Quick question, can I drop .3do files in the directory and veiw them?

Also, does, or will the GP2X demo support custom ones, assuming the clipping bug you mentioned doesn't crash the program, or have you put the polys into the executible itself. I see, inside the executable then.

No, not yet. The GP example has them inside the executable, yes (nicer than having several files scattered around your SD ;)). Actually 3do is a simple format I did for the 3d objects in my demos. I had also written some messy codes to read 3DS or PLG and store some basic object data a long time ago, that I reused now just to convert the objects in my format. The funny thing is that these codes were written in quickbasic(yes!), and so I'll have to port them in C (easy for the PLG, annoying for 3DS except if I just use 3dslib) and make an option for the user/programmer to load from those more popular formats. Ok, another thing to do for the next release..

Have you tried it on the TV-Out cable? The Yeti demo performed perfectly on the TV so I am going to bet your demo will too if it is just straight SDL output and not left-over GP32 screen optimizations like the emulators.

Could you code a TV-Res one specially so we can see what effect the differing amount of pixels rendered has on the speed of the program? Maybe just change the output size to something larger and just run it.

I'd like to check the TV-Out mode. No cable for that came with my GP2X. Where can I order this?
 
Last edited by a moderator:
Just tried that demo for the PC you had up, is that all Processor or is the 3D card doing anything?

Yep, pure software rendering :)

Have you tried it on the TV-Out cable? The Yeti demo performed perfectly on the TV so I am going to bet your demo will too if it is just straight SDL output and not left-over GP32 screen optimizations like the emulators.

Could you code a TV-Res one specially so we can see what effect the differing amount of pixels rendered has on the speed of the program? Maybe just change the output size to something larger and just run it.

I'd like to check the TV-Out mode. No cable for that came with my GP2X. Where can I order this?
I think anywhere, I ordered mine with my MK2 from Play-Asia.com (only $205 altogether when I used the $25 1-4 day Shipping :) :)).

GP32z.com in the US, GP2X.co.uk in the UK, Evildragon's German webshop (.de) I think they all stock it.

I will try it on my TV/cable when I get it for sure.

Pure software? You sir are a genius :). I think that is very impressive, How many polys do you think the GP2X can take like that?

And I don't know if you can do Squidge's MMU hack or if you already did.
 
Last edited by a moderator:
Pure software? You sir are a genius :). I think that is very impressive, How many polys do you think the GP2X can take like that?

And I don't know if you can do Squidge's MMU hack or if you already did.

Well, it depends on the size and shading of the polygons. The statue has around 5000 polygons but less are drawn according to the view. And it goes 21 fps at it's worst, in front of the face and envmapped. With simple gouraud or flat it's a bit faster (25-35). (that could be almost 150000 polys/sec according those specs). Oh btw, the cube is close to the screen and does only 90fps with 6 big triangles on yer face. Would that mean my engine only does 90*6 = 540 polys/sec? LOL! (That LOL also goes for those "xxxxxx polys/sec" wow-specs announced on consoles I cannot relate to ;P)

I believe that the triangle rasterizing routines can be optimized quite more if rewritten from scratch. Right now I am writting shorts for pixels, but I've read (and tried succesfully in some of my 2d code) that I should be putting one short to a variable, ORing it with the next one that I shift 16bits to the left first, and only write the final 32bit int to the screen. This way I avoid the 16bit writes which might be slower. It worked well a 2d plasma effect on my GP32 that went from 100fps to 160!!! But for the polygon routine it's harder, I have to rewrite the rasterizer from scratch and split it in diferrent cases. Too much work but I know I can do it if I find the time. Especially the flat polygons could be optimized a lot, maybe even using the blitter for them.

And yet I haven't tried using the second coprocessor or the MMU hack. For the later, I tried to compile it yesterday but I have some problems (probably of DevCPP, can't understand the ASM command, wtf?), but when I solve these problems and see how this MMU hack works, I'll give it a check. I am not sure if I'll get a speed gain, I am not using the upper 32MB memory yet, though some people say that maybe I'd gain some speed because the framebuffer where I write in software is located in that memory area. I'll have to test this first and then see the improvement. However the biggest improvement might happen if I rewrite and optimize that rasterizer code more imho, in the way I explained.
 
Last edited by a moderator:
smooth! what about something more complicated that would end up around 15 fps so we can see how good it can get while we can see how far it can go?
 
Back
Top