If you want to write modern, performant code for Dos (which, if you're doing stuff with graphics, you'll need to), then really you are looking at x86 assembly, C or C++.

This is still the same old song, even back Dos age, there are some alternatives like Pascal a we need really something like new age Pascal or Basic.. probably based on some good enough runtime adjusted for Dos.. And that adjusting means, simply remove lots of fuction which cant work under Dos.. make these which can run in Dos environment - these things (runtimes) are already written is C/C++ and ASM.. but for more modern OSes, compilers etc.

Some project above shows that it is possible, but they are simply more proof of concepts that complete tools.. but with more effort it could be done.

Sorry, I didn't read all posts in this thread, just stumbled across it, but, did you try QB64? It's a modern take on QuickBasic and 4.5 compatible.

https://www.qb64.org/portal/

I quickly read this thread and want to add my thoughts and ideas (I apologize in advance if such things have already been talked about).

As cool as building your own suite yourself that does exactly what you want sounds, for beginners I think we'd need at least a good programming suite with easily accessible documentation (most documentation for DOS exists on the web, but it's scattered everywhere), examples. This could eventually build a community of programmers that could help each other without wondering about strange compiler quirks, etc.
Such thing have been done for the Game Boy for example.
Another needed feature that seems *almost* there would be an emulator with an easily accessible debugger. DOSBox seems to have it, but you need a special version and it didn't feel intuitive at all in my experience. Viewing how other programs work (or even your own) could help a lot.
Again this exists for game console programming, so why not PC/DOS ?
When I was teaching myself asm, EMU8086 was incredibly useful as I could step through my program, viewing exactly which instruction was being executed and where it could get stuck, but I found myself rather limited very quickly.

A graphic designing tool would be nice too. It may not sound that useful at a first glance, but since DOS' resolution often don't use square pixels it's more useful than you may think. Maybe not a full blown editor since gimp and photoshop are just much better image manipulation tools, but maybe a suite of tools for images (A DOS screen "emulator" with the non square pixels, composite artifacting, dithering a picture with more color depth, compressing images in a way that can easily be decompressed from the game ...)

Another thing that came to me : you've been talking about lightweight versions of python that could be ported to DOS without to much effort. Do these lightweight versions of python support adding libraries ? Maybe a "DOS" library for python could be made, with functions to access to the CGA/EGA/VGA cards (maybe even more ?) ? There's even something named "cython" that can turn python code into C code which can then be compiled.
With such thing, making the game's logic could be far easier (which depending of the game you're making, might not be really demanding).

Also, I am myself looking for programming a DOS game right now, and some of my concerns are about how to build the app itself exactly ? Of course each game is different so there is no clear path anyways, but as I've been taught object oriented programming at school, I don't really know which design pattern are preferred when writing code with no object oriented programming and pretty much "DOS" limitations in mind.
Maybe I just didn't look in the right places ? Maybe there's just no answer ?

Something that seems even harder to make for me than VGA graphics is how to handle sound. I have literally no idea how I can do that, and finding answers is very hard as modern game devs often just throw a music file in their game engine and voilà, you have music. The "gun shoot" even happens ? Play "gunshoot1.mp3", done ... but it's not how DOS works.

Forget about using Python, that version linked a couple of pages ago is more than 16 years old and you'll struggle to get any recent python packages to work with it. The absolute minimum you want to run these days is Python 2.7, and even then that's been dead for several years.

The normal way to write something that targets more than one platform is to write a set of shim functions (or classes if using c++) and call these instead of your low level functions. At compile time you then link in your Linux x11 based GUI functions, or your opengl calls, or whatever, but your code is always just calling drawBox() or whatever, not drawBoxGL().

The biggest issue I find in targeting multiple platforms is finding sane ways to work around platform specific compiler/language implementation bugs; POSIX Vs non-posix system calls, systems that implement dirent.h versus those that don't, etc, etc.

ruthan wrote on 2021-05-18, 20:38:

This is still the same old song, even back Dos age, there are some alternatives like Pascal a we need really something like new […]
Show full quote

If you want to write modern, performant code for Dos (which, if you're doing stuff with graphics, you'll need to), then really you are looking at x86 assembly, C or C++.

This is still the same old song, even back Dos age, there are some alternatives like Pascal a we need really something like new age Pascal or Basic.. probably based on some good enough runtime adjusted for Dos.. And that adjusting means, simply remove lots of fuction which cant work under Dos.. make these which can run in Dos environment - these things (runtimes) are already written is C/C++ and ASM.. but for more modern OSes, compilers etc.

Some project above shows that it is possible, but they are simply more proof of concepts that complete tools.. but with more effort it could be done.

Sure, it can be done, but it's simply far easier to go back to assembly, c or c++ and take advantage of the massive base of prior knowledge and huge existing repositories of sample code and additional library functions.

Something that seems even harder to make for me than VGA graphics is how to handle sound. I have literally no idea how I can do that, and finding answers is very hard as modern game devs often just throw a music file in their game engine and voilà, you have music. The "gun shoot" even happens ? Play "gunshoot1.mp3", done ... but it's not how DOS works.

Well there were Dos sound engines and sound drivers for them, which were much more used that video engines, there is some list..
https://docs.google.com/spreadsheets/d/1L0aK1 … s_o0/edit#gid=0
Here a was doing my modern HW soundcard compatibility matrix i also added column, which game is using which sound engine just for info.

But really dunno, if some of these are free or not.. and if some off them were released later as free, but again.. i would prefer too used them.. same style as in modern videogames engines, what try to reinvent the wheel.. they have to exist for at least for C and Pascal and again with some effort and C or maybe ASM wrapper, they could be used with anything.

ruthan wrote on 2021-05-18, 23:50:

Well there were Dos sound engines and sound drivers for them, which were much more used that video engines, there is some list.. […]
Show full quote

Something that seems even harder to make for me than VGA graphics is how to handle sound. I have literally no idea how I can do that, and finding answers is very hard as modern game devs often just throw a music file in their game engine and voilà, you have music. The "gun shoot" even happens ? Play "gunshoot1.mp3", done ... but it's not how DOS works.

Well there were Dos sound engines and sound drivers for them, which were much more used that video engines, there is some list..
https://docs.google.com/spreadsheets/d/1L0aK1 … s_o0/edit#gid=0
Here a was doing my modern HW soundcard compatibility matrix i also added column, which game is using which sound engine just for info.

But really dunno, if some of these are free or not.. and if some off them were released later as free, but again.. i would prefer too used them.. same style as in modern videogames engines, what try to reinvent the wheel.. they have to exist for at least for C and Pascal and again with some effort and C or maybe ASM wrapper, they could be used with anything.

I think you need to accept many of the comments that have been made over the last few pages - many of the tools, APIs and libraries that you indicate you would like to use on Dos are written to take advantage of modern platforms and all of the functionality that those platforms bring (high resolution timers, threads, virtual memory, reloadable libraries/DLLs, and so on). You don't have any of that with Dos...

Most of the time you only have what you write yourself. There are some period libraries available like the Miles Sound System and Allegro, but if you are expecting something like you would get on modern Windows with plugins for Visual Studio, you are simply not going to have them.

Again, it comes back to accepting that you have to do a lot more lower level work with Dos - it doesn't hold your hand at all.

It's a different mindset and, compared to modern development (which many of us do in our day jobs), actually somewhat simpler and freeing as you don't have the vast complexities of a modern platform or huge software stack with all of their interdependencies.

I'm not expecting a full blown library, for sound, but simply some guide on how to do it, as you can't just skip over a sound, you can't delay it, etc. How to include that in the program's main loop ?

Actually maybe it's not really a problem related to sound but rather how to simulate things happening in parallel without any sort of thread

Deksor wrote on 2021-05-19, 06:58:

Actually maybe it's not really a problem related to sound but rather how to simulate things happening in parallel without any sort of thread

I guess the simple answer is, you don't.

The logical flow in most single threaded graphical applications/games would go something like this:

while true:
detect input
update state machine to reflect input
update UI/enemy/score state based on new collision data/mouseovers/button clicks
update music state
update soundfx
redraw graphics/scroll screen/repaint windows

The key is getting the logic for each element down to a point where its fairly deterministic - 5ms for this call, 10ms for that call etc. So that you know the audio update call is going to be made every 75ms (or whatever it may be). Then also ensuring that you only update the screen on a multiple of the vertical refresh (to avoid screen tearing) or implement double buffering, etc.

Unfortunately there's no real magic bullet involved with Dos - it's down to your management of timers, working with interrupts etc. Of course, if you are writing graphical Dos applications, rather than performance-biased Dos games, then it's a little easier as you don't have to worry about as much and you can take your own time for each step of your logic, as long as your application remains reasonable responsive to user input.

If you want to write something game-like for Dos, and you accept that C is going to be necessary, then you could do a lot worse than look at Allegro.

The older, Dos-relevant API is here: https://liballeg.org/stabledocs/en/allegro.html https://download.tuxfamily.org/allegro/allegr … al-4.2.1.en.pdf (Dos support was removed after Allegro 4.2.x)

It includes library functions for working with bitmaps, digital audio and midi.

Like I said before, the Dos version is now deprecated and it's probably not the best for multi-platform use (I'd go with libSDL if I wanted something to run on as many platforms as possible), but if you don't want to have to reinvent everything then Allegro would be a good start.

pan069 wrote on 2021-05-18, 20:46:

Sorry, I didn't read all posts in this thread, just stumbled across it, but, did you try QB64? It's a modern take on QuickBasic and 4.5 compatible.

https://www.qb64.org/portal/

unfortunately that's for windows, linux, macos and i don't think it can output dos executables

i did try it once and while initially it seemed good it also seemed vast (in binary size and output exe size) and slow when trying on P3 class machine

freebasic is a good alternative with native DOS binaries and its kept updated

then there is freepascal and of course djgpp + allegro

and if aiming for 16 bit then quick basic, turbo pascal, turbo c are all fine too

personally i see nothing amiss in using 'deprecated' tools or libraries for DOS, it's not likely to be updated now after all 😀

gerry wrote on 2021-05-19, 08:56:

pan069 wrote on 2021-05-18, 20:46:

Sorry, I didn't read all posts in this thread, just stumbled across it, but, did you try QB64? It's a modern take on QuickBasic and 4.5 compatible.

https://www.qb64.org/portal/

unfortunately that's for windows, linux, macos and i don't think it can output dos executables

Ah, OK. Maybe I misunderstood. I thought the idea was to use something modern to make something for DOS. QB64 does output exe's. It's also compatible with QuickBasic 4.5 so you can do development on a modern machine using QB64, then bring the source code over to a DOS machine with QB4.5 (or DosBox) and build an exe there.

Personally I use OpenWatcom for DOS development. It has a really good C/C++ compiler, supports DOS/Windows 16 and 32bit, has a great assembler, and a bunch of other great stuff. I do my development on my normal Linux desktop in a modern text editor (Sublime), I build my executable on the Linux command line (super fast) and then test in DosBox. Then, every once in a while I bring the exe over to a real machine (a 286, 386 or 486) for testing on real hardware.

It depends on what you want to build. If it is not something very radical, there are 1001 "RAD" programs to build a certain type of application. I will not remember names at this time, but for example, there are RAD programs to build menu programs for dos, it has a similar appearance to the setsound of old games, these menus are used to modify files, or start an external application. There are thousands of other programs, which are used to create database-based things in dos, for example, in the early 90s, rental companies and pizzerias used a database system in msdos, it was a program built in a custom way, for that one customer, but it was created from another program designed to create that kind of thing. It was as if a programmer made a program to manage a trade from scratch, and sold that program to you, to resell to the end user, before selling it you would customize some things, such as data field name, program name, colors , etc...