SDL - Too slow

Started by
36 comments, last by 23yrold3yrold 19 years, 1 month ago
Why not just blit the relevant tiles directly to the screen?
Advertisement
Quote:Original post by Kylotan
Why not just blit the relevant tiles directly to the screen?


because the screen is more thin than the vs, and I would like make a function that blit only the portion of vs is visible on the screen.
24 BPP tiles prolly makes it slow. My experience is that it's the slowest ever possible SDL flag.


[Edited by - relsoft on March 2, 2005 2:47:19 AM]
Hi.
Quote:Original post by NighTiger
because the screen is more thin than the vs, and I would like make a function that blit only the portion of vs is visible on the screen.


But you can just calculate which tiles are going to appear on the screen, depending on which part of the world you are viewing, and choose to only blit those. I can't see any reason for the intermediate stage, and it will probably halve your performance.
I've posted this in another thread, but it still applies.

make sure that both of your Surfaces, from and to, are in hardware memory. Like, if you're just doing some basic tiling like a 16bit console or something:

1) Make your visible surface in hardware memory
2) load the tile graphic into a software surface
3) make a non-visible surface in hardware memory
4) blit the graphics to that surface
5) Copy from Hardware to Hardware.

Blazingly fast.
william bubel
Quote:Original post by Inmate2993
3) make a non-visible surface in hardware memory
4) blit the graphics to that surface

It's usually best to use SDL_DisplayFormat to do these steps automatically.

Additionally, if the visible surface isn't a hardware surface, as the original poster said, then hardware->hardware blits aren't gonna happen. Fullscreen mode may be required for that.
Quote:Original post by Inmate2993
I've posted this in another thread, but it still applies.

make sure that both of your Surfaces, from and to, are in hardware memory. Like, if you're just doing some basic tiling like a 16bit console or something:

1) Make your visible surface in hardware memory
2) load the tile graphic into a software surface
3) make a non-visible surface in hardware memory
4) blit the graphics to that surface
5) Copy from Hardware to Hardware.

Blazingly fast.


I don't know why but I can't make a hardware surface under linux and windows too.
tnx
>>24 BPP tiles prolly makes it slow. My experience is that it's the slowest ever possible SDL flag.

Right, 24bit is slow. use 32 or 16
Simply, many cards simply dont support 24bit color formats in hardware. There is no need to since we have plenty of vram, and that was the only benefit of 24bit color compared to use 32bit and ignoring the alpha channel. You will need to use 16 or 32bit because they are both aligned for easy (and fast) access (ie a power of 2 multiple of 8).

You probably are not getting hardware surfaces because you are using a 24bit format. I think many people dont realize this limitation of newer hardware because most people use 16bit or 32bit for 3d rendering. The ones that do 2d rendering tend to use 16bit for speed and much easier access of the pixels. While others use 32bit so they can have an alpha channel.

24bit color has been dead for quite awhile on consumer video cards.
I just use 16bit for my surface!!!!!! :(((((


maybe the problem is the tile's png?

This topic is closed to new replies.

Advertisement