Nusakan

As Frob mentioned, aside from C++ you definitely need strong understanding of some linear algebraic terms. However there are more things to cover as well. otherwise it will be just a rendering engine not a game. A game has to be interactive in order to be called a game. for that reason you need some collision detection engine. if you are brave enough to implement that yourself, then you need to learn  math behind collision detection as well.

start with something simple such as AABB vs ray, AABB vs AABB, OBB vs OBB Sphere vs Sphere and so on. You must understand the basics of matrix and vector manipulation before you dive in to collision detection though, otherwise you won't make sense of things.

I would recommend following books.

3D math primer for Game development(by Fletcher Dunn & Ian Perberry)

and

3D game engine Programming(by Stefan Zerbst & Oliver Duvel)

Hi!

 

I took it upon myself to finally start migrating from SDL to OpenGl in my project today. So far I've managed to (in isolated code) translate an SDL_Surface to an OpenGl texture which i then use to apply on polygons.

 

In my previous rendering method i used a lot of clips. Meaning I've got one image with maybe 3-5 images on it which i then clip before i render to get the desired image to show. I've managed to translate this over to OpenGl as well but it takes a bit of work and i need to know the loaded image dimensions before i do.

 

Just to clarify how the rendering process works now, so you get a better scope of my problem:

 

1. Loads image to an SDL_Surface

2. Saves it to an array

3. Something fetches the image memory location from the array

4. Converts the SDL_Surface to a OpenGl texture

5. Clips the texture

6. Renders it to QUADS

7. Destroys the texture

 

My Convert code is basically the same as this one here: http://content.gpwiki.org/index.php/SDL:Tutorials:Using_SDL_with_OpenGL

 

Question time: 

 

1. I've noticed a sudden drop of FPS since the tryout change (only the tiles are being rendered at the moment since haven't made it global yet). The drop if from 400+ FPS to around 60 FPS after i use glDeleteTextures(); on the texture I've just drawn. Why is this? I suspect it's the conversion that drains the fps.

 

2. If it is the conversion that drains the FPS, then it is smarter to convert the image once just as it loads and save the texture in the array instead of the surface? Sounds like it...

 

3. Is there any reason for me to save the image as a SDL_Surface instead of loading it from OpenGL directly? Can i do that?

 

4. If there is no reason at all for me to involve SDL in the rendering process then how to i keep track of the loaded image width and height? Right now i use surface->w/surface->h. Is there similar ways in OpenGl?

 

I think that's all! Thanks for your time, i really appreciate answers!

 

// Tallkotten

the part 7 of your code is I'm worried about. are you deleting the textures on every frame?? or before exiting the program ? if you are deleting the texture on every frame than that explains your low FPS. you should be init and generate textures  once and then use the glBindTexture( ) to assign them to the quads.

I finished my uni about a year ago. Although it was a uni course of game dev, and A.I, most of the thing we learned how to use existing game engines. Which really made me mad because we were still far from understanding how things ACTUALLY work. In a perspective of a programmer, i would assume too much abstraction can become a really annoying issue because we can not kill our curiosity towards how things works. After i finished the uni, i started doing something more ambitious, creating my own engine so that i could finally appreciate the complexity of making games. I still got a long way to go. i would still consider myself a newbie. However, i can now gladly admid i can  understand some of the  complex algorithms of a game engine.  Long story short, Learn from making an engine. it benefits a lot even if we are using an existing game engine.