rei4 said:
@undefined Is there any other engine, like yours, that is capable of bypassing the constraints you mentioned? The ones inherent in Unity's “2d mode” while throwing all the 3D parameters every time you call a function?

I mean there is Rpg-Maker, which has some modern variants, but working with the Rpg-Maker XP was horrible, so I wouldn't recommend it. There is GameMaker, which I think is more specialized on 2d afaik. And Godot also has 2d support, but I don't know if they have the same issues like Unity or if it's more specialized.

rei4 said:
Do you just use directX 11 for the API? Any other dependencies?

Practically, I only use DX11 anymore, but I have an abstraction to support others - like an very old GL4 implementation, that I haven't touched in ages. Aside from that - almost no dependencies, especially in the graphics-deparment. The goal of this project, which initially used to be educational, was to not use more dependencies than necessary. I did end up using “DirectXTex” for texture-handling, to replace the D3DX-library, because all the specifics of texture can be pretty annoying to deal with.

rei4 said:
I understand that options are limited to those trying to use the now obsolete methodology for 2D games. But I am interested in the older hardware. Eventually I might try home brew on the Sega Genesis. For that you do need to be studying the ways of the 8/16 bit game hardware. Also, the XGS is about the only way I know of where you could learn about games for single board computers. I'm seriously considering simple enough SBCs to route my own PCB and stencil, paste, and bake in the components.

Oh, if you want to program for older hardware, that's all fine. There are still enough people interested in doing that, I see and read about games being made even with original cartridges here and there. I personally am glad to not have to work with all the constraints of the old hardware, personally. But to each their own 🙂

rei4 said:
But I am interested in the older hardware. Eventually I might try home brew on the Sega Genesis. For that you do need to be studying the ways of the 8/16 bit game hardware.

You must be aware of the relationship between the software and the hardware. The software does things they way they do because of the hardware. As new hardware came out developers shifted the way they programmed to take advantage of the new hardware. Then in turn, hardware makers talked with developers about the pain points and introduced new hardware. It's been a cycle where both of them drive each other, going on for more than 40 years.

You cannot work toward performance in one without also talking working toward performance of the other. The hardware and the software are tightly coupled.

Very often people who try to emulate doing things as they were done 10 years ago, 20 years ago, 30 years ago, they fail to take BOTH into account. When you try to copy what the software was doing with tile-based rendering, you're going to get into serious problems because the hardware no longer supports tile-based rendering. When you want software to emulate game consoles with a cartridge on chip, you need to remember that the ROM chip of the cartridge was literally part of the addressable memory space in ways that don't map to modern software. You could set a pointer to a grahpics system directly to a location in the ROM and everything was okay with that.

rei4 said:
Do you just use directX 11 for the API? Any other dependencies?

The directX version has been tied to the operating system version since 2007.

D3D 2.0 and 3.0 in 1996, D3D5 in 1997, those were independent releases. With Windows 98 and Windows 2000 they tried to tie them to the operating system, DX6 to Windows 98, Directx7 to Windows 2000, but it didn't stick. DX8 and DX9 were major shifts to hardware moving from fixed function to programmable shaders.

But starting with DX10 Microsoft clamped down on DirectX being tied to the OS.

DX10 = Vista.

DX11 = Windows 7

DX11.1 = Windows 8

DX11.2 = Windows 8.1

DX12 = Windows 10

DX12.1 = Windows 10 October 2018 update

DX12.2 = Windows 11.

There have been some relatively small exceptions where they've moved parts over those lines, but the teams have been working quite hard to keep and enforce those parallels. For 15 years it has been about the version of the OS you are on, despite what gamers think.

In general with Windows you target a minimum API version, and you get the entire Windows API for that version. That includes DirectX. You can certainly target old versions of the SDK, but they're depricated. You might be able to play an old game, even D3D6 or D3D5 games might work just like the old Windows 95 APIs can still work, but if they happen to be broken it isn't considered a bug.

frob said:

You must be aware of the relationship between the software and the hardware. The software does things they way they do because of the hardware. As new hardware came out developers shifted the way they programmed to take advantage of the new hardware. Then in turn, hardware makers talked with developers about the pain points and introduced new hardware. It's been a cycle where both of them drive each other, going on for more than 40 years.

Yes. I was surprised when I learned from you how wide sweeping the powers of the industry were in obsoleting bit block transfers as a rendering method.

I thought I might mention a video that shows how hardware centric game development on a Sega Genesis can be. It did not have hardware acceleration for rotation but it did for scrolling. The guy in the video looks like he has a copy of original Sega Genesis documentation, it almost looks like the photographs are stamped “confidential”. Anyway, imagine wanting to rotate like he does in his game but not knowing how? Because there is no hardware acceleration for rotation and using the CPU is too slow. Hardware can have a major impact on one's creativity.

rei4 said:
Do you just use directX 11 for the API? Any other dependencies?

The directX version has been tied to the operating system version since 2007.

DX11 = Windows 7

Yes I just don't fully understand what DX 11 actually does. Its a renderer. So if you had an engine that used DX 11 you might be able to break free of a locked perspective for use with emulating 2D scenes. I am still planning to use bit blitting and an engine designed for a 16 bit environment. For now that's Andre Lamothe's “ Tricks of the game programming gurus” 1994. It's an engine for MS-DOS. Later I plan to work with the X Game Station which uses an Atmel 8/16 bit ARM based SOC. It's going to be a while before I ever use modern methods of combining 2D and 3D rendering.

rei4 said:
Yes I just don't fully understand what DX 11 actually does.

DirectX11 just allows you to program the GPU to do stuff, to get to display your rendered image to the screen. It's just the modern way to do any type of graphics, with a dedicated GPU. That's probably the main difference in paradigm (as Frob already touched on):

On modern systems, CPU and GPU are two different sets of hardware, separated by a slow bus. On old hardware, you could write directly to the graphics-memory, because it was the same shared memory, same/similar processor, you get the idea. With the new system, you cannot do that. You still have to program what the game does on the CPU, but if you try to upload all the graphics-data each frame to the GPU, you'll run slow as hell. Instead, modern APIs like DirectX11 give you the tools to upload data ahead of time (for example, textures - no matter if for 3d or sprites), and each frame you just give the GPU a minimal set of commands to execute on that data. The actual main “processing” is done by shaders.

Don't really know how to put it into simpler terms. DirectX11 is just a layer to talk to the GPU, which (when talking about processing speed) is miles away from where your CPU works, and thus cannot be addressed to do pixel-manipulation directly, like you would expect with BitBlt.

Go back to the 8088, 8086, 80286, 80386, and the preferred method was the DMA transfer, which is a precursor of the BitBlt. The hardware had 4 channels to transfer from memory block to a different memory block without involving the CPU, but limited to a block of IIRC 64KB. The most similar modern hardware equivalent is uploading a texture. The CPU is not involved at all for moving potentially gigabytes at a time to GPU memory without involving the CPU or the far side of the data bus.

BitBlt was the most efficient way to get the block to the screen in that one particular era of hardware in the mid to late 1990s. The function name stuck around in the Windows SDK and a few others, but that specific method has been surpassed for about 25 years now.

Also as mentioned, console cartridges didn't even need that. The rom space was directly addressable memory space. A pointer saying “this is the buffer” requires no copy. No CPU involvement and no resources used.

And in the latest version, dx12.1 now has an interface for new hardware for additional resource binding for asynchronous simultaneous graphics and compute. That is even more along the 45 year long cycles of each pushing the other. They take the CPU and the data bus out of the way, allowing the GPU processor to consume and to manipulate memory without CPU involvement. Issue the hardware commands and the work is done efficiently, externally.

rei4 said:
I am still planning to use bit blitting and an engine designed for a 16 bit environment. For now that's Andre Lamothe's “ Tricks of the game programming gurus” 1994. It's an engine for MS-DOS. Later I plan to work with the X Game Station which uses an Atmel 8/16 bit ARM based SOC. It's going to be a while before I ever use modern methods of combining 2D and 3D rendering.

This means a lot of restrictions and obstacles, requiring detailed knowledge about the HW and how to use it, and eventually the need to program in assembly instead a high level language like C.

So why do you want to do this? If you do a 2D game for modern HW instead, it's easier and more flexible, more people can play it, and most importantly: You learn more about game development in much less time.

Noticing some trend of more and more people being interested in old HW, i'm actually interested in your motivation.

rei4 said:
Yes I just don't fully understand what DX 11 actually does.

It's easier if we look at it in historical order.

The first 3D API i have used was 3Dfx Glide. It could draw texture mapped triangles, not more. It was pretty simple, and this functionality is enough to implement tilemaps and sprites. Rotation is possible, perspective projection like in Mario Kart also is possible. So it could do anything a Super Nintendo could do, including it's extra 3D chips which were built into some cartridges. (This means you don't have to learn much if such functionality is all you need.)

The next improvement was transforming vertices and applying basic lighting on the GPU. Not really a big change for the programmer, and still pretty simple and easy.

After that it became complex with pixel and vertex shaders, making geometry deformation and per pixel lighting possible, by writing small programs for processing vertices and pixels.

Later this was generalized with Compute Shaders, CUDA, OpenCL etc. We can now write general purpose parallel programs for GPU, making it really flexible. We can do fluid simulations up to ChatGPT, and we're no longer restricted to just graphics applications.
This also enables us to do graphics in different ways, like back then with software rendering. Examples would be the PS4 Dreams game, splatting points instead rasterizing triangles, or UE5 Nanite which implements a software rasterizer in compute to overcome the HW inefficiency for small triangles.

So the HW became much more flexible with time, and the complexity of APIs has grown as well. If we want to use all of this and maximize efficiency, we need to know again a lot details about HW and API specifications. It's even harder now than back then when dealing with dedicated 2D gfx chips. Ofc. we can outsource this complexity by using game engines which care about those low level details for us. But then we move away from being ‘game developers’ to just ‘content creators’ a bit, so not all of us should go that easy route. Otherwise, after some time, nobody knows anymore how to do it.

However, personally i see no reason to work on outdated HW which no longer exists, and neither for retro consoles which may be forgotten within few years without preserving its games. To make a 2D game now, i would rather propose a cross platfrom target, to reach as many devices as possible, including low power mobiles. That's possible using C/C++ and OpenGL for example, which runs on Windows, Linux, Android and iOS (not sure if iOS still supports OpenGL, though.)

There are also Fantasy consoles, e.g. Pico-8, which i would recommend to beginners over using Unity. But maybe i'm a bit nostalgic here myself.

Using modern HW also allows to make games simply better.
Even if we use low res pixel art, we can now render sprites at any position, overcoming the limit of the low art resolution. As a result, motion looks smoother and is better predictable.
We also benefit from the higher precision of floating point numbers. A game like Angry Birds would hardly be possible on a 8 or 16 bit CPU. Even using fixed point math, the quantization would be too high to get such realistic physics.

That's really big arguments to avoid older architectures. It was nice, but it's over for the better. : )

Just saying ofc. It's cool to see there are still new games for the C64 for example.
But i follow this only on YouTube. I do not actually play them.

Thanks. I read through the details you mentioned in your post. It was nice to know that glide was just a textured triangle api. Of course there were many other points made. I hear such replies about anything that I do that is not the same kind of practical one has on hand in the now. For me I always wanted to know how the hardware and games from my childhood worked. There is only one road that would lead to that understanding and it is through history and the people like me that want to relive it.

At one point I wanted to make a vacuum tube computer on a scale like Univac I. But realizing that goal in my lifetime is made difficult mostly by fact that these machines made simple punch card programs in fortran for finance or pneumatic controls incredibly difficult. This is really the worst part. The other part is getting vacuum tubes designed and manufactured. Just doing that as a small binary computer with a punch card reader is hard namely because of what I said above already about programming. The way you code in fortran and the way your cards get processed are more complex than if you coded in fortran with a compiler - these show up later in the 60s around the time transistors were being replaced with integrated circuits.

rei4 said:
It maybe better for budding developers today than it was back then but if you don't want to be a modern developer why study modern techniques?

It depends on what you want to achieve. If you want to make oldschool-style games in a timely manner, then learning modern ways will save you a lot of effort. Don't forgot your time here on earth is limited. Is the actual process of doing it like back in the day really intrinsically important to you? Then sure, do it. But otherwise, think about how many more games, or better games, you could do if you didn't waste your time with antiquated development practices and restrictions.

You can still learn a lot of the basics, even if you go the modern route. I'm writing my own assembler/compiler for a while, and that requires pretty much the same level of understanding of ASM that you'd need for an oldschoold game. Doesn't mean that I have to code everything in that language, which you'd pretty much have to do if you were to code games like back then.

Please don't take this as me pushing you into a direction. You asked, and I answered. I also kind of wasted my time with developing my own engine, but I did enjoy it so it was worth it. Just carefully consider what your goal is, otherwise you can be lost in the process.

I have going for me an XGS game console development kit. It uses an AVR 8 bit CPU which is modern and well supported. Also PIC 16 bit CPU. The sprites are rendered with bit blitting from a C library.

Not using XGS right now but will eventually.

I'm currently using a 486DX-60 MHz and Windows 3.11. Andre Lamothe and Michael Abrash were the go to for making games. But the whole books out on organization and programming of PCs back then was astounding. Programming was mostly 16-bit, even if you had an early Pentium. The MCGA graphics mode was well known.

Not a bad deal. Had to really plan this out. But the plan includes fact that once you've tried Lamothe's old engines and other matters relating to the “astounding” number of books it does get to a point where learning to use Monogame would be far better.

The worst thing about the old games is the graphics modes are no longer supported. They died in the 2000s and were supplanted with modes starting at 480p also called HD. They were doing away with those old modes.

This means seeing painted graphics from a 90s game on a new screen is not like it was then. The way to see the painted graphics the right way means using modern techniques and video modes. Try seeing Streets of Rage 4. Painted characters and scenes using Monogame for the development.

rei4 said:
For me I always wanted to know how the hardware and games from my childhood worked. There is only one road that would lead to that understanding and it is through history and the people like me that want to relive it. At one point I wanted to make a vacuum tube computer on a scale like Univac

Hehe : ) seems like a new trend. The love for retro hardware.

Well, i'm confused. Like some years ago, when i've realized people still like pixel art. And that's not some temporary nostalgia for a certain generation, but rather seems here to stay.

I would be surprised, but maybe the same applies to retro HW as well? Really interesting.

Now i wonder how old you are, and what's your childhood HW is.
To me it's Atari 2600 and then C64. Both still see actual development and related online resources, tools and emulators.

rei4 said:
The worst thing about the old games is the graphics modes are no longer supported.

DosBox?