VBO

OpenGL Development
#14

You won’t see a perf. gain from glMapBuffer() until you’re doing rather a lot of rendering and state changing. FWIW it took me about 60 hours to get this all working right :slight_smile: You might want to take a look at the DefaultSpriteRenderer class in the Revenge of the Titans source code (and a bit of a mosey around in general in there). I think I’ve nailed the absolute optimum set-up there in so far as asynchronous rendering and Java computation goes. The only improvement I could make is to utilise geometry shaders and move most of that Java code into the driver but that excludes most systems in the wild.

Cas :slight_smile:

#15

What is your current performance.

from 1k sprites to 10k, 25k, 50k 100k, 500k.

Want to know if I am asking for too much.

#16

Totally varies depending on the sprites you’re drawing, the fillrate of the card, and the power of your CPU.

I can draw just a 20,000 sprites at 60fps on 1920x1200 if they’re all transparent and moderately large (say 64x64 ish). I say draw but I’m also including animation logic that’s running in my little sprite benchmark. Whereas if the sprites are all generally quite small like in Revenge of the Titans and some of them are opaque I can draw few thousand more. I’m on a 2.6Ghz i7 with Nvidia GTX 280 running Java 7 server with 2-tiered compilation.

Make no mistake, a couple of thousand sprites in a single video frame is a lot of sprites!

Sorry - got my numbers screwy - should be factor of 10 more sprites!

Cas :slight_smile:

#17
#18

Hm?

Cas :slight_smile:

#19

200k??? O.o I keep thinking I am doing something wrong.

Libgdx’s spritebatcher on my comp is about 10-13 fps fast then my spritebatcher.

Libgdx gets 42-44 fps on my comp at 40k alpha blended 14 pixel sprites. Everything the same and I get 30-31

i5 2.5gh with the turbo boost like 2.7-2.8 and well…meh laptop only uses the integrated chip ever.

On my desk top which is quad core 2.6 and geforce250 I get maybe 10k more sprites so I think I need to use more gpu.

I guess I should not be complaining about performance but still… >:(

Edit:
hehe java 2d using opaque sprites and volatile images, I get 20-22 fps at 40k sprites.

#20

Bah my edit is confusing :slight_smile: No I mean, 20k sprites. 20k is good for 60fps on good hardware.

Cas :slight_smile:

#21

Well I figured out what was the slow down.

it was filling the arrays with the damn data.

I could call drawArrays/Elements 4-5 times and no fps drop…hmmm

Basically, it is better to fill an array[] and then use put(array[]) to put it into the buffer.

Using a dynamic vertex array version of my spritebatcher I can now get 75k at 66fps and this is with everything being floats. I am not fillrate limited woot.

The drawing is only 20fps drop, the updating and pushing into arrays is the slow part.

Oh I followed libgdx’s code where you don’t have one huge array/vbo of all data but instead send everything in chunks. I think 1-2k texture quads is optimal. Getting larger only slows things down.

#22

I know… :clue:

#23

So quick little bench mark for my spritebatch is basically a rehash of my spacemaker prog but now you can get lots of particles looking all cool.

http://www.mediafire.com/?gv1ng4l7uz96m3d

Screen

Click around and have fun

right now I can get 50k with physics going at 60fps

bout 70k with no physics at 60fps

So tell me what you guys are getting.

#24

50k with physics at 60 fps

38 - 40 fps - 70k with physics
40 fps with 70k no physics

100k sprites - im staying pretty much at 30 fps

200k sprites - 15 fps

#25

What are you system specs?

The drop in fps should be much higher when you do physics. 10-20 My guess is that your cpu can do more but gpu is fill rate limited.

Just added delta timing which makes thing much smoother

Can actually do 120k at 35fps with physics.

#26

Graphics Card: NVIDIA Geforce GTS 250 (1gb)
ram: 12gb DDR3 if I remember right
CPU: Processor Intel® Core™2 Quad CPU Q9400 @ 2.66GHz, 2667 Mhz, 4 Core(s), 4 Logical Processor(s)

#27

Just relised, that clicking actually changed stuff lol, im stupid, heres the new list:

200k sprites - 15 fps (no clicking around)
200k sprites - 11 - 13 fps (clicking)

120k sprites - 25 - 27 fps (no clicking)
120k sprites - 20 - 21 (clicking)

100k sprites - 30 fps (no clicking)
100k sprites - 25 fps (clicking)

50k sprites - 60 fps (no clicking)
50k sprites - 51 fps (clicking)

by clicking, Im constantly clicking around, soon as i stop clicking for a second or 2, it jumps straight back up to what its going at before the clicking.

and after finally working out about the clicking, I got to say, that is awesome, I’m trying to learn VBO’s slowly, but still kinda hard lol, Making a game for my school project, and Iv hardly even started to make the game, and I have probably enough code to get full marks in the programming side of it lol. Still got 1 year or so left to make it, (have not even received the assignment sheet lol). but good luck in what ever your trying to make!

P.S not sure if this is intended but, I just left the program open while typing out those 2 paragraphs, and it says Sprites: 0 , do the sprites have a certain life time? or is that a bug?

#28

Yeah the sprites actually slowly fade out to test alpha stuff.

Clicking causes the particle to move towards the mouse via physics.

This is actually not using vbos just vertex arrays. The one I made using vbos was bottle necked. I think I can optimize it so it is fast then this but the main drop is not the number but filling up an array with all the vertices.

#29

One useless comment on closing the -tag :stuck_out_tongue:
Yeah… seems like I’m not that good in making jokes… :persecutioncomplex: :-\

EDIT: Okey… I should also contribute to this… This is what I get, when simply starting Tester.jar:
`
$ java -jar Tester.jar

A fatal error has been detected by the Java Runtime Environment:

SIGSEGV (0xb) at pc=0x00007f3a6c8ae9f6, pid=1806, tid=139888907867904

JRE version: 7.0_07-b30

Java VM: OpenJDK 64-Bit Server VM (23.2-b09 mixed mode linux-amd64 compressed oops)

Problematic frame:

C [ld-linux-x86-64.so.2+0x69f6] _dl_map_object_from_fd+0x746

Failed to write core dump. Core dumps have been disabled. To enable core dumping, try “ulimit -c unlimited” before starting Java again

An error report file with more information is saved as:

/home/philipp/Downloads/hs_err_pid1806.log

If you would like to submit a bug report, please include

instructions on how to reproduce the bug and visit:

http://icedtea.classpath.org/bugzilla

The crash happened outside the Java Virtual Machine in native code.

See problematic frame for where to report the bug.

#`

EDIT2: More information:
$ java -version java version "1.7.0_07" OpenJDK Runtime Environment (IcedTea7 2.3.2) (ArchLinux build 7.u7_2.3.2-2-x86_64) OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)

#30

O.o

Well…I made this with java 1.6 not 1.7 but I don’t think that should make much difference.

It runs on my 64bit laptop so that can’t be it.

You are using a version of linux? I may be missing some .dlls but I think it would give a different error.

I got a many of those when I was trying to figure everything out and generally it has to do with in proper offsets/pointer/other open related things.

Do you have an nvidia card or amd? do you have up to date drivers?

Side note: I may write a tutorial on how to make a basic spriteBatcher using vertex arrays and VBOs to no one else has to suffer as I have.

Edit:
Fullscreen/HD
180k 30+ fps with physics

Are you not entertained?

#31

I’m on linux, that means I’d need .so’s :wink: But That should only throw an UnsatisfiedLinkException… Strange thing…

I have a nVidia GeForce 550 Ti.

Woah! I’d like that! I need to understand these ones, because I need a modified version for my game…

#32

Ehh sorry I only know windows :smiley:

I used jarSplice to pack the natives into the jar so it could be an issue with that.

Sorry I can’t get it working for you. :-\

Maybe someone with more experience can come along and help. I am still very new.

#33

If you use JarSplice, then you only need to create a “linux” version: Pack the .so natives into the jar instead of the .dll’s.