VBO

OpenGL Development
#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.