Java-Gaming.org Hi !
Featured games (81)
games approved by the League of Dukes
Games in Showcase (513)
Games in Android Showcase (119)
games submitted by our members
Games in WIP (576)
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  
  What are OpenGL's limits?  (Read 2840 times)
0 Members and 1 Guest are viewing this topic.
Offline nhmllr

Senior Duke


Medals: 1
Projects: 3


slow and steady...


« Posted 2012-07-29 00:54:47 »

A little background: I'm working on my first game in java (using the LWJGL/OpenGL setup)
When I made the game loop months ago, I was not aware of this "delta-time" business with a shifting frame rate. It's a little too late to implement it into this game.
I worry a lot about efficiency. I try to keep the number of checks my game has to do down to a minimum.

I'm just kinda curious about how much OpenGL can handle. My framerate is arbitrarily fixed at 60 fps, and I'm drawing about 350-ish (2D) sprites at a time.
Of those, About 300 all come from the same texture (a sprite sheet) which is bound once then drawn a lot. Another 50 of those objects also come from a single sprite sheet, and then about 5-20 other small sprites that each have their own texture.
And then of course there are a load of other computations going into each step. Nothing crazy.

Given that the frame rate is unadjustable, should I drop it to something along the lines of 30 and half the speed of everything in the game? (Wouldn't be that hard)

Even though I'm a few thousand lines of source code into my game, only a few of those deal with movement. Is it worth it to go back in and put in a delta?

What are OpenGL's limits? Am I anywhere near them, or am I a ridiculous worrier?? What about players who have low end machines/netbooks?
Offline loom_weaver

JGO Coder


Medals: 17



« Reply #1 - Posted 2012-07-29 02:09:50 »

I wouldn't worry about it.  I can paint 160k transparent sprites from the same sprite sheet in less than 5ms.  There was a thread about a year ago where people were trying to see how many bouncy balls they could paint in a frame and it was some kind of ridiculous number (much higher than my 160k).

Ultimately those numbers depend on the hardware and driver quality.
Offline theagentd
« Reply #2 - Posted 2012-07-29 03:11:15 »

I wouldn't worry about it.  I can paint 160k transparent sprites from the same sprite sheet in less than 5ms.  There was a thread about a year ago where people were trying to see how many bouncy balls they could paint in a frame and it was some kind of ridiculous number (much higher than my 160k).

Ultimately those numbers depend on the hardware and driver quality.
Depends on the pixel area they cover. For pixel sized stuff you can do at least 1 million, but on high-end hardware almost 10 million.


When using the GPU, it works in parallel with the CPU. Your CPU feeds the raw vertex data to the GPU, and the GPU then processes the vertices, constructs triangles out of them and colors the covered pixels. CPU-wise you need to feed the GPU data fast enough to keep it from stalling. If you don't, you get a CPU bottleneck where the GPU has to wait for more instructions. It's even easier to get a GPU bottleneck, since with just a single quad you can cover the whole screen, for example:

CPU generates 4 vertices and sends them to the GPU.
 ---> GPU processes 4 vertices ---> GPU creates a quad (= 2 triangles) ---> GPU processes 1920x1080 = around 2 million pixels

OpenGL is just as potent as DirectX, so you have the exact same GPU capabilities as any other game out there, including commercial ones. For 2D the real problem is CPU performance. OpenGL commands are actually pretty expensive though (Java ---> native call ---> driver ---> GPU), so it's important to as CPU efficiently as possible draw as much as possible.

Some tips:
 - Instead of using glBegin()-glEnd(), batch the sprite vertices together into a VBO and draw it with glDrawArrays().
 - Texture binds make batching impossible since you need to do OpenGL calls in between to switch textures. Consider creating texture atlases (for example a tile set texture instead of individual tile textures) and picking out parts of it with texture coordinates.


Some GPU numbers to give you a general idea:
Pixels:
A low-end GPU can easily draw 5+ million pixels per frame (not including clearing the screen. glClear() is ridiculously fast). A high-end GPU can do over 40 million pixels per frame at 60 FPS. It does however depend on what operations you perform per pixel. Texturing and blending both have a small but noticeable cost.

Vertices:
At least 1+ million for 2D. In other words don't worry about vertices.


TL;DR: frameTime = max(cpuTime, gpuTime), and in the case of 2D CPU time is almost always higher. Focus on optimizing it.

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline nhmllr

Senior Duke


Medals: 1
Projects: 3


slow and steady...


« Reply #3 - Posted 2012-07-29 04:22:57 »


Some tips:
 - Instead of using glBegin()-glEnd(), batch the sprite vertices together into a VBO and draw it with glDrawArrays().
 - Texture binds make batching impossible since you need to do OpenGL calls in between to switch textures. Consider creating texture atlases (for example a tile set texture instead of individual tile textures) and picking out parts of it with texture coordinates.

First, I'd like to thank all of you for such detailed responses
(Also thanks for the glBegin() tip! I use that a lot. Looks like I have some research to do.)

Well, I feel properly comforted. Thanks, guys!
Offline theagentd
« Reply #4 - Posted 2012-07-29 17:32:36 »


Some tips:
 - Instead of using glBegin()-glEnd(), batch the sprite vertices together into a VBO and draw it with glDrawArrays().
 - Texture binds make batching impossible since you need to do OpenGL calls in between to switch textures. Consider creating texture atlases (for example a tile set texture instead of individual tile textures) and picking out parts of it with texture coordinates.

First, I'd like to thank all of you for such detailed responses
(Also thanks for the glBegin() tip! I use that a lot. Looks like I have some research to do.)

Well, I feel properly comforted. Thanks, guys!
There's no problem using glBegin()-glEnd() for some things like for example a fullscreen background. Switching to VBOs for the sake of 4 vertices covering hundreds of thousands of pixels does nothing for performance.  Smiley

Myomyomyo.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 816
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #5 - Posted 2012-07-29 18:12:37 »

There's no problem using glBegin()-glEnd() for some things like for example a fullscreen background. Switching to VBOs for the sake of 4 vertices covering hundreds of thousands of pixels does nothing for performance.  Smiley
Cas mentioned once that mixing VBOs and immediate mode did have an impact on the performance of VBOs (probably a driver issue)

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline gouessej
« Reply #6 - Posted 2012-07-29 18:40:06 »

There's no problem using glBegin()-glEnd() for some things like for example a fullscreen background. Switching to VBOs for the sake of 4 vertices covering hundreds of thousands of pixels does nothing for performance.  Smiley
Cas mentioned once that mixing VBOs and immediate mode did have an impact on the performance of VBOs (probably a driver issue)
It's something "common" now... I use VBOs even for trivial examples.

Offline theagentd
« Reply #7 - Posted 2012-07-29 21:23:50 »

There's no problem using glBegin()-glEnd() for some things like for example a fullscreen background. Switching to VBOs for the sake of 4 vertices covering hundreds of thousands of pixels does nothing for performance.  Smiley
Cas mentioned once that mixing VBOs and immediate mode did have an impact on the performance of VBOs (probably a driver issue)
It's something "common" now... I use VBOs even for trivial examples.
I do too since I'm trying to embrace OpenGL 3+, but it's still annoying having to create a fragment+vertex shader, a VAO and 2 VBOs just to do a fullscreen quad. >_>

Myomyomyo.
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #8 - Posted 2012-07-29 22:09:10 »

I use a little framework now to do all that crap for me. Worthwhile investing the time to make one I think.

Cas Smiley

Offline coltonoscopy

Junior Duke


Medals: 2



« Reply #9 - Posted 2012-08-01 03:13:07 »

I use a little framework now to do all that crap for me. Worthwhile investing the time to make one I think.

Cas Smiley
Cas, did you write this yourself? I'd be interested to see it. I have been hearing about VBOs here and there ever since I've started working with LWJGL and Slick and I've wanted to find out more about what they are and how they increase performance.

EDIT: Just found out you founded LWJGL! It's an honor to be using your technology to develop my game in! I know it's changed a lot but it's been great having the chance to interface with OpenGL using Java in such a clean and easy manner!

Straight flippin.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Ultroman

JGO Knight


Medals: 25
Projects: 1


Snappin' at snizzes since '83


« Reply #10 - Posted 2012-08-01 07:21:16 »

I don't know much about OpenGL yet, but on the subject of using deltatime instead of a flatrate to update sprite-animations, I highly recommend it. Since I made the switch, I feel like I've gained so much control over the state of my animations and entities in general, and if you're already thinking about changing your FPS, you might as well take the leap.

- Jonas
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #11 - Posted 2012-08-01 09:13:50 »

You can peek into the bowels of the code in the Revenge of the Titans source code. Be warned, it's obscure, hacky, organically evolved and grown in poo over 10 years.

Cas Smiley

Offline coltonoscopy

Junior Duke


Medals: 2



« Reply #12 - Posted 2012-08-01 17:26:49 »

You can peek into the bowels of the code in the Revenge of the Titans source code. Be warned, it's obscure, hacky, organically evolved and grown in poo over 10 years.

Cas Smiley
I'll definitely have a look! I think there's a lot to learn from it even besides VBOs. I'll try not to get my hands too poopy as well. ;]

Straight flippin.
Offline TheCodingUniverse

Senior Newbie





« Reply #13 - Posted 2012-08-03 08:39:34 »

Here are two ways by which you can improve performance with OpenGL.

Don't use immediate mode (glBegin/glEnd, excluding display lists)
You should use a rendering method where you supply the vertex data only once, and modify it as little as possible. This allows the GPU to optimise the way it handles your vertices, because they are stored in the server memory (memory on the GPU) instead of in the client memory (memory on the CPU or RAM). Try using display lists or VBOs.

Call as little OpenGL functions and possible
Try minimizing the amount of OpenGL functions called. For example, constantly binding and unbinding textures can be a costly operation. When you call a function like glGet, the graphics card has to execute all the previously issues commands (it doesn't do most of them directly) before it can give you a correct value. The less synchronisation there has to be between the CPU and the GPU, the better.

Oskar Veerhoek, founder of TheCodingUniverse.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #14 - Posted 2012-08-03 09:27:46 »

I have found that in a real-game situation then 1000 sprites at 60fps is a reasonable goal that's achievable on a wide range of hardware. And by "real-game" I mean a realistic scenario with a large variety of sprite types, drawing modes, layers, multiple sprite sheets and render passes. Any more than that tends to become either fillrate limited or cpu bound shunting sprite data around.

You can get higher than that if you start requiring more recent hardware, or doing scene-specific optimisations, but I find 1k a good ballpark to aim for. Fortunately pretty much any game can be done in 1k sprites.  Grin

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #15 - Posted 2012-08-03 09:46:32 »

Not mine! Even lowly Titan Attacks uses something like 1500 sprites. Seeing as that's been running at 60Hz for 6 years even on lowly hardware from back in the day I think you can realistically aim for 2500 sprites per frame instead of a lowly 1000 Smiley

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #16 - Posted 2012-08-03 10:46:37 »

Not mine! Even lowly Titan Attacks uses something like 1500 sprites. Seeing as that's been running at 60Hz for 6 years even on lowly hardware from back in the day I think you can realistically aim for 2500 sprites per frame instead of a lowly 1000 Smiley

Cas Smiley
Yeah, that may be a little on the low side. It also doesn't count particle effects, as I think those should be special cased these days anyway.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #17 - Posted 2012-08-03 10:50:01 »

Why special case 'em when you can just as easily treat them like any other sprite?

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #18 - Posted 2012-08-03 12:56:22 »

I'm a convert to doing particle effects entirely in shaders after seeing how simple it is to make a gpu particle system throw around thousands of particles with barely any cpu work. Grin

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline davedes
« Reply #19 - Posted 2012-08-03 12:58:11 »

I'm a convert to doing particle effects entirely in shaders after seeing how simple it is to make a gpu particle system throw around thousands of particles with barely any cpu work. Grin
How are you doing it?

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #20 - Posted 2012-08-03 13:03:26 »

I'm not, yet. Mostly just been eyeing up a friend's system after going over the high-level design with him. It's pretty vanilla really - a fixed size pool of particles with a life value incremented on cpu, and a stateless movement equation in the vertex shader.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline theagentd
« Reply #21 - Posted 2012-08-03 13:52:29 »

I'm not, yet. Mostly just been eyeing up a friend's system after going over the high-level design with him. It's pretty vanilla really - a fixed size pool of particles with a life value incremented on cpu, and a stateless movement equation in the vertex shader.
!!!

So particles are just represented by a starting position and velocity and creation time, and then you calculate the current position with a parabola function using gravity or something?

Myomyomyo.
Offline princec

JGO Kernel


Medals: 404
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #22 - Posted 2012-08-03 14:39:45 »

Hmm probably not quite flexible enough for my purposes... our particles are animated as well, sometimes quite complicatedly.

Cas Smiley

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #23 - Posted 2012-08-03 15:09:27 »

I'm not, yet. Mostly just been eyeing up a friend's system after going over the high-level design with him. It's pretty vanilla really - a fixed size pool of particles with a life value incremented on cpu, and a stateless movement equation in the vertex shader.
!!!

So particles are just represented by a starting position and velocity and creation time, and then you calculate the current position with a parabola function using gravity or something?
Yup. And colours are done by indexing into a 2d texture (with life on one axis and a per-particle random value on the other). It's pretty old school really, but I'm only just getting around to doing a proper shader based 2d renderer, rather than FF.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
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 (42 views)
2014-10-17 03:59:02

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

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

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

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

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

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

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

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

BurntPizza (80 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!