Porting to PSP

[fjtrujy]

Hello guys!
First of all thanks for the amazing project.

In the latest days I have been trying to port this game to Original PSP, however, I'm facing some issues.

Currently, the most important one is the screen resolution, PSP has a resolution of 480 x 272 however the game is trying to create textures from this values:

const resolution_info fullscrn::resolution_array[3] =
{
	{640, 480, 600, 416, 501},
	{800, 600, 752, 520, 502},
	{1024, 768, 960, 666, 503},
};

What should be the easiest way to adjust to the maximum PSP resolution?
Can I change these values and put whatever I want?

Thanks again

[fjtrujy]

Forget it!
I found it, just changing the windows should be enough.

I have the game almost working, however I'm not sure about how it will perform :(

[fjtrujy]

Reopening the ticket just to know if there is a possibility of having lower resolution, it will make to work faster in low profile devices...

[k4zmu2a]

Hello.

There is no easy way to change internal table resolution.
Game physics are tied to those fixed resolutions and renderer does not support sprite scaling.
The only practical way is to resize the output window.

About performance:
The game uses software rendering to vScreen, no easy way to HW accelerate it.
Blit from vScreen to frame buffer can be HW accelerated.
To find you bottleneck, try running the game without presenting vScreen. If it is still slow, then you are bottlenecked by software renderer.

[fjtrujy]

Hello.

There is no easy way to change internal table resolution. Game physics are tied to those fixed resolutions and renderer does not support sprite scaling. The only practical way is to resize the output window.

About performance: The game uses software rendering to vScreen, no easy way to HW accelerate it. Blit from vScreen to frame buffer can be HW accelerated. To find you bottleneck, try running the game without presenting vScreen. If it is still slow, then you are bottlenecked by software renderer.

If I comment the render::PresentVScreen(); line, it performs at 60 FPS, if I also disable the piece of code that execute the sleep_for at the end of the frame, I have around 260 FPS.

Thanks

[k4zmu2a]

260 uncapped UPS without presenting is good, this means that PSP has more that enough power for software renderer. For comparison, my laptop does about 7-8k UPS.
So, your bottleneck is in vScreen to frame buffer copy.
There are a few things you can do:
• Ensure that SDL is using HW accelerated renderer if PSP SDL supports it.
• Disable linear filtering, it has large impact on SW vScreen copy.
• Try using platform-specific API for presenting vScreen.

[fjtrujy]

260 uncapped UPS without presenting is good, this means that PSP has more that enough power for software renderer. For comparison, my laptop does about 7-8k UPS. So, your bottleneck is in vScreen to frame buffer copy. There are a few things you can do: • Ensure that SDL is using HW accelerated renderer if PSP SDL supports it. • Disable linear filtering, it has large impact on SW vScreen copy. • Try using platform-specific API for presenting vScreen.

Just to make it clear, it has around 230 FPS and 450 UP

Updates/sec = 460.54 Frames/sec = 229.77
Updates/sec = 459.16 Frames/sec = 230.08
Updates/sec = 459.54 Frames/sec = 229.77
Updates/sec = 460.62 Frames/sec = 230.31
Updates/sec = 467.53 Frames/sec = 233.77
Updates/sec = 451.55 Frames/sec = 225.77
Updates/sec = 451.10 Frames/sec = 225.55
Updates/sec = 449.55 Frames/sec = 224.78
Updates/sec = 450.20 Frames/sec = 225.10
Updates/sec = 451.10 Frames/sec = 225.55
Updates/sec = 450.65 Frames/sec = 225.32
Updates/sec = 451.55 Frames/sec = 225.77

Anyway, I\m not sure if I will make it work properly in PSP. In theory, the maximum texture width is 512, and here we have 600, which makes the texture to be wrong on the right side of the screen, I still need to investigate if it is an SDL2 issue.

Thanks

Thanks.

[k4zmu2a]

Ok, 460 UPS is even better. FSP is on 1/2 ratio to UPS, by default.

There are multiple ways to solve SDL texture size limitation.
VScreen has two textures: SDL texture (Texture) and software render texture (BmpBufPtr1).
Only BmpBufPtr1 must have fixed table resolution.
• You can change dimensions of Texture, replace direct copy from BmpBufPtr1 with manual downscaling.
• You can tile Texture, for example split it in two: table and score.

[fjtrujy]

Hello again,
Trying to speed up the execution in PSP, there is one thing that could be done.
The project is using palettes, however, instead of using natively the palettes, we are creating the texture buffer replacing the indexes of the palettes with the content of the palette.

This is obviously increasing a lot the amount of RAM used, and wasting a lot of CPU cycles when rendering the texture.
Is not the same to have:

1. Palette of 256 colors, 4 bytes per color, and a Matrix of 600x410, 1 byte each position.
   Total (256*4) + (600*410) = 247024 bytes.

2. Matrix of 600x410, 4 bytes each position.
   Total (600*410*4) = 984000 bytes.

This kind of this is really helping the low-end platforms as PSP/PS2 to perform well

You have more information here:
https://wiki.libsdl.org/SDL_SetPaletteColors

Finally, have you thought to create better driver interfaces?
For instance for PSP, could make sense to use the native graphic library instead of the SDL2 port.... however SDL logic is currently so encapsulated in the project, making it so difficult to do.

Thanks

[k4zmu2a]

Keep in mind that my project is targeting generic desktop, where indexed color textures are always emulated.
Ram saved by indexed colors in the game will still be used by SDL or video driver.

Original game used indexed colors, I intentionally moved away from that in v2.
First version of v2 mapped indexed->RGBA on the fly during rendering, now it is done with RGBA copy.
RGBA copy is faster than per pixel palette lookup btw, at least on modern CPUs.

I don’t see any point in introducing backend abstraction layers to the project, SDL2 serves the project just fine.
I am careful about intruding any unnecessary complexity, to avoid spread my efforts too thin.
Abstraction layer between game and SDL doesn’t not make sense in cost/benefit for the project, hopefully you can see that.
But I will be happy to add something that benefits both the project and your port.

[fjtrujy]

Keep in mind that my project is targeting generic desktop, where indexed color textures are always emulated. Ram saved by indexed colors in the game will still be used by SDL or video driver.

Original game used indexed colors, I intentionally moved away from that in v2. First version of v2 mapped indexed->RGBA on the fly during rendering, now it is done with RGBA copy. RGBA copy is faster than per pixel palette lookup btw, at least on modern CPUs.

I don’t see any point in introducing backend abstraction layers to the project, SDL2 serves the project just fine. I am careful about intruding any unnecessary complexity, to avoid spread my efforts too thin. Abstraction layer between game and SDL doesn’t not make sense in cost/benefit for the project, hopefully you can see that. But I will be happy to add something that benefits both the project and your port.

Thanks for the reply.
Most probably, with the current status of the PSP SDL2 port is going to be so difficult to have a good performance.
In the end BlitToTexture() methods take too much just "copying" content of texture... 😢

This is why I was thinking to use the palette, instead of the whole buffer. I did some dirty tests, and performance will be close to the 60 FPS.

I have tried myself, removing the use of the BmpBufPtr1 and just using IndexedBmpPtr, and then in the BlitToTexture() method fill the content of the texture, replacing each index with the proper color (I suppose that this is what you were doing previously), but I'm suffering some strange flipping errors

In the end, the PSP GPU is ready to work with textures using Palette color, and this will save a lot of CPU ticks (which is the current bottleneck), this is why I was giving it a try to the Palettes. I have used the same approach with emulators and the performance boost is quite visible.

Regarding including changes in the main repo, I totally understand that some changes that I'm doing most probably aren't going to be possible to merge, but I will try to do my best.

Thanks

[k4zmu2a]

BlitToTexture is slow most likely due to lack of HW acceleration in PSP SDL.
My code was written with HW accelerated SDL renderer in mind, software fallback in SDL is kind of slow even on desktop CPU.

Texture flipping you are seeing is caused by bitmap origin conflict.
V2 uses SDL origin, which is a horizontal flip away from original game origin.
Original bitmaps no longer work as is in V2.