Promit

Also consider an accountant. The costs start adding up, I know, but that's the life of business.

Is...is this really something you want to ask a forum about instead of a licensed lawyer in your legal distict/county/state/country?

I've taken an increasingly dim view of exceptions and pure RAII approaches in games, particularly given the headaches that C++ introduces as far as exception handling. Even with "flawless" platform level support for exception handling, I don't feel that constructors with exceptions are the way to go.

The existence of exceptions at all demands a sane exception handling strategy AND exception safe code. Exceptions are supposed to represent "exceptional" conditions and it turns out that in games, most of those conditions are common in day-to-day development. Since you're not going to crash the game just because an artist mis-named a file, the handling code typically degrades the exception to a return code anyway, swallowing it internally and taking some action like injecting a placeholder. Stack unwind isn't useful here either, since it's invariably caught by the immediate parent. All you've done at this point is blow a bunch of cycles on an internal error condition.

Then there's the practical problems with exceptions in C++ in particular, and the very fact that the term "exception-safe code" exists should be a giant red flag. There are code size consequences to enabling exceptions, and the way the standard or boost libraries reacts to the setting can mess with things too. There's also the question of whether it will interact cleanly with threads. (Checked iterators are globally re-entrant incompatible, for example. Think about that for a bit.) Let's not forget the problems with C++ constructors being shitty, either. Virtual dispatch won't work, chaining won't work, etc.

Last, it's helpful to be able to re-initialize objects and although you can do it with the explicit destructor call plus placement new, doing that just feels weird. Combined with the fact that other languages like C# won't support in-place reinitialization anyway, and explicit init and teardown functions just look that much more appealing.

I just like two-step better.

You may have misunderstood the WinPhone announcement. Basically, C++ is a viable language for WinPhone 8, whereas games/graphics were required to use XNA in WinPhone 7(.5).

Typically the easiest (but not best) way to handle this is to compute the interval between frames and assign all your values in a fixed time unit (seconds or milliseconds usually). This requires getting an accurate system timer (QueryPerformanceCounter on Windows), storing the time between frames, and multiplying all your values by the elapsed time in order to get the correct numbers.

Hmm. This is not something I've thought through clearly, but what if you scale the particles by their distance from the focal plane, and also bias the mip sample based on the distance? I'm thinking that if you deliberately sample a mipmap that is too small onto an expanded particle, you can create stretching that might make a reasonable fill-in for a blur.

Let's please not do the C references/pointers thing. This is a thread about numerical integration and I'll delete any further posts outside that.

So, for semi-implicit Euler update velocity first, and then use that to update position?

inline void proceed_SemiImplicit_Euler(body &b, const double &dt)
{
		b.velocity += acceleration(b.position, b.velocity)*dt;
		b.position += b.velocity*dt;
}

Yeah, that should be right.

For the tennis, it looks like semi-implicit Euler handles things almost as well as RK4 (and obviously much faster), and a bit better than Euler. The differences are small to begin with.

The key is that semi-implicit Euler sacrifices some accuracy for dramatically improved stability and better energy conservation (well, bounded energy fluctuation actually). RK4 systems will tend to explode or slow down very easily because of the energy instability. This isn't noticeable for simple motions, but becomes very evident in springs for example.

This is also called sympletectic Euler at times, and there are many other classes of symplectic integrators as h4tt3n pointed out. All of them are much preferable to the Verlet or Runge-Kutta type approaches. But the semi-implicit Euler is dead simple and very good for how easy and cheap it is.

Personally, I disagree with Gaffer -- Runge-Kutta is a terrible way to do integration for game simulation. Semi-implicit euler is a far better system for most games.

Actually I would suggest writing your logger in C. It's the craziest thing -- for example, you can write to stdout using printf or fprintf or fputs from anywhere in your code, at all! And they didn't use any singletons at all either. Who knows how they managed to pull off that wild trick? Oh right, it's because we had the ability to access global values safely before the GoF book burst in like Seinfeld's Kramer looking bewildered at its own discoveries.

The biggest rule of thumb is this: If you have to ask, you should use STL. There are many legitimate reasons to avoid using the standard libraries, but it is almost guaranteed that if you are encountering those reasons, you already understand why and what the correct solution is. Instead, spend your time on understanding how the STL works and why it works the way it does.

One caveat that I do feel is worth mentioning: STL containers like std::vector are extremely efficient in optimized builds. The design of these classes relies heavily on several categories of C++ optimizations. There are good reasons for this, but at the end of the day it means that heavy container usage will show an unexpectedly high impact in "debug" builds. What's more, mixing debug and release compilations (selective optimization) of these containers can be extremely dangerous. So a lot of the home-rolled crowd like the fact that the jump in performance from debug to release is not so extreme.

That said, all halfway decent games become unplayable in debug mode about halfway through development anyway

My current working theory has survived for several years now. The theory is:
There exists no legitimate use for the singleton pattern, anywhere.
If you want to use a global, fine, but don't use a singleton for it. All you're doing in that case is taking a global and slathering it in stupidity.

IF used correctly, std::vector should show equivalent performance to raw arrays IF optimizations are enabled and IF you have a sane implementation. There are caveats here to be wary of, especially if you're cross platform. But knocking std::vector out of your code is not an optimization strategy.

By comparison, I see people on these forums throwing together prototypes on a matter of days (I don't even understand how you can prototype a game, with all of the underlying framework that is required). People participate in the Ludum Dare competition, creating full games in under 48 hours. And full released games on Steam, like Terraria, which were developed in only 6 months.

There's your mistake. No framework is required. Some developers use existing frameworks (Unity, Allegro, whatever) and some just plain freeform it. The key to coding fast is to throw architecture to the winds. This is a healthy skill to have, though whether you should make a habit of of it is another matter entirely.

Rapid prototyping is a valuable way to build out the basics of a game, make sure it's worth building at all, and catch early design mistakes. I would suggest that it's vastly more useful than the idiotic design documents everyone thinks they need. Sit down and write a full, playable game in a week. It will force you to think very hard about what is actually machinery for the game, and what is your own toying around with code. Eventually you'll learn to do this in a way that doesn't defy expansion into well engineered code later.

I forgot to mention, also, that both APIs are essentially a minor part of your code these days. Once you've got the concepts down, it's more just a question of wiring up the API to do things the way you need. It seems like a really big deal as a beginner to be coding all this D3D or OGL stuff, but I can honestly say it's probably the most boring part of my graphics coding work. The API is just a machine I have to configure so that my CPU code and my GPU code talk to each other properly.