What fps could achieved at maximum ?
-
- Posts: 87
- Joined: Thu Oct 01, 2009 8:43 pm
What fps could achieved at maximum ?
Hi there,
I've done a little animation on my PSP with simple graphics. Putting pixel direct to vRam-Buffer and displaing them on the screen using sceDisplaySetFrameBuf(...). However, I've started to investigate on performance improvements. But now I would like ask: what is the target ? I've read through this great forum and there are lots of hints to improve performance, but what fps is the PSP possible to reach.
I've started with approx 5 fps and have improved now to approx 16 fps. Is that in your eyes still slow ? What could be a reachable fps value for simple graphics or GU ? Is above 20fps possible ? I know it depends and drawing just one pixel and flipping the screen may be the fastest but I guess this would never be a usefull app or game, wouldn't it ? ;o)
Regards
AnMaBaGiMa
I've done a little animation on my PSP with simple graphics. Putting pixel direct to vRam-Buffer and displaing them on the screen using sceDisplaySetFrameBuf(...). However, I've started to investigate on performance improvements. But now I would like ask: what is the target ? I've read through this great forum and there are lots of hints to improve performance, but what fps is the PSP possible to reach.
I've started with approx 5 fps and have improved now to approx 16 fps. Is that in your eyes still slow ? What could be a reachable fps value for simple graphics or GU ? Is above 20fps possible ? I know it depends and drawing just one pixel and flipping the screen may be the fastest but I guess this would never be a usefull app or game, wouldn't it ? ;o)
Regards
AnMaBaGiMa
There's no such thing as max FPS. Although I doubt the eye will find any difference above 70 FPS. Anyway, no use having a FPS higher than screen vertical refresh rate, because the frames will not be drawn...
Old films in cinema ran at 24 FPS, that's why you see some flicker in old movies. Standard PAL TV runs at 50 Hz vertical refresh and NTSC at 60 Hz vertical refresh. Normal house lights use alternate current at 50 Hz, and I guess nobody sees that flicker...
Old films in cinema ran at 24 FPS, that's why you see some flicker in old movies. Standard PAL TV runs at 50 Hz vertical refresh and NTSC at 60 Hz vertical refresh. Normal house lights use alternate current at 50 Hz, and I guess nobody sees that flicker...
The Incredible Bill Gates wrote:The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers.
-
- Posts: 107
- Joined: Sat Jan 13, 2007 11:50 am
-
- Posts: 87
- Joined: Thu Oct 01, 2009 8:43 pm
the refresh rate of the psps display is 60Hz
Code: Select all
int main(){
SetupCallbacks();
makeNiceGame();
sceKernelExitGame();
}
-
- Posts: 87
- Joined: Thu Oct 01, 2009 8:43 pm
Hi,
Regards,
AnMaBaGiMa
Would this mean - if you make the assumption that you need some time to calculate and render some stuff - it should be possible to achieve 50fps and above ? I would curently say:I'cant imagine ;o) Or had someone already reached this ?the refresh rate of the psps display is 60Hz
Regards,
AnMaBaGiMa
-
- Posts: 87
- Joined: Thu Oct 01, 2009 8:43 pm
Look at any example with a fps counter. you will see that most of them can reach a fps far more than 60FPS. When you use sceDisploayWaifVBlancStart() you practically limits the FPS to 60 so you don't have any flickering.anmabagima wrote:Hi,Would this mean - if you make the assumption that you need some time to calculate and render some stuff - it should be possible to achieve 50fps and above ? I would curently say:I'cant imagine ;o) Or had someone already reached this ?the refresh rate of the psps display is 60Hz
Regards,
AnMaBaGiMa
When you install cwcheat and run a game on your psp you can see the FPS of the game.
Code: Select all
int main(){
SetupCallbacks();
makeNiceGame();
sceKernelExitGame();
}
This topic is useless.
the psp Screen refreshes at 60fps, so no need to run your render thread faster than that. However the human eye is real time. But there is a "delay" in contrast changes, so depending upon the contrast in the rendered image and the fps, it can seem smooth at 10fps and jerky at 30fps. It also depends upon the rate of speed objects in the scene are moving.
Ok now, about how fast the psp can render, is up to a few things, Buffer bit depth, size and quality of textures, size and count of vertices, etc. (now this is assuming pure rendering and 0 cpu computations) The fps can easily exceed 1500fps with a simple colored triangle. But you will only see 60fps due to the screen, but also now that the triangle is no moving, you dont even need to update the scene. So 0.00000000000000001fps would be just fine.
FPS is a relative term. I cap my rendering to 30fps, to allow more cpu time for heavier game calculations and such. I have no problems with jerky graphics or anything. Now I can say the psp is quite powerfull. Ill show an example
This is a 952 triangle model + a 350 triangle smaller model, the 952 uses a 128x128 palletted texture and the 350 uses a 64x64 palleted glow source texture. This scene is a 3 pass render. First pass is no lights with the low poly to a 240x136 (256x256) 16bit texture with the glow source. Then this texture is rendered to another Identical texture using a 5x5 convolution. Then the frambuffer is returned to the screen, where the fully poly model is rendered with its 128x128 texture, then the convoluted texture is rendered on top using an additive blend.
So the aforementioned processes are quite GPU intensive, yet I am pulling 260 fps.
Here is a bit simplerer process
I split the screen into 4 regions and render each region 2 times as big (super scaling) to an offscreen texture (32bit 512x512) then In turn I down scale each texture to its quarter sceen size using linear filtering, and viola 4xAA at 354fps (sorry the fps is not in the screen, this sample has it printed to stdout so I can read it in psplink's pspsh)
Now the question is, how good do you write your code. I answer, Well actually it has tons of room for optimization. For example I am not using the VFPU for my math. I am not double buffering my display lists. I am using full 32bit vertexes, uv's, and normals, I could be using 16bit, or 8bit even. So the psp could push these scenes even faster TBH.
I have a few galleries should people be interested, these are on the psp of course.
http://thayer-remodeling.com/stuff/gearWorks/
http://thayer-remodeling.com/stuff/zombies/
http://thayer-remodeling.com/stuff/mp3vis/
http://thayer-remodeling.com/stuff/XMBFX/
And then on the PC I just started writing a ray tracer
http://thayer-remodeling.com/stuff/rayTrace/
the psp Screen refreshes at 60fps, so no need to run your render thread faster than that. However the human eye is real time. But there is a "delay" in contrast changes, so depending upon the contrast in the rendered image and the fps, it can seem smooth at 10fps and jerky at 30fps. It also depends upon the rate of speed objects in the scene are moving.
Ok now, about how fast the psp can render, is up to a few things, Buffer bit depth, size and quality of textures, size and count of vertices, etc. (now this is assuming pure rendering and 0 cpu computations) The fps can easily exceed 1500fps with a simple colored triangle. But you will only see 60fps due to the screen, but also now that the triangle is no moving, you dont even need to update the scene. So 0.00000000000000001fps would be just fine.
FPS is a relative term. I cap my rendering to 30fps, to allow more cpu time for heavier game calculations and such. I have no problems with jerky graphics or anything. Now I can say the psp is quite powerfull. Ill show an example
This is a 952 triangle model + a 350 triangle smaller model, the 952 uses a 128x128 palletted texture and the 350 uses a 64x64 palleted glow source texture. This scene is a 3 pass render. First pass is no lights with the low poly to a 240x136 (256x256) 16bit texture with the glow source. Then this texture is rendered to another Identical texture using a 5x5 convolution. Then the frambuffer is returned to the screen, where the fully poly model is rendered with its 128x128 texture, then the convoluted texture is rendered on top using an additive blend.
So the aforementioned processes are quite GPU intensive, yet I am pulling 260 fps.
Here is a bit simplerer process
I split the screen into 4 regions and render each region 2 times as big (super scaling) to an offscreen texture (32bit 512x512) then In turn I down scale each texture to its quarter sceen size using linear filtering, and viola 4xAA at 354fps (sorry the fps is not in the screen, this sample has it printed to stdout so I can read it in psplink's pspsh)
Now the question is, how good do you write your code. I answer, Well actually it has tons of room for optimization. For example I am not using the VFPU for my math. I am not double buffering my display lists. I am using full 32bit vertexes, uv's, and normals, I could be using 16bit, or 8bit even. So the psp could push these scenes even faster TBH.
I have a few galleries should people be interested, these are on the psp of course.
http://thayer-remodeling.com/stuff/gearWorks/
http://thayer-remodeling.com/stuff/zombies/
http://thayer-remodeling.com/stuff/mp3vis/
http://thayer-remodeling.com/stuff/XMBFX/
And then on the PC I just started writing a ray tracer
http://thayer-remodeling.com/stuff/rayTrace/
Code: Select all
.øOº'ºOø.
'ºOo.oOº'
-
- Posts: 87
- Joined: Thu Oct 01, 2009 8:43 pm
Hi,
thanks very much for this post and this is not useless for me. I've started to write a voxelengine for my PSP and this would write pixel mor or less direct to the vram buffer. I have read a lot of things that PSP is not optimated to run lots of code within loops etc. manipulating pixelsl, but have a very powerfull 3d Grafik Engine.
I got the impression (apart from FPU/Assembler) I've more or less optimized as best as I could, but wanted to know what is a good target to reach, with respect to fps.
If I read your post this was very helpfull as it seem to me I should give up my voxel engine and generate my terrains out of polygones as this seem to be much faster...
Thanks a lot for the post. Your images are no links..but I try to access them...
Regards
AnMaBaGiMa
thanks very much for this post and this is not useless for me. I've started to write a voxelengine for my PSP and this would write pixel mor or less direct to the vram buffer. I have read a lot of things that PSP is not optimated to run lots of code within loops etc. manipulating pixelsl, but have a very powerfull 3d Grafik Engine.
I got the impression (apart from FPU/Assembler) I've more or less optimized as best as I could, but wanted to know what is a good target to reach, with respect to fps.
If I read your post this was very helpfull as it seem to me I should give up my voxel engine and generate my terrains out of polygones as this seem to be much faster...
Thanks a lot for the post. Your images are no links..but I try to access them...
Regards
AnMaBaGiMa
You can use timers to keep things moving at the right speed even when the framerate drops or varies. This has the added advantage of letting you express times in your program in "real" units - seconds, minutes, hours - instead of counting frames. For example, I'm working on a 3D model viewer; with a light (in triangles) model is loaded, it can run 60fps easily, but when a heavy model is loaded, the framerate may drop to 20-30fps. Since the translation and rotation speeds are based on a timer, though, it doesn't look like it's running any slower.
I believe I stated that, however 60fps for a model and a light is slow :/ You may want to check your code. My model is in triangles as well. I recently optimized it to use triangle strips and 8bit uv's and 16bit normals, now I get 300+ fps on the glow/bloom effect render. mind you thats almost 2000 triangles, plus offscreen textures and a 5x5 convolution (and lighting of course)
Code: Select all
.øOº'ºOø.
'ºOo.oOº'
-
- Posts: 87
- Joined: Thu Oct 01, 2009 8:43 pm
Hi,
you are all talking only about 3D stuff. Has anyone ever tried to do just an "old style" 2D graphic application /game and some experience with possible fps ? Or does it make complete now sense to think about this kind of app/game on the PSP as it is completely prepared for 3D ?
Thanks.
Regards
AnMaBaGiMa
you are all talking only about 3D stuff. Has anyone ever tried to do just an "old style" 2D graphic application /game and some experience with possible fps ? Or does it make complete now sense to think about this kind of app/game on the PSP as it is completely prepared for 3D ?
Thanks.
Regards
AnMaBaGiMa
2D on the psp is 3D minus matrices/ the z-axis. Or orthographic matrices. Also since the size of meshes is usually a lot smaller it runs even faster, 16bit palletted fullscreen tilemaps 32x32 tiles can easily be rendered over 1000 fps, you just need to cull offscreen tiles, buildup a single mesh for a single call to sceGuDrawArrays, put the tilesheet in vram, and swizzle it. You could even strip blit it if you choose to use the GPU's texture cache. I think your problem is you are trying to work to primitively, using a perpixel rendering method, when the psp already ahs a nice gpu, and lib to go along with it, the GU is very similar to OpenGL, but also has some lower level control, there is also an OpenGL port, which is a bit slower than the GU, but gets the job done.
Code: Select all
.øOº'ºOø.
'ºOo.oOº'
It's limited to 60fps by the vsync; you said it yourself that anything faster is unnecessary. I don't know precisely how many triangles are used (I can find out if you like), but I don't really have the option of using triangle strips because the models are loaded from their original format which stores them as raw triangles. Converting them at run-time would not be much fun. Anyway, 30-60fps is "good enough," and that's all I need for a simple model viewer. When I take the next step toward animating them and using them in a game, I'll worry about optimizing things, maybe convert the models to a friendlier format.a_noob wrote:I believe I stated that, however 60fps for a model and a light is slow :/ You may want to check your code. My model is in triangles as well. I recently optimized it to use triangle strips and 8bit uv's and 16bit normals, now I get 300+ fps on the glow/bloom effect render. mind you thats almost 2000 triangles, plus offscreen textures and a 5x5 convolution (and lighting of course)
P.S. Actually, there is no light, just ambient lighting. I was lazy. :)
@anmabagima: I agree with a_noob: you shouldn't use per-pixel rendering unless you absolutely have to. You can do that on a lightning-fast multicore PC with gigabytes of RAM and it will still be slow. Conversely, most of the 2D homebrew games I've played run very fast and smooth despite having hundreds - sometimes thousands - of sprites on-screen, even the ones written in Lua, because they take full advantage of the GPU. If you don't want to write GU code from scratch, just pick up a library like PGE or OSLib, which both have excellent 2D graphics functions.
Just another quick tip, dont use sceCtrlReadBufferPositive, use sceCtrlPeekBufferPositive (prior caps thread to 60fps) also dont wait for a vblank, rather just setup another thread, or a timer callback that only renders at the desired framerate, that way you dont stall the cpu for stupid things such as a vblank. Then you can continue to max out the psp's true potential ;)
Code: Select all
.øOº'ºOø.
'ºOo.oOº'
-
- Posts: 87
- Joined: Thu Oct 01, 2009 8:43 pm
Hi thanks for this tips.
@CriptychI'm trying to do landscape. However, using triangles for this will end up in a very huge amount of them which I feel the PSP is nat able to hanle..I tried with 127*127*2 triangles and the PSP is not able to handle them....Therefor I decided to go with a VoxelEngine to render the landscape. But looking forward to further increase my fps. I hope some time I will reach 30fps to have enough time to do some furter calculations, which do hava nothing to do with rendering itself.
Thanks.
@CriptychI'm trying to do landscape. However, using triangles for this will end up in a very huge amount of them which I feel the PSP is nat able to hanle..I tried with 127*127*2 triangles and the PSP is not able to handle them....Therefor I decided to go with a VoxelEngine to render the landscape. But looking forward to further increase my fps. I hope some time I will reach 30fps to have enough time to do some furter calculations, which do hava nothing to do with rendering itself.
Thanks.
The psp can handle that, infact I believe I rendered a 256x256 height map using a tri strips so, 256x256x2 vertices, at about 100fps, mind you this was all unoptimized. Surely you should give us more info on what you are trying to render, whatever it is doing it via the cpu is pointless, when the psp has a gpu, that is plenty capable. Also, you will want to cull offscreen triangles, there is no reason to pass them to the GPU, infact the GPU even includes a offscreen culling function, sceGuBeginObject, and then the matrix aware version, sceGumBeginObject
Code: Select all
.øOº'ºOø.
'ºOo.oOº'
-
- Posts: 87
- Joined: Thu Oct 01, 2009 8:43 pm
Well I suggest using triangle strips. You save ALOT of mem, because then its 1 vert per triangle, rather than 3. Also, I dont think you want voxels, that is just a 3D pixel, aka a cube. When a heightmap is just a plane. I do have a heightmap sample, if you should need it, the code is quite old and unoptimized, but im sure you could get the idea from it.
Code: Select all
.øOº'ºOø.
'ºOo.oOº'
-
- Posts: 87
- Joined: Thu Oct 01, 2009 8:43 pm
Hi,
thanks a lot for your proposal. I've tried it on my own and get 128x128 height map with triangle strips to work and its really fast. Wow, it's really amazing and impressive. It's not only faster it looks pretty much better ;o).. Now I will start to optimize my engine a bit. and enable the viewer to "fly" over the ground. However, did you have an idea to make the landscape infinity - as in an voxel engine you just render the start of the map if the "ray" goes at the end of your height map. Any hint for this would be much approciated ;o), but not essential...
Regards
AnMaBaGiMa
thanks a lot for your proposal. I've tried it on my own and get 128x128 height map with triangle strips to work and its really fast. Wow, it's really amazing and impressive. It's not only faster it looks pretty much better ;o).. Now I will start to optimize my engine a bit. and enable the viewer to "fly" over the ground. However, did you have an idea to make the landscape infinity - as in an voxel engine you just render the start of the map if the "ray" goes at the end of your height map. Any hint for this would be much approciated ;o), but not essential...
Regards
AnMaBaGiMa
you will need to use LOD (Level of Detail) the idea is the same as Mipmapping, but with meshes. So basically the idea is show detail with objects that are close, and put very primitive low detailed objects in the background, since they occupy a small amount of pixels it will be hard to recognize the loss of detail. So basically you will want to create meshes that lank together, each mesh is a grid of verts, and then you will make a grid of meshes, each mesh with 3 or so levels of detail, each probably 5x5units, or 10x10 (you can decide the scale I suppose) then just a simple distance from camera to grid node will decide which LOD to render to the scene. so break the height map into tiles, thats the idea.
Code: Select all
.øOº'ºOø.
'ºOo.oOº'
-
- Posts: 87
- Joined: Thu Oct 01, 2009 8:43 pm
-
- Posts: 87
- Joined: Thu Oct 01, 2009 8:43 pm
Hi there,
I was successful in implementing a LOD engine - based on Peter Lindstrom and Valerio Pascucci SOAR algorithm and LOD papers - for the PSP.
Unfortuntely I've lost my coding due to a hardware issue with my Laptop...I need to start again from scratch, but may be I will sometimes post my project here :o)
Regards
I was successful in implementing a LOD engine - based on Peter Lindstrom and Valerio Pascucci SOAR algorithm and LOD papers - for the PSP.
Unfortuntely I've lost my coding due to a hardware issue with my Laptop...I need to start again from scratch, but may be I will sometimes post my project here :o)
Regards
Don't remember exactly when I made this or why, but here's an example of how complex things can get and still stay at (or over) 60 fps. It's compiled for later firmware I think... not sure though cuz I did compile for both. :p
I don't have source for it anymore, but I think it's 10 x 9 or 10 x 10.
I don't have source for it anymore, but I think it's 10 x 9 or 10 x 10.
Hey! Nice suggestion. I had my code waiting for VBlank, so usually run at 60fps with 30fps slowdowns, just when the calcs last more than one frame. I tried your tip but I get very unstable game in terms of framerate.a_noob wrote:Just another quick tip, dont use sceCtrlReadBufferPositive, use sceCtrlPeekBufferPositive (prior caps thread to 60fps) also dont wait for a vblank, rather just setup another thread, or a timer callback that only renders at the desired framerate, that way you dont stall the cpu for stupid things such as a vblank. Then you can continue to max out the psp's true potential ;)
I mean, the show framerate is quite stable but the main thread (the one wichs does physics simulation) varies the iterations from 70 it/sec to 140 it/sec, so the simulation isn't stable. Any ideas to solve it?
Thanks in advane!