OpenGL tips

Blake · December 19, 2002, 16:37

Compiling:
To make SDL+GL code compile under Dev-C++, use the following project options:
Compiler Options:

Code:

-I"\SDL" -Dmain=SDL_main

Linker Options:

Code:

-lmingw32 -lSDLmain -lSDL -liberty -lopengl32 -lglu32

If the code is advertised as "SDL/Linux" then it wont compile, it will bring up some weird error. You can either #include "windows.h" *before* including the GL headers, or you can do it how OpenSceneGraph does it, I'll attach the GL header to this post, you should be able to include this instead of "GL/GL.h" and it will do all the vodoo required to have GL.h included and working on all platforms

Note also that under Linux, a SDL app will compile with a main defined as either
int main(void) or int main(int argc, char **argv)
However, under windows, main MUST be
int main(int argc, char **argv)

Tutorials:
The two best resources are the NeHe OpenGL tutorials at www.gamdev.net and the OpenGL tutorials at www.gametutorials.com
NeHe
Gametutorials

Note that you WILL get compile errors for the SDL code for these tutorials, however 95% of the time the only required modifications will be the two things I pointed out above.

Blake · December 19, 2002, 23:14

hehe, I really should attach the darn file.

Zipped so the board will accept it.

Note the header is distribued under the GNU LGPL, meaning you can do pretty much anything you want with it except claim you wrote it

Vultur · December 20, 2002, 08:08

I'm looking a way to convert a SDL_Surface into an OpenGL texture: this will allow to use .PNG file format. Is it possible? Thank you for help.

Kurilka · December 20, 2002, 08:47

Why do you need it at all?
SDL in conjunction with OpenGL is used not for graphics

but for program initialization, threads, timers etc.

Blake · December 20, 2002, 16:38

Well, there are two ways:
Get an image loader designed to load OpenGL textures. (this really does seem like the better way...)

Take a SDL_Surface, and have some code to turn it into an OpenGL texture (this involves flipping the image, at the minimum). To find out how to do this, try looking at some of the tutorials - chances are the SDL versions will do something simialler.

DJ · December 20, 2002, 19:30

http://www.wotsit.org/

DJ · December 20, 2002, 19:31

File Format Collection

Kurilka · December 21, 2002, 06:35

2 DJ - Was it a joke?
I think that it's not yet decided what graphic libraries we will use. SDL+OpenGL are too low-level. And if we use something like OSG then there could be image loaders already.

Vultur · December 21, 2002, 06:41

I've found the code at GameDev, and I've modified it to load .PNG/.JPEG files.... Thanks for the help!

DJ · December 21, 2002, 07:04

Quote:

Originally posted by Kurilka
2 DJ - Was it a joke?
I think that it's not yet decided what graphic libraries we will use. SDL+OpenGL are too low-level. And if we use something like OSG then there could be image loaders already.

No, it wasn't a joke. I've found that site very useful for figuring out loading .3ds models, .X models and jpeg files for Quake3 BSP levels, i just thought it could be helpful in helping you guys figure out loading PNG files.

Vultur · December 21, 2002, 11:44

ehm... DJ... I have the code to load .PNG file (SDL_image.h)
My problem is to discover how to handle a texture once opened...
There are no books on the arguments and tutorials I've found won't explain how-commands-work...
SDL is not exactly easy to learn... and OpenGL is less clear!
I suggest to reduce coders craziness to attach part of code to implement simple things like 2D texture loading/showing...
In the meanwhile I'll learn as much as I can from GameDev tutorials...

DJ · December 21, 2002, 12:39

Ok, well I'm not sure how SDL does there stuff, but if you have a texture loaded then all you should have to do is bind it.

glBindTexture(GL_TEXTURE_2D,(unsigned int)texID)

note that the second argument is a pointer, so if you don't have a pointer variable just assign the reference '&' memory address of that variable.

Also, if you haven't done this in your initialization do this before binding the texture

glEnable(GL_TEXTURE_2D);

This will allow for you to bind the textures, when you want to stop binding a certain texture use:

glDisable(GL_TEXTURE_2D);

One more thing, all texture must have attributes (size) of powers of 2.

DJ · December 21, 2002, 12:54

Ok, that was just the beginning basics, I'm posting this in a new post hoping this can clear what's really needed.

When you get a texture you should have read or extracted the bytes for it somehow and stored it in your byte pointer: unsigned char* imageData;

Ok, so now that you have that, through your library you can set it up for use in your OpenGL program like this:

Code:


glGenTextures(1,&texID);
plBindTexture(GL_TEXTURE_2D,texID);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_S, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_WRAP_T, GL_REPEAT);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, (GLint)minFilter);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, (GLint)maxFilter);
glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
int mode = GL_RGB;
if(ci.depth==4) mode = GL_RGBA;
gluBuild2DMipmaps(GL_TEXTURE_2D,mode ,ci.width,ci.height,mode ,GL_UNSIGNED_BYTE,ci.imageData);

for the minFilter and maxFilter variables you can use GL_LINEAR or GL_NEAREST... mix them up and use GL_LINEAR_MIPMAP_NEAREST, this is just to get the best results in rendering the texture. Now that this is done you can use glEnable(GL_TEXTURE_2D) and glBindTexture(GL_TEXTURE_2D,&texID) for your use in your program.

Kurilka · December 22, 2002, 07:08

2 Vultur:
there are excellent OpenGL tutorials from NeHe (http://nehe.gamedev.net), and samples for SDL (could be found on SDL website)

targon · December 23, 2002, 11:13

Mmm... DJ, are you sure GL_MODULATE is right stuff? You prefer bother your head with vertex colors, are't you?

They're surely more easy to handle dynamicaly, but it seems to be excessive for this situation.

DJ · December 23, 2002, 12:08

I get impressive results...

targon · December 25, 2002, 04:04

OK, if you guys really want to bother with own 3D engine I may show you list of things I'm as artist expecting from you code to do (at least, eventualy, but not _virtualy_, please!):
1) Portability.
2) Really good FPS for complex scenes.
3) HW T&L native support (in fact, it's second item), so forget about glBegin/glEnd and display lists, stick to arrays.
4) For even more complex scenes (I've seen "3000 units" somewhere), impositors or other rendering caching techniques.
5) Multitexturing support, including, but not limited to
6) Environmental cubic mapping,
7) Bump mapping,
8) Vertex/fragment shader support (for platforms really supporting it, that means any modern 3D accelerator).
9) Particle systems, with some basic "particle physics" like wind etc.
10) Some simple animation support. No need to bones, IK and other advanced features, but feel free to add some anim sequence/script/whatever you mean.
Are you ready?

Kurilka · December 25, 2002, 07:58

Phiew...
I'm not

My thoughts:
- looks cool but:
- i don't think that we could implement (of course we can but the question of time...) such a complex engine, so if we want All these features then we should use somthing like OSG;
- what is HW T&L (i'm already getting mad from all these abbreviations)?
- do you think that all these features will be really used by designers?

targon · December 25, 2002, 08:31

This features are't something pure eye-candy. Items 1..4 are vital for 3D strategy game (large landscapes/space scenes, lots of units etc.). 5..7 are in fact somewhat obsolete variants of 8th, but the later still is't widespread (legacy 3D cards). All bunch 5..8 is for any not-ordinary looking surface any nowdays gamer expects, why StP must be worse than commercial ones? 9th is obvious choise for dust/smoke/explosions/stars etc. 10th is nessesary even for simple mechanical units unless you want table toke look for them.
No way, you need't all these once from the beginning; but this stuff will surely very helpful in future (do you expect this game has some future?).

Kurilka · December 25, 2002, 09:08

What is HW T&L?

targon · December 25, 2002, 09:16

HardWare Texturing and Lighting (though someone may call it HardWare Transformation and Lighting). This is that all modern 3D cards do unless you disturb them with obsolete rendering pipeline (ab)use (like glBegin/glEnd

).

DJ · December 25, 2002, 09:26

you can still get good results if you use glBegin/glEnd, if you cull right..., although my engine does ultilize vertex arrays because that's the best way to go i think :-D

Here's the difference:

If i render, say 5,000 verts with glBegin/glEnd, on my GeForce 2 | 1.2 MHz Athlon my computer will begin slowing down at a VERY noticable speed.

If i render about 60,000 verts with vertex arrays I experience no lag at all... Big difference eh?

I tested this idea actually on my 3D Terrain Engine when implementing quadtrees.

targon · December 25, 2002, 09:54

With arrays, 3D card (and its drivers ) may actualy upload vertex data into on-board memory (if you utilize it in clever way) and never bother about it (at lest on per-frame basis).
Vertex/fragment shaders are cool because all neat effects like refraction, grass, skinning, motion blur etc. may be disjointed from the mesh, so 3D card may stay in its rendering loop uninterupted. This is exactly the way of work all modern 3D chips were designed for. Vertex arrays (AKA "vertex buffers" in evil place far from here

) plus vertex/fragment programs.

Blake · December 25, 2002, 20:22

Well as far as I know, there is no-one on the team who has the skills to write such an engine. As such we are probably reliant on the work of other opensource projects for a decent 3D engine. Openscenegraph looks promising for sure.

The best strategy is probably to have it so the rendering can easily be changed, so initially we can use a quick 'n nasty 2D interface for testing stuff (prehaps written in straight SDL) and later change to a full featured 3D engine.

DJ · December 25, 2002, 21:15

Yea, all models in my engine (.3ds and .md3 models), are rendered with Vertex Arrays to provide the best performance. Unfortunantely my terrain isn't optimized yet, but it runs fine and i'm not sure if i'm gonna deal with it....

Vultur · December 27, 2002, 14:05

Quote:

Originally posted by Blake
The best strategy is probably to have it so the rendering can easily be changed, so initially we can use a quick 'n nasty 2D interface for testing stuff (prehaps written in straight SDL) and later change to a full featured 3D engine.

I've tried to inizialize the screen surface with SDL_OPENGL flag, and won't accept normal blitting with SDL

The things don't fit together...

Blake · December 27, 2002, 16:20

Yes... it says that in the documentation.

Try, instead of "SDL_OPENGL" use "SDL_OPENGLBLIT"

However the best way to do blits for small sprites (faster and better flexibility with stuff like coloring and rotation) is to convert the surface to a OpenGL texture then use it as a texture on a GL Quad.

Vultur · December 28, 2002, 07:09

SDL_OPENGLBLIT works fine...
But I've the impression that the program cannot blit together both a SDL surface, both a GL triangle...
Maybe I've forgot to write something, but I don't know what...
I think there is a simplier way...
Thanks for the suggestions

targon · December 30, 2002, 07:41

Quote:

Originally posted by Blake
Well as far as I know, there is no-one on the team who has the skills to write such an engine.

Right. Common horror story is the Boson.