Members - Reputation: 113
Posted 13 December 2012 - 06:26 PM
My goal is to create something close to what BrowserQuest is, but in Java using LWJGL (of which I am a newbie of both).
So far it pretty much works as intended. I'm using ARB_Texture_Rectangle to load sprite sheets, I'm reading my PNG files correctly and am able to specify which tile I want to use, and render it. Got animations working based on time delta for each update and so on. Again, works as expected.
I am doing a few more sprites per frame visible compared to BrowserQuest (honest guess). I'm working a 960x512 display, with 16x16 tiles. This sums to 1920 tiles to render my "map". This is excluding multiple layers, players and objects (such as swords, npcs etc).
Currently, how I've done it is that I'm reading an xml file (or tmx) generated by the Tiled app. Each tile is specifically specified, and unless it's 0 I draw a sprite.
I am worried about the fact that I need to render at the very least 1920 tiles just to render a frame.
I'm currently capping my frame rate at 60 using the Display.sync(60). I don't experience lag, flicker or anything alike as of today - however I am worried about the fact that I might be going about this the wrong way?
As of now I'm clearing the whole screen which maybe that isn't necessary. Is there a way to clear a specific part of the screen? I'm clearing the full screen using glClear() passing color and depth buffer enums.
Should I be looking at some type of render caching? I've yet to dip a toe into what VBOs actually are - though I feel I'm in pretty deep as it is and I shouldn't be digging deeper unless there's a good reason for it.
Any tip or useful resources is greatly appreciated as I am indeed a terrible newb who came from a PHP web world not to many weeks ago.
GDNet+ - Reputation: 9645
Posted 13 December 2012 - 06:51 PM
As for the number of sprites/tiles, I wouldn't be too worried about it unless you're using individual textures for each tile or sprite. Its switching state (like shaders, or textures) that kills performance. You can minimize state change by, for example, keeping all your 'ground' textures in one big texture -- sounds like you're doing this already. 1920 sprites is nothing -- that's not even enough to make a circa 1996 software renderer sweat.
Members - Reputation: 395
Posted 14 December 2012 - 04:56 AM
I'm sorry i can't provide any code since i'm using c++, but in the loading phase you could do a slow per-pixel copy ( since your screen is not so big it will be really fast ) and create an image, then instead of looping in each tile and draw it you could simply draw the image. If it's a static map this will really boost your performance if you are using many tiles. Then if the whole map is moving ( map is bigger than screen boundaries ) you simply draw the map based on you character ( i presume ) offset.
Members - Reputation: 276
Posted 14 December 2012 - 05:54 PM
Use System.nanoTime() at the start and end of your render cycle to get a feel for your render time. Don't use System.currentTimeMillis as it has an unreliable resolution that can be in the order of 20ms.