Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (492)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
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  
  Libgdx vs Stumpy: Sprites  (Read 7387 times)
0 Members and 1 Guest are viewing this topic.
Offline StumpyStrust
« Reply #30 - Posted 2012-10-30 03:37:50 »

In real game right now its fine.

I got threading working using your lib for the updating and all but got no fps boost (other then not droping when mouse click) as it spends almost all of its time filling arrays. This means that anything you do on the cpu takes time away from filling arrays but at this point you get so fillrate limited that going through the ugliness may not be worth it.
I will probably be fill rate limited at 50k sprites if they are 64*64 pixels. I don't drop fps on my shitty old pc till 100k+ now with the geobatcher.

I know about hyperthreading and all that jazz and I know about pooling (even though I have yet to implement it). I also, use the arraylist trick right now and have avoided link lists like the plague ever since CS 2.....

I need to add in different tex coords as it needs to work with calls that you would use with the old batcher and is still setup for atlases and texture regions. I also need to add rotation on the gpu....not sure how I want to do that. I like the if to check to see if you need to even do rotation and I know that you stay the hell away from ifs in shaders. But I also know that you don't want to use too much trig in shaders. 

Question on pooling in java. If you have an object and you take the referance of the object and use new to create a new object of that type. Does the old referance get GC? I think it does. I just don't know if I should have massive methods for resetting or many methods for setting one thing.

1  
2  
3  
4  
5  
6  
7  
8  
MehObject b = new MehObject(); //create
b = new MehObject(); //create again?
b.reset();
b.set(Super, long, set, method, to, set, everything, in, object); //proper pooling?
b.setThing1();
b.setThing2();
b.setThing3();
//mass method calls slow things down much?

Offline matheus23

JGO Kernel


Medals: 106
Projects: 3


You think about my Avatar right now!


« Reply #31 - Posted 2012-11-01 19:37:47 »

I also need to add rotation on the gpu....not sure how I want to do that.

You could do that in the geometry shader. Just pass in a rotation. You could use vec3's and use the z attribute as rotation (or something like that).

Question on pooling in java. If you have an object and you take the referance of the object and use new to create a new object of that type. Does the old referance get GC? I think it does. I just don't know if I should have massive methods for resetting or many methods for setting one thing.

1  
2  
3  
4  
5  
6  
7  
8  
MehObject b = new MehObject(); //create
b = new MehObject(); //create again?
b.reset();
b.set(Super, long, set, method, to, set, everything, in, object); //proper pooling?
b.setThing1();
b.setThing2();
b.setThing3();
//mass method calls slow things down much?


Eh.
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
Object o = null; // Allocates 32/64 bits.
o = new Object(); // Allocates the memory needed for the attributes of the "Object" class.
o = new Object(); // Allocates a bunch of memory again...
// The problem with the above statement is, that
// the first "Object" which was created, won't be simply thrown away instantanious,
// it needs to be gc'ed (you could have given another object a reference,
// the purpose of the gc is to collect objects, which aren't needed anymore...
// (I'm just explaining, why the second time "Object" is created, the old
// Object doesn't get thrown away...) )
// Take this as an example:
Object o = null;
o = new Object();
anotherObject.setObject(o);
o = null;
// (In case we wouldn't do it garbage-collected:) the "new Object()" is getting
// thrown away, since we re-assign "null" to "o".


How one usually does pooling:
1  
2  
3  
4  
5  
6  
7  
// For example with a vector. Can simply be changed to be a particle:
// Init-Function or constructor of whatever (your game):
Vec2 vec = new Vec2();
// Getting a vector to be used:
public Vec2 get(float x, float y) {
    return vec.set(x, y); // Vec2.set(float, float) returns itself.
}


The thing about pooling is to avoid "new" statements, because that would allocate new memory, and propably throw away the old object.

So why don't we always use pooling and only have one instance of every class?

Let's dig up the old example, but with vectors, again:
1  
2  
3  
4  
5  
6  
7  
Vec2 vec = new Vec2(10f, 10f);
// You expect the enemy to be placed at (10|10), which is right...
enemy.setPosition(vec);
// ... until now. We change the values for vec, and since we
// change the values in the same object, which also got passed
// to the enemy, the enemy will now be at (100|100)...
vec.set(100f, 100f);


So beware of that when pooling objects.

EDIT:
One more thing...
There are languages out there, where EVERY object is immutable, which means nothing can be changed. No values. Nothing. (Haskell)
It's called "side-effect" (it's just the above example with the enemy, why side-effects are bad). Many functional languages (I'd say) prefer being somehow immutable. Some allow side-effects, but it's not recommended to use them (like scheme / lisp) and some don't allow them (as said: Haskell).

See my:
    My development Blog:     | Or look at my RPG | Or simply my coding
http://matheusdev.tumblr.comRuins of Revenge  |      On Github
Offline theagentd
« Reply #32 - Posted 2012-11-01 22:57:22 »

Oh, sorry, I completely missed your response, Stumpy! T_T

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline StumpyStrust
« Reply #33 - Posted 2012-11-02 04:05:05 »

Yeah thats what I kinda though about pooling. So basically you will have to have methods with mass args for all attributes or set them with different method calls as the chance the dead particle being of the type you want is slim.

I was going to do exactly that for rotation. Use vec3 for loc and have z be the rotation. How do I rotate in shader with out dropping performance?

Offline theagentd
« Reply #34 - Posted 2012-11-02 17:00:03 »

Yeah thats what I kinda though about pooling. So basically you will have to have methods with mass args for all attributes or set them with different method calls as the chance the dead particle being of the type you want is slim.

I was going to do exactly that for rotation. Use vec3 for loc and have z be the rotation. How do I rotate in shader with out dropping performance?

My idea of pooling:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
public class Pool{
   
   private ArrayList<Particle> pool;
   
   public Pool(){
      pool = new ArrayList<>();
   }
   
   public Particle get(){
      if(!pool.isEmpty()){
         return pool.remove(pool.size() - 1);
      }
      //Tell the particle which pool it belongs to
     //so it can recycle itself when it dies.
     return new Particle(pool);
      //(Note: the caller of get() is responsible for initializing the particle)
  }
   
   public void recycle(Particle p){
      pool.add(p);
   }
}


Rotation can be done in multiple ways but the best way to do it in a shader is with a 2D rotation matrix. You simply generate a rotation matrix from an angle (the rotation variable) you pass to the shader per particle and rotate the generated coordinates with this matrix. It doesn't affect fill rate at all, so it won't cost anything in a real game. However, it does cost some memory bandwidth for the extra rotation variable per particle plus some geometry shader performance, but this is completely irrelevant in this case since fill rate will outweigh it by far.

You can generate the rotation matrix in your geometry shader like this:
1  
2  
3  
4  
5  
6  
    float sin = sin(vRotation[0]);
    float cos = cos(vRotation[0]);
    mat2 rotationMatrix = mat2(
        cos, -sin,
        sin, cos
    );

Then rotate the local coordinates by multiply them with this matrix. See the full shader source below.

There's no reason to pack the rotation into a vec3. Just add another float variable to the shader and treat it as a completely different attribute, since that's what it is. Packing is soooo fixed function pipeline.

Shader source code

Java source code
(The only relevant stuff is the attribute setup at start and before/after rendering, but I don't have time to pick out the relevant parts... >_<)

Performance had a slight impact since my particles/sprites/whatever are so small and many (= not fill-rate limited): I now only get around 1.0 million particles at 60 FPS, down from 1.1 million. I strongly suspect it's because of the additional memory footprint of the particles. 20 bytes --> 24 bytes =  a 20% increase in memory usage. The additional GPU load shouldn't be significant.


EDIT: Did some more benchmarking. Turns out the GPU impact was higher than I thought and that seems to be the main reason for the performance loss. However, doing that math on the CPU instead and uploading all 4 coordinates is of course a lot more expensive, so it's obviously worth it.

Myomyomyo.
Offline StumpyStrust
« Reply #35 - Posted 2012-11-07 03:43:09 »

Just posted a tut on spritebatcher. Would love for some of you openGL/coding gods to go over and rip it apart...you know...so I can make it better.

I know that the rotation explanation is lacking but I suck at maths so.... persecutioncomplex

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.

Nickropheliac (15 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (33 views)
2014-08-22 19:31:30

atombrot (41 views)
2014-08-19 09:29:53

Tekkerue (40 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (25 views)
2014-08-16 06:20:21

Tekkerue (37 views)
2014-08-16 06:12:11

Rayexar (72 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
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!