• Please review our updated Terms and Rules here

Little Game Engine for MS DOS.

Mills32

Experienced Member
Joined
Sep 25, 2018
Messages
149
Location
Spain
Hi.

Despite a lot of bugs, and things poorly implemented, this is working better than I expected. An 8086 - 8 MHz should run it OK.

I captured this video using DosBox Daum at 600 cycles (more or less an 8086-8 ).

You need a GUS card to play the MOD files.

I tried not to be a mess with the source. But I ended up making a lot of specific functions just to make the samples work.


I could not make it work on 320x200 with borders, so it works in 304x176, and some monitors won't work.

This is a github link in case anyone wants to test it:

https://github.com/mills32/Little-Game-Engine-for-VGA-MCGA/blob/master/README.MD

8)
 
This is really impressive, given the system requirements. :) I like!

Thanks.

On a real 8086/8088, the sprites will probably look a lot more glitchy. And depending on the VGA card, the game could run faster or slower, but it should work.
 
Lookin really good, ill have to try it out. The art looks really nice too, did you make that too?

:cool:

I found the moon and the asteroid in a web with sample images, and the top down map was a sample map for "tiled" software, then I added the water and the houses. I made the rest (the platformer and the puzzle games) using gimp.

Hmm super nes emulator for 80286

Quite impressive

Thanks.

Well, the engine can only scroll one plane, and I think it could handle 8 sprites (16x16) without a lot of flickering on a 286.

Cool stuff :cool:

Are you going to make a game with it?

Thanks a lot.

I don't know, maybe a simple platformer, or the bouncing ball one.
 
I captured this video using DosBox Daum at 600 cycles (more or less an 8086-8 ).

Keep in mind that DOSBox emulates an impossibly-fast video card. Your actual hardware requirements are likely a 286-10 (especially given the GUS usage).

Very impressive project! I didn't think the video manipulation would work, but I guess I was wrong. Maybe someday I can convince you to support mode-x proper :)

Looks like I have a lot of reading tonight.
 
Keep in mind that DOSBox emulates an impossibly-fast video card. Your actual hardware requirements are likely a 286-10 (especially given the GUS usage).

That's true. But I also tested on PCem which emulates several vga cards, and it also emulates a more acurate 8088 8086 or 286 (DosBox emulates a 386).

On PCem using the slowest vga card, produced some jerky scrolling on the 8088, for example the mario level is working a bit jerky on 8088, so you are right, but the 8086 + slow VGA runs the game just as fast as in dosbox.

I did not record the game on PCem because that emulator has some issues when wrapping the VRAM in mode 13 (mode X works OK).

Very impressive project! I didn't think the video manipulation would work, but I guess I was wrong. Maybe someday I can convince you to support mode-x proper :)

I wanted to make it work on mode x, but this is why I did not use it:

-Every time I have to draw something, I have to introduce a for, (to draw the four planes), so that will slow the engine.
-To speed up the drawing, I have to store the tiles and the sprites in VRAM, so that I can move just one byte, and it will move the four planes at a time. That's cool, a lot faster!. But there is a problem, you have to limit scroll, so that you don't overwrite the tiles and sprites stored in VRAM. That's exactly what a game called doofus does, (I think).
-And the last reason... To avoid all of this, you have to draw everything to a VRAM page, and use double buffering etc... That will kill the 8088 and 8086 :(.
 
We shoud compare this with a real computer :).

This is an emulated 8086 - 8MHz, and the slowest VGA on PCem:

Screenshot from 2018-11-24 12-16-16.jpg
 
And the last reason... To avoid all of this, you have to draw everything to a VRAM page, and use double buffering etc... That will kill the 8088 and 8086 :(.

Writing to visible or hidden RAM is the same speed. And it can be *faster*, not slower, since you can take advantage of double-buffering to not worry about where the beam is on the screen (don't have to wait for retrace), or erasing things "gracefully" (since they're hidden).

The advantages of mode-x:
- Playfields larger than the screen means you can have a 320x240 full-page scrolling experience, no need to try to "hide" borders or come up with non-standard video modes that are not compatible with all monitors/cards/emulators.
- VRAM copying can be faster than system-ram-to-vram copying (if you have slow video cards, and can fit everything you need in 128KB of VRAM or so).
- Hardware split-screen, if you want/need it
- If you need it, fast filling/clearing (turn on all planes, then writing one byte actually writes four)

I'm not trying to force you to support it, just making sure you understand that the advantages outweigh the disadvantages. But saying it would be "slower" on 8088 is simply not true, in fact the VRAM copying exceeds the speed of an 8088 CPU trying to do the same. For larger areas (16x16 and bigger) it is definitely way faster to do a VRAM copy on an 8088 system.
 
Ultimately, this is the most compelling reason for supporting mode-x: What you're doing doesn't work on all hardware:


This is a very standard Paradise PVGA1A chipset.
 
Ultimately, this is the most compelling reason for supporting mode-x: What you're doing doesn't work on all hardware:

Wow.. So PCem is working OK, it just does the same!.

I know why this happens... the VGA does not wrap the VRAM around 64 kb, if you scroll down all the 4 pages (256 Kb) it will show pixel data again...

Oh and the "snow" is because I change the palette outside vblank :(.

So this might work on a real MCGA, but not on VGA. It works well on SVGA and on modern GPU'S for some reason.

Ok, I first have to check if the wrapping issue can be solved by changing some register or something.

If that can't be solved, I'm going to do it with mode x :cool:, we just have to live with limited vertical scrolling, so that I can store tiles and sprites at the bottom of the vram, and also can use the split screen to draw a window with info.

But there is a problem, how do I port the sprite drawing with transparency to mode x?, that's going to be a bit complex.
 
Last edited:
I tried out the mario demo on a few of my computers and unfortunately I agree it isn't very compatible.

8088 10 MHz:
Oak OTI067 (512K) - only card that worked 100% - scrolls pretty smooth, some sprite flicker
ATI VGA Wonder XL (1MB) - hangs before loading screen
ATI VGA Wonder 1024 (1MB) - doesn't hang but no graphics (just blinking cursor in text mode), can see the palette fade when it's loaded

386SX 25 Mhz:
Cirrus Logic GD5410 (256K) - large amounts of graphics corruption, jerky scrolling
Cirrus Logic GD5429 (1MB) - small amount of graphics corruption, scrolls smooth

Pentium 75 MHz:
Cirrus Logic GD5440 (2MB) - very minor graphics corruption, scrolls smooth, randomly hangs during game
 
I tried out the mario demo on a few of my computers and unfortunately I agree it isn't very compatible.

8088 10 MHz:
Oak OTI067 (512K) - only card that worked 100% - scrolls pretty smooth, some sprite flicker
ATI VGA Wonder XL (1MB) - hangs before loading screen
ATI VGA Wonder 1024 (1MB) - doesn't hang but no graphics (just blinking cursor in text mode), can see the palette fade when it's loaded

386SX 25 Mhz:
Cirrus Logic GD5410 (256K) - large amounts of graphics corruption, jerky scrolling
Cirrus Logic GD5429 (1MB) - small amount of graphics corruption, scrolls smooth

Pentium 75 MHz:
Cirrus Logic GD5440 (2MB) - very minor graphics corruption, scrolls smooth, randomly hangs during game

Thank you very much for testing. I like that the 8088 runs the Mario demo smooth.

I guess it's mode x time :).

About the sprites in mode x, I found this in another forum: "If you want efficient mode X sprites, I suggest taking a cue from how DOOM does it's sprites. Encode them as a series of vertical run-length strips, so that your code can minimize the number of I/O writes needed to switch which VGA plane (one of 4 pixels) it's writing to and maximize sprite output."

That will be fast enough i hope.
 
Last edited:
Wow.. So PCem is working OK, it just does the same!.

But notice there is also very jerky horizontal scrolling on real hardware.

But there is a problem, how do I port the sprite drawing with transparency to mode x?, that's going to be a bit complex.

Why reinvent the wheel? Just use XLIB. They solved these problems 25 years ago :) and the code is in C (there's a port to TP called XLIBPAS) so you should be able to just drop it in.
 
But notice there is also very jerky horizontal scrolling on real hardware.

Yes that's something wrong in my code, i'm doing the scroll outside the vblank, (like the snow problem when fade in/out), PCem also shows it, I should forget Dosbox when I test :).

why reinvent the wheel? Just use XLIB. They solved these problems 25 years ago :) and the code is in C (there's a port to TP called XLIBPAS) so you should be able to just drop it in.

I downloaded xlib some time ago, but I had not tested it yet. I just read some source files and I saw it "compiles" the sprites. Does that mean the program won't be able to load bmp files at run time? and the images are compiled with the source?.

Thanks again for testing.
 
Yes that's something wrong in my code, i'm doing the scroll outside the vblank, (like the snow problem when fade in/out), PCem also shows it, I should forget Dosbox when I test :).

IIRC with mode-x the address start is latched, so you don't have to wait for retrace for that stuff.

I downloaded xlib some time ago, but I had not tested it yet. I just read some source files and I saw it "compiles" the sprites. Does that mean the program won't be able to load bmp files at run time? and the images are compiled with the source?.

You should read it more thoroughly. XLIB has three methods for handling sprites:
- Rearrange the data into a planar organization so that you only have to switch write planes 4 times.
- "compile" the sprites which turns them into executable code that plots them. This makes them bigger, but if you have large sprites with large transparent areas, makes them faster.
- Store them in VRAM so that VRAM-to-VRAM copies are possible.

It comes with the programs to rearrange/compile graphics data so you don't need to write that part.

Try the demo program that comes with it, run that to see what it can do and how fast.
 
It looks like the xlib compiled sprites are incredibly fast, a 30x30 sprite started to run slow at 92 cycles on dosbox, (while my little engine sprites were way slower).

The good thing is the engine should work faster in mode-x (without the double buffering), and will be a lot more compatible :).

I'll have to say goodbye to the MCGA, anyway MCGA is not very common.

But first I have to check if the compiled sprites are using a lot of 286 instructions, (I hope not).
 
Back
Top