Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!

Eric Lengyel

Member Since 25 Nov 2003
Offline Last Active Yesterday, 09:31 PM

Posts I've Made

In Topic: How can sample rate be 44000Hz?

12 January 2015 - 04:19 AM

Of course, you guys mean 22.05 kHz, not 22.5 kHz.

In Topic: Starting my own game engine - please don't laugh.

17 December 2014 - 12:53 AM

I've been developing a game engine for most of my professional career, so I can tell you about my experiences. First, let me mention that my book Mathematics for 3D Game Programming & Computer Graphics has a lot of useful engine development information in it. Don't let the first few chapters put you off. They are pretty dry and purely mathematical, but after that, the book gets into a lot of stuff that's specifically needed to make a decent game engine, like visibility determination, collision detection, basic physics, shading, curves, and fluid/cloth simulation. There is also the Game Engine Gems series, but they are collections of shorter chapters that discuss intermediate to advanced techniques. These books would probably be interesting after you've got an engine up and running and you're looking for some cool effect to implement, but there are a few chapters are would be generally useful to anyone (like a chapter in GEG2 about bit hacks for games).


Satharis made a couple comments above that I wholeheartedly agree with. Developing a game engine does take a long time, especially by yourself. I have been working on the C4 Engine for over 15 years now (although not continuously for the first five years), and there is still a lot of new stuff that can be added. It's important to start small and work your way up. Don't lose touch with reality and think that you're going to build a complete engine of high quality in a few months time, or even a few years. Choose very specific features to work on and implement them one at a time as best you can. After finishing some components of your engine, you should find yourself looking back and thinking to yourself that you now know a much better way of implementing the same thing. This ought to happen a lot in the first several years, and it's part of the learning process. Iteration is key to really discovering better ways of developing software and becoming a good engineer. Don't be afraid to completely throw away some system you spent a lot of time working on and start over. If you're not under any kind of time pressure, it will be worth it in the long run.


Way back in early 1999, the C4 Engine could barely render a handful of primitive geometry types (plane, cylinder, sphere, etc.), some particle systems, and some basic shading effects. After many years of hard work and meticulous refinement, it can do all of this today. It has been very rewarding, but also very difficult at times.


Btw, if you're going to write some kind of import component, I recommend using the Open Game Engine Exchange format (OpenGEX). The OBJ format doesn't support enough features (not even close), and FBX will have you tearing your hair out. OpenGEX supports Maya, and there's a free C++ import template that you can start with when building your own importer.

In Topic: Casting Pointer to Derived Type

13 November 2014 - 01:21 AM

SmkViper, I agree with most of your post, but I'd like to point out that exceptions do not actually have a zero run-time cost like compiler vendors would like you to believe. In my tests, it has about a 1% performance impact to simply enable EH and RTTI in the compiler without a single usage in the code (no try, catch, throw, typeof, or dynamic_cast anywhere). This is very small, yes, but it's measurable, and I would not argue against someone claiming that it's worth it to get the extra functionality of EH if that's what somebody really wanted. The overhead comes from the fact that a larger amount of code and data is generated by the compiler, and this has an affect on cache usage while the program is executing. Fragments of code that used to be side by side in the same cache line are now separated by a little extra code that the compiler inserted to handle an exception being thrown. And the zero overhead claim only applies to throw statements. Once you start sprinkling throw...catch blocks in the code, it does have a nonzero cost in terms of actual instructions executed, including new branches that wouldn't exist otherwise.


But as you discussed, the real downside to enabling EH is the fact that the programmers have to worry about what will happen for every function they call if an exception is thrown inside that function, and they have to jump through extra hoops to make sure everything is cleaned up properly in the case that the called function doesn't return and the remaining code in the calling function doesn't get executed. I'm normally a big proponent of writing clean, bulletproof code, but the burden of wrapping up all your pointers and implementing strong RAII for absolutely everything goes a little too far for me. There most definitely is the matter of programmer productivity to consider here, and it is more expensive in terms of time and money to write exception-safe code.


BitMaster, the more I think about it, the more I'm OK with using something like polymorphic_downcast with RTTI enabled in debug mode, so I think I may have overreacted to it. It's just that using RTTI or Boost are both things that would make virtually all of my peers give me a dirty look, and seeing them suggested together at once made me go all hulk-smash. Sorry if I came across as abrasive, but nothing I said justifies you resorting to name calling and derision of my qualifications. (And if you're going to do more, please grow a pair and use your real name.)

In Topic: Casting Pointer to Derived Type

11 November 2014 - 04:05 PM

Then why did you feel the need to downvote me? The huge advantage of boost::polymorphic_downcast is that it verifies the type in debug builds (always a good idea to assert things which should be true there) and is a static_cast in non-debug builds.


Again, the pros do not use RTTI and exception handling, even if it's only in debug builds. If you want to ignore the collective wisdom of all the top developers in the industry, you do so at your own peril.

In Topic: Casting Pointer to Derived Type

11 November 2014 - 03:59 PM

I don't think that anyone is arguing that a design that requires casting is always "wrong".


Maybe not here, but there are definitely people who think that way. In the OP's case, there's nothing to indicate either way whether a tilePlayer is a tile or has a tile, so you have no basis for which you can say my example is very different. You're assuming that a tilePlayer represents the player himself when it could just include some extra rendering data for tiles that show player locations. Maybe a player object somewhere else has a reference to a tilePlayer, which is a special type of tile, and all tiles are stored in some list of pointers to the tile base class. We don't know.