forums.ps2dev.org

[ipsp]

Has anybody notived that the SDL library are extremely slow, for example when filling 6 rectangles, i'm geting like 4 frames per second. Trying to draw anything complex, makes it run so slow it's a joke.

Basically I've built a small windowing toolkit, including cursors, window, events, dialog, selection lists, button, image maps, listners... etc and I've used my toolkit to produce a game, but the response is so slow.

Perhaps my implementation is not the best but with drawing 4fps for filling 6 rectangles it's a joke. The same code talking to the native psp libraries, works upto about 35fps. So I'm figuring this it the SDL implementation.

Has anybody else used SDL much on the PSP and noticed similar issues.

I'd just like to get some advice into what might be wrong, as I'm new to the SDL library.

[Brunni]

SDL is extremely slow. And it's even slower on PSP because this implementation is rendered in software.
If you want more speed, use the PSP GU, GE or OSLib. With OSLib for example, you can draw more than 1500 full-screen filled rects per second.
_________________
Sorry for my bad english
Oldschool library for PSP - PC version released

[ipsp]

Ok I'll drop SDL then.

Now my only problem is how do I get true type font (TTF) support, as this was the only reason I was even using it in the first place.

[Brunni]

It seems that LuaPlayer does it. LuaPlayer is slower than the quoted native methods because it's an interpreted language, but still faster than SDL.
But if you don't want to use it I'm sure you'll find some code for loading and displaying TTF ^^
_________________
Sorry for my bad english
Oldschool library for PSP - PC version released

[danzel]

You really hate on SDL don't you Brunni :P
Its not as slow as you think, tryed the commander keen port for psp? That's using SDL and has no problems with speed.

You can get TTF font stuff using the freetype library, you definately need to use a font cache to get good speed though. Rendering glyphs from a TTF font is an expensive job.
Perhaps if you add a font cache in your SDL font stuff you'll get an acceptable speed increase (not sure if your 4fps was rendering fonts too, if it wasn't then that is pretty poor speed indeed, sure you haven't done something wrong?)

[Garak]

If you want a world of speed increase in SDL, make sure to convert your screen mode from 32 to 16 bit. It will be the difference between night and day.

Garak

[ipsp]

Well I kept the SDL code around so i might go back to it.

It is unlikely that the true type fonts were causing the problem, basically during initalisation all text was rendered to a surface, and those surfaces kept (cached) and simply blit'd to the screen later.

Not sure if I was using 32 or 16 bit for the graphics, although I suspect it was probably 32. I'll try that and see what type of frame rate I get.

Otherwise for font support, I came up with my own way of doing it, not the best idea but seems to be quick enough, basically I set a png as a texture then have code that renders a string by using clips and offsets into that texture. I'm sure if I work how to allocate seperate vram, I can render these string once then just dump them onto the display buffer as needed.

Does anybody have any thoughts on this, the code is pretty messy and yes it does not do scaling but I have some ideas for that too.

Currently only noticable problem is that the top 16 pixels of the screen seem to flicker, and that is giving me a headache trying to work out what is wrong (any ideas ?????). Seem like I'm writing to the buffer being rendered. Hopefully I'll work that out.

[JesusXP]

keep us updated :)

[danzel]

maybe you need to flush the psp cache?
Call sceKernelDcacheWritebackAll(); before rendering the screen.

Thats seems an okay way to cache the fonts, shouldn't be taking any real performance hit from that.

[Brunni]

If it doesn't solve the problem, make sure you are using double buffering.
_________________
Sorry for my bad english
Oldschool library for PSP - PC version released

[ipsp]

Hi Guys

I checked and yes I was using 32 instead of 16, I changed this and well did not get the results I would have liked (night and day). But once I turned of the TTF handling, there was a dramatic improvement.

I believe my TTF caching was not working as I expected it to, for some reason even though the SDL_Surfaces (with the TTF on them) were cached, there was still issues with bliting so many surfaces. So that being said I've decide not to use SDL for this project.

The majority of the code has been ported into natiev PSPSDK calls, and I must say the improvement is huge. I have gone with my own font handling, i.e. using png texture and clips (not sure how to cache though). I'm still getting up near 50fps which so more than acceptable, as cursor movement is smooth so is all window component rendering.

One quick question can I have a texture clip write to a specific vram address rather than to the current vram buffer. This would help significantly as that way I could cache the strings when they are created and only blit them as required. I want to do this as obviously clipping and blitting 200 characters each frame is expensive, and I would prefer to streamline the font handling.

[Garak]

I'm a little confused on the TTF problems you were having with SDL...

In SDL, you use ttf_render to create your text string and it returns an SDL surface to you. Once you have that surrface, you can reuse it as many times as you want. There is no need to re-create that surface again and again each time you re-pait your screen. I think you may have been doing that, though I am not quite sure.

Once you have your SDL surface represnting your text, if you rendered it as blended, it will use an alpha channel for transparency. In that case, you cannot convert the surface to 16 bit. To my knowldge, all surfaces that use an alpha channel for transparnecy in SDL have to be 32 bit. Yes I know there is a 4444 pixel mode, but at last I checked that did not yet work in the PSP SDL port.

Thus, if you only create your text surface 1 time, and you create it as a SOLID/SHADED surface you can convert it to 16 bit mode and get another speed boost.

Not trying to preach SDL on you, only trying to help =). I've had good luck with SDL so far. I'm writing a 2D sidescroller and regular SDL together with a few GU functions gives me the desired 50fps I was shooting for. I know my situation is possibly very different from yours, given our projects are very different.

Garak

[ipsp]

[Garak]

Hi,

What do you mean by "the surfaces were created in the constructor"? I am just curious, as I thought TTF_Reneder was the only wat to create TTF SDL_Surfaces.

Go to the SDL docs and look at the def for SDL_ConvertSurface. that is the function one uses to convert from 32 to 16 bit surfaces. I'm not sure if you are aware, but just initilizing your screen mode to 16 bit does not make SDL load all of your images as 16 bit images. You have to set your screen mode to 16 bit, and load each SDL image as a 16 bit image. Otherwise you are doing a 32->16 bit conversion each time you blit your image, which will no doubt be pretty slow.

Generating your text surfaces as solid is fine, but you still have to convert the returned surface to 16 bits, as it is created using 32bit pixels depth.

JGE sounds like a great engine. If it had been around 6 months ago when I started I probably would have used it for its GU accelerated features. But at the time, only SDL was availabel and in a very stable state. Not to mention the online SDL documentation is 2nd to none. And proper documantation is something you cannot have to much of when doing PSP programming.

Garak

[ipsp]