Hi everyone, I’m Petruza, I’m posting for the first time in this list.
I’m coding an emulator and want to load the tiles into tile_sheet which is an SDL_Surface.
To make rect blitting easier, I thought of making the tile_sheet of 256 x 8 pixels.
Is it more or less efficient than making a more square-ish surface?
Since I’m not using the whole surface, but just 8x8 rects out of it, the dimensions really don’t matter,
so I’m free to make them anything I want having efficiency in mind.
Look, the word “efficiency” usually does not mean what people think it means.
I am not trying to be an ass hole, I’m just an old programmer (57
years old, programming since I was 19) who has come to learn that any
time someone is worrying about efficiency and they have not
characterized the problem in terms of an algorithm they are in danger
of chasing off down the rabbit hole. When they start talking about
efficiency and they are worrying about trying to save what amounts to
less than 1 percent of a resource, be it time, memory, disk space, or
what ever, and are not worried about wasting the one resource that
only gets more expensive every day, which is the time left in their
life, then they are already deep into the rabbit whole and may have
already been sipping on the bottle of drink me that warps the minds of
so many programmers. So, remembering that I am trying to keep you from
wasting any part of your life chasing rabbits please read the
following:
How many tiles are you going to have? What size are the pixels? When
you say 8x8 what are the units you are using for the number? Is it
pixels, bytes, inches? It is hard to answer a question when you leave
most of the information in your head
Ok, so if I assume that 8x8 is in pixels, which by the way is very
very small on a modern screen then each tile is 64 pixels. If I assume
that each pixel is 32 bits/4 bytes, then a tile is 256 bytes. That
means at the best possible packing you get 4 tiles per kilobyte or 4
kilotiles per megabyte. But, you said you are writing an emulator so
you are mostly likely emulating some ancient video game system or
computer which probably only support a few dozen tiles. Of course,
this is another assumption because you didn’t mention what you were
doing. To me that means that you are going to use up a fraction of one
percent of the memory on your computer or your graphics card for
storing these tiles. So, why are you worrying about the "efficiency"
of this storage? Just do it how ever works out best for your project
and stop spending time on problems that are not problems?
OTOH, if you really want to make it fast and don’t care about using a
little bit of memory you might want to just make the tiles into OpenGL
textures so they are stored in the video card memory where the
graphics hardware can get at them and slam them around the screen so
fast no display can keep up. Plus, OpenGL solves about 2000 of the
next 10 problems you are going to run into.
Do not optimize your code until you have evidence that it is too slow.
Write the simplest code you can as quickly as you can because in a
project like yours you are likely to have to rewrite it several times.
If you have already invested a lot of work into getting it "optimized"
you will be unwilling to throw away all that work and you will waste a
lot more time trying to keep it optimized. That means you may wind up
optimizing the same code dozens of times. On the other hand, if you
make it simple and easy to code and only optimize it when the projects
works, but is too slow. You will only optimize it once. And, if you
use a profiler to find the slow spots you might find that only two or
three sections of code need to be optimized. But, more importantly,
you may find that the optimization requires changes of a more global
natures that you could never guess at during the early stages of
development.
Never optimize code until testing shows you that the application is
too slow. Only optimize code after a profiler shows you that it must
be optimized.
In your current problem the only thing you need to worry about is
making sure that the SDL_Surface you wind up with is properly laid out
to work with the graphics system you are rendering on. You really do
not want to be converting from say and 8 bit image to a 32 bit image
before each blit.
Ok, back on the subject of really helping you, please give us more
information about what you are trying to accomplish, not about a
specific problem that is occupying your mind right now.
Bob PendletonOn Sat, May 22, 2010 at 10:13 AM, Ernesto Borio wrote:
Also, what does the pitch depend on, besides surface width? it depends on the video hardware?
Can I assume that a surface which is not wider than the main SDL screen surface (SDL 1.2) will have the same pitch
as the screen?
Thanks
PS: I signed-up on the SDL forums but I’m not granted permission to post or reply, and private messages are disabled so I can’t contact any admin. Do you know why is this?
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------