SDL Surface management

[so88ccer]

I just have a quick simple question for debate. When dealing with surfaces in SDL, is it better to load one giant surface, or many small surfaces? The game is a fighting game, so there are quite a few moves. I know that with OpenGL it is better to have one big file. My only concern with one file is that it could be HUGE. If each character has 15+ moves in each direction the file for a single character could grow very fast.

Thanks!

Brent

[zenogais]

My vote is for one file, because that means that everything is allocated in memory as, in theory, one giant block. One file is also in the end probably more efficient than many smaller files loaded onto many different surfaces.

[so88ccer]

What if there were going to be 20 different moves for a single character? That means 40 different moves because you need them in each direction. That means if the character is 100 pixels tall, the height of the bitmap would be around 4,000 pixels tall. That seems a little absurd to me. That's the only dilemma i'm facing.

[Reedbeta]

Well, for one thing not every character will need a different set of graphics for left-facing and right-facing, as you can probably just flip the left graphics to create right graphics for many characters. Second, instead of having a huge column of 40 sprites, you can make a 4x10 or 8x5 grid of them in the file.

[gardon]

I was facing the same problem. I had 8 directions (4 main, 4 diagonal), each with 8-12 animations, doing 8 different actions. Memory quickly adds up.

I guess you could work with some image flipping or something.... but what I did was just say screw it, computers nowadays can handle it. After all, as long as you have loading/unloading optomizations for the rest of the game (loading levels and chunks of levels at different times so you don't take up all resourcable memory), you could really have as much memory as you want for the main player.

I mean if you think about it, 8 directions times 12 animations * 20 movements is about roughly 30 megs. But, that's like you said: a huge ass bitmap, so figuring in tiles that you're loading an unloading, you shouldn't breach 50.


the only other option would be to thread the loading and unloading of files. Like while you're character is doing one thing, load/unload another.
For example: if he was about to die, have the bitmap for dying load right before his death sequence... but then of course you'd have to worry about proper timing.

Gardon

[gardon]

It makes you wonder though, like how did SNES do it with limited memory? The only thing I can think of is that there really only was 2-3 animations per direction, and sometimes the direction count was only 4 (never really see diagonals in older consoles, so 2 * 4 * 3--things to do is only 24 animations, which is what we're both basically dealing with in just one movement, lol)

Gardon

[Mihail121]

Well the SNES had a pretty limited resolution, CPU power and memory so the perfect balance was to be found. Optimisation tricks like flipping and rotating the sprites are common optimization tricks. And, yes, using only one block of memory (one surface) is the way to go!

[so88ccer]

No one has really given me a good reason why 1 surface is better than 20. Is there really that much of a difference in performance? What's the difference between loading 1 surface or loading 20 and swapping between them?

[gardon]

Perfect example. Why switch and load between 20 pointers when you only have to do one? Same size, faster speed, easier to manage

Jason

[Reedbeta]

Cache!

Accessing a series of bitmaps that are sequential in memory is much faster than accessing stuff that's spread out randomly all around the memory, because of caching. Same holds for any kind of data.

[gardon]

Who says they're sequencial?

And experiment. Try loading your 100's of surfaces. See the lag it produces.

Try it.

Jason

[gardon]

But whatever, it's just previous experience.

The gaming industry uses it, so it must be good.

And I'm only speaking from experience. It's nice knowing I have a bitmap for attack modes, running, walking, dying, etc. rather than managing 100's of surfaces

[Reedbeta]

Who says they're sequencial?

If they're all in one big surface (as opposed to many small ones), they're pretty likely to be sequential... ;)

[gardon]

Cache!

Accessing a series of bitmaps that are sequential in memory is much faster than accessing stuff that's spread out randomly all around the memory, because of caching. Same holds for any kind of data.

then what were you referring to with this? Unless you were supporting my idea with another theory and question?

I don't understand what stance you're taking.

Jason

[Reedbeta]

What I'm saying is that one big surface is better for cache purposes, because with one big surface the different textures will all be contiguous in memory, and contiguous (especially sequential) memory access patterns are much more cache-friendly (read: faster) than random access patterns, which would be the case if the different textures were in different surfaces and thus probably spread more randomly throughout memory.

[gardon]

Ya I know. By the way you said "cache!" I thought you were disagreeing with me. I had no idea why you were talking about sequencial memory with different surfaces, but now I get it.

Anyway, this topic is dead. If you're doing a fighter-game like street-fighter/mortal-kombat then it shouldn't really matter, because you only have 2directions with different animations.

But big bitmaps are better anyway. I made a top-down RPG style game with 8 directions, 20 actions, and 12 animations per action (roughly). That's one friggen ton of memory for a 2D game, but it worked out, plus it's all nice and smooth XD

Jason

[so88ccer]

Jason, you said:

"made a top-down RPG style game"

Could you post the exe on here? I'd love to see it!

Brent

[gardon]

Well... "making". i was referring to the bitmap/sprite issue as "made" because that problem's taken care of.

I'm not releasing anything just yet, I mean after all, wouldn't want anyone to steal my ideas.

But here's a screenshot if interested:

massive-war.com/Untitled.bmp

[gardon]

I should be finished by about June

[so88ccer]

I'm not seeing it. I get a broken link.

Brent

[baldurk]

I'm not seeing it. I get a broken link.

Brent

That's probably for the best. it's a huge 3mb bitmap. I've uploaded a jpg (suitably censored) here (http://baldurk.org/killstuff.jpg)

[geon]

Uh... That's just a menu.

[so88ccer]

Maybe that's all he has... Right now that's pretty much all I have with my game.

[monjardin]

Uh... What had to be "suitably censored"? :unsure:

[baldurk]

Uh... What had to be "suitably censored"? :unsure:

Some coarse language. "Kill Stuff" :).

[SamuraiCrow]

There's another reason you might want to keep the file in one big picture: compression. A tall/wide GIF with a lot of redundancy in it should make the disk space less. Of course you'd have to link in SDL_Image instead of just using the BMP loader in the main library but it will save loading time and disk space for sure.

[gardon]

Well... "making". i was referring to the bitmap/sprite issue as "made" because that problem's taken care of.

I'm not releasing anything just yet, I mean after all, wouldn't want anyone to steal my ideas.

But here's a screenshot if interested:

massive-war.com/Untitled.bmp


That's why it's only showing a menu

Jason

[so88ccer]

So do you have an in-game shot? That's some pretty nice artwork too. Where did you get it?