VOGONS


New game: Loonies 8192 (386+, VGA, OPL-2)

Topic actions

First post, by thp

User metadata
Rank Member
Rank
Member

This week I've extended my quick DOS port of a Lumines-like puzzle game and the result is Loonies 8192, a 16-bit (386+), VGA and OPL-2 game coming in at only 8 KiB (executable size, that is -- it should only need 64 KiB of RAM). I've been developing it mostly in DOSBox, and at least on my machine, it runs perfect with ~ 8000 cycles and is still playable with 3000 cycles. I have also briefly tested it on a K6-II with 500 MHz and a SB16 (OPL-3, although the game itself only uses OPL-2 features, so it should work fine on an original AdLib).

I'd be interested in getting feedback on how the OPL-2 audio output is on sound cards that don't have an original OPL chip but some kind of compatible chip or even software emulation (again, tested and developed this game on DOSBox, so mostly interested in reports on running this on actual hardware).

Similarly, would be interesting to find out how low it can go, obviously 386 is the minimum for this game, since it uses some 386-specific instructions, but does it run fluently on a 486 already? Does the VGA card make a huge difference?

Also if you just want to give it a spin on your retro gaming machine and report back how you like the game, etc.. (generic feedback), that'd also be welcome 😀

With this game, I mostly wanted to play around with the rhythm section of the OPL-2, with palette cycling and creating tiles and fonts (the block tiles and the font used for the score numbers) and creating (generating) aesthetic color schemes.

Download here: LOON8R44.ZIP

UPDATE 2018-07-23: New build with music and performance improvements for retro hardware, thanks to all the testers in this thread for making this possible 😀

UPDATE 2018-09-05: New build with PC-Speaker support, German translation, new keyboard handling and VGA performance improvements to make it smooth on 286-era machines as well as newer ones. Thanks again to the testers in this thread 😀

Screenshots:

shot1.png
shot3.png

Last edited by thp on 2018-09-05, 18:48. Edited 5 times in total.

Reply 1 of 120, by Eleanor1967

User metadata
Rank Member
Rank
Member

How did I do? 😉

So the OPL2 music sounds good to me, I sometimes feel that there is to much silence between notes being played but since I do not know how it is supposed to sound I can't give you anymore information besides that it works and that I think it fits the game well.

I played the game on my 486 (well pushing it, Cyrix 5x86 120Mhz with register enhancements) and it played without any noticeable lag. The game felt responsive is probably the best way to put it.

To gameplay I have to say I think its fun, but a bit to easy and therefore outstays its welcome a bit. It's not that the game gets boring, it just after 10 mins or so of cluttering the board I would have preferred to loose the game and start again with a fresh board. Maybe let the game run faster when reaching certain milestones like Tetris does?

I do like the pallet switching, it keeps it fresh. I hope this didn't sound to harsh sine I enjoyed my time with your game.

Anyway, the entertainment to KB level is very high so keep on going 😉

Attachments

  • 20180705_200237.jpg
    Filename
    20180705_200237.jpg
    File size
    1.24 MiB
    Views
    4498 views
    File license
    Fair use/fair dealing exception

Reply 2 of 120, by xjas

User metadata
Rank l33t
Rank
l33t

Looks awesome! Will give it a go when I get home today. I have a few different "OPL-compatible" machines around to try it on.

twitch.tv/oldskooljay - playing the obscure, forgotten & weird - most Tuesdays & Thursdays @ 6:30 PM PDT. Bonus streams elsewhen!

Reply 3 of 120, by root42

User metadata
Rank l33t
Rank
l33t

Question: what 386 features does it use? Would a 286 or 8088 port be hard? If you only need around 64 KiB RAM, protected mode should not be the issue... so what other features do you use? 32 bit moves? Maybe a 16 bit port might be possible...

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 4 of 120, by thp

User metadata
Rank Member
Rank
Member
Eleanor1967 wrote:

How did I do? 😉

7495 is quite a good score 😀

Eleanor1967 wrote:

I played the game on my 486 (well pushing it, Cyrix 5x86 120Mhz with register enhancements) and it played without any noticeable lag. The game felt responsive is probably the best way to put it.

Thanks for testing and the "proof photo" 😎 Nice to see it running on real retro hardware than just a DOSBox window.

Eleanor1967 wrote:

To gameplay I have to say I think its fun, but a bit to easy and therefore outstays its welcome a bit. It's not that the game gets boring, it just after 10 mins or so of cluttering the board I would have preferred to loose the game and start again with a fresh board. Maybe let the game run faster when reaching certain milestones like Tetris does?

Yes, I thought about that, there are a few possible ways to make things harder (quicker "fall" speed for the tiles, slower/faster "sweeper" speed, possibly a meaner selection of blocks so that you get more "checkered" blocks and less full-color of half-hand-half blocks). Maybe I'll add some modification to those parameters as the number of cleared blocks increases.

Reply 5 of 120, by thp

User metadata
Rank Member
Rank
Member
root42 wrote:

Question: what 386 features does it use? Would a 286 or 8088 port be hard? If you only need around 64 KiB RAM, protected mode should not be the issue... so what other features do you use? 32 bit moves? Maybe a 16 bit port might be possible...

So I'm using Borland C++ 3.1 and I'm building without the C standard library (mostly for binary size purposes, but also to see how far I could come without actually using the standard library and relying on interfacing with DOS/BIOS/VGA interrupts directly). When building for 8088/8086, the linker complains (because I'm not linking the standard library) about long integer (32-bit) division, multiplication, modulo and shift operations (in particular those are: N_LUDIV, N_LXMUL, N_LUMOD, N_LMOD, N_LXRSH, N_LXLSH, which as far as I understand it would be the software emulation of those operations implemented in the standard library). Linking against the standard library then of course works but blows up the binary size and of course makes those long operations more expensive.

If there's interest (and somebody willing to test) i can try working on a 8088/8086 compatible build, either by just linking in the software emulation parts for those or by seeing if I can avoid using 32-bit integers (mostly used for time and score keeping, but there might be some hidden uses that I didn't catch, and because the error happens at the linker stage, the Borland tools don't seem to show me which source code lines actually use those instructions).

Reply 6 of 120, by K1n9_Duk3

User metadata
Rank Member
Rank
Member

I tested it on two old laptops and only got a black screen. The first system is a 486 SX @ 25 MHz and the other is a Pentium MMX @ 266 MHz. The pentium has an OPL-2 compatible sound card, the 486 only has the internal speaker. I did hear some sound on the pentium laptop (the first notes/events of the song, I assume), so at least some part of your code appears to actually do something on that machine, but that was it. I was booting both systems from the same bare-bones DOS 6.22 bootdisk which also had the game's EXE on it.

After that, I tried a third laptop, a K6-2+ @ 533 MHz. Booting from the same boodisk as above gave the same result. But booting to Windows 98 from the harddisk and then running the game from the floppy (kind of) worked. I got to see the title screen (and the music played), but after I pressed Space to start a new game, it crashed because of an illegal opcode or something like that. After exiting to Win98's DOS mode, I got that black screen again, no sound at all.

I don't know anything about your code, but I would assume that it waits for some state or event that doesn't occur on the systems I tested it on (at least not in pure DOS) and that causes the game to get stuck at the black screen.

Reply 7 of 120, by thp

User metadata
Rank Member
Rank
Member
thp wrote:
root42 wrote:

Question: what 386 features does it use? Would a 286 or 8088 port be hard?

If there's interest (and somebody willing to test) i can try working on a 8088/8086 compatible build

After removing the long integer usage (which might lead to problems with timekeeping, as the code doesn't yet properly deal with overflow there, and it limits the upper score bound, although that could be fixed with a bit more code), here's a build. Coincidentally, after packing it's 8129 (as opposed to 8192) bytes long.

The intro sequence is probably a bit too much for these older CPUs (if I turned it into just color cycling, it should be fine, but was too lazy to figure it out with the faux alpha-blending overlay), but in-game might just work well enough.

Attachments

  • Filename
    LOON8086.EXE
    File size
    7.94 KiB
    Downloads
    112 downloads
    File comment
    8086 compatible build
    File license
    Fair use/fair dealing exception

Reply 8 of 120, by Ozzuneoj

User metadata
Rank l33t
Rank
l33t

What video modes are supported? My IBM 5150 (8088 with a 286 upgrade card) would probably like this game, but I can only run CGA or EGA games on that system.

Now for some blitting from the back buffer.

Reply 9 of 120, by thp

User metadata
Rank Member
Rank
Member
Ozzuneoj wrote:

What video modes are supported? My IBM 5150 (8088 with a 286 upgrade card) would probably like this game, but I can only run CGA or EGA games on that system.

Right now it only supports VGA mode 13h, due to the linear addressing mode being a bit easier to grasp for me (still). Planar EGA (and once planar has been implemented, also page-flipping VGA unchained mode) might be interesting. CGA might be doable (switching between the red/yellow/green and cyan/magenta/white palettes), but I'd probably be ripping out other parts (since the whole palette cycling thing is obviously not a thing there) then as well.

Reply 10 of 120, by thp

User metadata
Rank Member
Rank
Member
K1n9_Duk3 wrote:

I don't know anything about your code, but I would assume that it waits for some state or event that doesn't occur on the systems I tested it on (at least not in pure DOS) and that causes the game to get stuck at the black screen.

Thanks for testing! Sounds weird, especially the "unknown" opcode thing, since all your machines are much newer than a 386. Are the OPL-2 compatible sound cards on port 388h (they very likely are, just asking). Also, do you have any slowdown utility or something activated that would maybe mess with interrupt 1A, AH=0 ("Read RTC"), as I'm using that for timing of things. Also, out of interest, which video cards are in those machines? I did at least once successfully test with a K6-2 500 MHz with an ATI Rage Pro (inside Windows 98 and in pure DOS).

Reply 11 of 120, by Eleanor1967

User metadata
Rank Member
Rank
Member
thp wrote:

[...] but I'd probably be ripping out other parts (since the whole palette cycling thing is obviously not a thing there) then as well.

Well you could go with CGA composite mode, which would give you atleast 16 colors

Reply 12 of 120, by root42

User metadata
Rank l33t
Rank
l33t
thp wrote:
thp wrote:
root42 wrote:

Question: what 386 features does it use? Would a 286 or 8088 port be hard?

If there's interest (and somebody willing to test) i can try working on a 8088/8086 compatible build

After removing the long integer usage (which might lead to problems with timekeeping, as the code doesn't yet properly deal with overflow there, and it limits the upper score bound, although that could be fixed with a bit more code), here's a build. Coincidentally, after packing it's 8129 (as opposed to 8192) bytes long.

The intro sequence is probably a bit too much for these older CPUs (if I turned it into just color cycling, it should be fine, but was too lazy to figure it out with the faux alpha-blending overlay), but in-game might just work well enough.

Awesome. I will try it on my 286 tonight, if possible and give feedback. It has an OPL2 card, so sound should work as well. Let's see how slow the intro will be...

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 13 of 120, by thp

User metadata
Rank Member
Rank
Member

I found a bug that might cause the crashes (wrongly sized palette table, was overwriting 96 bytes of memory somewhere where it shouldn't have). Fixed builds attached (r16 for 386+ and r17 for 8088/8086), I've also not packed the executables this time in case there are incompatibilities with the packer, especially on 8088/8086.

Attachments

  • Filename
    L8086R17.EXE
    File size
    16.09 KiB
    Downloads
    110 downloads
    File comment
    Loonies 8086, r17, 8086/8088+ (not packed)
    File license
    Fair use/fair dealing exception
  • Filename
    LOON8R16.EXE
    File size
    15.92 KiB
    Downloads
    110 downloads
    File comment
    Loonies 8192, r16, 386+ (not packed)
    File license
    Fair use/fair dealing exception

Reply 14 of 120, by root42

User metadata
Rank l33t
Rank
l33t

Alright, it does run on a 80286. Here is the proof: https://youtu.be/MnDiIgg7WyA

However there are some minor problems. Introscreen indeed looks choppy. Gameplay also seems at times a bit sluggish. The music is... well, I guess you're not a composer? 😀 However it's still better than what I could manage. Or is this because of the slowness of my machine...?

All in all I am impressed how much is fitting into 16 KiB. I think if you polish it a bit, optimize some aspects for speed on slow machines and get someone here to compose a tiny OPL2 chiptune for you, you might have a real winner!

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 15 of 120, by K1n9_Duk3

User metadata
Rank Member
Rank
Member
thp wrote:

I found a bug that might cause the crashes (wrongly sized palette table, was overwriting 96 bytes of memory somewhere where it shouldn't have). Fixed builds attached (r16 for 386+ and r17 for 8088/8086), I've also not packed the executables this time in case there are incompatibilities with the packer, especially on 8088/8086.

Thanks. These work perfectly fine on my 486 and Pentium laptops. After testing it on those, I didn't see the need to test it on the K6-2+ as well, so I skipped that one.

Reply 16 of 120, by thp

User metadata
Rank Member
Rank
Member

Cool that it started working now 😀

As for the OPL-2 chiptune, that'd be a good idea to improve upon my ad-hoc "music" 😉 Anyone knows somebody who would be up for it?

I'll think about adding EGA or CGA support, but maybe creating a totally different game (or a really stripped down version) for those standards might be more productive (two games instead of just one), especially since this one is quite tailored towards features of VGA as it is right now (6 of the 16 EGA colors would be used up by the tiles already -- two colors, and each of them has a normal, dark and light share, then it needs black + quite at least for the text + backgrounds, leaving only 8 colors for the background animations, and if I want to have the faux transparency as it is right now (=darker variant of the background colors), that'd leave only 4 colors, maybe more if one can use some overlap there (e.g. 2x6 colors with two color overlap).

Reply 17 of 120, by thp

User metadata
Rank Member
Rank
Member

..and one more build with the in-game background redraw logic a bit optimised (only draw "in between" areas, not the whole screen, which then gets overdrawn anyway by the playfield + score/instruction boxes) and an extra block pattern as bonus, compiled for older machines (8086/8088 compatible).

Attachments

  • Filename
    LOON8R19.EXE
    File size
    19.75 KiB
    Downloads
    122 downloads
    File comment
    Loonies 8192 for 8086+, r19 (not packed)
    File license
    Fair use/fair dealing exception

Reply 18 of 120, by root42

User metadata
Rank l33t
Rank
l33t

Also tried this: https://youtu.be/opgguHF4O40

I can't see many differences. However both versions exhibit screen noise, probably due to palette changes. I tried a second Tseng card in this video, but the noise is not better, maybe even worse.

Could it be that you are not waiting for horizontal or vertical refresh for the palette changes? My DOS coding is 25 years at least gone, but IIRC you have to wait for the retrace to start to change palette without video noise. Probably has something to do with the RAMDAC...

EDIT: tested with some other games and I think the second Tseng is at fault for the noise. Wonder what could trigger that? Well nevermind then.

YouTube and Bonus
80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, SnarkBarker & GUSar Lite, PC MIDI Card+X2+SC55+MT32, OSSC

Reply 19 of 120, by amadeus777999

User metadata
Rank Oldbie
Rank
Oldbie

Pretty cool software - well done. How long did it take you to develop it?
I really like the intro screen.

Not really into soundcards and their features - are ESS 1868/SB Live!/ALS1x0 good for testing regarding OPL2?

Could take me a while but I will try running it one of these "Industrial" Epson 486s which houses an ALS120.