Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Awfully many sprites, what to do?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 iwantoski   Members   -  Reputation: 113

Like
0Likes
Like

Posted 13 December 2012 - 06:26 PM

(I think this is my first post here, so I guess a greet is in order: Ohai, thanks for having me!)

Mornin',

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.

Yours,
Me

Sponsor:

#2 Ravyne   GDNet+   -  Reputation: 7880

Like
0Likes
Like

Posted 13 December 2012 - 06:51 PM

If you know your tiles are opaque (that is, at least the 'lowest' level of each tile space has no transparent pixels) then you never have to clear the screen. If some tiles are not opaque, you only have to clear the area behind those tiles.

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.

#3 Sparkon   Members   -  Reputation: 395

Like
0Likes
Like

Posted 14 December 2012 - 04:56 AM

As Ravyne as said, just clear the screen if you need to. If your map is static, with that i mean that the tiles will never move or change, you could try to create an image out of that map.
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.

#4 Verik   Members   -  Reputation: 260

Like
0Likes
Like

Posted 14 December 2012 - 05:54 PM

Measure before you optimize. You might convince yourself you don't need to. And even if you find out that you do need to optimize, you are now capable of measuring the effects of your optimizations.

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS