What is Reddit's opinion of
OGRE?
From 3.5 billion Reddit comments
80 reviews of this app found across Reddit:
Alternatively, if you're interested in getting started with 3D development at a slightly higher level than interacting with raw OpenGL or DirectX code, I'd highly recommend either Irrlicht or OGRE, two free, open source graphics engines. Irrlicht is the simpler of the two. It's somewhat stuck in the past compared to OGRE, but it is great for getting started (it's what I used to learn the ropes). OGRE is much larger and more complex, but it has built-in support for many features used in modern game and graphics development such as post processing composition, dynamic LOD, flexible vertex formats, etc.
no royalties AT ALL with the free and open source MIT licensed cross platform ogre3d system. no watermarks. no crap.
http://www.ogre3d.org/about/features
http://www.ogre3d.org/licensing/licensing-faq
http://www.ogre3d.org/gallery/album/72157613447657691/Featured_Projects.html
This may not be the answer you want to hear, but if you want to use an existing rendering engine, you're going to save yourself a lot of work and heartache by going with an existing dedicated rendering engine, such as Ogre3D, over trying to rip the renderer out of any full-game engine.
Agree, nothing personal here.
Ogre3D sadly not part of GSoC 2014 (but they're part of GSoC 2015)
Also Blender3d been rejected as well.
If we're going to make an open source KSP-like game then I'd prefer it if it were fully open source, meaning that every component that we use should be licensed under either a permissive license like MIT/Apache/BSD or a Free Software license like GPL. Godot fits this criteria, but things like Unity or UE4 don't.
Other options would be things like Ogre or Urho. They might be harder to get up-and-running than a more user-friendly engine like Unity or Godot but it might be worth it in the long run.
The project looks awesome, though I have really mixed feelings about the graphics engine it uses, Irrlicht. It's awesome in that it has a super clean API, is really easy to get into, and super easy to set up on your machine. Unfortunately it's stuck in the mid 2000s:
For some reason it has a continued goal of supporting DirectX 8. Since that was dropped from the DirectX SDKs around the time DX10 showed up, there's no (official at least) support for DX 10 or 11.
It eschews the standard library and uses its own containers and algorithms instead. Once upon a time this was done because MSVC had bugs in its standard library implementation, but it's 2014 and they're still rolling their own.
It uses manual reference counting to handle all its resources. It works, but it's is pretty easy to forget (and therefore leak). The use of smart pointers or even some kind of RAII guard to help with the ref counting would be great.
I really love the library, and a long time ago I was a pretty active member, but it's becoming more of an anachronism every day. I realize it would be a monumental effort, but they really need to move forward. I usually pitch my tent with Ogre if I'm in need of a graphics engine nowadays.
> I hope GLnext can keep up
OGRE 2.1 includes AZDO (Approaching zero driver overhead) improvements supporting OpenGL 3+ : http://www.ogre3d.org/2015/02/06/ogre-2-0-rc1-announcement
You can clone Git from here : https://bitbucket.org/sinbad/ogre/commits/branch/v2-1
I've seen lots of people learning graphics programming in OGL/GLUT lately. While I appreciate building from the ground up, I think there's also some merit in higher level graphics dev that abstracts the details until you become curious about them.
If someone told me they wanted to get into graphics dev, I'd recommend Irrlicht or OGRE. I started in Irrlicht, and it really let me get used to basic concepts like meshes, textures and UV coordinates, etc., without feeling overwhelmed by matrix math.
Does anyone else feel this way?
> Irrlicht
Seeing Irrlicht mentioned makes me sad and nostalgic. It's awesome in that it has a super clean API, is really easy to get into, and super easy to set up on your machine. Unfortunately it's stuck in the mid 2000s:
For some reason it has a continued goal of supporting DirectX 8. Since that was dropped from the DirectX SDKs around the time DX10 showed up, there's no (official at least) support for DX 10 or 11.
It eschews the standard library and uses its own containers and algorithms instead. Once upon a time this was done because MSVC had bugs in its standard library implementation, but it's 2014 and they're still rolling their own.
It uses manual reference counting to handle all its resources. It works, but it's is pretty easy to forget (and therefore leak). The use of smart pointers or even some kind of RAII guard to help with the ref counting would be great.
I really love the library, and a long time ago I was a pretty active member, but it's becoming more of an anachronism every day. I realize it would be a monumental effort, but they really need to move forward. I usually pitch my tent with Ogre if I'm in need of a graphics engine nowadays.
There is nothing better that Ogre for this, IMO. It's pretty simple if you are good at C++, and very powerful. Have a look at the Paging Landscape Scene Manager, in which I think you might even be easily able to change the heightmap etc. live, using brushes. If not, search the web, there is at least one Scene Manager supporting that.
Also if your game needs physics, have a look at OgreBullet, which "allows you to easily integrate Bullet Physics Engine into your project".
For GUI there is MyGUI, which is pretty powerful, maybe a bit confusing at first (lots of XML files, a bit of code involved in making it work) but really great once you set it all up.
The MMORPG game Eve Online is written in python for example. [just google "Eve Online python" instead of asking for citations please]
If you were to do something like these, you would probably be implementing the graphics engine using pyOgre http://www.ogre3d.org/tikiwiki/PyOgre which is realy just a python binding for the c/c++ graphics engine. For the physics engine you would use the python wrapper for physX, and for collition detection you would use another library written in C or C++ and the rest of the game logic you write it in python. Note that since you are using python wrapper for the libraries, you end up coding only in python 100% of the time.
Been waiting for these scans since the announcement since I can't get PC Gamer US in Holland... obviously. Thanks for pointing us towards them.
The article mentions "interior mapping". There's a post on the Ogre forums about how it works, for those interested.
It also mentions Chris Tilton as composer. Check out The Coma-Naut for an example of what he did.
I'm mostly working on 3D procedural generation, and here is my advice. If you're familiar with Java, JMonkeyEngine is incontestably the best in 3D. If you're more into 2D, libgdx is your best choice. You can set up both of those engines in few minutes and begin prototyping right after. There are A LOT of tutorials for both those engines, just Google them. If you prefer C++, then Ogre3D might be right for you. I've never really used Unity/Unreal, so I can't really talk about them.
Heh, honestly, you couldn't learn how to build a 3D engine in just a week. I'd suggest you start with a 2D game, and go from there. But if you really want to, you could take a look at this open source 3d engine
Well damn I'm wrong.
But most engines I have looked at in the past used arrays of floats. For example OgreMatrix4.h. I had always assumed speed to be the reason.
ah, yes, it would be good to have a solid understanding of c++ before getting started. http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Tutorials
c++ is the kind of language you can spend a lifetime learning. You will never "know all of c++", but practice and you will get more comfortable. The best way to know if you have enough knowledge of c++ is to give it a shot and see how well it goes for you. If its too challenging, just step back and go to something more basic.
You could try OGRE. It's a clean, powerful graphics engine, and it's very active and open-source. You can get started by just modifying one of the samples that comes with it, there's loads of documentation.
I started out in managed C# to learn the basics of 3D engines. This was when XNA got serious, so I decided to switch. At first I was surprised how easy it was to make prototypes, but then I found myself in a never ending battle against the content pipeline and the garbage collector. I decided to return to a more controlled environment.
At this point I was also fed up with installing XNA2.0, XNA2.1, XNA3.0, DirectX, C# runtime, visual studio, etc. I decided to look for open source alternatives. At the time I had sort of an "assembly" viewpoint of C++, expecting it to extremely hard. However, eager to get into industry standard, I downloaded Ogre and started hacking.
That was a painful start, but that's my way of learning. Headers, linker errors, circular dependencies was all gibberish and "useless" in my eyes. By trail and error I slowly figured out what worked and what didn't.
Now that XNA has become mainstream and is considered a valid language to make games in, I sometimes question my decision to switch to C++. It's more complex, marginally faster, less convenient (GC). But for me, it feels more correct, as I'm able to get closer to what's really going on inside a computer. Also the ability to have no proprietary dependencies, but to rely on open source libraries is absolutely wonderful. Programmers need to level up sometimes too.
I would look into OGRE: http://www.ogre3d.org/
I had to design a game for a senior project, and we did it basically from scratch using Open Scene Graph (which was a horrible choice) for scene graphing.
Found out about OGRE when we were near completion :( I wish we had used it. It's scene graphing (for graphics) and has a number of other useful utilities and plugins for making games in C++. Also has a Python framework and a ton of tutorials.
I happen to love Panda3d - it's a free, open source engine co-developed by Disney (for some of their games) and Carnegie Mellon. They have quite an active community on their forums, and the library is very simple and easy to use (and has a good number of advanced features too).
I'm working on a barebones, sample FPS right now to learn the ropes, and I have projectiles, animated sprites, a 3d world with collisions, and UDP networking in about 1.3K lines of code.
It's free for non-commercial and commercial projects alike (except for their sound library, but that's easily replaced).
I've also heard good things about PyOgre, but have no experience with it.
If you want a PBR workflow and to keep the game open source, you can use the Blender Game Engine or the new Rendering Pipeline with Panda3D. Both utilize Python, although performance-light PBR is only really approachable in BGE at the moment. You could also use OGRE's new material system but you'd need to plug in another engine or create your own to get it working.
If you don't care about Physically Based Rendering, I'd say stick to Godot since it has a more predictable future, rich visual editors, Python-like syntax, and additional C++ support if you need it to squeeze out some more performance. It's also got more platform support and it's likely to actually have a PBR renderer in the near future.
However, if you're willing to give up some software freedom, UE 4 is probably going to give you the most balanced package if you're comfortable working with it. If you don't need the console platforms or state-of-the-art visuals, Godot is probably right up your ally. I think Blender and GIMP are more than capable tools for creating the game assets, of course, as I use both in my professional work.
I've done some 3d game programming a long time ago in opengl from scratch using no engine so compared to that this should be a walk in the park.
Back then I found a good online tutorial, followed it then started changing it to make my own labyrinth game.
Basically learn by doing.
There are samples for ogre over here.
Have fun and don't forget to share your creation with us once it's done. :D
The same result can be obtained for 3d graphics, but you'll have to modify your projection matrix. There is more info on the matter on this Ogre3D wiki page
OGRE is just a graphics engine alone (an insanely good one at that), but using its extensive array of addons, it becomes a pretty capable game engine. I say go with OGRE + addons if you want to use C++.
You have some options, though arguably not as many as on Windows and nothing that can entirely match Unity. The Ogre engine has a pretty modern structure, API and feature set, exporters for most 3d editors as well as some authoring tools. It'll require more leg-work than Unity though.
Edit: On second thought, maybe the Blender Game Engine is closer to what you're looking for.
You're going to need 3D engine with good landscape and vegetation support. Unity is a good choice for beginners because of included tools and high-quality tutorials. Ogre engine is more flexible and powerful, at the cost of being more complex. You could check open source Stunt Rally for terrain and vegetation editor built on Ogre.
First step would be building a solid combat prototype. Expect to throw it away later, so you don't have to obsess over details. Work on 3D meshes, animation, combat mechanisms until you get it right. Work from there to turn it into a real game.
Here's an addon for Ogre3D that appears to do what you need, just remember that Ogre is just a renderer and that you'd have a lot of other work ahead.
Just another example, Torchlight also uses Ogre, and that's available as well as their level editor on Steam for both Mac and Windows.
I'm in a similar situation and I was looking at OGRE, I thought it looked interesting because it's open source and will work with Direct X and Open GL. Does anyone else have any positive/negative experience with the engine?
>the idea of manually mapping a color to each pixel
You don't really use OpenGL like that, it's more like: "Here's the blueprints for the triangles I want you to draw, the texture for it and here's a GPU shader program which determines how they are drawn". You aren't manually doing any rasterizing.
Anyway, I don't know any well used "mid-level 3D graphics API" except for Ogre3D which markets itself as a "graphics rendering engine". It's open source, cross-platform and C++ based (though probably non-modern C++). Hopefully it is what you are looking for.
There's a couple of ref on that page http://www.ogre3d.org/tikiwiki/List+Of+Libraries but I've never tried any of those. Hope this can help.
I'm also curious to hear about some AI libraries, even proprietary ones.
It helps to be very familiar with each API you want to support. DirectX and OpenGL have plenty of overlap, but there's also a lot of things that they do fundamentally different. For starters, OpenGL is state-based. For example, you call glActiveTexture to specify which texture unit you're operating on, and then you make calls to modify that texture. With DirectX however, you just make calls with a texture object (ID3D11Texture2D in DX11) that you've previously created. Furthermore with DirectX you need to track a Device and a Context object (ID3D11Device, ID3D11DeviceContext). With OpenGL, this is managed by the driver; You create the context with a call to wglCreateContext (on Windows at least), and from then on your calls from that thread are specifically applicable to that known context.
So, you want to abstract the high-level rendering concepts away from the API calls. You could create a virtual class for rendering and then inherit two copies of that class, one for DirectX and one for OpenGL. But if you go too low-level, you're going to find yourself putting in hacks to make one work more like the other. If you go too high-level, you'll have a lot of code duplication.
Honestly I think the best approach is to dive in and start trying to write your own. Read other people's explanations, look at other people's examples, etc. Your first rendering engine won't be perfect, but you'll learn a lot along the way.
Here are some links to get you started:
VR needs huge resolution and great anti-aliasing at high framerates. IIRC this means we need large buffers refreshed many times each second (notice that bandwidth numbers are per second, not per frame, so high framerates multiply the resolution problem).
Deferred shading (like in UE4 or the better graphics path in Unity) is a smart, hacky way to do impressive rendering, but this method was designed for TV/monitors at 1080p max. It uses a lot of big buffers and even Titan can get bandwidth bottlenecked by this method at very high resolutions.
Here is what a mastermind behing OGRE engine wrote about Deferred Shading that the consolized industry loves so much:
http://www.ogre3d.org/forums/viewtopic.php?f=1&p=505215#p505090
DS also cannot do hardware anti-aliasing, so supersampling (4x more pixels) would be the best solution. This means we should effectively render at 6048 x 3360 (based on eye buffer resolution from Valve) to use the full potential of CV1 / Vive screens and to get the most optimal clarity in UE4 games.
I'm not an expert and I might be completely wrong but I have a hunch that HBM is saving UE4 from being almost irrelevant for CV2 / Vive 2.
Meanwhile, Valve is developing an "unimpressive", "outdated", non-photorealistic traditional forward renderer for VR in Source 2 with fast 8xMSAA support...
Both godrays and caustics can and should be implemented as shaders.
http://www.ogre3d.org/tikiwiki/shaders - All about shaders in Ogre3D
http://http.developer.nvidia.com/GPUGems/gpugems_ch02.html - Caustics
http://http.developer.nvidia.com/GPUGems3/gpugems3_ch13.html - Godrays
If you need more help you could refer to /r/gamedev or /r/GraphicsProgramming
Yeah, I was there. I was just a bit dismayed when no discussion links were newer than 2009. I am also leaning towards Ogre, mostly because I found this.
Hey, thanks. I wrote the first version in Qt, doing the OpenGL part myself. The reason I'm asking is that I would like to do the 3D part on a higher level, because neither I nor any others in the group are very knowledgeable with raw OpenGL. Implementing picking was a particular pain in the ass. Ideally what I would like is to keep the existing GUI in Qt and get a higher level 3D framework and put it in a QGLWidget subclass somehow. But I'm not sure which is best for that. I'm leaning towards Ogre so far, mostly because I found good documentation but I was just wondering if anyone else had a better suggestion.
"Dead Cyborg" was made using the Blender Game Engine: http://deadcyborg.com/
The engine is not specifically for adventure games, but looking at the code of the game might help you.
The game is not open-source from what I could see, however you can open the .blend files which include the code with Blender. Here's what the author says:
This is not a free program - free to play but not free to distribute. The only download site of this program is www.deadcyborg.com - no other download sites allowed. -------------------------------------------------------------------------- Dear Blender users! You can examine and modify this game, but DO_NOT_PUBLISH your versions!!! Why? Because of the copyrights and because your untested version will ruin my business - the players will think: this game is untested and full of bugs... :-(
Don't forget: gamedev is my job, this is not a hobby project, I am not a student.
Note: You might want to get familiar with Blender and Python before getting into its game engine.
Since it's a generic 3D game engine, any of the many other FOSS game engines might be just as good as soon as you figure out how to set up an adventure-game-like system in them...
If you don't mind using a generic 3D game engine, but want to use a free or FOSS one, OGRE might be a good option since a lot of commercial 3D adventure games (Ankh, Jack Keane and The book of unwritten tales) have used it: http://www.ogre3d.org/
Otherwise, Adventure Game Studio is a free(as in gratis) 2D adventure game engine, but there seems to be some user-created 3D extension: http://www.adventuregamestudio.co.uk/forums/index.php?topic=29419.0
What the hell are you guys talking about? Have you even programmed 3d games? Everything is in terms of how you look at the screen.
X is left and right, Y is up and down (vertical) and Z is forward and back (in and out of the screen).
What you guys are actually referring to is called clamping. You put a ray downwards from your character and find the first collidable object, then set your feet at the level. Bam, done. If you have a terrain, then you get terrain fragments. Collidable entities (bridges, overhangs) then you get the surface of that.
Seriously, go check out Ogre, it is not even hard to use.
The shortest introduction is probably Mathias' GSoC proposal, here http://www.ogre3d.org/forums/viewtopic.php?f=13&t=77143
There is a whole forum section dedicated to it here http://www.ogre3d.org/forums/viewforum.php?f=25
and the commits are here https://bitbucket.org/sinbad/ogre/commits/branch/v2-0
If you intend to use OpenGL for graphics processing, I would strong strongly encourage you to use OpenSceneGraph. It's a very rich and finely tuned API for OpenGL which takes advantage of the object orientation of C++. I've tried using OpenGL and GLUT directly before, and it's a nightmare even for an experienced programmer.
On the other hand, if you intend to use DirectX rather than OpenGL, then it's not too bad. I would prefer the object oriented aspects of OpenSceneGraph over the buffer swapping style of DirectX, but I can't deny that DirectX has much better Quality Assurance than OpenGL could ever hope to have.
Another thing you might want to look into is OGRE. I haven't used it myself, but I know it's very popular, and I understand that it works similarly to OpenSceneGraph.
Try OgreXML (It can be either XML or binary). It's a format used by the Ogre3D graphics engine and has widespread support in many modelling packages.
FBX is another option. Same deal, it's widely supported by most 3D modelling tools.
Lastly, you could just roll your own. But you'll waste a lot of time creating tools. That time could be put to better use.
Since you are learning C++, I would say go with Ogre.
http://www.ogre3d.org/docs/manual/manual_4.html#SEC4
It should be ready to go for you, without having to do all the nasty platform overhead. You can even create your meshes progromatically if you want.
Read up on Games Engines at Wikipedia.
DevMaster is a huge list of game engines you can look at.
Ogre is a popular 3D game engine that's nothing but graphics.
Sure, it's just that even 'moving things around' in a commercial-grade full-blown C++ 3D engine (nee game framework) like Ogre requires fairly extensive knowledge of linear algebra, C++, scene graphs etc. Quite a mouthful. At least for starters.
I jumped into C++ and game development with the Ogre engine, and it's been excellent. It's open source, has a very permissive license, supports multiple platforms, and doesn't get in your way.
It will run on openGL or Direct3d, and you can get very fine grained control if need be.
There are loads of tutorials, and it seems like a lot to take in initially, but once you plow through, you can really start making things quickly!
Basically, with texture atlas you have all your textures packed into a single texture. Now, texture coordinates for your vertices must map into this atlas, so it's a question of parameterization. So you have a function [0, 1] -> [us, ut]. Where [us, ut] is in texture atlas coordinates. Find this function.
May want to check out nvidia's paper on texture Atlas:
There are problems with texture atlas such as mipmapping and filtering issues, which are explained in the above paper. To get around this issue, you can find a solution here:
http://www.ogre3d.org/forums/viewtopic.php?f=4&t=61602
Or you can use Texture Arrays.
These aren't OpenGL problems, just basic programming problems. OpenGL puts triangles on the screen. Everything else is not an OpenGL problem.
Your mouse callback has to handle all jobs, usually by calling out to a hierarchy of event handlers registered from different areas of the code.
Honestly, if you're a beginning programmer or just beginning graphics, I really recommend you use an existing graphics or game engine. You can learn a lot about how modern graphics code is structured from an engine like Ogre3D.
Additionally, the fixed-function, immediate-mode OpenGL you're using in your code is obsolete by about 10 years. New OpenGL code should use the modern API with shaders and VAOs. And, frankly, that's a little hard to explain how to write from scratch to a beginner who doesn't know how any of modern graphics works. So using an engine can be a good guide just in how things work. And it will provide many convenient utilities for things like mouse handlers.
I only do graphics stuff sometimes as a hobby but if you want to be a graphics programmer professionally knowing opengl, directx and vulkan makes sense.
If you want a feel for how gpus work you could start with higher level stuff like bgfx or maybe a rendering engine like Ogre. You might learn something about gpus from CUDA too.
If you really feel like waiting for Vulkan you can always brush up on your linear algebra and read-up on the theory of raster rendering.
So far graphics programming seems pretty tough (debugging opengl = wtf) but if like C++ so far then go for it.
Hypothetically, you could paint the Windows Forms canvas with whatever you wanted and make any kind of application. You pretty much just asked how to create an "app for windows" and I gave you a way to get started. From the sounds of things, it's unlikely that your first effort will replace Skype, so maybe starting small would be a good idea?
In answer to your second question: no. You literally never need an IDE like Visual Studio. Again, I was trying to help you along the path of least resistance from "how do I start" to "hey look, I made a thing". You should absolutely feel free to follow an Ogre3D tutorial with whatever editor and build tools you'd like to use. Knock yourself out.
I haven't used this graphics engine before, but you might be able to start with it: http://www.ogre3d.org/about/features
It should handle the rendering parts for you, while you tackle the engine parts.
>What options do I have for a lightweight 3D engine
I was looking for one earlier as well, but there wasn't really a good one.
The major ones that I came across (for C++) was
But they all had gripes or lack of active development that turned me away, so I ended up rolling my own thing with OpenGL. It was just a little hobby, so I wasn't exactly pressed on time, but if you are, I would suggest Unity or Unreal.
One thing about ogre that makes me chuckle though is just the first post on this
http://www.ogre3d.org/about/testimonials
I wouldn't use it for a game and yet some navy thinks its a good idea for physics simulations, suddenly it seems we didn't have it quite so bad :P
>ogre
http://www.ogre3d.org/tikiwiki/CMake+Quick+Start+Guide?tikiversion=Linux
I would of thought you would use the guided link in the first post.
(sudo) add-apt-repository ppa:andrewfenn
(sudo) apt-get install libogre-dev
Here is another way to install ogre. http://www.ogre3d.org/tikiwiki/Installing+the+Ogre+SDK?tikiversion=Linux
You could take a look at how existing open source object-oriented graphics engines do it. I know OGRE3D wraps both OpenGL and Direct3D in an object-oriented abstraction layer, although I'm not sure how up-to-date OGRE's OpenGL usage is. The Torchlight games use OGRE, btw.
> You wont ever see a windows class where you're ask to work with a console.
They should be teaching you Power Shell Scripting and various other tools that are primarily command line only.
All I got from this is that your Linux class was maybe decent but your Windows class was bad. You will be expected to deal with the command line even in Windows.
It's unavoidable, a lot of tools in your tool chain are command line only. Even Visual Studio can't completely shield you. They are just hidden away under project properties.
Look what you need to do to configure Ogre. A 3D rendering engine.
I do not think you're setting realistic expectations for yourself.
> I have experience with java and python projects
Java and Python are managed code languages running within virtual environments. There is more to learning C++ than new syntax.
> I'm competent in my ability to pick up c++ programming, just not in the context of the SDK or c++ project organization under an IDE.
Do you realize just how much work is involved in writing your own rendering engine? Even software rendering a simplistic scene of a "room with a box in it" is no small task.
Don't get me wrong, I think this would eventually make a good project for learning C++, but I would start much smaller first. Write some command line applications to start and maybe some MFC. I highly recommend a lot of reading.
When you're ready, I suggest you look at some of the code that's already out there. Take a look at the Quake 1 source code for a good foundation or something like OGRE for more modern techniques.
Oh goodness gracious.
Had only there been a real-world AAA game engine working on Linux for 16 goddamn years: http://en.wikipedia.org/wiki/Unreal_Engine
Or, you know, this one: http://www.ogre3d.org/tikiwiki/tiki-index.php?page=CMake+Quick+Start+Guide&tikiversion=Linux
Or almost every one of these: http://en.wikipedia.org/wiki/List_of_game_engines
But hey, we are totally special you guize. We really super duper need to write our own engine, for realz.
Also, you seem to be claiming that Starbound works flawlessly. Or that it handles lower-end hardware better than existing engines. OK.JPG
It's just a bullshit piece of code written by people who fail at project management. Get real.
Oh, and unless your main client base is using Linux, writing the game on a different platform than the one it will be running on is a BAD IDEA. Do like me and install the GNU tools on Windows. They are all POSIX, so they compile just fine. It's easier and also won't cause your support forums to implode on day one.
Why would people invest a lot of effort into making a top notch game engine without any graphics to go with it exactly. The open source projects that end up being top notch are the ones people end up using. That being said there's no lack of open source game engines like Ogre 3D.
In this topic, nerds who never wrote a game trying to claim that one shader in several hundred was so OBVIOUSLY the issue on ALL machines that Riot should give everyone 1000 free RP to compensate.
Seriously, chill the hell out and read a book. The orange book, perhaps. Report an issue and be done with it, the conspiracy bullshit is just there to make you feel like you uncovered something more than just a line in a config file.
And if you are wondering on a technical level, typically, when 3d game is rendered, you have two things - a mesh and a texture. Textures turned into shaders. Shaders are a set of small programs that run on the GPU.
Inking is almost certainly implemented by a shader. Case in point, this for the code and this for what it looks like. Pretty much by definition, if you add a shader, you are increasing the workload on the GPU. If you add a shader past some parallel processing threshhold, it's entirely possible to change the number of rendering passes performed on certain machines with certain hardware with certain GPU drivers in certain circumstances.
So get off your high horse.
Honestly, C++ is a terrible language to start in if you want to make a game.
Start with something like PyGame, then create a game state handler, then start translating those ideas into C++. Java and LWJGL are also pretty straightforward if you wanted lower level access to GL.
If you want to persist with C++, I personally enjoyed OGRE. Or, just write MUD style games - this will help you learn the language in the context of making a game, generating content, etc.
+1 for Ogre. I'm using it for my current project and would definitely recommend it. The community is really helpful and the website has a bunch of tutorials of varying complexity. I also find if you're stuck a google search along the lines of 'Ogre do x/y/z' will lead you to post in their forums by someone who wanted to know the same thing.
There is also a book for beginners (http://www.ogre3d.org/2011/01/10/ogre-3d-1-7-beginners-guide-book) but I've never used it.
I assume you are new to programming? If so, you might want to read up on algorithms and design patterns first before thinking about creating an engine. If you want to read code of a decent graphics rendering engine, Ogre3D is your man. It might only render graphics, but technically it's pretty good. You will need to know about design patterns at least when you read the Ogre3D source code (or code examples).
You have a great card (double precision, cool!) and it should support the profile. In the code, Cg is also instructed to use the latest profile, so in theory this should work.
I included your changes in the code, so the DLL and M_PI issues should be gone if you pull from the repo again.
Could you uncomment this line and report the output?
Thanks for your build instructions.
Edit: according to this thread, the problem might be that ATI's opengl driver is the issue.
It seems like the cool kids are using Unity these days. Unfortunately, as far as I cant tell, there's still an open petition for Linux support.
But it does look like they're working on WebGL+nativeclient support, which would run on Chrome in Linux with no additional plugins required.
There are actually plenty of alternatives, but I have no idea about whether this actually makes a good replacement.
This is probably unrelated, but in Ogre, you have the option to count batches. I believe this is the number of draw calls to the GPU, which in many cases is actually more important than the vertex count. Thus instancing exists. As for XNA and shader instructions count, I have no clue.
Ogre is a free open source 3D rendering engine. So you can look at the code and get in touch with the devs or other users.
I don't know any devs personally. So I can't help there.
That's kinda dumb to be honest. It should be a node connected to another node. Then you only need one movement. See Ogre's Node class for an example.
The whole entity itself could simply be generated once as one large static piece which would of course have the limitation of not having breakable blocks but that seems a fair price to pay rather then making all the individual cubes move.
Sure, no problem. This is an interesting post though: http://www.ogre3d.org/forums/viewtopic.php?f=4&t=63792
So for some very specific questions I may say: I have no idea what you are doing there (not because I am so smart/dumb/its so complicated although it may be but because of the issues brought up in teh gury myth post), this is how I do it posts code
I've learned more more languages than I have fingers though trying and failing, no education. Currently in progress of making a Ogre game. I always get things to work, but I don't know what is "correct" way of doing it.
How did you learn to program? (Asking since you proclaim yourself as a hobbyist.) Also, what "techniques" would you recommend for a 3D game? (Singletons, inheritance, game states, etc.)
I do glow in my current project by rendering only glowing objects, with a special 'glow map' to a buffer (non-glowing objects are black), blurring the buffer and adding it on to the normal render.
Here's a short article I wrote on it. I posted about it in the Ogre forums (Ogre is a graphics engine I use) and it spawned this Wiki article.
Good luck! :)
Unity is definitely pretty cool; I've been working with it lately.
OGRE has a bunch of projects that have used it listed here. Among the most prominent is probably Torchlight.
Irrlicht is also behind a few games, but a lot of people (including myself lately) shift from Irrlicht to OGRE when they start doing "serious" work. Irrlicht is an awesome engine to learn in because it keeps things extremely simple and straightforward. The problem is that it's based around the fixed-function pipeline. It supports shaders, but the devs are seriously struggling to bring the engine to DirectX 10 and 11 because its architecture is so focused on the fixed pipe.
Often very modified though. And there are other engines like Cube, Cube2(sauerbraten), Crystal space, Ogre 3D. (incomplete list, don't know which are good.)
i recommend you download the SDK version of Ogre and look at the code to the samples, try tweaking some stuff. just have fun at this point, it will help build motivation that you will need to buckle down and learn the language/principles.
IMO you should start with a 2d game engine. There are some options in this thread.
If you want to make a 3d game, the only thing I can recommend is the Ogre3d engine, since it's the only one I have worked with. It's really a graphics engine though.
I don't know if this will help at all as I'm not really an expert on engines, but I would suggest looking into various open source 3D engines.
Something like OGRE 3D would be a good place to start if you're looking for a decent rendering platform (without all the extra baggage that comes with most other engines) http://www.ogre3d.org/