Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (498)
Games in Android Showcase (115)
games submitted by our members
Games in WIP (562)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Sprites!  (Read 12756 times)
0 Members and 1 Guest are viewing this topic.
Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Posted 2010-01-13 13:00:44 »

Arrgh! Me sprite engine isn't fast enough!

Revenge of the Titans continues apace, with all sorts of extreme niceness being packed in there. Unfortunately this niceness has come at a bit of a cost; we're now rendering around 1,000 sprites per frame (in maybe 100 draw calls) and we're getting performance issues (that is, rendering at less than 60fps). Investigation reveals that the biggest bit of compiled code that takes the most time is the writeSpriteToBuffer call in the DefaultSpriteRenderer.

I think that buffer bounds checks are probably accounting for a not inconsiderable time waste, and probably also some general Java inefficiency at dealing with floating point mults and adds but without looking at the equivalent assembly produced by C++ and the JVM I can't really speculate. And anyway, there's pretty much bugger all I can do about the contents of that method: I have to do everything in there.

Also, the number of draw calls cannot really be optimised any more than it already is optimising: the sprites are already sorted into the best possible (and only possible) rendering order by virtue of their Y coordinates, layers, sublayers, texture IDs, and rendering state.

So, the only other thing I can think of that will optimise things is using some modernfangled OpenGL cleverness like VBOs or somesuch. I used to use NVidia's fence stuff and AGP RAM but no longer as it only worked on half the machines out there.

Will VBOs make things any faster for me? The actual amount of vertex data is pretty piddly - we're only talking 1,000 sprites a frame here, that's 4,000 vertices, or 125kb (yes, kilobytes!) of data being sent to OpenGL, and that's being split up into roughly 100 1kb chunks anyway by virtue of the required rendering order.

I'm otherwise rather dismayed at the atrocious performance I seem to be getting these days Sad

Cas Smiley

Offline Spasi
« Reply #1 - Posted 2010-01-13 13:42:51 »

You can try pseudo-instancing or ARB_draw_instanced on modern GPUs. You could also use texture atlases or a unified fragment shader that does multiple kinds of rendering, to reduce the number of draw calls.

It all depends on the specifics of your rendering code of course. There are lots of tricks you can use if you're willing to exploit shaders, but I'm fairly sure you're going to want a solution that works on older hardware. Unfortunately, I don't think simply switching to VBOs would make a significant difference, for sprite rendering that is. It could provide a slight performance boost, but I find that VBOs are too platform/vendor sensitive. I wouldn't depend on them on pre-shader hardware anyway.
Offline pjt33
« Reply #2 - Posted 2010-01-13 14:16:46 »

Are you sure that you're limited by the Java code rather than by the fill rate of the graphics card? (And if so, can you tell me how to test this? I'd love to know).
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kappa
« League of Dukes »

JGO Kernel


Medals: 77
Projects: 15


★★★★★


« Reply #3 - Posted 2010-01-13 14:17:52 »

From the brief look at your code, I see your still using Java's default Math library. (cos, sin, tan, atan, atan2 are all very slow on it), you should really be using Riven's FastMath library, its upto 8x faster then java's default Math library. From what I've seen it really does have a big impact in speeding up code, especially for action packed 2d games. Another nice thing about it is it uses all float Math so no need to be casting from double or even using double. (riven's site seems to be down atm but might be up again soon).

Also use the following method as an alternative to Math.random() http://www.java-gaming.org/topics/math-random/18426/msg/155445/view.html#msg155445
again massively faster then Math.random()

Also what type of Lists are you using? (if any)
Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #4 - Posted 2010-01-13 14:58:56 »

@Spasi - looks like it might be fraught with pitfalls and complexity, I have a feeling also that it won't help too much.

@pjt33 - profiling shows I'm spending, er what was it, 7.5% of the time writing sprites and 35% of the time calling gl commands (25% glDrawArrays or so). That's on my uber-rig. I wondered if by using some sort of magic VBO memory the glDrawArrays commands would either be quicker or return asynchronously or something clever like that, letting me get on with doing something else with the CPU other than waiting for the GPU to finish.

@kapta - 99% of the sprites aren't rotated, so the vast majority of sprites drawn never go near sin or cos, so there's little point in trying to optimise those calls away. About half the sprites in the frame are scaled, which makes for 4 floating point mults in addition to the floating point adds. I suspect that's probably far less time than I worry about. I would like to know if there was some way to disable buffer bounds checking and see if that's slowing things down much but I kinda doubt it - after all the actual drawing is taking 4x as long as the data collection phase.

I barely use random numbers, and I barely use Lists. The GC rarely ever fires off ever.

Cas Smiley

Offline elias4444

Junior Member





« Reply #5 - Posted 2010-01-13 16:41:52 »

I'm gonna say it...

Try implementing VBOs!  Roll Eyes

My MvR engine was mostly DisplayLists and the like. With my new engine, I switched over to VBOs (which I admit, took some restructuring). The speed increase was VERY noticeable. I even switched my font rendering class over (which is basically like your sprite rendering) and noticed a big leap there as well. I have to wonder if the drivers these days are just geared that way.

The other big leap I saw was when I moved from individual textures for sprites to a single, larger texture with all the sprite graphics in it. It didn't help much when I was using DisplayLists, but with VBOs it was a different story.

NOW, my engine isn't just for sprites, so your mileage may vary.

Here, this will help you on your way (it's the least I can do for the help you've given me):

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
64  
65  
66  
package com.tommyengine.utils;

import java.nio.FloatBuffer;
import java.nio.IntBuffer;

import org.lwjgl.BufferUtils;
import org.lwjgl.Sys;
import org.lwjgl.opengl.ARBVertexBufferObject;
import org.lwjgl.opengl.GLContext;

public class VBOUtil {

   /*
    * To create a VBO ID
    */

   public static int createVBOID() {
      if (GLContext.getCapabilities().GL_ARB_vertex_buffer_object) {
         IntBuffer buffer = BufferUtils.createIntBuffer(1);
         ARBVertexBufferObject.glGenBuffersARB(buffer);
         return buffer.get(0);
      } else {
         Sys.alert("ERROR", "VBOs not supported on this hardware");
         System.exit(0);
         return 0;
      }
   }

   public static void destroyVBOID(int id) {
      ARBVertexBufferObject.glUnmapBufferARB(id);
   }

   public static void bufferDynamicData(int id, FloatBuffer buffer) {
      ARBVertexBufferObject.glBindBufferARB(ARBVertexBufferObject.GL_ARRAY_BUFFER_ARB, id);
      ARBVertexBufferObject.glBufferDataARB(ARBVertexBufferObject.GL_ARRAY_BUFFER_ARB, buffer, ARBVertexBufferObject.GL_DYNAMIC_DRAW_ARB);
   }

   public static void bufferStaticData(int id, FloatBuffer buffer) {
      ARBVertexBufferObject.glBindBufferARB(ARBVertexBufferObject.GL_ARRAY_BUFFER_ARB, id);
      ARBVertexBufferObject.glBufferDataARB(ARBVertexBufferObject.GL_ARRAY_BUFFER_ARB, buffer, ARBVertexBufferObject.GL_STATIC_DRAW_ARB);
   }

   public static void updateBufferData(int id, FloatBuffer buffer) {
      ARBVertexBufferObject.glBindBufferARB(ARBVertexBufferObject.GL_ARRAY_BUFFER_ARB, id);
      ARBVertexBufferObject.glBufferDataARB(ARBVertexBufferObject.GL_ARRAY_BUFFER_ARB, buffer, ARBVertexBufferObject.GL_DYNAMIC_DRAW_ARB);
   }

   public static void bind(int vboID) {
      ARBVertexBufferObject.glBindBufferARB( ARBVertexBufferObject.GL_ARRAY_BUFFER_ARB, vboID );
   }

   
   //////////////////////////////////////
  //// For Index Buffers (IDOs) ////////
  //////////////////////////////////////

   public static void bindIndex(int vboID) {
      ARBVertexBufferObject.glBindBufferARB( ARBVertexBufferObject.GL_ELEMENT_ARRAY_BUFFER_ARB, vboID );
   }

   public static void bufferIndexData(int id, IntBuffer buffer) {
      ARBVertexBufferObject.glBindBufferARB(ARBVertexBufferObject.GL_ELEMENT_ARRAY_BUFFER_ARB, id);
      ARBVertexBufferObject.glBufferDataARB(ARBVertexBufferObject.GL_ELEMENT_ARRAY_BUFFER_ARB, buffer, ARBVertexBufferObject.GL_STATIC_DRAW_ARB);
   }


}


A sample VBO creation using that code:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
// Geometry = FloatBuffer()  -- but I'm guessing you knew that

// .put() all of your vertice information into geometry here

coordsVBOID = VBOUtil.createVBOID();
geometry.flip();
VBOUtil.bufferDynamicData(coordsVBOID, geometry);

// .put() all of your vertice information into textureCoords here

textureVBOID = VBOUtil.createVBOID();
textureCoords.flip();
VBOUtil.bufferDynamicData(textureVBOID, textureCoords);


A sample draw routine:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
GL11.glEnableClientState(GL11.GL_VERTEX_ARRAY);
VBOUtil.bind(coordsVBOID);
GL11.glVertexPointer(3, GL11.GL_FLOAT, 0, 0);

GL11.glEnableClientState(GL11.GL_TEXTURE_COORD_ARRAY);
VBOUtil.bind(textureVBOID);
GL11.glTexCoordPointer(2, GL11.GL_FLOAT, 0, 0);

GL11.glDrawArrays(GL11.GL_TRIANGLES, 0, vertexCount);

GL11.glDisableClientState(GL11.GL_TEXTURE_COORD_ARRAY);
GL11.glDisableClientState(GL11.GL_VERTEX_ARRAY);


Good luck!

Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2010-01-13 16:50:25 »

Actually that's rather helpful just having it there to stare at. I've been skirting around VBOs for years because they used to be a bit rubbish and I never really needed the performance before. Let's hope that it gets me that much-needed speed increase! (I've managed to get another 10% boost by using the server VM too)

Cas Smiley

Offline elias4444

Junior Member





« Reply #7 - Posted 2010-01-13 16:52:23 »

DOH! And I just remembered... I super-boosted my particle engine performance by moving all of the QUAD sprites for it into a SINGLE VBO!!!! Yes! A SINGLE VBO!!! It drastically reduced my number of GL calls.

My ENTIRE list of viewable particles (which are all QUAD sprites) is called by this single function:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
   public void draw() {

      int vertexCount = (numVisible)*4;
      if (vertexCount > 0) {

         GL11.glPushMatrix();

         texture.bind();

         GL11.glEnableClientState(GL11.GL_VERTEX_ARRAY);
         GL11.glEnableClientState(GL11.GL_COLOR_ARRAY);
         GL11.glEnableClientState(GL11.GL_TEXTURE_COORD_ARRAY);

         VBOUtil.bind(geomVBOID);
         GL11.glVertexPointer(3, GL11.GL_FLOAT, 0, 0);

         VBOUtil.bind(colorVBOID);
         GL11.glColorPointer(4, GL11.GL_FLOAT, 0, 0);

         VBOUtil.bind(texVBOID);
         GL11.glTexCoordPointer(2, GL11.GL_FLOAT, 0, 0);

         GL11.glDrawArrays(GL11.GL_QUADS, 0, vertexCount);

         GL11.glDisableClientState(GL11.GL_VERTEX_ARRAY);
         GL11.glDisableClientState(GL11.GL_COLOR_ARRAY);
         GL11.glDisableClientState(GL11.GL_TEXTURE_COORD_ARRAY);
         
         Texture.unbind();

         GL11.glPopMatrix();

      }


That's the power of VBOs. When I update the particles, I literally just clear the FloatBuffers, recalculate each particle (I have a particle array for ongoing data), throw them back into the FloatBuffers via .put(), and then call:

1  
2  
3  
4  
particleGeometry.flip();
VBOUtil.updateBufferData(geomVBOID, particleGeometry);
particleColoring.flip();
VBOUtil.updateBufferData(colorVBOID, particleColoring);

Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2010-01-13 16:59:13 »

My sprite engines a bit more generic than that, it's already pretty much doing that wherever it can. One of the real killers is Y-sort. I wonder if there's any easy way I can optimise that part. I only need to Y-sort if the sprites actually overlap each other. What I need is an algorithm to band them together, even if roughly.

Cas Smiley

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #9 - Posted 2010-01-13 17:47:28 »

Inplace array-sort (better than Arrays.sort() that creates an auxiliary Object[])
http://riven8192.blogspot.com/2009/08/arraysorter-in-place-one-thread.html

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #10 - Posted 2010-01-13 18:22:00 »

Take a peek at the sprite engine sort Wink

Cas Smiley

Offline elias4444

Junior Member





« Reply #11 - Posted 2010-01-13 18:23:03 »

Your problems with Y-sort seem a little hefty considering it's a sprite-based game. Can you give me an example of the sprites that need to be sorted, and why?

Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #12 - Posted 2010-01-13 18:45:09 »

I;'m pretty sure I found the cause of your dogslow writeSpriteToBuffer() method


You are writing data with FloatBuffer.put(value).

Relative puts are SLOW. it's not like floatArray[p++] = value

Perform management of the 'offset' yourself and see a massive performance increase.


Old:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
  481       i += VERTEX_SIZE;
  482
  483       buffer.floats.position(i >> 2);
  484       buffer.floats.put(x10);
  485       buffer.floats.put(y10);
  486       buffer.floats.put(z);
  487       buffer.floats.put(s.isMirrored() ? tx0 : tx1);
  488       buffer.floats.put(s.isFlipped() ? ty0 : ty1);
  489       if (useTexture1) {
  490          buffer.floats.put(s.getTx10());
  491          buffer.floats.put(s.getTy10());
  492       }



New:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
  481       i += VERTEX_SIZE;
  482
  483       p = i >> 2;
  484       buffer.floats.put(p++, x10);
  485       buffer.floats.put(p++, y10);
  486       buffer.floats.put(p++, z);
  487       buffer.floats.put(p++, s.isMirrored() ? tx0 : tx1);
  488       buffer.floats.put(p++, s.isFlipped() ? ty0 : ty1);
  489       if (useTexture1) {
  490          buffer.floats.put(p++, s.getTx10());
  491          buffer.floats.put(p++, s.getTy10());
  492       }


Due to the non-deterministic behaviour of HotSpot regarding Buffer performance, it might even be better to dump your data into float[]s and byte[]s and put() them into your FloatBuffer/ByteBuffer

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #13 - Posted 2010-01-13 18:49:26 »

Ooh! That sounds like a useful tip. I will give it a whirl.

You'll soon see why we need to do Y sorting.

Cas Smiley

Offline EgonOlsen
« Reply #14 - Posted 2010-01-13 20:32:54 »

How large are these sprites actually? I did a quick test with a pretty stupid sprite blitter that even uses Collections.sort() each frame to do the y-sort (http://www.jpct.net/download/hacks/SpriteTest.zip - SPACE to add 1000 sprites, s to toggle size) and tried how many alpha blended and scaled sprites i could blit onto a 1024*768 screen before falling below 60 fps. The results (large sprites/small sprites) ranged from ~12000/~20000 on a Core2 Quad @ 3.2Ghz/Radeon 5870 down to ~100/~2100 on a P4 @ 2.2Ghz/Geforce 2 Go with an older midrange system AthlonX2@2200Mhz/ATI 3650 AGP being somewhere in the middle with ~1000/~12000. On what kind of system are you actually running your tests on?

Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2010-01-13 20:41:23 »

5000 small sprites runs at ~60fps using the server VM. Are those sprites alpha blended?

It's an AMD Turion 64, dual core 1.6GHz. The chipset is a 6150 Go.

Cas Smiley

Offline EgonOlsen
« Reply #16 - Posted 2010-01-13 20:46:28 »

5000 small sprites runs at ~60fps using the server VM. Are those sprites alpha blended?
Yes, all of them. But the alpha channel isn't pretty, because it's calculated at load time based on the black parts of the texture.

Offline elias4444

Junior Member





« Reply #17 - Posted 2010-01-13 20:56:28 »

Riven: I just tried your method of using an index for the buffer puts... it cut my performance more than in half. I get much better performance clearing the buffer and then refilling it with the updated information. I'm therefore guessing you were specifically talking about instances where you're only updating a small portion of the data in the buffer?

Offline thalador

Senior Newbie





« Reply #18 - Posted 2010-01-13 21:04:56 »

I also got a huuuge performance boost when switching to VBOs.

Riven mentioned the Buffers put() operation: For me single put()s are pretty slow, I try to put() everything in the Buffer with a single put(). To do that I keep arrays for all the data (vertex, color, etc. ) and collect the game's data in there every frame and then put it in the buffer with one call. I even don't create the arrays every render call to keep the garbage low. Instead a simple int shows how big the array is. Works like a charm for me.

[EDIT] Ahh, that's exactly what Riven suggests in his latest post. Didn't see that.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 799
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #19 - Posted 2010-01-13 22:35:42 »

Riven: I just tried your method of using an index for the buffer puts... it cut my performance more than in half. I get much better performance clearing the buffer and then refilling it with the updated information. I'm therefore guessing you were specifically talking about instances where you're only updating a small portion of the data in the buffer?


You saw:

Quote from: Riven
Due to the non-deterministic behaviour of HotSpot regarding Buffer performance, it might even be better to dump your data into float[]s and byte[]s and put() them into your FloatBuffer/ByteBuffer

?



FloatBuffer performance is so retarded that it is simply best avoided. Often absolute puts are about 2-4 times as fast as relative puts. Sometimes they are even slower, especially if your have created a heap-FloatBuffer somewhere else.
It sometimes even has completely different performance characteristics in two identical VM launches. float[] is fast, always, independent of the day of the week.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2010-01-13 23:20:10 »

Hm, might I assume also then that blatting the data into float arrays and then writing the completed float arrays to buffers is going to be fastest...

Cas Smiley

Offline elias4444

Junior Member





« Reply #21 - Posted 2010-01-13 23:31:20 »

Riven, Cas: Yes. I think using the array would be best.  Tongue

Offline pjt33
« Reply #22 - Posted 2010-01-13 23:45:28 »

One of the real killers is Y-sort. I wonder if there's any easy way I can optimise that part. I only need to Y-sort if the sprites actually overlap each other. What I need is an algorithm to band them together, even if roughly.
Sounds like a case for shell sort.

My experience with VBOs (setting up a buffer per triangle group, populated at load-time) was that they produced no measurable performance difference on my box, even though model rendering was a bottleneck. GeForce 8400GS.
Offline Spasi
« Reply #23 - Posted 2010-01-14 01:44:35 »

I have a hard time believing that populating a 1000 sprite buffer is even remotely a bottleneck. Or a 5000 sprite buffer. Or a 5000 sprite buffer that's 4x times slower to fill than what it should be.
Offline lhkbob

JGO Knight


Medals: 32



« Reply #24 - Posted 2010-01-14 04:54:14 »

My experience with VBOs (setting up a buffer per triangle group, populated at load-time) was that they produced no measurable performance difference on my box, even though model rendering was a bottleneck. GeForce 8400GS.
This is very peculiar, I have a 8500 that sees 3-4x performance boost when using vbos compared to normal vertex arrays.

Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #25 - Posted 2010-01-14 10:19:48 »

I think the main problem is the number of state changes I have to do as a result of too-fine Y sorting. I absolutely have to do Y sort because my sprites have to appear in front of each other when they overlap - but there's the key: they don't have to if they don't overlap. So I am going to adjust the Y sort to a "band sort", where I take into account the Y hotspot and height of the image to be displayed. Unfortunately that's probably going to break my neat radix sort. But it may cut down on state changes by an order of magnitude. One issue I have noticed is texture state change thrashing - drawing a sprite using one texture then switching to another texture to draw another sprite, over and over, one sprite at a time, for the irritating case where the images are placed in different texture atlases. I need some way of optimising this, either by getting statistics from a run and applying them to the sprite packer, or by some dynamic reorganisation of the atlases at runtime.

I've now interleaved the writes and draws per render state, so that I write a few sprites out at a time, set up the render state, call glDrawArrays, and then start immediately on the next set of sprites.

I'm going to implement VBOs and see if they improve the asynchronicity of glDrawArrays. BTW is glDrawArrays the best way to do this or would glDrawRangeElements be better (given the totally sequential nature of my vertices I suspect not but it's worth asking...?)

Cas Smiley

Offline lhkbob

JGO Knight


Medals: 32



« Reply #26 - Posted 2010-01-14 17:13:12 »

Off the top of my head, I know I've been through my own battle over glDrawArrays, glDrawElements and glDrawRangeElements.  glDrawRangeElements is definitely the way to go over glDrawElements, although performance differences aren't significant it never hurts anything.  For me, on a 8500MT card I found that glDrawArrays was slower than using glDrawRangeElements with indices that were sequential.  This was done a long time ago and was fairly informal, so my best bet is to try it out.

Offline princec

JGO Kernel


Medals: 379
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #27 - Posted 2010-01-14 22:11:36 »

Optimisation continues:

With Y sort on my "typical scene" of about 1300 sprites takes 150 state changes to draw.

With Y sort completely turned off, it takes 50 state changes to draw.

With band sorting, where I use an interval tree to determine if sprites are overlapping, I get a pretty similar 60 or so state changes to draw the same scene. This is a massive reduction in state changes and calls to glDrawArrays - however, the interval tree code I found (in OpenJDK) is so slow, my frame rate plummets to 10fps Smiley

I'm now working on getting a much much faster interval tree of my own implementation. If that achieves any speedup I'll let you know...

Cas Smiley

Offline Nate

JGO Kernel


Medals: 147
Projects: 4
Exp: 14 years


Esoteric Software


« Reply #28 - Posted 2010-01-14 23:59:22 »

What was the performance difference between 50 and 150 state changes?

Offline Eli Delventhal

JGO Kernel


Medals: 42
Projects: 11
Exp: 10 years


Game Engineer


« Reply #29 - Posted 2010-01-15 00:03:49 »

If you have a lot of sprites that potentially aren't moving at once, you can try drawing them once into an FBO and then draw the FBO instead. Only update the rects in the FBO that have objects which have moved. I'm not sure if this will be useful for you, but it has been really big for my own optimizations because I have a lot of objects that don't move all the time.

See my work:
OTC Software
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

radar3301 (10 views)
2014-09-21 23:33:17

BurntPizza (28 views)
2014-09-21 02:42:18

BurntPizza (18 views)
2014-09-21 01:30:30

moogie (20 views)
2014-09-21 00:26:15

UprightPath (27 views)
2014-09-20 20:14:06

BurntPizza (29 views)
2014-09-19 03:14:18

Dwinin (46 views)
2014-09-12 09:08:26

Norakomi (74 views)
2014-09-10 13:57:51

TehJavaDev (102 views)
2014-09-10 06:39:09

Tekkerue (50 views)
2014-09-09 02:24:56
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!