• Hey Guest! Ever feel like entering a Game Jam, but the time limit is always too much pressure? We get it... You lead a hectic life and dedicating 3 whole days to make a game just doesn't work for you! So, why not enter the GMC SLOW JAM? Take your time! Kick back and make your game over 4 months! Interested? Then just click here!

Do too many tiles slow down the game?

pixeltroid

Member
I spent 2 working on tiled graphics and adding them to my levels. It looks nice now, but the game has slowed down a bit. Initially my player would move fast and smooth before I added in those tiles.

I had the same problem earlier when I had too many objects, but I found a code to deactivate objects outside my view and it made my game fast again.

Is there a way to similar to deactivate tiles outside my view?

EDIT - I am using only 3-4 tile layers.

My average room size is 2000 x 1200 pixels.
 
Last edited:

TheouAegis

Member
Are you running any code on the tiles? Tiles shouldn't cause any slowdown outside the Draw event. If you're running code on the tiles, that causes the most significant slowdown.
 

pixeltroid

Member
Are you running any code on the tiles? Tiles shouldn't cause any slowdown outside the Draw event. If you're running code on the tiles, that causes the most significant slowdown.
I'm not using code on the tiles at all. (I don't even know how to).

I just placed them in the levels.
 

Zerb Games

Member
Yes, of course. Just like anything it slows down the game a little but tiles are incredibly efficient, and really shouldn't slow down the game much. Objects in comparison are incredibly inefficient, and really shouldn't be used in their place unless it's on a small scale.

Too many is an incredibly high number.
 
A

anomalous

Guest
You didn't mention tile count. What's your tile size?
Generally no, you can delete tiles out of view, but if you are already at min tiles to fit view, you're out of luck...however I'd be surprised if that were the case.

Your overall speed should slow when you add your entire screen drawing of tiles...but your FPS should not drop below 60 in doing so (assuming you run at 60fps) just from that many tiles (tbd above).

Other options include drawing instead to a surface, but it really all depends on room size, target platform, and other constraints.
 

TheouAegis

Member
I filled a room with 4 layers of 16x16 tiles and the fps_real was still over 700 on average. Granted, with no tiles it was over 2000, but all that slowdown was during the Draw event. The same number of instances created and then deactivated outside the view resulted in 500 fps on average for me; while the Draw Event was faster, the Step Event was much slower.

GM needs to optimize its tiles, period. Tiles should be indexed like backgrounds, but GM has a system in place that allows tiles to be of various sizes and as a result (due to the programming), tiles are grossly inefficient for what they should be.
 

TheouAegis

Member
@seanm Actually I reran a test I did back on GM8 and it seems Studio did optimize them a little. I got an improvement of about 75% over the expected results of the test. So I'm not sure what YYG changed, but tiles do run a little bit faster

As for possible optimization, I'd just like if they treated tiles as how they should be. If you're going to define a background as a tile sheet and assign widths and heights to the tiles, then it should index the tiles accordingly.

ABCD
EFGH
KLMN
OPRS

If you click on A, and put it in the room, it should write to the map that A is in the room. If you click and drag from A to F and put it in the room, it should write A, B, E and F to the map. However, that is too restrictive for a lot of people, so it seems all the tile definitions are only for the frontend while the game simply writes the all the same arguments used in draw_background_part() and the depth of a tile seems to be indexed (hence why you have tile_layer* functions and not any other broad tile functions).

I'm all for a more restrictive interface for the sake of vast improvements over speed. However, as I said, there has already been a 75% improvement over tile speed between GM8 and the latest stable GMS. It's not enough of an improvement for some people, obviously, but it appeased me well enough.
 
M

Misty

Guest
Why not just draw all the tiles to a surface, then delete all the tiles?
 

TheouAegis

Member
@seanm Oh, and to elaborate a tad, I'd like if you define a background as a tile sheet that GM maps each tile as separate textures on the texture page and that A,B,C,D stuff I was talking about would be the IDs of the tiles in the sheet. So in essence, I'd like for GM to treat tiles the same as it treats backgrounds and sprites. As it is, it still seems to treat them as arrays of arguments, albeit perhaps with a bit better indexing (compared to GM8).
 

TheouAegis

Member
Why not just draw all the tiles to a surface, then delete all the tiles?
Don't delete tiles. Hide the layer(s) they're on. Tiles themselves aren't slow, the drawing of them is slow. Tiles are useful even when they're not drawn, just like instances.
 
M

Misty

Guest
I am wondering, are there any computers out there that cannot draw surfaces besides the default application surface? Because even my computer can do surfaces.
 

TheouAegis

Member
Not as far as I know. It is just video memory allocated to GM. I think when GM creates a new surface, it asks the video card to allocate it more memory. That's why if you don't clear a surface before drawing it, you'll see garbage from your OS/other programs.
 

RangerX

Member
By testing my game on different setups, I found some toshiba laptops and some PCs having a certain models of Intel graphic ships that REALLY don't like surfaces. As soon as there are graphics that aren't at a power of 2 size they panic.
One of those setups happens to be the one of my brother, which is doing music production and a ton of costly tasks on its computer + gaming alot. Its only with GMS surfaces that it panics.

another thing, more on topic, tiles that aren't on screen aren't drawn. So I really wonder why you get that much slowdown.
 
S

seanm

Guest
@TheouAegis Ahh, that does clarify things a lot, thanks.

@RangerX It seems like tiles and objects, don't actually use random access data structures. The more objects/tiles you have, the longer it takes to access any specific tile/object. So if you have thousands of tiles, you will experience slowdown only when you try and access the tile data structure. Other than that, there's no issue.
 

RangerX

Member
@TheouAegis Ahh, that does clarify things a lot, thanks.

@RangerX It seems like tiles and objects, don't actually use random access data structures. The more objects/tiles you have, the longer it takes to access any specific tile/object. So if you have thousands of tiles, you will experience slowdown only when you try and access the tile data structure. Other than that, there's no issue.
I understand, but he said he doesn't use any tile function. He doesn't touch nothing, he just have tiles in the room editor that's all.
 

TheouAegis

Member
Actually I want to run a couple more test when I get home in a few minutes, but I have this nagging feeling that having more than one layer of tiles even if they're not being drawn automatically is slowing game maker down. I was getting some results this morning and I am not sure if it was an error in my code logic or an actual issue with game maker
 

RangerX

Member
Probably that everything that's "on screen" is actually drawn. You can test it but I'd bet if you have 30 layers of tiles on top of each other, all of them are drawn even if you only see "layer 30".
 
R

Robert

Guest
I didn't read through all the replies so forgive me if you already solved this, but it's worth mentioning that you should make sure your room speed is higher than 30, and also try setting vsync on as I have lag with gm ify room speed is low(under 100) and vsync off (Windows graphics area to enable). Usually you don't notice the lag until you start getting objects or tiles added to the room. Just try vsync and see. Good luck
 
R

renex

Guest
You can also manually precompile all tiles to a vertex buffer. There are several methods to do this but the general idea is to reduce the workload of the engine by making tiles a single draw call.

You could also separate them in layers / textures by using multiple vertex buffers.

Last time I messed around with this, I could render millions of tiles before hitting a fillrate brickwall.
 

TheouAegis

Member
Probably that everything that's "on screen" is actually drawn. You can test it but I'd bet if you have 30 layers of tiles on top of each other, all of them are drawn even if you only see "layer 30".
I forgot to run the test last night and now I have to go to work. But the issue I think I was having had to do with having 5 layers (one just outside each edge of the view and one in the middle of the view) and disabling the visible (in-view) layer. I wasn't getting the change in fps that i had expected.
 
I made a mistake in my chunk system prototype recently and ended up piling 5 screens worth of tiles at coordinate 0, 0. Nasty slow down as you might expect. soon as they were offscreen, the slowdown vanished. interestingly enough, I got a major performance boost with the tiles half out of view. wasn't looking at fpsreal though so I can't tell you the gritty details beyond that, sufficed to say that tiles are definitely not drawn out of view.
 
R

renex

Guest
interestingly enough, I got a major performance boost with the tiles half out of view.
Fillrate. It had so many fragment operations going on at that point that it bottlenecked your gpu, but putting half the workload offscreen allowed it to keep up again.

As an example, here's an old test with 100000 quads. They are small enough that my gpu can still finish everything in time:


However, jumping to one million quads completely wrecks the speed out of proportion.



What's interesting to note, though, is that reducing the zoom in this 1000000-quad test allowed it to hit at least 100 fps if I recall correctly.

tiles are definitely not drawn out of view
This can only be tested properly using 3d views. For some insane reason, GMS still uses view boundaries to determine the clipping rectangle for 2d draw operations, even if you use no views at all or a 3d projection. This is very easily seen with sprite font rendering. This is a major source of frustration for me, and it's been on Mantis several times. However, this is only valid for internal draw routines - which is actually one of the things that prompted me to create a batch optimizer for tiles and text.

This is achieved with only three draw calls:



Sounds like a tutorial is needed. Or is there a link to one? (hint hint) ;)
The code is terrible, but I do have plans to refactor and upload Batchman to the marketplace. It doesn't look like it but I spent several weeks working on it and would definitely not just throw it around like that, hehehe. It's not even done yet.
 
@renex , interesting information and good to know. I was debating if unloading tiles was worth the effort for my chunking prototype, but based on what you said, sounds like it's a good idea. luckily, I had designed the system to be theoretically infinite and to handle unloading from the start, so bonus!
 
Top