You're lucky to get it in full screen. I can't get it in full screen. I'd like to, but running it in a 1600x1000 window isn't too bad.
Well. Good news guys. I was able to help Alam debug the issue with the water effects crashing the PSP! Just a few minutes ago, I made a new build that is based on: http://trac.srb2.org/changeset/3904 along with a simple file edit in "screen.h":
Here is the file: http://sonict.sepwich.com/Random_Stuff/SRB2PSP_Builds/SRB2PSP_r3904e.PBP
You can't really compare the FPS to quake 2 at all since SRB2 has huge levels. I suspect the reason it might be running slower now is because it needs 5 screens for the underwater effects instead of just 2 normally.
At any rate, the most major issue right now is that any level after THZ will most likely crash the PSP on level load because the levels are so damn huge.
Is Windows really joking?SRB2 DirectX(Level Deep Sea Zone 2) said:r_create colormap Too many colormaps!:
lolSRB2 SDL(just starting) said:JIT depurator window opened to choose depurator(I have Visual Studio 2008 Professional, could be cause of problem). Next program was closed.
R_CreateColormap: Too many colormaps!
JIT depurator window opened to choose depurator(I have Visual Studio 2008 Professional, could be cause of problem). Next program was closed.
Still does the same thing.
It looks like large black lines are flashing horizontally across the screen.
Any clue on this?
Hold on a second there, I know what I'm talking about. Level size should only concern RAM, not the FPS. If your talking about how wide open some parts of the level is, THATS where mip mapping would help, which is what Quake engines do to help with rendering large open spaces and generally provide a boost in performance regardless of the size of the room. But still, why would there still be so much slow down even when not looking at an open space and just really close to a wall? That tells me right there that something besides level size, or how wide open the levels are, don't have that much of an effect on OVERALL fps and something else is. Unless the game is trying to render the whole level no matter what your looking at. That would definitely explain it.
But then again, not all of the it. Even the main menu is suffering from serious frame rate issues! So I have come to the conclusion that there is some really unoptimised code somewhere in the renderer, or it might be some old buggy libraries being used. SDL by any chance? I hear that's not the fastest, you would gain more performance coding directly to the psp sce libraries.
Bottom line, there is definitely room to get a lot more performance out of this. And something else besides level size is causing frame rate issues.
And thanks for explaining why it's slowing down each build. Would it be better to disable the water effects?
Well, there are several things that are causing the general framerate loss over time:Hold on a second there, I know what I'm talking about. Level size should only concern RAM, not the FPS. If your talking about how wide open some parts of the level is, THATS where mip mapping would help, which is what Quake engines do to help with rendering large open spaces and generally provide a boost in performance regardless of the size of the room. But still, why would there still be so much slow down even when not looking at an open space and just really close to a wall? That tells me right there that something besides level size, or how wide open the levels are, don't have that much of an effect on OVERALL fps and something else is. Unless the game is trying to render the whole level no matter what your looking at. That would definitely explain it.
Code:JIT depurator window opened to choose depurator(I have Visual Studio 2008 Professional, could be cause of problem). Next program was closed.
Please use the Debug version of SRB2SDL and exchndl.dll so the crash backtrace goes to srb2sdl.RPT
How do you use the OpenGL version?I'm just asking...