So this is an oddly specific question, but I've always wanted

>>3734342
Hope you're ready to learn some older programming languages

>>3734342
I have no idea why you would want to do that. Just pick up C and OpenGL and have at it. No need to interface with shitty software like DOS. Honestly when it comes down to it, 95% of your code will be platform independent; only the last details of getting input and drawing to the screen are really platform specific.

>>3734442
>only the last details of getting input and drawing to the screen are really platform specific.
Depends. Some code implemenation is platform specific even when it shouldn't be, for example shit like rand() or srand() can be platform specific. There are reproducible Mersenne twisters you can use for randomization these days that are guaranteed platform specific but that wasn't always the case. Sometimes types can be platform specific but can be dealt with using typedefs.

>>3734460
if you rely on a library rand() to produce the same result across all platforms or your code breaks, you're doing it wrong.

Also with correct typing in C and proper use of the preprocessor, there should be no cross-platform issues.

File: 1482369242348.gif (1MB, 406x449px) Image search: [Google]

1MB, 406x449px

>>3734342
learn C basics with K&R and make some games in the command prompt. Get used to the command line in bash and DOS. Programming is a very nonlinear thing so you might need to do some out of the box thinking to get modern methods to work on DOS. like >>3734442 said, the main difference in code will be the rendering engine, so learn multiple drawing methods for different platforms

>>3734342

although your committment to retro is commendable programming is a very serious and involved thing and its better not to re-invent the wheel.

if you want to enjoy the process I suggest following this advice:
>>3734442

Besides the way something is displayed can be made quite retro anyway, they have fonts that look like old dos prompts for example, you dont have to use any modern graphical techniques.

I suggest looking at a game called Broforce. They use alot of scaling for that but if you think about it... that game could have been made for Dos or even a console (possibly even SNES) with some minor adjustments.

Its like vaporwave, you can make new things look old.

If you want to make a doom game id also suggest using zdoom, there are some games (like Harmony and Chexdoom) which were made for it that completely redo everything including the palette, with its functionality you can make any game that has been produced using the idtech1 engine. But thats just a useful tip.

> for 3d games the quake2 engine isnt all that bad either but its got problems with scenery causing you to gib...

I've always considered doing this too OP, but settled for recreating the look in modern hardware.

I've lately been very tempted to buy either an Amiga or a silicon graphics workstation (I believe the dkc games were made using these).

A quote from an Amiga documentary said how people would come up to him saying "I love the retro look you achieved!" And he says back "it IS the retro look"

>>3734342
Learn x86 assembly language. It's challenging, but it's how a lot of DOS games were coded, and a number of old timey programmers swear that this is the best way to write fast, efficient code. Be warned however that your code won't be very portable. If you code for low enough specs though, you should be able to run your game on a variety of platforms through DosBox.

Alternatively, look into languages like Borland C++ or TurboPascal. Again, these aren't very portable to modern platforms, but they would be easier than assembly language. There's also DJGPP if you want something open source that's closer to modern development tools.

If you want something simpler, then look into QuickBasic. You might remember messing around with QBasic if you had a DOS PC back in the day, but QBasic was merely a cut down version of the full QuickBasic. There's even a modern open source equivalent known as QB64.

Some people will question why someone would want to write software in an ancient programming language for an ancient OS, but I think it's actually a pretty cool idea. It'll be challenging, and you'll likely have to consult a lot of dead tree format documentation, but I'd say it's worth a shot if you're up for it.

>>3734442
I will make a small correction to my post. Large DOS programs had to "segment" their code because of how memory worked on old x86 CPUs. Code had to be divided into 65536 byte "banks", and you would have to do something special to switch between banks. Since I never developed on DOS, I don't know the specifics, but I do dev on SNES and a similar strategy is used. On the SNES, to call code from within a bank, you use a 16-bit Jump Subroutine (JSR) instruction, while out of bank calls need a 24-bit JSR.

Btw, old devs didn't have fancy tools (like IDEs). They most likely just had a line-buffer editor (like vi, vim, or emacs) and a compiler (like gcc).

>>3734430
I already know C as I've developed my own simple C games in the following year, and I've been studying x86 ASM, so I've been working at this for a while.

>>3734474
I've already set up a batch coding environment and I've been using emacs and gcc/gdb to do most of my coding.

>>3734520
I've made my own retro looking games before using game maker, but it's not the same. I want the limitations, I want the challenge

>>3734430
>older programming languages

Fucking retards on this board, I swear to god, kill yourself

>>3734820
You might want to check out djgpp then. BUT, to do things the retro way, Borland C++ would be the way to go.

>>3734342

Yes. While you might appear a lot on /r/4chan, usually referenced by the name robot, others actually invest more then just time in games.

>>3734837
What are you talking about?

>obsessing over programming language

You can use any fucking language you want for DOS development. The difficulty lies in learning the hardware, not the language. If you're doing DOS dev from scratch, I hope you know a lot about writing drivers and dealing with interrupts from all over the fucking place. A thousand times worse than console dev.

>>3734860
okay do you have any book suggestions then?

>>3734474
idk why I like that animation, but I do.

>>3734985
Is it the butt?

I bet it's the butt

>>3734342
>programming a game in DOS
just write C in djgpp and read a vga programming guide
with djgpp, you don't even need to deal with memory segmenting (which is really fucking awful) since the CPU is in 32-bit mode.
Quake was built using djgpp.

there are a small handful of things you'd absolutely need asm for (like interrupt handling -- you can do it in C, but you will have problems, read http://www.delorie.com/djgpp/v2faq/faq18_9.html for details), but it's not massively difficult overall to write DOS software in djgpp, other than the lack of documentation
shit, I'm currently writing an OPL3 tracker using djgpp (entirely because I don't like Adlib Tracker II one bit)
the fun bit was the actual sound code and poring over the OPL3 docs, now I'm bogged down with UI code and I hate it

>>3734998
Any good VGA programming books? I'll definitely look into DJGPP, I think that's covered in the book I posted in the OP anyway.