Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (120)
games submitted by our members
Games in WIP (577)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Why use VBOs/VAOs/FBOs/etc?  (Read 1536 times)
0 Members and 1 Guest are viewing this topic.
Offline Zhon

Junior Duke


Medals: 4



« Posted 2013-04-26 18:06:53 »

I've been messing around with opengl in java for a couple months (using lwjgl) and I've always wondered why is it important to use these complicated things.
All I've been doing is drawing things directly using gl primitives.
I know how to use display lists and shaders, and everytime I try to learn things like vbos, using matrices and other stuff, I drop it.

All I've been doing is messing around with basic games like, 2d rpg scroller, 3d simple first person shooter, simple zelda-like rpgs..
In a 800x600 display with nothing drawn, I get a fps range of ~750, when I have my game's graphical engine ready, the fps drops about only ~30/50 fps, then when I implement a physics and logic engine, the fps decreases by 100~150, like in my 2.5d minecraft/terraria game:
http://i.imgur.com/gbVAW7w.png http://i.imgur.com/HLXitTv.png

So why should I learn these complicated stuff? Will it make my graphical engine much more efficient than just using primitives?
Sorry for my mediocre English (I'm brazilian) and thanks in advance Smiley
Offline theagentd
« Reply #1 - Posted 2013-04-26 18:23:02 »

In a 800x600 display with nothing drawn, I get a fps range of ~750, when I have my game's graphical engine ready, the fps drops about only ~30/50 fps, then when I implement a physics and logic engine, the fps decreases by 100~150

First of all don't compare FPS values like that. It's confusing and misguiding. If you have 200 FPS and drop by 150, a frame just took 4 times as long time to render, while going from 750 to 600 is almost nothing. Instead measure time in milliseconds per frame.

I don't think you know what FBOs are. They allow you to render to textures which isn't relevant in your case I believe.

Considering that your game becomes slower when you add physics and other CPU calculations, it's safe to assume that your game is CPU bound, not GPU bound. From the screenshots I'd guess you're only drawing around ~1000 vertices per frame so you're not vertex limited and at 800x600 you're hardly fragment limited (fill-rate limited), so if you want to optimize it you should focus on optimizing CPU performance. This is EXACTLY where VBOs and display lists come in. They allow you to in a much more CPU-efficient way instruct the GPU what to do.

Since you're hardly having any performance problems it's hard to justify optimizing it. As long as you have basic frustum culling working I wouldn't worry about performance in your case.

Myomyomyo.
Offline concerto49

Junior Duke





« Reply #2 - Posted 2013-04-27 00:04:30 »

At least for FBO it's not  just performance. You can do post processing and other stuff using it.

In terms of performance -- it's not just your PC? If you want to make it playable think about the PCs that are a lot slower out there. Some people can't afford fast equipment but want to play.

It gets more important as you go 3D anyway. 2D isn't as much of an issue these days.

High performance, fast network, affordable price VPS - Cloud Shards
Available in Texas, New York & Los Angeles
Need a VPS Upgrade?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Online princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #3 - Posted 2013-04-27 00:59:12 »

It gets more important as you go 3D anyway. 2D isn't as much of an issue these days.
So you'd think but actually 2D is every bit as demanding as 3D still.

Well, good 2D.

Cas Smiley

Offline Cero
« Reply #4 - Posted 2013-04-27 10:40:36 »

It gets more important as you go 3D anyway. 2D isn't as much of an issue these days.

It gets more important as you go 3D anyway. 2D isn't as much of an issue these days.
So you'd think but actually 2D is every bit as demanding as 3D still.

Well, good 2D.

yep, absolutely not true, due to the nature of what you do in 2D, its a lot to push to the gpu.
Good 2D, like muramasa or rayman origins, with many layers and stuff, is even more hard to do fast than 3D games... well if its not cutting edge 3D stuff

Offline relminator
« Reply #5 - Posted 2013-04-27 14:17:12 »

With the same amount of fragments, 2d should be slower than 3d.

We usually draw from front to back in a 3d scene with znear being as far from z0 and zfar as near as possible to reduce fillrate.

You can't do that in a 2d scene since you always have to draw from back to front.

Of course, there are some cards that can optimize back to front rendering but they are quite new.

Sorry, replied via phone.
Offline theagentd
« Reply #6 - Posted 2013-04-27 14:58:43 »

With the same amount of fragments, 2d should be slower than 3d.
I sample 5 textures, transform normals from tangent space to object space and write to two RGBA16F textures per pixel. 3D games usually require much more complex shaders, much more bandwidth (in the case of deferred shading), more anti-aliasing and higher screen resolutions. Even with early-Z optimizations, we still get massive overdraw for lighting and post-processing.

Myomyomyo.
Offline relminator
« Reply #7 - Posted 2013-04-27 15:15:25 »

With the same amount of fragments, 2d should be slower than 3d.
I sample 5 textures, transform normals from tangent space to object space and write to two RGBA16F textures per pixel. 3D games usually require much more complex shaders, much more bandwidth (in the case of deferred shading), more anti-aliasing and higher screen resolutions. Even with early-Z optimizations, we still get massive overdraw for lighting and post-processing.
,

The same amount of "simple" non-transformed fragments.
Offline theagentd
« Reply #8 - Posted 2013-04-27 15:27:40 »

The same amount of "simple" non-transformed fragments.
Then why?

Myomyomyo.
Offline Roquen
« Reply #9 - Posted 2013-04-27 20:29:31 »

You can't do that in a 2d scene since you always have to draw from back to front.
No you don't.  Any cases where you might choose to render back-to-front are identical in 2D and 3D (say transparency and you don't want to be fancy about it).
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #10 - Posted 2013-04-27 20:37:54 »

You can't do that in a 2d scene since you always have to draw from back to front.
No you don't.  Any cases where you might choose to render back-to-front are identical in 2D and 3D (say transparency and you don't want to be fancy about it).
Isn't that the whole issue at hand? In 2D you're expected to have every sprite nicely translucent at the edges, whereas in 3D you can get away with your typical antialiasing, defining shapes not by transparant pixels in sprites but by geometry.

That's the single reason good 2D games are prone to be suffering from overdraw, caused by mandatory back-to-front rendering.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline relminator
« Reply #11 - Posted 2013-04-28 02:02:24 »

You can't do that in a 2d scene since you always have to draw from back to front.
No you don't.  Any cases where you might choose to render back-to-front are identical in 2D and 3D (say transparency and you don't want to be fancy about it).
Isn't that the whole issue at hand? In 2D you're expected to have every sprite nicely translucent at the edges, whereas in 3D you can get away with your typical antialiasing, defining shapes not by transparant pixels in sprites but by geometry.

That's the single reason good 2D games are prone to be suffering from overdraw, caused by mandatory back-to-front rendering.

This and the fact that you can upload static models on the gpu then optimize rendering further by using strips.  2d scenes are usually done with tris and vertex arrays.
Offline theagentd
« Reply #12 - Posted 2013-04-28 16:59:20 »

Isn't that the whole issue at hand? In 2D you're expected to have every sprite nicely translucent at the edges, whereas in 3D you can get away with your typical antialiasing, defining shapes not by transparant pixels in sprites but by geometry.
I'm pretty sure 4x MSAA is more expensive per pixel than enabling blending, plus you have the MSAA resolve overhead.

This and the fact that you can upload static models on the gpu then optimize rendering further by using strips.  2d scenes are usually done with tris and vertex arrays.
Strips are slower than indexed rendering on most OGL2+ hardware, so there's no real difference to 2D here. Besides, you're usually not vertex limited in neither 3D nor 2D if you have proper culling (and LOD for 3D) in place.


It's actually possible to render 2D front-to-back with correct blending. This requires an alpha channel in the frame buffer though, but may have slightly better performance since your GPU should be able to avoid a ROP write for occluded pixels, but I haven't tested it.

EDIT: Also, some people seem to be under the impression that an occluded pixel (= a pixel that failed the depth test) is free. This is not the case, but an occluded pixel may be cheaper. At best, the depth test is done before the pixel shader, and the pixel can be culled before the pixel shader is run, giving it a constant cost regardless of how expensive the pixel shader is. However if the alpha test is enabled, the pixel shader modifies the depth of each pixel or the pixel shader calls
discard;
somewhere, the decision to cull the pixel has to be done after the pixel shader is run, in which an occluded pixel is just barely cheaper than a non-occluded pixel.

Myomyomyo.
Offline Roquen
« Reply #13 - Posted 2013-04-28 19:17:51 »

[aside mode]
The discussion of which is harder: 2D vs. 3D is somewhat silly.  Using only a small handful of "state-of-the-art" techniques for either will throw you way over a highest end consumer GPU configuration cycle budget.  So like pretty much everything: it depends.

Wouldn't you guess that most 2D games that do indeed render back-to-front still get it wrong by not appropriately using precomputed alphas?  And also that in a fair number of these cases that the "defect" goes unnoticed because it's not pronounced enough and/or simply because people are used to rendering that's wrong?  (Likewise in 3D with rendering in gamma space and the tv/movie "effect" of night looking like a blue filter...which it doesn't...we're just used to being shown very defective images).
[/aside mode]

Back on my point.  My issue is with the words "always" of relminator's original statement and Riven's "mandatory".  This kind of thinking is self fulfilling.  If you thinking you "can't", you're right...but that doesn't mean you "couldn't".  Always back-to-front is certainly the easiest to code.  In a fair number of cases it may well indeed be the best solution. 

Trivial counter examples.  Visual design is based on classic console hardware: some number of tiled background planes with priorities mixed with some number of prioritized sprites.  I've certainly seen games with multiple backgrounds which are behind all sprites.  Back-to-front rendering obviously isn't required and these logical layers can be rendered in a single pass.  Likewise this can be partially extended to other background planes formed from logical layers (with of course the tricky part being edges).  If it's common that these further forward background planes have reasonably large opaque real estate then minimally one could render all opaque tiles front-to-back and in a second pass render all transparent back-to-front...in other words, the classic solution one would do in 3D.  It seems pretty common to see games logically based on even older hardware, which only support color-key transparency.  Assuming proper sampling and the only allowed scale factors are integers.  Alpha-test and render front-to-back.  I haven't thought deeply about this but it could be feasible to extend this sprites/tiles with full alpha range: first pass renders fully opaque texels front-to-back and a second pass draw the same geometry back-to-front (again with alpha-testing).  Win/Loss? No idea..wild hare thought and certainly scene type and fragment shader complexity dependent if it ever is.  Other thoughts: various order independent transparency techniques could be considered, such as various flavors of depth peeling.
Offline theagentd
« Reply #14 - Posted 2013-04-29 17:38:50 »

In case anyone's wondering, front-to-back blending is around 25-30% faster than back-to-front blending in my test. It all depends on how much overdraw you have and how transparent your pixels are. If everything you draw is 50% transparent, it won't be much faster. If most pixels are opaque (for example sprites with anti aliased edges), you can get a lot better performance with front-to-back blending!

Myomyomyo.
Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #15 - Posted 2013-04-29 18:14:18 »

3D rendering is harder for humans i guess, adds an extra dimension to think of.
Since you're talking about front to back rendering, give some samples so we can see for ourselves Smiley
Offline Zhon

Junior Duke


Medals: 4



« Reply #16 - Posted 2013-04-29 19:15:37 »

Wow oh wow, I got flying in this conversation  Yawn
So, in a 2D game it is better to draw things using vbo/vaos instead of imediate drawing?
Offline RobinB

JGO Ninja


Medals: 44
Projects: 1
Exp: 3 years


Spacegame in progress


« Reply #17 - Posted 2013-04-29 19:59:56 »

immediate mode is never an good solution in opengl (except some testing / debugging) since its depricated anyway.
vbo's and vao's speed up your code, and forces the programmer to program some clean drawing code.
So at least you will get cleaner code and faster drawing (much much faster).
Pages: [1]
  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.

Longarmx (52 views)
2014-10-17 03:59:02

Norakomi (42 views)
2014-10-16 15:22:06

Norakomi (33 views)
2014-10-16 15:20:20

lcass (37 views)
2014-10-15 16:18:58

TehJavaDev (68 views)
2014-10-14 00:39:48

TehJavaDev (66 views)
2014-10-14 00:35:47

TehJavaDev (59 views)
2014-10-14 00:32:37

BurntPizza (73 views)
2014-10-11 23:24:42

BurntPizza (45 views)
2014-10-11 23:10:45

BurntPizza (85 views)
2014-10-11 22:30:10
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

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
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!