Hey,

Though I just as well place it here. I'm running against problems with 3dgs when trying to show 80*60 little bitmap tiles on the screen. I want to make a little game like diggers/minecraft/dwarffortress in 2D; dig blocks and search for treasures. So I made a tileset with 8x8 tiles, and using some noise functions to create a 60*80 tiles geological landscape.



I first tried to use panels for each tile, but that soon proved to be very fps-inefficient. Then I used one panel and 80*60 windows on it. That worked significantly better, but 14 fps is not all that great. Using BMP instead of TGA saved me another 3 fps, but what else could I do to improve the framerate to at least 30? Should I approach this way differently? Any ideas?

Thanks,
Joozey

Use an array (or a bitmap, doesn't matter) and use draw_quad to draw bmaps on the specific positions, that works pretty well.
You can declare a BMAP array and draw the bitmaps f.i. as follows, should be self-explanatory:

For any 2D, polygons are better , a method used in other engones for 2D like Unity also !

What will be your new ideas in this game ?
Caus making exactly same ideas gameplays, feels a litlle useles, or can be good to learn !

Superku has the right idea but there are a few improvements that could be made. First of all the way he's doing it will cause the terrain to draw itself sideways, and the tiles will be spaced out far too much!



I like to keep as a general rule of thumb that whenever possible, use bit shifts to perform multiplication instead of straight multiplication. This is possible whenever you are multiplying a variable by a number that is a power of 2.

Also you should put the "y" for loop before the "x" for loop to get better caching performance.

Could you explain this, if possible in different words?
I think it's pretty obvious that "64" stands for the tile size in my example, and I don't get what you mean with "the terrain to draw itself sideways".
Of course there are more things to consider, f.i. you only draw the part of the array that is potentially visible (in a scrolling game).


What kind of difference is that supposed to make?

i had a similar problem and used a shader, it worked pretty neat - but i don't really have a clue whether this is a 'good' approach or not (my knowledge about shaders is actually non existent)...the method i used is the following(roughly) :

- create an entity with a skin of the size your landscape needs to have, for example : 80 * 60 pixels
- then use pixel_to_bmap to write a pixel with a color , for example (255, 0, 0) ! this pixel represents a tile ! and (255, 0, 0) is the type of the tile !
- then you only need a shader that reads the pixel value (thus for example 255, 0, 0) and then paints a bmap that represents the tile (like the one you now use as panel element) at the position where the pixel with the value is read...

Joozey stated in his first post that he was working with 8x8 tiles, so I naturally assumed that your example would use that size. Also, you were using the "y" variable to reference the tilemap column and the "x" variable to reference the tilemap row, and then you were drawing the tilemap with draw_quad with the "x" parameter as the column and the "y" parameter of the row! Basically, you confused the variables halfway through, which would cause the data to be drawn sideways. I've done it before lots of times.


2D arrays in C are stored in memory with each row of data stored in linear succession. Therefore if you put the for loop for "x" before "y" then you will start referencing row 1, column 1, and with each cycle you will go down one row until you reach column 2. This actually throws the CPU off, because it anticipates you to access the columns in succession, not the rows.

Basically the tilemap might visually look like this:

1, 2, 3, 4,
5, 6, 7, 8,
A, B, C, D

But it is stored in memory like this:

1, 2, 3, 4, 5, 6, 7, 8, A, B, C, D,

And if you access them the way you were doing, they are referenced in this order:

1, 5, A, 2, 6, B, 3, 7, C, 4, 8, D

Which completely throws off the CPU!

I did not confuse them, you've just assumed that the first index variable indicates a row. I know that it's against the convention (of matrix notation) and now I know how those arrays are saved internally, thanks to you, but it doesn't matter, my approach works fine as well. I've done it before.

On second thought, you're probably right on that point. I tend to confuse myself on those grounds and assume that the data is being stored by the matrix convention, because that's how I always did it.

Thanks Superku, had not thought of using that.

I'll have to rebuild the noise function, and store it in an array as quads need to be drawn every frame. The bitmap drawn by the quads is determined by a noise function consisting of several formulas. I can not recalculate those each frame, as that would be again very slow. When moving the screen I'll have to update the array with a column or row of new noise values from the new position then.