I need a lot of help optimizing (Tiling Engine)

Kasumi · Post by **Kasumi** » Sun Jun 25, 2006 5:29 am

Okay. I'm trying to make an adventure game with at least two backgrounds read from a map file and blitted to the screen with my tileset.

Problem is, I get slowdown with 1 background. Chances are my code is a menace so if anyone has some (or a lot) of time could you take a look at it and help me perhaps? I think one of my main downfalls is using so many large functions. If that's all I need to change then, that's fine with me.

I've got 2 versions of this which both run at about the same speed on PSP. (Even though one should run a bit faster)

Edit: It occurs to me that I didn't explain which actual files I needed help with. In scripts, the tiling engine is called blit.spt. .spt is just a .lua with a different extension. Sorry if this caused any confusion.

This: [Link Removed]
is the one that should run faster.

The thing that probably slow it down is the fact that is has an extra blank image for basically no reason. I blit background to this image, then I blit the image back to background, and blit my new tiles to that. I only did it this way because when I tried to blit background to itself, I experienced strange graphical glitches.

This One: [Link Removed]
tiles smoother, but it blits everything, every frame.

If anyone wants me to just post the code, I can do that too.

Ideally, what I'm looking for is an engine that can read and display the maps I create with my map editor (like the one included in those two files) that doesn't cause the song included to lag when playing.

Also, how bad/good do you think the chances are of people stealing characters ETC. off of a LUA program? Me posting this here at all is something I didn't like doing, since I made those sprites and the tileset myself. (Though the sprites are done kind of like Earthbound, they are NOT edits) Can't take credit for the song though. That's from Mother.

I already completed one LUA game that I never released to the world because I'm very afraid of that kind of thing. It's a simple game of tag written on a platforming engine.

Player One takes the d-pad and L button. Player Two takes the shape buttons and R button.

R/L is jump. Left and Right, Square and Circle are walk. If you double tap a button you dash. Pressing down/cross button is a slide. You can also add your own modes and stuff. I wrote a tag mode, free play mode, a ball test mode, and a very basic game of keep away that run on the engine.

Altair · Post by **Altair** » Sun Jun 25, 2006 10:32 am

Your first game sounds fun. To answer your last question is: very easy. Sorry but LUA is qlearly readible and the pictures are just png's or jpg's. Everything can be accessed without any problem.

To optimize your code you have to only blit the things that are actually visible and changing.

Kasumi · Post by **Kasumi** » Sun Jun 25, 2006 12:50 pm

Altair wrote:Your first game sounds fun. To answer your last question is: very easy. Sorry but LUA is qlearly readible and the pictures are just png's or jpg's. Everything can be accessed without any problem.

To optimize your code you have to only blit the things that are actually visible and changing.

Both versions make an attempt to do this. The "slow", smooth version checks where you are from the scrolling and only blits what's on screen. However, 480 / a 32 pixel wide tile = 15 and 272 / a 32 pixel tall tile = 8.5 or 9 rounded up. Which means it blits 135 tiles every time the screen scrolls. It also blits the sprite so that makes 136 total images.

The square by square one (Which shows the most promise), only blits the new tiles displayed when you scroll. and saves the rest to an image so that only about twenty four 32 by 32 images are blitted and two 512 by 272 images are blitted. That's 27 including the sprite. Interestingly enough this version doesn't seem to run ANY faster on a PSP than the 136 images blitted one.

It's not that I don't know that I need to only blit what's visible and changing. It's that I have no idea how to go about it and these two are my closest attempts.

Altair · Post by **Altair** » Mon Jun 26, 2006 9:09 pm

Ok so you are blitting everything to the screen? So every tile you say "screen:blit(x,y,tile,0,0,width,height)"? Because if you do that then indeed it has to blit everything one by one to the screen and LUA is really slow at that. Whta you should do is blit everything to another ofscreen image, lets say "map" and then you blit the map to the screen. This is way faster with LUA.

(I haven't checked your code so Im not sure if you already use this or not)

Kasumi · Post by **Kasumi** » Mon Jun 26, 2006 9:45 pm

Neither one blits everything at once. I know this because a 15 by 9 tile map is blitted no slower than a 320 by 320 tile map. It takes into account the scolling and blits the tiles shown accordingly. They also blit the tiles to a seperate empty image called "background1" which is then blitted to the screen.

The second file in the first post (slow, smooth) blits everything on screen every frame. However it's not noticeably slower than the first file which only blits to the screen the newly scrolled to tiles. There's a bunch of other junk in the first file that probably causes that, but when I remove anything to speed it up, I get weird graphical glitches. And it's looking like I'm getting no benefit of speed. I'm just about to give up on LUA for this particular project. I think that further down the line there's going to be a bunch else that will slow it down even further even if I ever get this to work as fast as I want it.

Altair · Post by **Altair** » Tue Jun 27, 2006 6:07 am

Hmm Im out of ideas. I checked your code (very clear structure) although i havent studied very well so it was a little confusing with all the bgtilesx bg1 etc. Sorry, i cant help you i think.
I thought it would have been better if I used a tile system in my game, but Im already having problems with the amount of units. Maybe I should just give up on LUA and start to learn C or something.

How I do scrolling is like this: I have one big image already loaded as the map and then I have the part that should be on screen blitted from that image. So there's only the blitting from the big image to the screen, instead of alot of small tiles.

Kasumi · Post by **Kasumi** » Tue Jun 27, 2006 7:48 am

So far it's looking like C is a better option for this type of game at least. I've done a few programs in C++ on the computer. I'm simply having a lot of trouble getting a PSP program to compile. (I've been working on getting all the proper things to work together to do that for a lot of the day...)

A large image as a map isn't an easy option for me, as this game was planned to be very large. (3200 by 3200 maps for the smaller towns)

My tileset (512 by 512 pixels) is 20 kb. A 3200 by 3200 .map file created with my editor is the exact same size. With a lot of maps things would get very big, very fast. There's also no way to easily create an image that way. With the map editor I created though, it's easy enough to make a loadable file.

So yeah... I'm gonna keep trying for a different sort of code then. Thanks for responding.

Altair · Post by **Altair** » Tue Jun 27, 2006 9:05 pm

np. If you find a good way please tell me/us. Maybe it'll help me/others aswell. If I think of something I'll post it too.

Kojima · Post by **Kojima** » Thu Jul 13, 2006 8:16 pm

The fatest way to blit a map (That I know of) is to only blit a visible portion of the map and to totally ignore the non-visble. Well actually you blit about 2 tiles in each direction more than visible, so when you're scrolling you don't get gaps in the map.

Here's some C++ code using a made up 2d library for how I'd do it.

Code: Select all


int ViewX = 20
int ViewY = 20
int TilesPerWidth = TileWidth / ScreenWidth;
int TilesPerHeight = TileHeight / ScreenHeight;
for&#40;int dx=ViewX-1;dx<ViewX+TilesPerWidth;dx++&#41;
&#123;
 for&#40;int dy=ViewY-1;dy<ViewY+TilesPerHeight;dy++&#41;
 &#123;
    int BlitX = &#40;Dx - MapX&#41;*TileWidth+ScrollX
    int BlitY = &#40;Dy - MapY&#41;*TileHeight+ScrollY
   BlitImage&#40; Tile&#91;dx&#93;&#91;dy&#93;,BlitX,BlitY &#41;
 &#125;

&#125;

That's laid out to be easy to understand. Ideally you'd pre-calculate as much as possible, and possible use lots for the blitx,y portion too, depending on your cpu load.

All in all this lets you blit a 1200x1200 map as fast as 120x120 map, because you only focusing on what's visible.

ScrollX/Y are scroll offsets that wrap around. they are in the range of 0..TileWidth/TileHeight

You'd also wanna throw in a depth for loop to speed things up.
Another speed up maybe gained by using while loops and breaking instead of for loops, depending on the compiler. In languages I've used and benchmarked it, while has been faster.

Altair · Post by **Altair** » Sun Jul 16, 2006 2:24 am

I already only blitted what is visible in all my games. Furthermore i dont even use tiles so its even faster (its just one big image. This way it doesn't have to blit all the tiles first). the thing is, LUA is just not fast enought to blit a lot of stuff at the same time.
Thx for the tip on the while loop being fater than the for loop, I didn;t know that.

Hmm i just thought of something (because of what i said and because of what you said). In LUA if you use a tile set, you should just blit all the tiles on a big image in the beginning of the game. Then you can just use it as a big map. In order to do this you need to load a JPG since a png cannot be bigger than 512x512 or something like that. However it should be small in filesize. I have a 1000x1000 JPG of about 58 kb. But there is stuff drawn on it, so it can be even smaller if there's nothing on it.
I haven't used it like this but i think it should work. Maybe if Kasumi still reads this, he could try this for his game.

Kasumi · Post by **Kasumi** » Sun Jul 16, 2006 2:56 pm

I've semi moved on to C for the game. I don't like LUA much anyway, due to the fact that everyone can easily steal your images, and edit your programs.