K
Kululu17
Guest
Hi All,
I was hoping someone could explain what is causing the difference in processor load for a draw event, for a demo project I am working on.
I have a 2D map that I am drawing sprite by sprite in squares - the map is set up as a array, and the draw event loops through the map array, and draws each sprite in its proper place. Long term, I will probably switch to tiles, but for now I am using sprites, because what needs to get drawn is not fixed, but depends on a lot of different parameters (which character is viewing the map, which map mode you are in, etc). So for now I am just using sprites. Anyway, if I use a really big map, predictably the performance slows down a lot. I was able to get around this by changing the draw even to only draw the squares that are visible in the current view. So far, so good, and performance jumps back up to acceptable level.
Now here's the weird thing - the performance (fps) varies A LOT depending on where on the map you are looking at. For example if you are viewing the upper left corner of the map, fps is about 70, but if you scroll down to the lower right corner, the fps jumps to over 200. The total number of squares being drawn in each case should be the same, since I am referencing the upper right and lower left corner of the view (which doesn't change), and then drawing the sprites only for the map coordinates that fall within that frame.
Can someone explain why referencing different parts of the array (but the same total number of of values) seems to require different processor loads?
The code is below for reference... it goes longer and draws all kinds of things depending on various map parameters, view modes, etc, but the important part is shown here:
I was hoping someone could explain what is causing the difference in processor load for a draw event, for a demo project I am working on.
I have a 2D map that I am drawing sprite by sprite in squares - the map is set up as a array, and the draw event loops through the map array, and draws each sprite in its proper place. Long term, I will probably switch to tiles, but for now I am using sprites, because what needs to get drawn is not fixed, but depends on a lot of different parameters (which character is viewing the map, which map mode you are in, etc). So for now I am just using sprites. Anyway, if I use a really big map, predictably the performance slows down a lot. I was able to get around this by changing the draw even to only draw the squares that are visible in the current view. So far, so good, and performance jumps back up to acceptable level.
Now here's the weird thing - the performance (fps) varies A LOT depending on where on the map you are looking at. For example if you are viewing the upper left corner of the map, fps is about 70, but if you scroll down to the lower right corner, the fps jumps to over 200. The total number of squares being drawn in each case should be the same, since I am referencing the upper right and lower left corner of the view (which doesn't change), and then drawing the sprites only for the map coordinates that fall within that frame.
Can someone explain why referencing different parts of the array (but the same total number of of values) seems to require different processor loads?
The code is below for reference... it goes longer and draws all kinds of things depending on various map parameters, view modes, etc, but the important part is shown here:
Code:
var Quad_X;
var Quad_Y;
//Determine visible view, so that you only need to draw visible
var Visible_St_X = floor(view_xview[0]/g.Grid_Size);
var Visible_St_Y = floor(view_yview[0]/g.Grid_Size);
var Visible_End_X = ceil((view_xview[0]+view_wview[0])/g.Grid_Size);
var Visible_End_Y = ceil((view_yview[0]+view_hview[0])/g.Grid_Size);
//Make sure you do not exceed the array's range
Visible_St_X = max(Visible_St_X,1);
Visible_St_Y = max(Visible_St_Y,1);
Visible_End_X = min(Visible_End_X,g.Map_Width);
Visible_End_Y = min(Visible_End_Y,g.Map_Height);
//Could eventually be done as tiles, not sprites to save processor power
for (Quad_X = Visible_St_X; Quad_X <= Visible_End_X; Quad_X ++) {
for (Quad_Y = Visible_St_Y; Quad_Y <= Visible_End_Y; Quad_Y ++) {
var Quad_Number = script_execute(SCR_Get_Map_Key,Quad_X,Quad_Y);
draw_sprite(SPR_Map_Tile,-1,Quad_X*g.Grid_Size,Quad_Y*g.Grid_Size);//eliminating this has no noticeable effect
if g.Debugging_Info != "Off" && g.Exploration_Map[(Quad_Number),3] != 0 {//Here is the exploration overlay
draw_sprite(SPR_Show_Explore,-1,Quad_X*g.Grid_Size,Quad_Y*g.Grid_Size);
draw_text(Quad_X*g.Grid_Size,Quad_Y*g.Grid_Size,string(g.Exploration_Map[(Quad_Number),4])+" ("+string(g.Exploration_Map[(Quad_Number),3])+")")
}
var Hillsize = 0;
var Map_Hillsize = g.Global_Map[(Quad_Number),3];
if g.Debugging_Info != "Off" or g.Player_Map[(Quad_Number),3] >=1 {
switch Map_Hillsize {
case 10:
case 9:
draw_sprite(SPR_Hills,0,Quad_X*g.Grid_Size,Quad_Y*g.Grid_Size);
break;
case 8:
case 7:
case 6:
draw_sprite(SPR_Hills,1,Quad_X*g.Grid_Size,Quad_Y*g.Grid_Size);
break;
case 5:
case 4:
case 3:
draw_sprite(SPR_Hills,2,Quad_X*g.Grid_Size,Quad_Y*g.Grid_Size);
break;
}
}