Ludum Dare happening caused me to forget to write an update post this past Friday/Saturday, so here it is a few days late!

Right now the entire DOS Game Development project has basically turned into a DOS Tool Development… and I intend to fix that, soon. I just need to make my graphics editor spit out engine-usable (And RLE compressed) files and palettes so I can start work on my game.

As for the game, I've decided that making Breakout is going to be too boring with the amount of work I've put into the graphics editor. I'm going to make an attempt to "port" one of my earlier Ludum Dare games to DOS.

This one in particular.

By "port", I of course mean "re-imagine". It's an LD game, I hardly pulled it together to begin with. I'd like to, if possible, make an Ultima-like game by the end of things, even if it's just a short one.

Anyway, back to the toolchain!

The Graphics Editor

It's nearly finished! Nearly! I just need to add in a palette editor, along with the utility shortcuts I've been putting off for nearly a month now (Frame copy/insert/delete).

Also need to actually implement my Save/Load code, but that's pretty simple. The only 'twist' to it is that I want to implement some basic RLE (Run Length Encoding) to save a few bytes of disk space.

Most of the work I did this week (And over LD weekend) was to implement some nice "Quality of Life" changes in the editor.

For one, key-repeat works on the arrow keys, and you can hold down the Draw/Erase buttons and basically erase an entire row or draw a line that way.

The UI now 'shades' itself when losing focus so that multiple layers of UI don't become too cluttered.

Zoom levels have been implemented. The editor can now handle an editing grid of arbitrary size, and zoom in right down to the 8x8 pixel editor for fine-work.

Also finally got over my procrastination and implemented the color chooser again. Had to iron out a few bugs/general protection faults, but otherwise got it working in about 20 minutes.

Here's a few screenshots of the editor in 'action' so far:

Hello.

Shark/Dragon-girl thingy. Hard to translate to 32x32, also the default Mode13h palette is kinda… weird. But I've worked with worse. Workflow wasn't too bad, but I have earmarked a few things I want to add before I call this ready for "production".

Those things being Undo/Redo and Flood Fill.

And that's the UI shading in action.

My next 'big' feature that needs addressing is a palette editor. I'm planning on having a global editor palette that can be saved/loaded from disk.

I also want to look into defining an upper area of the palette for cycling. Maybe the last 32 entries in groups of four, or add some way of marking a cycling palette in the palette file that isn't going to require too many hours of work.

That's it for the editor… now for the rest of the toolchain!

Code Editor

Turbo C++ is… OK. The IDE isn't the most comfortable thing in the world to use, requiring gymnastics to do things like copy/paste snippets of code. Also it has nasty window management.

But the biggest issue I have with it is the display resolution. It can basically run in "Argh, everything's huge" mode or "I can't squint hard enough to see that" mode.

It gets a bit tiring, which is one of the main roadblocks I've been facing while working on this project.

The other one is the fact that VMWare doesn't like to scale guest windows, so I'm actually peering into this when working on the project:

Fun times.

So I decided, after much joking about it, that I'm going to look into creating a text editor next. I could in theory just use Emacs for DOS, but that requires protected mode and a DPMI server… and in the spirit of things I want to keep to writing my own stuff using only the tools I had back in the day.

Now, all things considered, a text editor isn't that difficult to make. I made one last year following the Kilo tutorial.

The issue here is screen resolution. A text-mode editor is still gonna be a text-mode editor.

So I started doing some more digging, and decided to take a look at VESA modes. A lot of older DOS PCs don't support VESA at all, but since my original development hardware was a Pentium that did, I'll use it.

Which is easier said than done, especially when working in Real Mode. If I have a high resolution, only a window of that gets mapped to the usual location in CPU-addressable space (0xA000:0x0000), 64K at a time.

The Window can be repositioned, but only in increments that vary based on the graphics mode (Called the "Window Granularity").

So what I'll have to do before I can use VESA modes is create a driver/library of sorts that allows me to hide away all that nonsense behind some abstractions.

Of course, this constant repositioning relies on a DOS interrupt, so it's not exactly the fastest thing in the world. The 'better' way to do it is by entering Protected Mode or using a Protected Mode Interface, then you can access the entire 32-bit address space, with the VESA mode mapping into upper address space in one big chunk.

So I'm weighing up the pros and cons of the two approaches. Because of the way I'm handling things, I don't want to use a premade DPMI system (CWSDPMI/DOS4GW).

So I'd have to write one myself. I'm planning on doing a bit of research later into what that would entail.

Entering protected mode isn't too difficult in and of itself, but the issue here isn't with entering it, it's that Turbo C++ doesn't know protected mode is a thing.

So you end up having to jump into a lot of assembly and interface abstractions to get anything working.

But in the end, performance might end up being similar in nature between a DPMI TSR and just using VESA with its 'window' addressing.

I'll report on any tests I do next(?) week? Maybe this Saturday, to get back into the 'once a week' blog rhythm.

Also, interesting bit of information I brought up on Discord, but VESA can support some pretty out-there modes for an old standard. How 'bout some 1920x1440 16-bit color DOS?

I'm aiming for 1280x1024, which sounds like it'll be a huge performance hit, dealing with that amount of screen estate in 16-bit DOS mode… but this isn't for a realtime program, with a text editor I can get away with "dirty rectangle" updates on a relatively small scale.

Now, onto the final 'thing' I want to make (But won't, yet).

A graphical shell

All versions of Windows up through 98/ME were, essentially, just really fancy shells operating on top of DOS (And overriding a lot of default DOS interrupts, implementing an executable loader, dynamic linker and so on).

Naturally, all of this digging around into VESA and the like has made me think I'd really like to make my own "OS on DOS", just for fun.

I won't be doing it now though, because otherwise my original project will never see the light of day.

But it's definitely going to be something I'm adding to my list-of-things-to-make.

And that's the end of this week's report. This Saturday I'll see if I can get any example code up for VESA programming, whichever way I decide to do it.