Hi,
I am starting to make video games with a group of programmers and was considering making games for psp and ds.
The sites I go to show psp has a polygons per second of 33 million, but what I would like to know is: how much is the average real amount of polygons that is allowed on screen at each frame and with special effects and textures applyed? It is obvious we can't put 30 million polygons on the screen at the same time.
Currently we are just programming the games for pc, but need to take into consideration, how much quality we can have when we port it over.
Thanks
how much polygons is psp capable of?
That number of polygons is the amount per second, but your game will run at 60 frames per second. You'll be looking at 550,000 polygons per frame. Now, this with without texturing, and actually, these aren't polygons either. They are lines all connected together using the GU_LINE_STRIP method actually. Lines do count as polygons (I think the lines' thickness are two polygons, or quads made from two vertices).
Now, on a realistic level, I've been able to render +20,000 3D textured vertices a frame without adding in all my optimization code for bsp tree support, or octree support. Actually, I've had scenes up to 230,000 vertices with texture, and movement all working at 56 fps. Without mesh to sphere collision detection on, and without lighting and and blitting on. All texturing was 32 bit on 32 bit framebuffers, and they weren't even stored in vram either. I eventually found out the memory address range for the vram, and added that feature in after this test from like last April.
I was working on an RTS game when I did this test, and I loaded up a 1000 vertex church model. I then drew 81 of them in a 9x9 grid in my scene. That's 81,000 vertices with 81 calls to sceGumLoadIdentity(), and 81 calls to sceGumTranslate(). I did use the PSPs culling methods with sceGuBeginObject() and sceGuEndObject() methods to stop the rendering of objects outside the viewport, but still, it worked well, and I still managed to get about a dozen or so churches rendering. I also didn't have hidden surface removal added in either. I still need to add that. My camera was free to rotate itself around on its y-axis and move around freely though to explore the scene.
Now, keep in mind that this was still at well over 60 frames per second. I think you are well capable of doing more. Especially since these are benchmark results from months ago back before I added in other new drawing optimizations.
In a long story short-- you can do a lot with the PSP, and there's a LOT of potencial in it. You can do a lot on the DS too although I've never worked with it, but porting it all over won't be a big deal, and you'll probably keep a lot of your quality too. There's three major exceptions I would like to warn you of though. First off, there is no shader support for the PSP. All you shader operations can still be done, but in software that you write. Anti-aisling is the second one. It kinda sucks on the PSP. The third one is the PSP's clipping software. It sucks hard, and can be a pain to work with. I haven't found any good ways to deal this this as of yet.
Now, on a realistic level, I've been able to render +20,000 3D textured vertices a frame without adding in all my optimization code for bsp tree support, or octree support. Actually, I've had scenes up to 230,000 vertices with texture, and movement all working at 56 fps. Without mesh to sphere collision detection on, and without lighting and and blitting on. All texturing was 32 bit on 32 bit framebuffers, and they weren't even stored in vram either. I eventually found out the memory address range for the vram, and added that feature in after this test from like last April.
I was working on an RTS game when I did this test, and I loaded up a 1000 vertex church model. I then drew 81 of them in a 9x9 grid in my scene. That's 81,000 vertices with 81 calls to sceGumLoadIdentity(), and 81 calls to sceGumTranslate(). I did use the PSPs culling methods with sceGuBeginObject() and sceGuEndObject() methods to stop the rendering of objects outside the viewport, but still, it worked well, and I still managed to get about a dozen or so churches rendering. I also didn't have hidden surface removal added in either. I still need to add that. My camera was free to rotate itself around on its y-axis and move around freely though to explore the scene.
Now, keep in mind that this was still at well over 60 frames per second. I think you are well capable of doing more. Especially since these are benchmark results from months ago back before I added in other new drawing optimizations.
In a long story short-- you can do a lot with the PSP, and there's a LOT of potencial in it. You can do a lot on the DS too although I've never worked with it, but porting it all over won't be a big deal, and you'll probably keep a lot of your quality too. There's three major exceptions I would like to warn you of though. First off, there is no shader support for the PSP. All you shader operations can still be done, but in software that you write. Anti-aisling is the second one. It kinda sucks on the PSP. The third one is the PSP's clipping software. It sucks hard, and can be a pain to work with. I haven't found any good ways to deal this this as of yet.