For those who don't know what Ogre is like I didn't "OGRE (Object-Oriented Graphics Rendering Engine) is a scene-oriented, flexible 3D engine written in C++ designed to make it easier and more intuitive for developers to produce applications utilising hardware-accelerated 3D graphics. The class library abstracts all the details of using the underlying system libraries like Direct3D and OpenGL and provides an interface based on world objects and other intuitive classes."
It definitely existed earlier than that. I found an old project in my backups for a 3d space game that dates from 2003 and can see a CVS update history on the web archive that stretches back to 2002.
Not sure what the launch in 2005 entailed, probably a rebranding and freshening up to make it seem more serious and appealing to developers, but it was already one of the better 3d frameworks around at the time. I was able to extend it to support LUA scripting in my game engine, was well abstracted and really nice to work with.
You're thinking of the game from Steve Jackson Games, in the early '80s. Later on they made Car Wars, then GURPS, and Munchkin, among lots of other stuff. IIRC it was a science fiction wargame with hex maps and counters, about tank battles.
SJG is also famous for being raided by the Secret Service, having lots of stuff vital to their operations seized and being awarded a nice sum of money in SJG vs. Secret Service, which iirc. was also one of the reason why the EFF was created. They got on their radar because "The Mentor" of Legion of Doom fame (a familiar name for anyone reading Phrack at the time) also happened to work there and he distributed some (illegally?) obtained material via the SJG BBS.
The work in progress Cyberpunk module for GURPS was confiscated and believed to be a "handbook for hackers".
Ogre is a great little 3D engine. It is small and elegant with some tools surrounding it to make it work. One big downside though is that it is/was made in an 'object oriented' style where everything is a pointer to a virtual table that then points to a heap allocated object. This makes everything slower and more difficult to debug. Small games usually don't have enough entities to make it a problem though.
Worth noting is that there is a v2 branch of Ogre, which is a near-full rewrite aimed at fixing these issues [1].
It was, I think, more than 5 years ago that Matias Goldberg wrote the first demo of what speedups are possible in Ogre by following a data-oriented approach: contiguous structures, eliminating excessive branching, structure-of-arrays layouts, etc. I'm happy it's grown into something pretty usable today (from what I see).
Now it seems that all this is the standard industry wisdom, but I feel like at the time people were only slowly realizing the real cost of all those vtable lookups and abstractions.
Ogre has been around for a while and not only were people less aware of pointer chasing issues, they weren't as much of an issue relative to the full speed of the cpu.
Ogre got a bit of a critical review from Mike Acton a few years ago along those lines and since I believe they have re-architected things quite a bit. So I'm not sure from what version your comments apply, it is more performant now than it used to be.
It might not be the engine to use if you want to make Doom5, but some of the best selling games of all time of have been made in Java, or older versions of Unity, which have more performance limitations than Ogre.
Pokemon Go, Subnautica, Kerbal Space Program come to mind immediately.
It should be noted that ALL of these, including minecraft, suffered in quality because of their performance. But, commercially they all did really well.
Interesting side note. OGRE3D was created by a British citizen and they chose to follow many British idiomatic spellings - such as Colour - one of the few libraries I have used which chose those spellings over US variants.
I find it more interesting that some people expect the British not to use British English. It's not a choice, we just adhere to how the language was created. Apart from the US, British spelling differences are mostly followed by other countries where English is the main language too. It would be strange if an Englishman chose to use US spelling.
I am from UK, but for professional purposes I always use American spellings in APIs, even if it's an open source project and I'm the only author. It's objectively better for everybody to use a standard consistent spelling across all APIs.
For comments I use British English, I wouldn't know how to write American grammar if I tried.
But probably larger number of English speakers(including large countries in the Commonwealth like India, Pakistan, Nigeria, ) use the British spelling than American one.
I remember once getting confused when Android Studio kept pointing out that an Android SDK method I was calling didn't exist. Turned out I was using the British spelling of "colour".
That was the moment I realised most of the api calls I'd been making used the American spelling.
Generally agreed, if universality is a goal of the codebase. Eric S Raymond [0] and Jeff Atwood [1][2] have both written about the merits of the universal use of English in software development, and I think their reasoning can be extended to American English specifically. I say this as a Brit, generally fond of our proper spelling.
To expand on my proviso: if a codebase is written by and for British developers, I see little reason to use American English. For a serious international FOSS project though, American English makes the most sense.
It's costly to have a codebase undecided on proper English vs American English. If Alice writes 'initialize' and Bob writes 'initialise', it causes pain for everyone. This even applies to keywords and reserved identifiers. For instance, in Ruby, methods named 'initialize' get special treatment.
American English tends to dominate in tech, so if we have to make a choice, it's clear enough which one it should be.
Incidentally, Google [3], and apparently also Microsoft [4], agree with us.
> For comments I use British English, I wouldn't know how to write American grammar if I tried.
I think I could cope if the need arose (it hasn't for some time, for me). As you imply, the real value is in consistent spelling in the API, rather than in the comments.
On another note, I think it's an interesting choice of words that you wrote "created."
Languages and spellings weren't created at some point in the past. They evolved gradually and are still evolving. There's no principle stating that American and British spellings are forbidden to converge in the future.
My girlfriend, who is from Britain, also tend to go on about how "british english" is the only correct english because "we invented the language". Not 100% serious of course, but subconsciously I think she believes it. She also dislikes it when swedish (us being in Sweden) borrows english words and changes the spelling or meaning. I think this attitude is a bit lazy or ignorant - people don't think about what a language is or how languages develop when they say something like this. All languages are thieving slaves of fashion that cut, copy and paste with abandon, continuously.
"The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don’t just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary."
--James D. Nicoll
Ah, but which English? I rather suspect it was the American variety that did the most of that. Because, you know, American tradition of rendering unconscious and emptying pockets, and all. It's a thing, here.
On the topic of "words" "found in" pockets, they didn't harvest every single password I'd created for a handful of years because they didn't care about the USB drive-- just the bit of cash. I also had someone's CC# on a sticky note in my wallet, and they left it all on the ground. Amateurs.
Very true that languages evolve and you're right, "created" was poor choice on my part. In the case of the US however, even they spoke British English at one time, and then some guy called Webster decided to write yet another English dictionary, one with significant differences, in an attempt to standardise the language. This xkcd comes to mind:
> Apart from the US, British spelling differences are mostly followed by other countries where English is the main language too.
Canadian English is a funny case here — it adheres to British (Zed) and American (tire with an i) customs by equal measure, but by and large Canadians sound closer to ‘mainstream’ Americans than they do to Brits. This is of course ignoring Quebec...
Let's get this straight. There's "American English" used in the US and Canada. And then there English, where "colour" is spelled with a "U", and that's used in lot more countries, and natively spoken by more people than American English.
Really? Are you talking about India? If so, I'm not sure what percentage of people have english as their mother tongue - I think it would be quite small. Also, I think indian english is about as dissimilar to british english as american english is.
wxWidgets provides "wxColor" typedef too however and many functions exist in both "colour" and "color" versions. There would be just too many bug reports about misspellings in the API otherwise.
I can remember coding with Irrlicht around 2004, 2005. Ogre seemed to have a much larger learning curve, so I never dived into it. Glad to see it's still around, though.
Same here - for a newcomer to C/C++ looking to play with a 3D engine, I found Irrlicht way easier to get started with. And I seem to remember Ogre had some kind of weird pre-compile step that made working with it far harder, and put me off completely.
Wow, that's a blast from the past. A decade or more ago Ogre was one of the go-to engines for hobby game development, before Unity and Unreal sucked all the oxygen out of the room.
Wow, this is a trip to the past. The Ogre community was one of the first online communities I ever joined. I mostly lurked around it until I realized that I didn't really want to put up with C++ :). Nonetheless I am happy this project is still going strong.
Is there a good, feature-rich scene editor built around Ogre? How can someone build environments, place objects, create animations, check lighting, set physics, make game UI and cut scenes for something built upon Ogre?
The first result, which pops up, is the Glue Editor [1]. But this looks so basic, that I have a hard time coming up with a reason to try Orge. Compare this to Unity or Unreal where you can do everything above and even more. Maybe I'm missing something?
If you're starting from scratch and trying to pick a toolchain to build your next game with, there aren't many reasons to go with Ogre. Unity/Unreal will get you off the ground much faster, and the tooling is much better for sustained work.
On the other hand, if you're trying to build a C++ based game engine, Ogre isn't a bad place to start. However, you probably don't need your own game engine.
For context, I used Ogre for various things starting from ~2007 and stopped around 2015. By then Unity was the obvious choice if you were a 1-2 person shop and wanted to spend less time wrangling code and more time making stuff.
Ogre is a free open source library with a liberal MIT license unlike Unity or Unreal which are both proprietary tools. And in many projects you'll write your own editor so the lack of a good editor doesn't always matter. Being open source has a few advantages: You can adapt the engine to your project. You can learn how the engine really work. You can debug into the engine itself on troubles. You are less dependent on a company staying around maintaining a proprietary engine. You can influence the direction of development with patches.
It's an older engine, but it checks out. The games Torchlight 1 and 2 use Ogre and they look very pretty and never needed a high-end machine to perform well (even when they came out).
Wow Ogre is one of those things I looked at as a teenager and said Inwould learn, but lacked the attention span to do so. I didn't even remember it before this.
