Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
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  
  OpenGL changes in the last 10 years  (Read 2671 times)
0 Members and 1 Guest are viewing this topic.
Offline Archibald

Junior Member


Projects: 1



« Posted 2012-02-21 21:23:05 »

I was doing 3D games for PC around 10 years ago and well, I need to refresh and update my knowledge Smiley We were working on openGL 1.2 with 1.3 being the "cutting edge version we should not use because only high end machines have it installed" Cheesy I was learning openGL via NeHe tutorials, I know RedBook rather well, I think I looked through BlueBook too. GreenBook and OrangeBook were not existing in my times. I have read the history overview here: http://en.wikipedia.org/wiki/OpenGL (althrough I simply don't know most of the terminology after 1.3 since these things were not invented when I was learning openGL, but I overall know what a shader is, these were just about to be introduced when I quit 3D). I plan of doing only very basic things in OpenGL, I don't have the resources to make a full fledged 3D games anymore anyway, so things like how to make the texture appear super cool does not interest me too much (althrough, it would be still nice to know Smiley).

Questions:
1) Is the information in RedBook still valid? Will the old code still work (I read somewhere about removed glBegin/glEnd, is that true?)
2) Can you drop me an example code of the simpliest method to draw a textured triangle (or a cube)?
3) What is the current minimum safe to use (guaranteed to be installed on lower end machines) OpenGL version for PC (Windows XP SP2, DirectX 9.0c)?
4) What is the current minimum safe to use (guaranteed to be installed on lower end machines) OpenGL version for Mobiles Android/iPhone)?
5) What is the current best tutorial for learning openGL (preferably something that is chaptered well, so I can notice what i already know and don't need to read and what is "new"?
6) Anything else I should know?
Online kappa
« League of Dukes »

JGO Kernel


Medals: 74
Projects: 15


★★★★★


« Reply #1 - Posted 2012-02-21 21:32:36 »

The latest edition of the Redbook is ok (but doesn't cover the latest versions of OpenGL), however if you're referring the old free version then its too old.

The biggest change in OpenGL is the move from the fixed function pipeline to the programmable pipeline (mostly in OpenGL 2.0).

I'd say currently a good target to learn these days is OpenGL 2.1 as you can use the programmable pipeline and work on most cards, any graphics card released in the last half decade should support it. Once you learn the programmable pipeline further OpenGL versions after that are mostly small incremental evolutions, unlike the the drastic change from the fixed function pipeline.

For mobiles OpenGL ES2 is used alot which is largely based on OpenGL 2.1 (with some bits missing).

IMO currently the best tutorial/book is 'Learning Modern 3D Graphics Programming' (you can find LWJGL ports of the examples in there here).

Example to draw a triangle can be found in the above book and is likely to use VBO's with shaders. The programmable pipeline has a higher initial learning curve than that of the old fixed function pipeline, however its much more efficient and faster.
Offline sproingie

JGO Kernel


Medals: 202



« Reply #2 - Posted 2012-02-21 22:17:31 »

OpenGL is ridiculously backward compatible, and the code in the Red Book will compile and run with no problems (mind you it's C, but once you port it to java, the API will work).  All the deprecated functionality is still there in backward-compatible contexts, which is the context you get by default.

As for what versions you want to target, it really depends on your intended platform, and there's a lot of variables to take into account there.  Rule of thumb is OpenGL 1.4 for low-spec "casual game" platforms and 2.1 for anything using shaders (shaders might be supported on <2.0 as an extension, but are likely to be so quirky that you won't want to use them at all).

The path for learning OpenGL is a bit of a dilemma: if you're at all targeting lower-end platforms (which includes 90% of game engines I might add, where "low-end" is any OpenGL version before 3.2) you'll need to know the fixed-function pipeline.  Otherwise, kappa's recommendation is good for an online resource.  If you're planning on buying a book, the OpenGL SuperBible is excellent: the fourth edition covers fixed function and a bit of shaders, and the fifth edition is all modern OpenGL with no fixed-function at all.

Also, be sure to read the top sticky post in this sub-forum.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline theagentd
« Reply #3 - Posted 2012-02-21 22:34:33 »

How is removing almost all fixed functionality a "small incremental evolution"? >_>

Until OpenGL 3 they just kept on adding stuff while keeping full backwards compatibility. I believe everything except GL_POLYGON_SMOOTH still works, and driver support isn't going away anytime soon. However, shaders have evolved to a point where almost all fixed functionality has become unnecessary since it can be done with shaders. Alpha testing is just a call to "discard;" in the fragment shader, shadow mapping is just a shader comparing z-values, e.t.c, so in OpenGL 3 they "deprecated" everything that could be replaced with shaders or could be done more effectively using newer OpenGL features.

Examples of things that were deprecated:
 - The fixed functionality pipeline (e.g. you can't render anything without a shader)
 - Multitexturing without shaders
 - glBegin-glEnd and sending vertex attributes one at a time, replaced by Vertex Buffer Objects
 - Alpha testing
 - Point and line smoothing

Many things are still there though, like blending, and depth and stencil testing. Anyway, OpenGL 2 is the way to go if you're masochistic enough to enjoy supporting hardware which best-before date was several years ago, but I'd recommend going for OpenGL 3 because the API is cleaner and it's so much easier to keep track of the OpenGL state. Well, I guess it depends on what you're doing. For 2D, OpenGL 2 is probably fine.

Myomyomyo.
Offline gouessej
« Reply #4 - Posted 2012-02-22 00:15:04 »

Hi

I still target OpenGL 1.2. theagentd has better skills in shaders than me, I sometimes waste some time with engines mixing fixed and programmable pipelines. Some things that should work just cause an OpenGL error (invalid enumerant)  Sad Shaders are difficult to use, you often have to program several versions of the same shader, it is quite difficult to debug. I don't know if you plan to use a 3D engine, none really provides the support of fixed and programmable pipelines, Ardor3D mixes both, JMonkeyEngine 3 relies much more on shaders.

Offline theagentd
« Reply #5 - Posted 2012-02-22 04:59:25 »

Hi

I still target OpenGL 1.2. theagentd has better skills in shaders than me, I sometimes waste some time with engines mixing fixed and programmable pipelines. Some things that should work just cause an OpenGL error (invalid enumerant)  Sad Shaders are difficult to use, you often have to program several versions of the same shader, it is quite difficult to debug. I don't know if you plan to use a 3D engine, none really provides the support of fixed and programmable pipelines, Ardor3D mixes both, JMonkeyEngine 3 relies much more on shaders.

You can load more than one of each shader type for each program, so it's possible to split up functionality between shader source files. You can also define a function without actually writing the code for it (like a Java interface) and then put that code in a different file. That way you can create an uber-shader which just calls a number of "abstract" functions (like transform(...), skin(...), e.t.c). If you don't want a certain functionality in a certain shader, just define that method as an empty method. When linking everything is inlined anyway, so there's no performance impact.

Myomyomyo.
Offline pitbuller
« Reply #6 - Posted 2012-02-22 09:22:08 »

Debugging shaders are in my opinion easier than fixed pipeline. I allways write complex shaders against ide with continious compiler. So I never have to bother run program and notice that shaders do not compile. This also give big perforamance hints when writing stuff.
Actual debuggin is easy becouse I can allways first check is vertex shader ok and just draw red or or normals.  If there are no problems with vertex shader then I just test every part individally and its really easy. Usually I found my errors when shader do not work inside of java code and its allways some openGL state that is wrong. Shaders are really easy becouse those are short and compact code that is stateless.
Offline theagentd
« Reply #7 - Posted 2012-02-22 09:59:17 »

Debugging shaders are in my opinion easier than fixed pipeline. I allways write complex shaders against ide with continious compiler. So I never have to bother run program and notice that shaders do not compile. This also give big perforamance hints when writing stuff.
Actual debuggin is easy becouse I can allways first check is vertex shader ok and just draw red or or normals.  If there are no problems with vertex shader then I just test every part individally and its really easy. Usually I found my errors when shader do not work inside of java code and its allways some openGL state that is wrong. Shaders are really easy becouse those are short and compact code that is stateless.
True, and there's a lot less OpenGL state to worry about. God, I've forgotten glEnable(GL_TEXTURE_2D) so many times...

Myomyomyo.
Offline kaffiene
« Reply #8 - Posted 2012-02-23 01:26:21 »

Debugging shaders are in my opinion easier than fixed pipeline. I allways write complex shaders against ide with continious compiler. So I never have to bother run program and notice that shaders do not compile. This also give big perforamance hints when writing stuff.

What IDE are you using which tells you that your shaders don't compile?
Offline theagentd
« Reply #9 - Posted 2012-02-23 10:19:18 »

Debugging shaders are in my opinion easier than fixed pipeline. I allways write complex shaders against ide with continious compiler. So I never have to bother run program and notice that shaders do not compile. This also give big perforamance hints when writing stuff.

What IDE are you using which tells you that your shaders don't compile?
Just try to compile it with OpenGL normally, and then query for the error log, which tells you where the error occurred, e.t.c.

Myomyomyo.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Danny02
« Reply #10 - Posted 2012-02-23 14:41:54 »

there is a plugin for netbeans, which is called opengl pack

which comes with alot of jogl opengl examples project templates and..
GLSL code editor, so netbeans can autocomplete your shader code and mark errors while typing red and so on
Offline gouessej
« Reply #11 - Posted 2012-02-23 21:13:07 »

there is a plugin for netbeans, which is called opengl pack

which comes with alot of jogl opengl examples project templates and..
GLSL code editor, so netbeans can autocomplete your shader code and mark errors while typing red and so on
Bienator stopped maintaining this pack. Is it still used nowadays?

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.

Riven (19 views)
2014-07-30 07:09:19

Riven (13 views)
2014-07-30 07:08:52

Dwinin (12 views)
2014-07-29 23:59:34

E.R. Fleming (31 views)
2014-07-29 16:07:13

E.R. Fleming (12 views)
2014-07-29 16:06:25

pw (42 views)
2014-07-24 14:59:36

Riven (42 views)
2014-07-24 10:16:32

Riven (28 views)
2014-07-24 10:07:15

Riven (29 views)
2014-07-24 09:56:16

ctomni231 (60 views)
2014-07-18 19:55:21
HotSpot Options
by dleskov
2014-07-08 16:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 13:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 13:47:22

How do I start Java Game Development?
by ra4king
2014-05-18 00:13:37

HotSpot Options
by Roquen
2014-05-15 22:59:54

HotSpot Options
by Roquen
2014-05-07 04:03:10

Escape Analysis
by Roquen
2014-04-30 11:16:43

Experimental Toys
by Roquen
2014-04-29 02:24:22
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!