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.
SDL / SDL_Image / SDL_TTF Efficency Problems
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.
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
Oldschool library for PSP - PC version releasedIt 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 ^^
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
Oldschool library for PSP - PC version releasedYou 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?)
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?)
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.
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.
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
Oldschool library for PSP - PC version releasedHi 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.
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.
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
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
No, actually the surfaces were created in the constructor (yes i know this has problems), and displayed as required. So this was not the problem.Garak wrote: 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.
How do you do this conversion, i'm new to SDL so not sure how this is done. Sounds like it might work, as all text surfaces were generated as SOLID. As far as SDL, one reason for using it was TTF, but that being said I typically need very small fonts, about 10 pixels high, and it is very difficult to find good TTF that display at this size using SDL.Garak wrote: 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.
My new approach allowed my to generate TTF using photoshop and save them as PNGs, not only is this giving me a huge performance boost but the fonts seem to look much better.
The project I'm working on was doing a port of dopewars/drugwars (not really a port as I have written it from scratch), and compressing the interface into such a small area has caused problems. The windowing toolkit I'm building (aka PSP_WTK) is based upon Java swing (I used to do work with this Swing professionally) but I have removed the layout managers. The idea I had was to create a generic windowing toolkit so that any other games/applications I might want to write that are similar format to dopewars/drugwars would be easier to develop an interface.
I have to admit I used SDL originally, as I was really confused by alot of the example code for doing direct Gu operations, so hiding them with a library seemed like a good idea. I'm sure SDL works fine, but have you considered the JGE project. Had a look and seems it would handle 2D side scroller better than SDL, but that is just by looking quickly at it.
ipsp
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
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
My system is using C++, hence I'm constructing the surfaces in the constructor of my 'PSP_WTK_Text' class, and I'm ignoring any errors that occur. This is what I meant about being a little silly. At the moment I just assume nothing can go wrong. Error handling error is inplace (taken from examples) but nothing is done when an error occursGarak wrote: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.
Was not aware of this so you are right I'll have to convert each surface once it is created, should be no problems there I'll read the documentation.Garak wrote: 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.
Agreed documentation when developing anything is so important. Professionally I write software to interface to Xml systems, and if the documentation is crap, it usually means the system I'm trying to interface to is crap. So agreed, I have noticed the PSPSDK documentation is rather weak, just listing the function calls and parameters is not at all helpfull, which is why I was using SDL as it had rather good doucmentation plus the amount of example code out there is huge. In fact the first thing I did with SDL was to port 2 other games (well not really port just adjust for the PSP), just so I got an idea of how to use SDL.Garak wrote: 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.
Now with everything you have told me, I'll look into changing everything across tonight, and update the results, if the improvement is there I will probably go back to SDL, for this project but I still think learning the PSPSDK will help me in the long run.