Side scrolling speed

[GBeebe]

I don't know about you, but I'm finding that my game is "evolving" far from my origional idea, but that's ok. Origionally, it started out as a single screen, tile based game with a little dude that runs around shooting stuff (shooting straight left or right). Then it became to more of a side scroller (levels are bigger than the screen) and the dude shoots towards the mouse cursor and he's got rotating arms Then I added different weapon types which puts me at odds with attempting yet another step in the evolution. Right now my levels are pretty much "static". When you throw a grenade at a bridge, the grenade blows up and the bridge is just fine, or when you shoot a rocket at the ground the grass/dirt is unaffected. I think it would add to the puzzle element to make the levels be destroyable, kinda like in the game Worms. And then it got me thinking - Do I really want it to be tile based or do I want terrain like the game Worms has (which can't be tile based)?

So, here are some performance questions that I have:

When doing large maps reaching 8000 * 2400px on a 800 * 600 screen, should the map be devided into only 800 * 600 sized sprites, or should I go with smaller 64 * 64 sized sprites?

I am using sprite3D for the dudes arms, but the rest is done in 2d, would using DisplaySprite3D for the map sprites be better?

I realize that displaying sprites is auto clipped, but should I be doing a SpriteCollision to see if a level sprite would appear on the screen before displaying it? Would that speed it up? Or does someone know of a way to do a for ... next, starting from the first tile that would appear on the screen to the last?

I guess all in all, the appropriate question would be: What's the best/fastest way to display a map that isn't tile based.

Sorry if you think I'm being lazy, I'm just not a fast coder and don't want to find out 2 months down the road that i'm doing it all wrong. And I'm hoping that someone has the definitive answer.

Thanks.

[dagcrack]

No, for displaying tiles onscreen you must do a very simple mathematical calculation based on the sprite size, player position and screen size.

That way you'll only render what you see (and only "parse-through" those sprites instead of the whole bunch). Thats how it must be done.

Give it some thought and if you really cant make it work after a bunch of coffees, come back and we'll see what you've got and fix it.

And yes, I'd cut your image in chunks (you can do this with a few lines of code trust me) and take the tile approach. You should have powers of 2 for image / sprite sizes... always. Even though on SW this is not really required on most cases, its good to keep it power of 2!. As for an optimal size, I'd to either 64x64 or 128x128. And use simple RAW data (bmp if you please) packed in a file.

If your chunks are too big, you'll be rendering parts that you wont see in a few frames... But if you make them too small, you'll be calling much more drawing operations... Its a tradeoff, make some benchmarking tests on several hardware setups and take a decision based on the best numbers.


Best way to understand this is to learn it by your own. (might that be the hard way, which is in my opinion the good way, but, up to certain point. don't let frustration win the race).

[GBeebe]

No, for displaying tiles onscreen you must do a very simple mathematical calculation based on the sprite size, player position and screen size.

That way you'll only render what you see (and only "parse-through" those sprites instead of the whole bunch). Thats how it must be done.

Give it some thought and if you really cant make it work after a bunch of coffees, come back and we'll see what you've got and fix it.

Actually, that wasn't too hard to figure out:

Code: Select all

For w = -Int(SOffSet\X / 128)  To -Int(SOffSet\X / 128) + 8

And yes, I'd cut your image in chunks (you can do this with a few lines of code trust me) and take the tile approach. You should have powers of 2 for image / sprite sizes... always. Even though on SW this is not really required on most cases, its good to keep it power of 2!. As for an optimal size, I'd to either 64x64 or 128x128. And use simple RAW data (bmp if you please) packed in a file.

If your chunks are too big, you'll be rendering parts that you wont see in a few frames... But if you make them too small, you'll be calling much more drawing operations... Its a tradeoff, make some benchmarking tests on several hardware setups and take a decision based on the best numbers.

I'm doing 128 * 128 and it seems ok.

Best way to understand this is to learn it by your own. (might that be the hard way, which is in my opinion the good way, but, up to certain point. don't let frustration win the race).

Yea, I've been learning this alot in the last week.

Thanks,

EDIT:
FYI: I'm getting about + 25 FPS using Sprite3D to display the background tiles instead of using 2D stuff.
EDIT #2:
Correction, using Sprite3D is only + 25 FPS than using Mode=#PB_Sprite_Memory when doing 2d, but I gained another + 2 over Sprite3D when doing 2d with Mode=0 (which is default)

The PB documentation says:

0 : Default mode. Sprite resides in video memory (if possible)

Dose this mean that if the default mode can't be used it'll automatically revert to #PB_Sprite_Memory? In that case wouldn't it be wise to add an option to either use 2D (which would be good if default mode is available) or 3D (if default mode isn't available)? I guess I could also have an "auto" setting where it would do a small FPS test to see which is faster.[/quote]