Ogre graphics engine??
Community Forums/General Help/Ogre graphics engine??
| ||
These days I thought about the possibility of learning c + +, in fact I'm reading my book that the only purpose I had was used to lock the door. But I thought Ogre, since what matters to me is that is free, would use his experience to know if it is a good choice. Last edited 2011 |
| ||
| I have played with it, it is extremely powerful capable engine. Its a fairly large learning curve though and if you are totally new to C++ you may want to consider starting with something a bit less complex. (or not :D) |
| ||
| It's very complete alright, but I think someone should only use it if they plan specializing with programming. If you're a one-man-band (making graphics, handling audio and programming) you need a higher level solution so you're not overwhelmed with its complexity, so you spend less time "fighting" with it and more time producing. Last edited 2011 |
| ||
| I greatly appreciate your comments, it is true that Ogre demands on the programmer but my goal is not to take a commercial project, but rather what I really want is to learn C + +, because it would give me more options in the future and I personally to know c + + gives more prestige to mention that I'm a programmer. No embarto is true, the learning curve is really a bit difficult, but I would like to specialize in something, at least as a Adaji says "If you want to be a garbage collector, wants to be president of your country" |
| ||
| what I really want is to learn C + +, because it would give me more options in the future and I personally to know c + + gives more prestige to mention that I'm a programmer. Nooooooooooooo.... C++ is a horrible, horrible language. It is an abomination and an offence against good language design. Cue rant, copied from here: Personal opinion: C++ is an easy language to use badly, and an incredibly hard language to use well. The basic principles of OOP are pretty much the same as in Java and C#, but combine first with all the features of C, and then a second set of duplicated features, to create a language with a massive amount of redundancy and dozens of similar but slightly different ways to do similar things. A lot of these features are also not as well designed as in other languages, and almost all of them were thrown in simply because they sounded good at the time with little or no thought for how they would work together, or even in many cases compete. C++ also does little to encourage or teach good programming techniques (many not even being possible in it), and has no concepts of important things like type safety or encapsulation. Those high-level features that it does have will usually also come at the cost of performance, meaning that you can either write fast programs in an obsolete subset of C, or buggier and comparatively slower programs using inferior copies of the high-level features in languages such as C#. The huge flexibility also means the language can't benefit from automatic code assistance in IDEs to the same extent as other languages. Strong personal opinion: C++ is a hacked together mess, and completely obsolete (as you observed above, it doesn't even have a garbage collector - that's not acceptable in modern language design). It is a nightmare to learn properly. I'd actually advise against learning it at all, because there's simply no need for it now that it's been completely surpassed by several objectively superior languages. The fact that many existing engines are written in it isn't a good reason to learn it; it's a good reason to learn something else and save the computing world from having to stick around C++ any longer than it has to. End of opinions If that came across as a little strong... it was meant to be. I honestly don't believe that you would be helping yourself to learn C++ at this point in history. Other strong competitors with it are: - C# (for non-game work, you don't need C++'s speed, and C# has type safety, libraries and a GC) - Java (similar advantages to C#, much better cross-platform compatibility and slightly better jobs available) - C (C is an excellent choice for implementing select parts of your program that do need performance; it's a much smaller, cleaner language than C++ - and not actually compatible with it) - OCaml (excellent blend of performance with incredibly strong, safe typing - this one will get you a lot of jobs in the financial sector) - Vala (as mentioned above, basically similar to C#, but as fast as C++ - meaning there's honestly no reason to use C++ at all now that Vala exists) ... and of course a hundred other things. I should also point out that "speed" is a vague concept. Compilers for C and C++ have traditionally output the fastest programs, but that's mainly because they were the best compilers. The idea that a GC slows down a program is rapidly becoming outdated; GCs reduce memory fragmentation and generally improve the performance of the memory that has been allocated, and the GCs themselves are very fast indeed at searching for unreachable memory (or in the case of BlitzMax and Vala, use reference counting, which has no noticeable speed hit at all). Languages that make use of Just-In-Time compilers, such as C# and Java, can also take advantage of certain machine-specific optimisations; the Java port of Quake 2 ended up faster than the C original thanks to this! And on the other side, there's the other kind of speed; developing in a low-level language that provides no solid type-checking and doesn't handle memory for you means that any reasonable program will be fraught with bugs, taking longer (between five and twenty times longer, on average) to develop and make reliable enough for release, all while providing no solid debugging features. ... yeah, that was a rant. Yes, it's true that C++will give you more options than Blitz, but Blitz is a tiny niche language only used by a few people. C, Java, C#, Vala, OCaml, Lisp, Python, Ruby, Haskell or even Smalltalk will also help you to get jobs, and get you far more respect. They'll also help you to learn to be a better programmer: C++ encourages bad programming techniques and many good techniques are either hard or flat-out impossible to use. It's a barely adequate language for an experienced programmer, and a pain to work in. For a beginner? A terrible, terrible mistake. There is absolutely no reason to use C++ unless mandated by a corporate employer. Learn a real language, and then if you need C++ for a specific job, you'll pick up what you need quickly. Learning it first is just wasting your own time. Last edited 2011 |
| ||
| @Yasha've left me in one piece, it's like when you're in the clouds and you get hit in the head and you return to earth, however I greatly appreciate your comments because you are very right. However I want to know your opinion about if instead of c + +, use Mogra, is a wrapper that allows use with visual basic 2008 or 2010 as these are free today. http://www.ogre3d.org/tikiwiki/MOGRE |
| ||
| it's like when you're in the clouds and you get hit in the head and you return to earth I hope my post didn't come across as harsh on you - I do want to help. Now I happen to have a lot of reasons for disliking C++, but just as I think you shouldn't use it for the reasons given above, do remember to make up your mind after reviewing both sides. As for MOGRE - The difference between OGRE and MOGRE is that OGRE is for use with C++ and other "traditional" compiled languages, while MOGRE wraps it for use with .NET Framework languages. So that's not really the choice - the choice is between traditional and .NET languages, and then use OGRE or MOGRE as the language you've chosen requires. As for VB.NET? These days it's basically just the same as C# but with slightly wordier syntax ("End Function" instead of "}", and so on). You might find it easier to learn because of the similarity to Blitz, but it does do a number of things differently - it's a lot more verbose. I haven't used VB, but all major .NET languages have modern features like a garbage collector, lambdas, proper OOP and so on, so they're better for learning good programming techniques than C++. ...as these are free today. My biggest piece of advice for you at the moment is to stop judging products by whether they're free. Almost every programming language is free - it's not normal at all to have to pay for a compiler (we don't buy Blitz products for the compiler, we buy them for the cool graphics libraries). So you can almost always choose the language you want first, and find a free compiler for it second. C#, F#, Java, Lisp etc. are all available "for free", and pretty much all of them work together very well. I'd recommend you do a survey of the different types of language out there and see what jumps out at you as "I like the look of this" or "this way of expressing problems suits my thoughts". A language should "sing" to you - you'll know a good one when you see it. To get started, try comparing example snippets (if you can find them) for: - VB.NET - FreeBasic - C# (that's pronounced C-sharp) - F# (similarly) - Python .. and if you're feeling daring and want to go way off into things totally new: - Scheme (a kind of Lisp) - Standard ML - Haskell (you probably won't want to use these with graphics, but you should see how different they look) All the languages I've listed above are wildly different from each other and will give you a good idea of how varied the scene is, and after looking at such a wide range of snippets, you'll have be able to recognise what kind of code "sings" to you. ...then, once you know what language you want to learn, you can get a graphics engine for it. On the other hand, if you want to learn a specific graphics technology, it may be more sensible to do what the makers of that engine recommend. e.g. if learning OGRE is a more important goal than learning to program. I'm assuming you want to know about programming in general, not about a specific graphics technology - I hope I do not misunderstand you totally. Extra note: As far as finding work goes, the best languages are probably C#, Java, Python and Ruby. These have the largest number of jobs going in the business sector. C++ and VB seem to have a large number of jobs, but they're usually for low-level grunt work and are not highly valued skills. On the other hand, there are also Erlang, Smalltalk, and OCaml, which tend to have fewer jobs available but will be much, much more highly paid. I've heard the rumour (unsubstantiated) that if you can actually find a job for a functional programming language such as OCaml or Lisp, the average salary is twice as high as for the common-as-dirt simple languages listed above. Last edited 2011 |
| ||
| Well THAT was an interesting pair of posts to read, Yasha. I know little about what goes on under the hood of the main industry these days; what languages are more commonly used, with regards to programming games? I had always understood, or at the very least assumed, that at least 90% of all mainstream, AAA titles were C++ affairs, with a few exceptions like the Jak trilogy for PS2, which I recall was programmed in Python. So what's the real scoop? Do the AAA players indeed use the apparently obfuscated Frankenstein's Monster that is C++, or what? |
| ||
| I found Ogre to be a pain with all its dependencies, don't know if this became better lately. You could have a closer look at Irrlicht which is quite powerful and much, much easier to grasp. C++ itself is a beast. It's not an easy language to learn and even more difficult to master - if that is possible at all. |
| ||
| I had always understood, or at the very least assumed, that at least 90% of all mainstream, AAA titles were C++ affairs, with a few exceptions Well, they probably are... 1) Games engines need speed. Many of the big-name AAA producers will choose to write their own low-level engine code from scratch rather than use an existing solution. While <language of your choice> is fast enough for everyday program logic, renderers and physics engines are a special case that needs all the power you can get out of a computer. There simply aren't that many compilers that can deliver that kind of power outside of C and C++, thanks to their immensely powerful, old compilers. (Even OCaml, mentioned above as being fast, is still several times slower than C for some things.) Other languages are making headway here but there's still a lot of work to be done. One thing to note is that the high-level features of C++ (exceptions, lambdas, etc.) aren't actually that much faster than they are in other languages (and just having exception support enabled slows down the whole program); most of the famous performance comes from the subset that's similar to C, so if you really want speed, you may as well write in plain C instead. 2) Games need a combination of different abstraction levels. Low-level direct pointer manipulation for the super-fast stuff, and high-level pushing around of objects for the things that aren't speed bottlenecks. A lot of people choose C++ because it's a mixed-level language: you can have direct pointer manipulation on the same line as heavily abstracted code using lambdas and combinators. This, incidentally, is one reason why the academically-minded among us dislike C++: it doesn't know what its niche is and wanders around all over the place throwing in everything that looks good but doesn't really work together. The "correct" way (from my perspective) to handle this sort of differing level of abstraction is to alternate hard and soft layers: write the "engine" and speed bottleneck code in C (which is all low-level), and write AI and game logic in Python or Lua or another scripting language of your choice. This keeps things "clean" (and probably improves overall performance by keeping the high-level constructs out of the C code). Every game that has a scripting engine is at least capable of being designed this way. Which ones actually do it depends on the developers. 3) AAA game development is heavily top-down. Coders do what they're told with the tools they're told to use and that is that. If management think there's a benefit in "compatibility" with old code, then that has to be taken into account, and so on. Even if every programmer in the shop thinks that C++ is the wrong tool for the job, they may not have the power to do anything about it. Games also have different priorities from most other programs: performance is more important than the program actually performing correctly, because a bug in a game isn't going to crash an aircraft or lose millions from an accounts department. This means that the great speed of the end result program is more important to developers than the fact that it's also almost certainly full of bugs, bugs that would have been caught by a stricter (but less performant) language. 4) For the reasons outlined in #3, game development is not exactly considered the pinnacle of greatness in the computing industry; with a few exceptions like Carmack the Living God, large games companies are where mediocre coders go to get burned out by management and replaced within three years. The chances are that many AAA companies don't actually have enough people who even know what e.g. functional programming is, to consider using anything other than the lowest common denominator languages. The fact that C++ doesn't enforce any particular coding style is at least pragmatic when your team doesn't know, or care, that coding styles exist. Anyway, there are always other options: http://www.bytonic.de/html/benchmarks.html That game was originally written in C, and became faster after a suitably well-written port to Java! Last edited 2011 |
| ||
| I appreciate many comments, actually I have always to learn something, but the important thing is to learn what it really is. Well, at this point that you Yasha think http://www.ogre3d.org/tikiwiki/PyOgre At this point try to balance the objectives however, according to the reading of this post, I can say that c + + is for those who attend a school of engineering, and to me this would be somewhat a waste of time when I need is some way to accelerate productivity. And now I'm giving a view of Irrlicht. Last edited 2011 |
| ||
| PyOgre is probably a really good choice. Python is a very easy language to learn. Well spotted! |
| ||
| Wow, thanks for that, Yasha. That was a real eye-opener. I reckon I'll pick up C when I have the time to spare on it; even if I don't start using it in games any time soon, I'll certainly have plenty of applications for it in some of my data-shoving ideas. Here's a total noob question for you, completely out of curiousity: does C work cross-platform? At any rate, this explained many things, especially point #3; I'd been wondering for some time now why on Earth it seemed like the bigger and more expensive the game, the more bug-riddled it became, despite the seemingly high standards of the distribution portal. It also explains why many smaller-scale indie games seem to be far better programmed, tighter with less bugs and so on. |
| ||
| does C work cross-platform? ...yes. There is a C compiler for pretty much every hardware and OS combination known to humankind. However, what you need to remember is that C is an unusually minimalist language. The standard defines very, very little outside of the language constructs themselves; pretty much the only things it defines where platform is even an issue are memory allocation and I/O. This means that for the language itself to be cross-platform is frankly no big deal. When people wax on about cross-platform in the context of BlitzMax, they're mainly praising the fact that the graphics libraries and so on all work identically across Win/Lin/Mac. C, as a systems-programming language, doesn't have graphics libraries as part of the package. Obviously third-party ones exist, e.g. SDL. ...so while C is cross-platform, C code may not be. There are also a few other "gotchas", e.g. the standard size of "int" is actually the size of "void *" for the target platform, not (as many assume) four bytes (as of C99 the "expected" sizes - 16, 32, 64 - are also made available as distinct types though, so that you won't run into problems on 64-bit); similarly a "char" is defined as a platform-byte, not eight bits (70s computers had many different byte sizes, some still do)... etc. It's a lower-level language than a lot of people think! But yeah for the purposes of using it with games across Windows and Linux, it's as cross-platform as anything else. Last edited 2011 |
| ||
| I see... So if I'm thinking straight here, basically - since any and all languages are to be compiled into machine code - the only thing that stops all languages being cross-platform is the nature of whatever libraries may be included. No libraries, no limits, but also no functionality outside of RAM-and-CPU data pushing, right? Last edited 2011 |
| ||
| Well, let's start with PyOgre!! =D. |
| ||
| No libraries, no limits, but also no functionality outside of RAM-and-CPU data pushing, right? Arguably. It does depend though on what you consider "language" and what you consider "library". Some examples: -- Blitz3D: only available as a large package with 3D engine. The 3D engine is completely inextricable from the rest of the compiler, so you could make a good case either way (the counter-argument is that the 3D and 2D engines use a completely different typing discipline from the user-defined code). -- BlitzMax: the compiler is much more barebones and doesn't include any graphics stuff, but does have a built-in managed memory object system capable of runtime reflection. -- C: No object system, but all the components are there to build one (every Objective-C construct - not so much C++ - has a 1:1 equivalent in C code). Memory allocation is defined in the language standard, but at the same time you have to explicitly import the stdlib module in order to actually allocate block memory (so kinda the reverse of Blitz3D). -- Common Lisp: defines not only a comprehensive object system, but all manner of input/output, complex data types, condition systems, etc. etc. as explicitly being a part of the language required for ANSI conformance, not as optional libraries. The Common Lisp language spec is over a thousand pages long as a result! -- Scheme: In contrast, Scheme (the other main Lisp) can be implemented on top of only seven primitive operators because it doesn't even define how numbers should work under the hood. 50-page spec as a result. ... and so on. It's a matter of preference really... not important unless you're the sort of person who cares about ISO conformance and all that. |
| ||
| Hello, please help me with this: http://wiki.python-ogre.org/index.php/Binary_Releases I have no idea what to do, the Google translator translate not quite understand the thing. I can not install pyogre. Last edited 2011 |
| ||
| You might be having problems with getting the right versions? That tutorial references at least three different versions of Python, which is a bit weird. Basically it just wants you to make sure you have the right DirectX, clear your PC of any existing Ogre stuff, install Python, then install PyOgre. And the PyOgre downloads are in 7-Zip archive format. I don't know much about Python myself, but I do know that versions 2.X and 3+ are not compatible, because the change to 3.0 made core changes to the language. That's why 2.7 is still available alongside 3.2 from the Python website. If you look at the Python-Ogre "Files" page ( http://sourceforge.net/projects/python-ogre/files/Latest/1.7.2/ ), it has different downloads for use with Python 2.7 and Python 3.2. So you should make sure to match your Python and PyOgre versions correctly. Last edited 2011 |
| ||
| Hello, I downloaded the following versions 1.7.2 and Python 27. The problem I have is to install the SDK but the demos do not run. = ( |
| ||
 |
| ||
| Ogre is really good, the biggest drawback to starting is the crappy demo framework which is over coded and too complex making ogre seem much harder than it needs to be. |
| ||
| I would reccommend anyone learning C/C++ because it is more "middle level" programming. After that everything else like Java, C#, BlitzMax etc seems so much more logical and friendly. (and much more intuitive to get into as well) |
| ||
| After that everything else like Java, C#, BlitzMax etc seems so much more logical and friendly. I'd have to question this. Java and BlitzMax have straightforward, simple object systems. In every way that C++ is different, it's also more complicated/just plain weird (e.g. having to explicitly declare virtual methods... makes no sense. Ridiculously broken implementation of multiple inheritance. Complicated and yet pathetically weak type system. Templates. No GC!). Sure they will seem "more" logical, but why teach yourself bad habits just to unlearn them later? (And it's only "middle level" by virtue of averaging; really it's just inconsistent. What kind of twisted logic leads to a language with both namespaces and header files?) Last edited 2011 |
| ||
| PureBasic uses the ORGE engine. That could be an option. |
| ||
| @yasha, I will agree and disagree. GC is a good thing, but not always. There are times when GC can actually chew you up. Besides it is good -learning- practice to clean up after yourself. And templates can be useful if used properly. Put it this way.. B+ and B3D have no garbage collection and we all regard them as easy to use. So the fact that C and C++ have no GC is not really the end of the world. As for multiple inheritance i agree... but at least it can do it (although i never implement this, i prefer the single inheritance abstract/interface approach) At the end of the day, I guess it depends on what you use C++ with as to how horrible it is. Use it with different libraries and it can be like using different languages. Of course C++ is an easy language to use badly, but that is the nature of the beast, the more untamed and low level a language is the more easy it is to screw up and put together a load of crap. Basically i see it like this. If you had to build a house: -Assembly would be clay, oil, iron, and sand etc... -C would be bricks, steel pieces and mortar. -C++ -is- C, except it has a few bundled odd prefab pieces with few rules on how you glue them together. -C#/Java would be detailed prefab pieces with tight rules and regulations on how it goes together (with a guy named Garry Clop to clean up your mess) The more "constructed" your building materials the less likely you are to use them badly, so that goes without saying. However the less bult something is the more flexible your options become. (but slower your development time) Last edited 2011 |
   |