Mega
Mega
Posts

382

Following

30

Followers

31

This user leads a small army of cyborg shark-people.

Joined on August 8, 2010, 11:12 AM Visited on June 19, 2019, 2:03 PM
Badges

Mega posted on July 16, 2018 at 7:49 PM

PNG4D Art Jam Entry

Welp, got an entry. Posting it in three pieces, with an explanation to follow:
So what happened? Indecision! It's kinda hard to come up with a "Summer" piece in the middle of South African Winter. So I sat down with a bunch of references, drew out a grid of thumbnail sketches, couldn't decide which one to go with... ended up using over half of them on a 7200x4800 canvas. ClipStudio Paint started to choke a bit towards the end, and exporting the full sized image as PNG takes about 3 solid minutes, with a 13mb file as the result. XnView chokes on that.


I decided, instead of uploading the full-size picture to upload it in 'pieces', first a resized overview of the whole, then two zoomed in crops of the main elements. I'm going to try upload the full-size image to the file manager and let people peruse my hasty line and brushwork at their leisure.


Big lesson learned? Don't overreach my design for art jams either, I don't have the time to work on super-complex pieces and maintain some sanity.
Thanks for the excuse to draw something Jani.

Mega posted on April 28, 2018 at 12:31 PM

DOS: Graphics Editor Completed, and VESA

I 'finished' my graphics editor yesterday. Got saving and loading working, and can now produce usable art for the game.

There are still a few comfort features to add, such as flood-fill, copy/paste, undo, etc, but for the moment I have something to work with and get get to work on the other things I have to work on.

Here's a couple of test images I threw together in the editor over the past couple of days:



Still using the default palette. I intend to implement a simple HSL slider palette editor next week, so I can choose my colors instead of trying to work with the default VGA palette.

Multi-frame saving/loading also works as intended, so the editor is "feature complete" so far as core functionality goes.

But now, I promised VESA shenanigans earlier this week...

VESA shenanigans

Now this was a can of worms to open.

So VESA. Holy crap is it hard to do anything with VESA in Real Mode.
The extent of what I was able to do was get into 1024x768x32 mode so far, and get a pattern on-screen:

This came at a great cost though: Clobbering DOS' memory pages. I have to restart the VM every time I test this.

You'll notice some strange lines on the left hand side of the screen if you look closely. That's DOS, trying to write into the same heap I allocated.

The biggest issue here is that the mode I chose, 1024x768x32, is not well suited for 16-bit programming. It takes 3.1MB of RAM to create a backbuffer, which I need because trying to blit directly to the VGA controller is slow.

Next week I intend to test out the lower bit modes (8bpp and 16bpp) as well as 800x600 mode, see which is the most workable in Real Mode DOS, then start working on a simple graphics library for that. Nothing fancy, I just want to render small bitmaps really (Bitmap fonts).
Might also look into VESA text modes, see how readable they are. But given the nature of the default VGA fonts, I'm not expecting much.

Otherwise, not much done this week besides the push to complete the graphics editor, besides my day job(s).

If I can sort out the VESA nonsense by the end of next week, I'll write a more in-depth wall of text detailing how it works, how to use it, etc.
If I still absolutely can't do it with Real Mode, I'll install a DPMI system and use that.

Until next week!

Mega posted on April 24, 2018 at 11:04 AM

DOS: Tools and More Tools

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.