i didnt read the last like 4 posts, but what about making some clumped prefabs.... like if an area has a square of like 9 of the same tiles, make 1 tile the size of 9 with 9 small tiles in it. the math shouldnt be too hard i dont think.

How about one relatively low-res bmap (obviously at something less than 32 bits per pixel) and use a shader to render the tiles over each pixel?

Jibb

In the end draw_quad still appears to slorp down to 15 fps. And I now have the disadvantage not to be able to draw panels in front of the level.

I guess clumped prefabs also requires a lot of calculating to determine where the clumps are, and again when a tile in the prefab is destroyed. But since there are large spots of ground that are all the same, may be a solution. It's just a downside that the fps goes down when you dig more pathways in the screen... unless the pathways are bitmaps in front of the tiles... hm...

Not sure about a shader, never fancied them as they tend to make my laptop cry (no matter how simple they are), and only used premade shaders thus far. I have no idea where to start writing a shader that puts tiles on pixels of a lower scaled bitmap generated from a noise function. I guess it's like using an array and bmap_blit, but somewhat faster?

The best approach would probably bmap_blit... Your problem is the high amount of draw calls, as each quad is rendered seperately and the parameters and stuff are probably all seperately updated. And while the bmap_blit itself won´t be extremely fast, it shouldn´t cause any problems as long as don´t change all tiles each frame. The resulting bitmap can than be rendered in just one draw call...
Another alternative not directly possible with gamestudio would be geometry shaders. The possible solution which is similar would be to prepare a mesh with the maximum number of quads you need and do some vertex manipulation on it to set positions and texcoords in an atlas texture. The last thing would probably be the fastest solution with gamestudio, but bmap_blit should be a bit easier to realize and perform good enough.

^ and when moving around I could simply bmap_blit that image, minus the row or column that I move from, and only update that part. Let's see how that performs.

If you had access to video memory, I could give you some extremely fast tile map drawing code I once wrote. It would give you at least 60 FPS as well as scrolling if you wanted it, and you wouldn't have to mess with updating only a few tiles per frame...

But shaders solve everything Ever. Forever.

Jibb

the geometry shader approach also came to my mind. but you can strip that down to a pure vertex shader approach. just prepare the mesh for all quads and then do a texture lookup to check which texture should be drawn; changing blocks then works via pixel_to_bmap.

I did a test rendering using simple pixel shaders some time ago.
This way you can fill your whole screen with multible layers of tiles at very high frame rates.
I see no reason not to use shaders even if you create something old-schoolish.

I do see it as an overkill
Slin's method of using bimap blitting looks more suitable I guess. Just use the blitting and erasing only when needed(even if you are going to do it on multiple tile, do it once at a time, spread the load), and there should be no slowdown.