Well, one BIG question I need to ask is if you prefer the easy route, or the purist route.

The easy route is to use the most developed DOS programming tools and libraries which do all the hard work for you. These include game programming libraries such as Allegro 4 and IDEs such as DJGPP. You also need to grab CWSDPMI to act as a free DOS extender.

The purist route is to just follow along with the old books from the 90s, writing your own graphics handlers, I/O, sound support... This is a LOT harder, takes a lot more time, and quite frankly, unless you're making something extremely intricate, isn't going to work much better, so the only real reason to go this route is for the fun and challenge of it. DJGPP should still act fine as your dev environment, or you can seek out a copy of Open Watcom C/C++ which would allow you to write code the same way they did in the 90s and compile for the DOS4GW extender. Even though Open Watcom C/C++ doesn't have the exact same features as its commercial predecessor, I'm told the features it does have now exceeds what the original could do.

Lastly, if the end goal is to just make games, you really are better off coding for modern operating systems so you can add things like proper gamepad support, internet support, support for wide-screen resolutions, hardware accelerated graphics handling... It would be faster and easier and there's a lot more active communities online to help you through it.

Gemini000 wrote:

Well, one BIG question I need to ask is if you prefer the easy route, or the purist route. […]
Show full quote

Well, one BIG question I need to ask is if you prefer the easy route, or the purist route.

The easy route is to use the most developed DOS programming tools and libraries which do all the hard work for you. These include game programming libraries such as Allegro 4 and IDEs such as DJGPP. You also need to grab CWSDPMI to act as a free DOS extender.

The purist route is to just follow along with the old books from the 90s, writing your own graphics handlers, I/O, sound support... This is a LOT harder, takes a lot more time, and quite frankly, unless you're making something extremely intricate, isn't going to work much better, so the only real reason to go this route is for the fun and challenge of it. DJGPP should still act fine as your dev environment, or you can seek out a copy of Open Watcom C/C++ which would allow you to write code the same way they did in the 90s and compile for the DOS4GW extender. Even though Open Watcom C/C++ doesn't have the exact same features as its commercial predecessor, I'm told the features it does have now exceeds what the original could do.

Lastly, if the end goal is to just make games, you really are better off coding for modern operating systems so you can add things like proper gamepad support, internet support, support for wide-screen resolutions, hardware accelerated graphics handling... It would be faster and easier and there's a lot more active communities online to help you through it.

I think that I would honestly rather take the purist route. I have ordered the one book, along with an old book about C programming and a MS-DOS programming reference manual which should come in handy. I am currently downloading Open-watcom. What else will I need?

You will get a lot further with using C compared to Qbasic. Either use Open Watcom which is free or Turbo C++ which is old and err... available.
I know Turbo C has a graphics library available (BGI). It's not the fastest but it's pretty easy to work with. Watcom might have a graphics library too -- I am not sure.

I'm not sure what sort of web sites are still up nowadays, but you should study up on how to program VGA graphics directly. MSDOS game programming books of the 90s would also certainly cover this.
"Mode 13h" is a good search term, that being in reference to the extremely popular 320x200x256 color VGA mode. There used to be many web sites all about MSDOS game programming in mode 13h. It's a very straightforward mode - 1 byte per pixel, arranged in memory in the order you'd expect.
Moving beyond that would be "Mode-X" and VESA, but start with 13h.
I don't know what kind of graphical APIs for DOS are provided in other compilers, but under Borland, their API seemed pretty silly and was useless for anything where you cared about performance. I just got annoyed trying to do anything with it and was relieved when I found out how to code the hardware directly, which cut out all the nonsense and was actually simpler.

Creative Labs used to publish programming information for their traditional ISA sound cards. Hopefully there's still web sites about that subject, I remember finding bunches of them in the late 90s. I never got into the OPL side of things, but did spend some time learning to do PCM. The simplest method is to write data directly as it's being played, but that's nasty. Then you move on to the better methods involving DMA and double buffered DMA (oldest model cards don't support double buffering). This crosses into learning to program interrupts.

At some point you might be interested to learn assembly language. That yields the most efficient code but perhaps more importantly, it gives you the experience of directly controlling exactly what the CPU is doing. It's a difficult grind, but it's cool IMO and it's a real rush when you make a handcrafted assembly routine that works. Many people seem to hate it though.
You don't have to use assembly - today it's not difficult to throw more hardware at it and make it run faster, but at the time, assembly would have been used for critical portions of code.
The C compiler will let you code assembly inline, which is convenient. This also lets you reference memory locations by their C variable name. As long as the compiler supports 32-bit, then it should let you use 32-bit assembly instructions. Depending on it's age, it might not recognize later instructions like SIMD stuff though.

I used to use Borland Turbo C++ 3.0, but I'm sure that's not the best choice nowadays. Most importantly it does not compile 32-bit code. The only 32-bit code I got running in DOS was with some graphics routines I had written in MASM, which then had to be linked with the C output. That was tricky and I don't remember how it was done anymore.

ahendricks18 wrote:

I think that I would honestly rather take the purist route.

Considering you don't already know C, I'm afraid the odds are overwhelmingly against you.

I hope you at least have some idea of what sort of game you want to make.

I want to make a RPG game, maybe in the era of ancient rome. I always thought ancient rome was cool and wondered why most of the games revolving around Ancient rome were RTS or managerial. I am somewhat inspired by daggerfall. A first person view would be nice, but I am ok with isometric. I think I will follow the books that I bought (they should arrive soon here) and report back here. Thanks

First you need to learn basic programming. You have a long way to go.

ahendricks18 wrote:

A first person view would be nice, but I am ok with isometric.

Good $deity. Do you honestly believe that with no programming skill you could, on your own, be able to construct a first-person 3D engine from scratch?

I've hacked in indexed high color colored lighting into Quake's software rendering mode. I still don't know assembly and I wouldn't know where to begin to build a DOS RPG game from scratch.

My best advice at this point is learn how to design in something far simpler in a more modern environment, like say Gamemaker, Clickteam Fusion or Construct or whatever that touts ease first design. Developing a DOS game without experience in 2015 is going to be severe mental torture than a challenge.

Jorpho wrote:

Good $deity. Do you honestly believe that with no programming skill you could, on your own, be able to construct a first-person 3D engine from scratch?

https://www.youtube.com/watch?v=HQYsFshbkYw

Bisqwit sure makes it look easy.

Start by trying to clone something simple - like frogger - and you'll quickly realise that it isn't simple at all. Baby steps and practice are my suggestions.

ahendricks18 wrote:

I am not sure how programming old dos games really works, I am still a newb to it.

ahendricks18 wrote:

I think that I would honestly rather take the purist route.

ahendricks18 wrote:

I want to make a RPG game, maybe in the era of ancient rome. I always thought ancient rome was cool and wondered why most of the games revolving around Ancient rome were RTS or managerial. I am somewhat inspired by daggerfall. A first person view would be nice, but I am ok with isometric. I think I will follow the books that I bought (they should arrive soon here) and report back here.

You sir... are jumping in WAAAAAAAAAAAAAAAAAAAAAAAAAAAY over your head here. o_o;

OK, first of all, I do have to give you credit... if you said "MMORPG" instead of "RPG", I would've facepalmed, since MMOs are the hardest kinds of games to actually make.

However, with zero programming skill, you simply are not going to be making any kind of 3D game in the next few years, no matter how much effort you put into it. You could indeed learn how and could indeed pull it off, but it doesn't happen overnight. You'd be looking at MANY years of effort without other people working on the project with you, even longer due to your lack of experience.

As others have pointed out, you need to start small... REALLY small. Concentrate on just making really simple things to start, like moving a sprite around the screen, or just drawing text even. From there, you can actually move forwards to try and have basic gameplay.

Again, since you want to go the purist route, you're looking at countless hours of just figuring out how the heck to do basic things. You want to code in mouse support? Expect to do some assembly code and to burn at least a week figuring it out. That's just to get a mouse cursor working from scratch. The ONLY reason to go the purist route is if you're doing this less for the end goal and more for the challenge. (IE: You'd rather learn tons of stuff than reach the goal you set.)

Otherwise, if you're in this to make a game, not to spend days on end writing stuff people have already written, I highly recommend using existing game libraries and coding for something other than DOS.

I gave up DOS coding back in 2002 when I realized continuing to do it was a dead end as far as making commercial games... though I would've given it up sooner had I access to a Windows IDE and compiler sooner. :P

I interpret the RPG project as a long term aspiration, not something he's expecting to do right away. As he starts learning to do basic things, simpler projects will probably take hold.
I was always trying to do things I didn't really know how to do. That's what motivates you to learn more. When you have a goal in mind, it gives a reason to study and develop the underlying aspects of the project. As you figure those things out, it probably will provoke some smaller project, like the simple Pong and slightly-less-simple Breakout games I wrote at one point. I wasn't really a fan of those games, I just had an "aha" moment and realized I could do them, so I did them. My real goals remained as more complicated projects (which never actually ended up happening, but that's my own fault).

DracoNihil wrote:

Jorpho wrote:

Good $deity. Do you honestly believe that with no programming skill you could, on your own, be able to construct a first-person 3D engine from scratch?

https://www.youtube.com/watch?v=HQYsFshbkYw

Bisqwit sure makes it look easy.

Okay, I'm impressed. Someone on Reddit calls him "the Finnish code slinging Bob Ross".

shamino wrote:

I interpret the RPG project as a long term aspiration, not something he's expecting to do right away. As he starts learning to do basic things, simpler projects will probably take hold.

In the past, I have watched more than one person start making an MMORPG with no experience. They get about as far as learning how to use a world editor for the libraries they've chosen, add some prefab buildings and trees... then they're never heard from again. :P

So they get maybe about 0.0000002% done before realizing it'll take them their entire life just to make the damned thing. ;D

No no no, you're doing it all wrong here 😀
If you want to walk in the shoes of those before you, you'll need to learn what they knew. However a far easier route exists. Start programming your game for windows and leverage the modern tools available for it. Then when your game is complete and you have sufficient programming knowledge under your belt "THEN" tackle programming for DOS.

By doing so you'll understand the value of provided library's, timer functions, I/O handling, video output, audio output, scripting and other valuable game coding stuff.

Because in DOS, you'll have a severe lack of all this functionality, and will most likely need to code your own.
You'll probably be using OpenWatcom and what they provide in the end.

The final nail in my game crafting coffin was the visual stuff. Coding the engine was fun it's all for naught if you don't have some pretty sprites to push around, and geeze louise it's hard to fake an interest in graphic design. That of course is why it takes teams of people with different skills sets to do a game in < 1 human lifetime.

That of course is why it takes teams of people with different skills sets to do a game in < 1 human lifetime.

So they get maybe about 0.0000002% done before realizing it'll take them their entire life just to make the damned thing. ;D

There actually are some decent games churned out by single people or a small team. Not AAA titles of course but that's not what anyone is expecting. You do need to start with basic programming. The first game I wrote was a tic tac toe game. And yes, it will take years of programming experience before you can write any kind of 3d or even advanced 2d game.

Maybe try and focus on doing something for a while. You jump from initiative to initiative. I also strongly recommend you focus on academics (e.g. high school) to prepare for college. Once in college you can take computer engineering classes: that will actually position you for a better life. Burning a lot of energy on obsolete technology is not smart. For people with a strong background or natural talent in programming it is a fun hobby. Otherwise it is completely nonsensical IMO.