How difficult will it be to learn Ogre?

[IceThatJaw]

I am 5 classes away from getting my CS degree and I am taking a game programming class as an elective.

We are attempting to design a 3D FPS using Ogre as the main engine. I am not even remotely close to being familiar with game programming but I am decent enough at C++. Although I'm afraid that my knowledge of inheritance, polymorphism, and the STL will not help me too much since it seems like it's mostly linear algebra converted into code from what I hear. (I did get a B+ in that class but I don't remember shit from it. haha)

Any pointers as to how to get started on learning this stuff while I'm on break? (besides the usual reading and tinkering?)

[WinwordExonar]

If you want to gain some footage over the other class mates, learn the differences in OpenGL and DirectX. Do a lot of research using google to understand why those two are being called from within Ogre. It may seem out of the way, but the truth of the matter is, Ogre is just a front end for one or both of those two APIs. The reason that its important to know WHICH API your using is because of the Shader Language and Hardware support. With DirectX its known as HLSL or High Level Shader Language. In OpenGL its shader is GLSL ( OpenGL Shader Language ). ( Both have a similar C like scripting language. ) Shaders are used in practically all 3D games in general now days if you want the game to look good. Example : I wrote a game in BASIC. But I had to know the Shader language of choice for my game if I wanted to use water and make it look good, which means I had to know if my game supports DirextX or OpenGL. Well the Language IDE I used for BASIC ONLY uses DirectX, so I had to know this so that I knew which shader language to use. Which in my case at this time was HLSL.

It is the same no matter what Engine you use or graphics API you use. You must know the main API your working with so that you can prepare yourself. This ALSO means you need to know what the NATIVE version of DirextX and OpenGL your video card can support. ( Native meaning it is supported by default from the manufacture. ) This is VERY important. Why ? Well take the game Crysis 2 as an example. It supports DirectX 9 and DirectX 11. But, DirectX 11 tessellation support is NOT enabled by default unless your video card is a NATIVE directx 11 video card. Meaning, you will NEVER be able to enable support for DirectX 11 on a video card that is only native for DirectX 9. You CAN install DirectX 11 video drivers, but the hardware was not made for it meaning NOT ALL features will be supported. ( SOME features might be supported though. ) Tessellation is actually one of those features that is a DirectX 11 Native support ONLY. So no card that has a previous native version of DirectX 9 will use it. So in Crysis 2, I have seen sooo many posts on their forums from people that complain about how they cannot enable DX11 support and its because of their video card every time. Graphics programmers NEED to know these little tidbits. Your target audience is everything in game design. This is where research comes in to play here to knowing what the target audience is using as an average when it comes to Video Cards. In other words, is the average user supporting DirectX 9 or 11 now days, or are they using OpenGL 2.1 or 3.3 now days.. When your done making your game, will the target audience be using DirectX 11 on the average, even if DirectX 12 comes out ?

Now i'm not saying that your Native DirectX 9 video card cannot install the DirectX 11 Drivers. Nope. But I am saying that not all the features will be accessible by your video card. Same goes with OpenGL.

Believe it or not, everything I just mentioned here you will learn over time. 3D Game programmers understand this. Its why sooo many in class quit the class before its finished because there is SOO much you have to know. And knowing the Video Hardware as well as which API your going to use is one that is important and most fail at this. They see the glamor in game making but don't realize what all is involved and I have to admit it is a LOT of work. But oh so awesome once your see your 3D come to life.

This is a demonstration of a terrain I did in BASIC using the DarkBasic Pro engine ( DirectX support only. ) If I did not know that I was using DirectX, I would not have known which shader language I could use. So don't listen to people who tell you that you do NOT need to know which API and other info. It just means they are not 3D game programmers, even if they are good at programming. ( Notice how I say 3D all over my post, not 2D game programming. Shaders are not always used in 2D game design and so my whole post here would be useless. )

http://www.youtube.com/watch?v=CuUWGeAyRRM

http://www.youtube.com/watch?v=JOlyCN9txbg

NOTE : Please forgive the first video, I was not actually planning on putting this out there for the public originally when I made it so the sound was bad. The second shows you that I accomplished shadows on a Matrix Terrain by making aligning the Matrix Normals. If you do not understand Matrix Math and Normals, you will learn this in class. Hopefully. Its a LOT of math, just letting you know now. ( Algebra and Trigonometry )


NOTE : I forgot to mention Cg library which is the Cg shader language. All this is, is the basic functions that most all GPUs know and can use. A lot of 2D gamers will use this too.

[IceThatJaw]

Cool , thanks. We did mention DirectX and OpenGL and we were leaning towards OpenGL because the computer lab at my school is mostly linux machines. My own rig is pretty beastly and can handle any game on the market but most of the students just have regular laptops.

I guess I will read up on GLSL and how to use it in Ogre.

[WinwordExonar]

I highly recommend reading this book for GLSL :http://www.amazon.com/OpenGL-Shading-Language-Randi-Rost/dp/0321334892/ref=sr_1_1?s=books&ie=UTF8&qid=1324156129&sr=1-1

This is OpenGL® Shading Language (2nd Edition). There is a 3rd Edition. But as you soon will find out, most computers barely allow you to use it yet. My current HD Intel 3000 Video card sucks and will barely run the OpenGL 3.1 shaders. But the 2.0 from that 2nd edition book runs great. Your Ogre class most likely will take advantage of the 2nd edition book of shader info. Meaning Shader Language 2.0.

The other book I recomend you keeping in your library of books : http://www.amazon.com/OpenGL-SuperBible-Comprehensive-Tutorial-Reference/dp/0321498828/ref=sr_1_8?s=books&ie=UTF8&qid=1324156012&sr=1-8

This is the OpenGL SuperBible 4th Edition. Do not bother with the 5th Edition as it will not work. Again, this is for computer that have AWESOME video cards, and Linux users usually do not run Video cards that can handle it yet. ( I'm not saying they wont, but the chances are slim that they are using the latest Tech on Linux. ) The 4th Edition book has all the code on their website for you to download and compile here : http://www.opengl.org/sdk/docs/books/SuperBible/

Make sure you read that RED at the bottom. It will say Code for Fourth Edition. Also, double check the file after you download it. The file gets corrupt sometimes from that website. A Few of us have complained about it over the past couple years.


If you want tutorials on OpenGL : http://www.videotutorialsrock.com

Also, most everything ( including that 4th edition SuperBible ) uses wrappers known as Glut / Glut32 and freeGlut. Swap out Glut / Glut32 library references and put freeGlut in its place. You can still use the Glut commands. FreeGlut is the free and open Source alternative to Glut. Glut / Glut32 has not been updated since 2001. But freeGlut is up to 2010. So all the website that require Glut, just use freeGlut instead.

Hope this info helps. :)

[Nathaniel Sheller]

From what I heard it sounds much easier then learning raw OpenGL or raw DirectX. I learned raw OpenGL and it was pretty tricky at first to grasp but I soon picked up on it.

http://www.cprogramming.com/tutorial/openglvsdirectx.html

Take that into consideration if you ever want to learn the raw counterparts.

[WinwordExonar]

This is VERY TRUE. Its much easier to learn freeGlut then to learn the straight up OpenGL API. I totally agree with that. My game would have never gotten off the ground if it was not for freeGlut because its the first of the OpenGL wrappers I learned. From there I bounced around with Shaders and now its so much easier to make 3D terrain or whatever else I want to do.

[Ben Bowen]

I must be unusual, but I enjoyed working with the bare APIs a lot! I thought they (both GL and D3D) were fun to learn and experiment with.

However, my struggles have always seemed related to handling the C++ language itself, rather than implementing new things, which makes programming hell. I guess this is because I'm always trying to find the "best" way to do things before I get anything accomplished. No, this is really because the "not-the-best way" is actually extremely terrible (I think?)

And then there's that FreeType compilation/linkage roadblock, when I was trying to make a text engine. That just killed all my fun.

I must be a freak, because this bad programming season I've had has tortured me. Now my life sucks... really.

Mental disorder confirmed. Blah.

Should I post a question topic now? Maybe you guys can help me.

[WinwordExonar]

@ Ben Hahaha.. you sound like you have had a bad day.. been there bro. IF you got a project your working on I would love to hear about it. I love learning new things and seeing new ideas. Its amazing the technology that is actually out there. I was in shock the first time I saw an ACTUAL interactive hologram on a HUGE stage and you could literally see all the objects the guy was touching in mid air. Talk about impressive.

[WinwordExonar]

I just was introduced something that I had seen but not tried yet and thought you guys might want to check it out.. Its OSG - OpenSceneGraph. Basically its another OpenGL toolkit.

http://www.openscenegraph.org/projects/osg

Covers all the major OS's. Check it out.

I pulled this out of that beginners guide :

System requirements
OSG can run on most computers, as well as mobile devices with OpenGL ES installed which is
a subset of OpenGL 3D Graphical API that was specially designed for embedded devices. OSG
has been designed to take advantage of multi-processor and multi-core architectures, and
works fine on both 32 and 64 bit processors.
Since OSG is an OpenGL-based scene graph API, it is recommended that you have an AGP
or PCI-Express graphics card which guarantees satisfying OpenGL performance. In fact,
most professional and consumer grade graphics hardware on the market nowadays should
suffice for development needs. OSG is capable of working with a very low version OpenGL
and limited graphics RAM, at the price of losing particular rendering features and functional
extensions. Therefore, it is suggested that you have the latest version of the device driver
installed on your machine before programming with OSG. A graphics card with 256 MB or
512 MB of memory will be a good start, too.
The needs for disk space and system memory depend on specific application requirements
and the scale of the datasets to be rendered. Basically, the core OSG binary and library file
size is up to 30 MB, without any debug information. The size of the executable file will be
even smaller and only those shared library files are necessary at runtime.
Note that developers who decide to build OSG completely from the source code
have to make sure there is at least 3GB of free disk space available for storage of
intermediate files generated during the compilation process.

There is also an installer in case you do not want to compile it from source.

EDIT UPDATE : Ok word to those trying to use this in Code::Blocks. Give it up if your new to compiling from source. Because the only way to do this is to find a TON of tutorials on all kinds of libraries that this relies on. Apparently it is made for Visual Studio only. They never made a MinGW GNU GCC version. And from what it looks like, they do not plan on it only because no one has figured out how, OR they know how but never explained in steps HOW to do it in Code::Blocks. At least not so far. Not even their website is any help.

[naraku9333]

@WinwordExonar
Looks like OSG uses CMake to generate makefiles and it is capable of generating Code::Blocks makefiles. Also the dependencies page says you may not need the deps prior to building as they are for plugins.

[WinwordExonar]

Yes I know Naraku. But it doesn't work. I already tried all this. I even went on google searches for hours to find answers and what I wrote up above is what the end result of reading what others have written is how I came to that conclusion. It has some dependencies that MinGW requires, but no one seems to know what it is.

Its why I dumped that whole idea and I already got something working in OGRE 3D. Ogre is one of the easiest 3D engines I have messed with.

[S6k9GNh0]

Irrlicht is fun as well although it feels a bit dated.

Also, an alternative to GLSL is Cg shaders from nVidia, which is similar to HLSL. Despite some people stating other wise, it functions in both OpenGL and DirectX. It's also not just specific to nVidia cards.

[WinwordExonar]

Irrlicht is fun as well although it feels a bit dated.

Also, an alternative to GLSL is Cg shaders from nVidia, which is similar to HLSL. Despite some people stating other wise, it functions in both OpenGL and DirectX. It's also not just specific to nVidia cards.

Yes I totally agree. I been doing more reading lately on Cg.. I gotta say it impresses me more and more.

As for Irrlicht, I have been looking into it. Dated, somewhat, but.. because of it being open source, it can still be updated to your liking, so that's a plus. Also I like its license. FREE without any restrictions. Ogre 3D has some restrictions.

Irrlicht License : http://irrlicht.sourceforge.net/license.html

The Irrlicht license is based off of this : http://en.wikipedia.org/wiki/Zlib_License

Ogre 3D License : http://www.ogre3d.org/licensing
Ogre 3D License FAQ : http://www.ogre3d.org/licensing/licensing-faq


Its not that Ogre 3D is going to stop you from making your game, but you must comply with their rules ( License ) if your going to use their engine. Irrlicht, for the most part, doesn't care what you do.

Also, just to let you know.. Both Forums to both engines are still active even up to today. I have installed and gotten BOTH to work just fine with Code::Blocks. I love how easy Irrlicht was to setup for code::blocks once I copy and pasted their beginner code to test that it works. ( Make sure in C::B that you choose the Irrlicht icon from the list of choices and setup the folders directly to the includes and libraries through that popup window. It will work just fine without needing to add links to external libraries. Its fast and easy. )

Time it took me to get both engines up and running :
Ogre 3D --> 1 hour because it refuses to run if you do not have every god forsaken file.

Irrlicht 3D - 2 minutes, it will run and just send you a message if its missing files. But it will still run.

I had BOTH of them running using OpenGL 3.1 as the main API.

BOOKS :
IRRLICHT 3D
http://www.amazon.com/Irrlicht-Realtime-Engine-Beginners-Guide/dp/1849513988

OGRE 3D
http://www.amazon.com/OGRE-3D-1-7-Beginners-Guide/dp/1849512485/ref=sr_1_1?s=books&ie=UTF8&qid=1324735491&sr=1-1

Notice how NEW those books are.

What really FLOORED me here is that the Irrlicht book tells you the EXACT error that code::blocks is going to have and how to fix it. I am in love with Irrlicht. . hahaha

Change one lines that has s32 to u32 and it works just fine.