5 replies to this topic

[Enedin]

I've run into a problem with my latest project. The project involves creating a world like the one in Transport Tycoon, and that was achieved quite easily through the use of 2D arrays and a lot of for-loops.


The map shown by drawing the correct tile[ix,iy] at location xu[ix,iy] and yu[ix,iy] for every ix,iy.

Bigger maps, however, devour resources. Therefore I decided to convert everything to ds_grid functions. I am currently in the process of converting everything to ds_grid functions, but I can't seem to get this one thing working.

In the original, I use 2 for-loops in which I check every tile for its distance to the mouse. The tile that is closest to the mouse (the current ix,iy) passes on its coordinates to cmx,cmy, which is then injected into 2 arrays (xu[cmx,cmy] and yu[cmx,cmy]) which tell me the x and y coordinates of the current tile on screen.

    maxdistm = 1000;
    mx = xu[cmx,cmy];
    my = yu[cmx,cmy];

    for (ix = 1; ix <= width+1 ; ix += 1)
    {   for (iy = 1; iy <= length+1 ; iy += 1)
        {   
            // find corner closest to mouse to determine mousecorner
            if (abs(mouse_x-xu[ix,iy]) < u) // if the mouse isn't too far from the current tile, x-wise
            {
                if (abs(mouse_y-yu[ix,iy]) < u) // if the mouse isn't too far from the current tile, y-wise
                {
                    distm = point_distance(xu[ix,iy],yu[ix,iy],mouse_x,mouse_y);
                    if (distm < maxdistm) {maxdistm = distm; cmx = ix; cmy = iy;}
                }
            }
        }
    }

    // draw cursor
    draw_sprite_ext(sprCursor,0,mx,my,1/(zoomval[zoom]/100),1/(zoomval[zoom]/100),0,c_white,1);

Now, this works fine. The problem is that this is way too slow, and thus I need everything converted to grids. I've tried converting this to grids, but I can't seem to find how to extract the coordinates I need from the grids.

What I have:

- mouse coordinates mouse_x,mouse_y
- grid grid_xu which contains the on-screen x-coordinate for each cell (equivalent to xu[ix,iy])
- grid grid_yu which contains the on-screen y-coordinate for each cell (equivalent to yu[ix,iy])

What I need:

- cmx,cmy which is the location of the cell on the map that holds the same on-screen x and y coordinate as the mouse (in other words, the cell that is directly under the mouse on the screen)

How to get there:

- mouse coordinates > find cell in grid_xu that holds mouse_x and cell in grid_yu that holds mouse_y > extract that cell's location (cmx,cmy)

In the original example (using arrays), I just checked every cell near the mouse to determine which is closest. But I'm at a loss with grids, as I've no experience using them. Is anyone able to help me?

[Enedin]

By using a for-loop I got the whole thing working the same way as I did with arrays, but I swapped in the ds_grid functions. Whereas arrays would reduce the fps to around 13-14, I can get 43-45ish now. Guess I'll have to use for-loops. I'll try and optimize some more.

[brac37]

Use models. They are a lot faster since they are remembered by gamemaker.

[Enedin]

Use models. They are a lot faster since they are remembered by gamemaker.

Replacing arrays with a grid seems logical, but replacing arrays with models? How does that work?

[xot]

You need a new approach. Grids aren't going to make anything any faster. The problem is computing the mouse-cell distance (width*length) times each step. Instead, take the mouse screen coordinates and perform an inverse transform based on whatever formula you used to compute the xu[],yu[] arrays. That will give you the cell indices directly without the need to use point_distance or cycle though every cell.

Another approach: If you wanted to get nutty, there is a little trick you can do with models and a special texture. With it, each cell is given a unique color and the color encodes the cell indices in some way (eg. red = ix, green = iy). If you draw this specially colored model and use draw_getpixel() to check the color under the mouse, you can easily compute its location on the model based on the returned color. The advantage is it works like magic when the model is of any shape and is drawn in any orientation or position. The disadvantage is having to draw the model twice: once for the mouse interface and once for the player view.

Edited by xot, 12 April 2012 - 10:16 PM.

[DanRedux]

Xot stop giving out all the big, efficient, automagic secrets!