What I’ve got is multiple layers of tile grids, each with the same dimensions and everything, “stacked” on top of each other (because some things need to be drawn under other things).
When being painted, each “layer” is cycled through from back to front, meaning if each layer is 15x15 squares, then that’s how many times the layer’s repaint loops have to check for null squares/sprites/tiles to be drawn.
I’m starting to just learn about taking advantage of clipping areas, and repainting “dirty” regions with Java Graphics objects.
The system I use for traversing each layer’s grid is fairly simple: each layer has a Rectangle Field called “bounds,” which (for example) could be set to 15x15 (since I work with multiple levels of zoom, the actual pixel size of the layer is determined by [bounds * tile size * zoom factor]). So, the loops just go from 0 to bounds.width and bounds.height, originally designed to try and reduce working strictly with pixel locations.
Just so you understand my own understanding of my code, each time repaint is called, even with a dirty region, the loops have to traverse over 0 to bounds.width / bounds.height (right? Since the loops are still there…).
The way I have it currently makes me feel like even though I’ve specified dirty regions to repaint (for example, when mouse hovering), there is wasted CPU usage / resources iterating over each layers’ grid, even though (somehow, I don’t exactly understand) the graphics object currently does what I intend it to do (repaint for hovering mouse over new square / repainting to reset from mouse leaving square). I’ve checked this by setting the stroke to some obscure color and making it paint the clipBounds. Only the affected Tiles were changed.
Begin question:
Would it be more efficient to locate the clipBounds on-screen (pixel x & y) coordinates with the current Graphics object, and somehow start the loops only checking grid squares that are contained in and intersect the clipBounds? This would require some “extra” arithmetic prior to beginning the loops in order to determine which squares, from [x1][y1] to [x2][y2], lie in intersection with the clip bounds (the indices would be the same for all layers, since they all have equal tile dimensions).
For example, currently I have:
Mouse movement detected at point (x,y) on-screen. Convert (x,y) coordinate of MouseEvent to (X,Y) tile within the grid, retrieve Tile’s Rectangle bounds, and send that Rectangle as a dirty region to be repainted. Repaint then iterates over all layers, and within each layer, it iterates over all tiles from grid location (0,0) to (WIDTH)(HEIGHT). Somehow, because of the dirty region parameter passed, it only repaints the affected area once it reaches it within the loops, and the rest are left unchanged. However due to the nature of the repaint method, each Tile on each layer had to be passed and done “something” with, correct?
Would it be better to have:
Mouse movement detected at point (x,y) on-screen. Convert (x,y) coordinate of MouseEvent to (X,Y) tile within the grid, retrieve Tile’s Rectangle bounds, and send that as a dirty region to be repainted. Now, instead of iterating over the indices of the grid, start loop at first affected Tile’s (x,y) pixel location. Traverse loop in pixels, incrementing by the Tile’s width and height, until the clipBounds’ size has been exceeded.
Does this second way reduce computation energy and resources used?
Keep in mind, I am trying to highly optimize because I’m using a slightly old machine. This thing can give me a really good hunch as to whether or not what I’ve coded was done well or not. The reason this “problem” even came about is because I noticed a performance drop once the currently open Layers actually contain sprites/tiles and not empty space. It made me feel like something was being done with the entirety of each layers’ objects, and not just the objects that lie directly beneath the intersection of the clipBounds.