SRB2 Ports list

[Cheese]

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.

[Jon God]

Originally Posted by Cheese

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.

Heh, with the state it's in, it wont be playable in fullscreen.

[MDave]

Originally Posted by Sonict

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_Stu...PSP_r3904e.PBP

Thanks for an updated build with the fixes! But man, I'm with Chaos on this one, the frame rate is getting noticeably worse each release. There is something going very wrong somewhere, because I don't think it should be running this much slower after fixing the crash bug. Even Quake in software mode runs at a more steady 20fps on the PSP :P

I think what would help increase performance across the board for all platforms in software mode, is implementing some sort of mip mapping technique to textures on walls and floors. For software rendering, this would be a HUGE performance gain. Probably very easy to implement if you mipmap textures based on sectors that are at set distances from the camera. Maybe there is already something like this for other open source Doom engine modifications. I think it's very worth taking a look at :)

[Sonict]

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.

[MDave]

Originally Posted by Sonict

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.

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?

[marcsancessoftware]

Originally Posted by SRB2 DirectX(Level Deep Sea Zone 2)

r_create colormap Too many colormaps!:

Is Windows really joking?

Originally Posted by SRB2 SDL(just starting)

JIT depurator window opened to choose depurator(I have Visual Studio 2008 Professional, could be cause of problem). Next program was closed.

lol

[AlamGBC]

Please do not make fake quotes, it make it hard to me to replay to; hmm..

R_CreateColormap: Too many colormaps!

the SRB2 trunk colormap limit had be raised from 30 to 60

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

[Jon God]

Originally Posted by Jon God

Still does the same thing.

It looks like large black lines are flashing horizontally across the screen.

Any clue on this?

[AlamGBC]

Originally Posted by Jon God

Any clue on this?

yea:

• I_SkipFrame messes with OpenGL fullscreen mode, added a check for render_opengl mode
• disable use of direct video memory access for the software render for MacOSX systems

now software and opengl mode work in fullscreen without tearing the display

I have compile new version of the builds and made a nodata version of Srb2Mac.dmg (Srb2Mac Lite)
but I have not check if the OpenGL fullscreen tearing fix break non MacOSX systems

[Sonict]

Originally Posted by MDave

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?

Alright. What you said does make lots of sense to me. Yes, we are using SDL for the porting. The main exe that comes with the game doesn't use SDL. I do agree there is room for improvement. However, unless we can somehow get Alam / LoganA (I don't know who has the PSP) able to do PC <-> PSP linking, we aren't going to get very far.

Thanks for the advice. I'll let Alam and LoganA know about this.

[Mystic]

Originally Posted by MDave

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.

Well, there are several things that are causing the general framerate loss over time:

1. There are simply more features. More things for the game to keep track of slowly degrades framerate. Over 11 years we've added a lot, and the framerate has suffered because of that.

2. People tend to play at a higher resolution than they used to. When I first started playing SRB2 I was playing at 320x200 and it was generally expected you would play at such a resolution. Nowadays with 640x400 the default and 1920x1200 an option, the old renderer is being strained even more than it ever was.

3. The stages are much larger. This causes a lot of the resources the game uses for various parts of the game to balloon in size and have to be checked more often. For instance, the reject, which the game uses for determining what sectors have line of sight to each other, is literally a table with a bit for each potential combination of sectors. This increases in size dramatically as the stage increases in size. As the player moves around, the gigantic reject table is being checked to see what enemies could possibly have line of sight to see the player from their position. To make matters worse, larger maps are far more likely to have even more enemies that need to be checked against the rapidly growing reject table. Hence, as the size of the map grows, the game is checking more things against rapidly growing resources.

4. The levels are more complicated in design. This is a problem for the framerate because the renderer actually does not stop rendering when line of sight is blocked. It only stops rendering when it encounters a one-sided linedef, which must be placed inside a pillar or wall that the player cannot cross under any circumstances. This means that if you have a room with a wall you can climb over to reach another room, if you face that wall directly with the other room beyond, it is actually rendering the room beyond the wall, then rendering the wall on top of that. This is why you see clever usage of pillars and other walls in a lot of SRB2 stages, to allow us to place one-sided linedefs inside to stop the renderer from wasting cycles rendering rooms the player cannot even see. As a lot of the newer stages are far more complicated, this kind of doubling up on rendering pixels becomes more common. To take an example, Eggrock Zone Act 1 is VERY commonly rendering things you can't even see.

[MDave]

Thanks for the indepth explanations! It's quite unfortunate that there seems to be nothing that can be done though (in software rendering anyway) to help increase performance, due to the nature of the engine.

Any possible reasons why the menus are slow to render though? (PSP version).

If time permits, I would try and lend a hand but I have my hands full with other projects.

[Mystic]

Well keeping proper framerate is mostly left up to the level designer under the SRB2 engine. A couple of our new stages, especially CEZ2, but also a bit in DSZ1, have major issues in certain rooms because it wasn't designed properly with framerate in mind. It just requires well-placed one-sided linedefs and a little bit of clever optimization to get much better framerate in certain areas, which unfortunately hasn't been done in those areas.

[marcsancessoftware]

Originally Posted by AlamGBC

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

Nope, still fails. But, don't worry, this happens lots of times in my computer, (just in Windows Explorer I saw typical XP crash message, DEP error, JIT window and BSOD in just 45 minutes...)

[Jeck Jims]

I get it to start but after the PSP logo it gose back to psp menu and say "THE GAME COULD NOT BE STARTED. (80020148)" What can i do to fix it?)

[Chaos Zero 64]

Is your PSP even hacked? If your PSP can't play homebrew games, then it can't run SRB2 in it. We won't tell you how to hack it though, so just Google it.

[Snowyfox]

How do you use the OpenGL version?I'm just asking...

[AlamGBC]

Originally Posted by Snowyfox

How do you use the OpenGL version?I'm just asking...

use -opengl to enable OpenGL mode

I change the 1st post to include this and new URLs:

SRB2 Mods ports:
http://alam.srb2.org/SRB2_ALAM/
http://alam.srb2.org/SRB2_MORPH/
http://alam.srb2.org/SRB2_PYTHON/
http://alam.srb2.org/SRB2_SNK/
http://alam.srb2.org/SRB2_XMOD/
SRB2Mac Mods:
http://alam.srb2.org/SRB2_mac/

[Chao Freak 1]

Are..... Just wondering if NiGHTS mode would be fixable in the intel mac version. After you move for a little bit, SuperSonic gets stuck and can only move up and down.

[Cheese]

Originally Posted by AlamGBC

http://alam.srb2.org/SRB2_mac/

What's XSRB2 doing there when it hasn't even been released yet?