Show HN: 3D Game Programming using bitblting in Windows

        [TestMethod]
        public void NextPowerOfTwo()
        {
            const int bitPowers = 32;
            const int StartValue = 2;
            const int PowerOf = 2;
            UInt32[] powers = new UInt32[bitPowers - 1];
            UInt32 value = StartValue;
            int i = 0;
            powers[i++] = value;
            for(; i < powers.Length; i++)
            {
                value *= PowerOf;
                powers[i] = value;
            }
            int[] valuesToTest = new int[] { 126, 128, 130 };
            int power;
            foreach(int valueToTest in valuesToTest)
            {
                power = 0;
                value = powers[power];
                while(valueToTest > value)
                {
                    power++;
                    value = powers[power];
                }
                System.Diagnostics.Debug.WriteLine($"{valueToTest} -> {value}");
            }
        }

        Test Name:	NextPowerOfTwo
        Test Outcome:	Passed
        Result StandardOutput:	
        Debug Trace:
        126 -> 128
        128 -> 128
        130 -> 256

edit: just to add, I think "width = sqrt(filesize/3)" would be a better version for newbies. Even better would be to replace the code altogether.

Windows: 98.04% OSX: 1.56% Linux: 0.32%

That's not a significant number in the least. Now the numbers may be skewed by developers vs players, mobile vs desktop etc, and yet even then it's still not worthwhile in general.

As to the 2nd part, I far more agree with that. There's no reason not to use SDL. But by that metric you should be using Unity/Unreal etc. anyway, unless if your focus is really on becoming an engine programmer.

Not necessarily. Casey discusses this issue well into his series, but it would be twenty or thirty hours in.

There are two general approaches to multiplatform.

Approach 1: the SDL way. Have an abstract system that represents a generic desktop environment (e.g. QT suite). Build your apps into that. The upside of this is that you can build once, run everywhere. Some downsides are that it will not necessarily feel like it fit into the ecosystem, and you need to learn an abstract platform. That platform may have license overhead. When they do version upgrades, you might not like what they do, but you are stuck with them.

Approach 2: native wrappers. Build your codebase in generic C/C++. Then write endpoints interface wrappers for each platform you deliver to. In this case, you could create a Windows codebase that #includes your game code, and calls into it from WinAPI. For linux, you can create a ncurses or GTK frontend, and then #include into the samre game codebase. Your product will feel like it was built for your target platform. Yes, you need to learn platform-specific ways of doing things. But once you have, your end-users get native feel. If you want to call a Windows voice API for the Windows version of your product, you can do it without depending on a vendor.

If you were building a forms application, Approach 2 would be painful. But if you are building a game, Approach 2 is viable. You probably need a single-window wrapper. It would need to have a menu system, to be able to display an image, and to be able to consume keystrokes and mouse events. I don't have much audio experience, but the little experience I have is that the moment you want to do something remotely sophisticated with audio (e.g. creating a music sequencer) you want to be working against native APIs. I would rather build something from first principles on a robust system API than debug bizarre threading behaviour in the SDL mixer library.

You'll also find that people who work on high-performance games (i.e complex 3D) are pretty allergic to using existing libraries, and while it would make sense to use SDL in an example project like this, it's not unreasonable for someone to default to the "proper" way. Beyond things like the basic GL loader, linear algebra and font loading / text rendering libraries, anything that's available is almost guaranteed to be woefully insufficient, more effort than it's worth or loses you too much control. Not to mention you'll inevitably wind up with your own library that provides an equivalent of half the C++ std (even if most of it is implemented using the normal std), which often makes using anything that depends on the usual C++ std pretty painful.

For the above reasons, things like SDL or even libev/Boost.ASIO would only be considered suitable for toys. I can't say I'm too happy about having to re-implement things that have already been written a thousand times over already though.

Steam measures 98% Windows, 1.56% OSX.

To make it clear, the main platforms for more AAA-like titles are Windows/PC, PS4, XboxOne, and now the Switch. The main platforms on mobile are iOS and Android. Each of these requires an adaptation layer to be written because they are all different to each other, some more than others though.

So you can "lock" yourself into one of these platforms, "lock" yourself into using an engine or existing library which covers some subset of those platforms, or write your own adaptation layer and engine.

For learning and experimenting it's quite easy and convenient to focus on a particular platform, Windows/PC in this case is a good simple default since it's available and doesn't require NDAs, licensing, etc.