So I know in a Tile Based game its more effecient to have static final instances of each tile, then populate your array with those instances. But what about Rendering? You have to pass the position that tile should be rendered into your method you use for rendering. Is there a way for the tile to render from its position in a Tile array? Is passing in a position each render the most effecient way?
The only thing that matters is that you load the tile once to create a Tile object that persists for the whole game. Provided you do that, static or final won't make any difference. Regardless of how you track those objects (in an array or a List etc) they still give you the address of the Tile object so the renderer can access it. Remember that arrays etc do not actually contain Objects, they just contain references (pointers) to the objects.
There's much out-of-date info on the web regarding efficient graphics in Java. In particular you used to have to handle your own double-buffering, but now that's done automatically by default.
@JamesCherrill I get what you're saying, however I'm not really feeling like my question has been fully answered. I basically wanna know if there is a way to render without passing the position every time it renders, almost as if each tile (which doesn't move) stays in it's own position.
I get that with each render, the screen "clears" before drawing all the pixels again. I think this is where I'm questioning things.
I'm using Spritesheets then cutting the images out. They're bufferedImages when they're passed into the Tile Object.
I'm rendering an area around the player, not the entire tile array. Also, when I introduce npc's and enemies into the game, I need to implement movement even if they are out of range of the player. I was wondering if it was really expensive to tick everything that needs to move, or do something while the player isn't nearby. Or would you go another route of a larger area around the player, and just update those?
This sounds like the "premature optimisation" anti-pattern!
I would concentrate on getting it working properly with a simple implementation (eg re-draw everything each tick). If you try to optimise too early then
1) You may well be wasting time fixing a non-problem
2) Your optimisation may well clash with things you have to do later to complete the functionality
I'm not saying ignore efficiency totally. You should try to start with simple clean sensible data structures and algorithms, but do not complicate things until/unless you know you have a performance issue and you have understood all the constarints of the full functionality.
If you have a strong suspicion that a particular area will be a perfomance bottleneck then define it as an interface and provide a basic implementation. That way if later it is confirmed to be a problem you can swap in different implementations.
Finally, remember you have a machine that processes thousands of instructions in a microsecond, and most of those instructions are OS and JRE, not your code.