9 replies to this topic

[trowtlip]

I'm spending way to much time goofing around. I read the panda3d manual and decided it's way to high level. I'm trying to setup and environment where I can work with 3d math AND still be able to build a game if I don't get bored or frustrated.

I started doing some opengl tutorials, and I'm enjoying this. One problem I find though, is if I get stuck or want some extra resources to understand something, I end up opening a whole new can of worms. I start off with GLFW and GLEW. The next resource uses GLU, so I have to start messing with another framework, further confusing the situation. Can someone point me to a framework that is pretty standard but that won't leave me lost when I need to add audio, or some other functionality, and is not going to be depreciated anytime soon?

I don't want to learn every tool before I even start writing any code. That doesn't make any sense, and doesn't seem productive. I want to stay as industry standard as possible. My intended platforms would be: Win, Linux, Mac and Android, although for learning Win is just fine.

Why does every tutorial on the exact same subject have to drag in a different framework? You should see how much crap I have installed on my computers, and I still haven't writen a line of code.

Is Qt a good place to be? GLFW, SFML?

[bd36]

You can use SFML to provide the windowing and an openGL context for you to use. You can also use SFML to get input for you. This way this window is there for you without doing anything and you get to to the rest yourself. The RC for the new version of SFML was just released, check it out. I was playing with it the other day then decided I don't want to learn openGL right now

[trowtlip]

The more I read, the more I understand this is going to be a long road. I bet it will take me a good year just to decide what kits/frameworks/environments to begin to with. One thing opens to another, and another, to another. It's overwhelming.

[Qasaur]

The more I read, the more I understand this is going to be a long road. I bet it will take me a good year just to decide what kits/frameworks/environments to begin to with. One thing opens to another, and another, to another. It's overwhelming.

I agree with you, I've been looking around for something for ages but I found LÖVE which is based on Lua, it is quite good if you ask me. I'll probably try SFML in the near future.

[zdkroot]

All of the things you listed are pretty standard. They aren't really frameworks, they're just very thin libraries. OpenGL itself exclusively handles graphics rendering. It doesn't have any way of doing audio, mouse/keyboard input, etc. DirectX has all of those things (DirectSound, DirectInput,etc) so for windows you can simply use DirectX if you want. OpenGL however, actually requires additional libraries. Basically everything you need to know can be found here or here.

SDL, SFML and freeGLUT are popular; GLFW is a freeGLUT alternative that also looks good. Only SDL and SFML handle sound, but they all do windowing and input. Qt and GTK+ are for gui building. Vlc for example uses Qt for it's interface.

You only need one of those, basically just pick one and use it until you have a reason not to. That being said, if you want to make a game more than you want to learn how to program a graphics/physics engine, you probably want to use an already built one, which will vary depending on what kind of game you want to make. Unity, UDK, LOVE, Ogre3D are all engines that do all sorts of different things. That is, as you said, a whole other can of worms. So what do you want to do? Write an engine or make a game?

[trowtlip]

Thanks for the replies. And thanks zdkroot, for the breakdown on the frameworks. When you ask what I want to do, I want to create a game environment with procedurally generated play areas. Land, space, water, whatever; and eventually create interactivity with areas of the game map (more than likely procedurally as well). I had little interest in game making until I started reading about procedural terrain generation, and some of the challenges and successes people are having.

This is where I have trouble deciding where I should start. It seems logical to start with lower level libraries I suppose, but it will be a longer road for me. When I finally have my Eureka moment, everyone else will be "ya, been there, done that - like 5 years ago". So I have to consider time as well.

[larspensjo]

I have gone through a similar situation. In the end, I found I spend 80% of the time programming low level OpenGL, sound, various libraries, and 20% on the actual game idea.

You mention using GLU, which indicates that you are looking at the OpenGL deprecated immediate mode. Consider taking the step to post version 3.

[trowtlip]

You mention using GLU, which indicates that you are looking at the OpenGL deprecated immediate mode. Consider taking the step to post version 3.

I need to research this. I certainly don't want to spend my time in anything 'depreciated'. So far I'm only in beginning opengl tutorials similar to what zdkroot linked for me.

[zdkroot]

Basically, anything related to the fixed-pipeline, is depreciated. OpenGL and DirectX both use shaders now, but OpenGL maintains backwards compatiblity by using immediate mode, which you don't want The modern 3D programming tutorial I linked uses shaders.

Based on your description, it sounds like you want to make an engine, and that's totally fine. Building an engine is something I'm really interested in as well. I've been doing a lot of "game development" research in the last few months, and it seems to me that most people don't have a clear idea if they want to make a game or an engine. Most of the advice is don't reinvent the wheel; if your goal is a game, then you shouldn't. But if your goal is to play with proceduaral terrain generation, and maybe make a game out of it, then do whatever you feel like

I would definitely check out Unity, UDK, Ogre3D and recently CryTek3 (I'm leaving off several, just wikipedia game engine), if for nothing other than to play with them and see what a real modern engine can do. They are all complete engines with an IDE that use various scripting languages. They handle everything from input to importing 3D models and assests to sound, etc. I've never played with them much, they may already have a built in means for doing prodcedural terrain generation. Best of luck! It's going to be a long road but I'm on it too, lol.

Edit: Further reading.

[larspensjo]

I can also recommend the link above from zdkroot (http://www.arcsynthesis.org/gltut/), it is based on the "current" OpenGL, and it contains a lot of good basics about 3D rendering you need to know. OpenGL is quite a steep step, not something you learn in a week.

Regarding spelling, I think it shall be "deprecated" and not "depreciated". But English is not my native language, and I can have got it wrong.