amadeus777999 wrote:

Pretty cool software - well done. How long did it take you to develop it? I really like the intro screen. […]
Show full quote

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.

The game mechanics I did one afternoon in June, the VGA+OPL port roughly a week last week. The intro screen was done in an afternoon, but it was done last, so I already had most things in place, only needed to figure out how to do the projection using integer math + the shading of blocks that appear farer away.

SB Live! would be interesting, since afaik it does not have native OPL, but some kind of emulation. The other card I don't know anything about..

Very interesting - I will sit down and test your title on a 486/586 + aforementioned cards in the coming days.

Ok,
tested it on a P75 and the SB - Live!. The sound may be perfect(as far as OPL2 goes at it is emulated) and the game is very nice!

I like the title screen and the overall look as it reminds me kind of the ZX Spectrum and the Nes. The vertical tracer is neat but I'm not really sold on it... kind of too much.
The changes in the tiles could be less frequent to let the player settle on an art style but a pretty cool touch.
I also dig that the blocks are vertically moveable which makes it more interesting and dynamic.

You could do an altered version of Sokoban maybe...

Ran nicely on this setup, getting a score of 9920 at first try:

CPU: AMD Athlon 64 X2 4200+
Motherboard: ASRock 939Dual-SATA2 + AM2CPU
RAM 256MB DDR2
Sound: Philips PSC605 (CMI 8738) behind a PCIe-PCI bridge using REMAPCMI
Graphics: Nvidia GeForce 6200 PCIe something

Cool, thanks for testing 😀

I've now also got some MIDI soundtrack for the game, I'll try to adapt it to OPL-2 soon and maybe also a MIDI output option, or is that overkill?

And if I get to it, maybe also implement the other suggestion from here to add some level progression, slower change of palette and different speed/difficulty per level. Let's see.

I'd say the palette and artwork should change with every level. And every level should get a bit faster, or otherwise more difficult. This way the player notices when he advanced a level and will notice it getting more difficult. A level change could happen every 1000 points or something, or maybe first after 1000, then after 2000, 3000 points and so on. Making every level even a bit harder to pass.

Cool game! Quick video is online. 😀

Cool, thanks for the video! Also, I'm going to implement the gameplay / levelling up things still, but the music thing kept me busy a bit longer than expected, so here's an interim build and some development news.

So, I got a new MIDI-based gameplay tune from Tim (samoff.com) and started working on creating some tooling to translate it directly to OPL-2 commands. One thing lead to another, and after some unsuccessful tries creating a tune of my own on my MIDI keyboard, I ended up being kinda successful with creating a tune interactively (no real-time playing) using a MIDI editor. So, we now have two songs, the "S" button now toggles between those in game.

As an added bonus, I've received my OPL2LPT this week, so I've added native support for that as well, you get to choose at the beginning (port 0x388 for normal adlib, or the two OPL2LPT options that appear if you have LPT1 and LPT2 on your machine, respectively). I guess that's really the first time I've tested it on a real OPL-2? Looks like the rhythm section things at the intro are a bit off with OPL-2 (works fine with OPL-3), but the music works great with the OPL-2 as well.

And having done that, and learned a lot about the MIDI protocol, I started wondering how easy or hard it would be to add MPU-401 (MIDI) support to it. Turns out not that hard, so I extended my MIDI-to-OPL2 tool to also output raw MIDI commands, and added MPU-401 support to the game as well. It works nicely in DOSBox (which emulates an MPU-401 in UART mode and the backing synth on macOS at least is the General Midi softsynth provided by apple). So General MIDI is now an option.

For MPU-401, I've looked up some Sound Blaster docs, and it says 0x330 is the default and 0x300 is an option. Are there any other weird MPU401-compatible boards that have different ports that I should support?

However, I've tried it on my retro PC, SB16 with a Roland SCB-7 WaveBlaster daughterboard and I didn't sound at all correct. Is there anything I need to send to the WaveBlaster board to make it switch to the general MIDI program list or is there something else I'm doing wrong? Anyway, maybe you have more luck with these options than me (the MIDI stuff works fine with e.g. Windows Media Player + CANYON.MID). So consider the MIDI support experimental.

New build (r24) attached. This is uncompressed, and I haven't really looked into making the binary smaller, so it's a whopping 32 KiB at the moment, roughly 14 KiB of which is just the music data (2 songs in both OPL-2 and MPU-401 format, I could just store one variant and "generate" the other, but this way it's easier with tooling and presumably more efficient at runtime [it just needs to blast those bytes out the right ports]).

thp wrote:

Cool, thanks for the video!

You're welcome! I really like these kind of puzzle games. 😀
Just for fun, I also did a little experiement and the outcome was rather positive:

Congratulations! The initial 386+ version (r14) of Loonies is "dumb" enough for EMU386. 😉
It's a bit slow, but playable on my 286-10 (Schneider Tower AT with installed OTI-037c)

https://youtu.be/VdUnbXzHNAk

If I had to criticize something, it's the pause screen.
Painting it takes forever on my 286.

Edit: What I meant to say is that EMU386 is compatible only to games/programs which do not perform a CPU check.
That beeing said, I'm glad that your other builds also support 16-Bit CPUs directly.
Here's a screen shot taken from my 19" CRT monitor - The game looks magnificent, I have to say!

New build r26 is now attached to this message.

Changes since r24:

- fixed MPU-401 MIDI timing on real hardware (thanks to Scali and Tiido in this thread)
- reprogrammed the PIC timer to 1000 Hz (from the default 18.2 Hz) for better audio timing

Tested with:

- SB16, built-in OPL-3 FM synth
- SB16, Roland SCB-7 WaveBlaster board
- OPL2LPT

Still to do: Level progression (link falling/sweeper speed to level, also link background, color and tile changes to level progression maybe or at least make it happen less often). Plus, for 286 machines, it might be nice to have a mode where the background drawing is a bit more optimised.

Wow, thanks! This gets better and better! ^^
- I've also taken two more videos about the game.

Loonies 8086 on a 286.. https://youtu.be/zmJ78GZU6g0
Loonies 8192 on real hardware #2.. https://youtu.be/jiH1JCGmmXI

Edit: MIDI not tested, since my CT1350B uses SB-MIDI. Sorry.
I've got several synths, MT-32/CM64/CT460, though, for testing.

Thanks! I guess I can't pass up the opportunity to get it tested on a real MT-32 (and possibly having to figure out a MIDI program number mapping from General MIDI -> MT-32)?

So I read how the SBMIDI works, and DOSBox kindly emulates it as well, let's hope the real hardware works similarly (this time I made sure to check the status ports, something I learned the hard way when programming the MPU-401 😉). Please note that if you pick a wrong port setting or I did something wrong, the game will likely lock up waiting for the port to signal "ready". In that case, at least you could try the "slow" machine setting with no sound or Adlib sound.

Attached is Loonies r27, with these additions:

• Support for SBMIDI on port 0x220 or 0x240 (selectable at startup)
• "Optimized" drawing loop for the background effects (might or might not help..)
• Slow/fast machine speed selection, which disables some expensive drawing

The slow machine speed mode enables line skipping in the intro sequence, disables the background effect on the play area and disables the background effect on the quit yes/no selection screen. Would love to see if the SBMIDI integration works on real hardware with real synths 😀

Thanks, too. I'm astonished how fast you make progress! 😁
By that speed I'll have to keep my camcorder's backup battery charged. 😉

PS: There's also the ThunderBoard programmer's manual,
which might be easier to read at some point.

I linked to it in LABS' Sound Blaster 2.0 project thread.
That beeing said, I believe TB doesn't feature MIDI yet. That was added with the PAS line.

The SDK of the PAS includes a programmer's guide, too. If you're curious, you can have a look at
the SDK which Cloudschatze has mentioned in his posting.

Anyway, I don't know if the PAS (not PAS16) had its own proprietary MIDI interface,
and if so, how much it differed from the standard MPU-401 that the PAS16 got later on. 😅
I guess the manual describes how to use MVSOUND to send/receive MIDI messages (MVSOUND was like an API or HAL).

I'm just mentioning this, since the original PAS got some attention here at Vogons,
because it had an interesting Dual-OPL2 configuration. So there might be one or two users who
use that card in his/her rig as the main soundcard.

Edit:

thp wrote:

Would love to see if the SBMIDI integration works on real hardware with real synths 😀

No problem, I'll try soon! 😀 My CT1350B also has the CMS upgrade installed, btw. 😉

thp wrote:

background effect on the play area and disables the background effect on the quit yes/no selection screen.
Would love to see if the SBMIDI integration works on real hardware with real synths 😀

Hi again! Just checked, it works. I used my MT-32 for testing.
In the recording, only left channel is audible though, because I'm missing the second audio adapter. 😅
https://youtu.be/torFyYTsmXE

As far as I can tell, the new quit yes/no selection screen now works fine on my 10MHz 286.
Maybe it's also the OAK OTI-037c that in part causes the comparable slow graphics, too.
If someone else is willing to test the game on his/her 286, too, I'd be really glad.
IMHO, that game and its developer deserves a lot of testers. 😀

thp wrote:

Attached is Loonies r27, with these additions: […]
Show full quote

Attached is Loonies r27, with these additions:

• Support for SBMIDI on port 0x220 or 0x240 (selectable at startup)
• "Optimized" drawing loop for the background effects (might or might not help..)
• Slow/fast machine speed selection, which disables some expensive drawing

The slow machine speed mode enables line skipping in the intro sequence, disables the background effect on the play area and disables the background effect on the quit yes/no selection screen. Would love to see if the SBMIDI integration works on real hardware with real synths 😀

I just tried r27 on my 286 with AdLib -- and it simply hangs on startup.

Now trying r26. Give me a few minutes...

Nope, neither version works for me. I do not get anything. It just gets stuck in a newline on the DOS prompt.

Hi, I loaded EMU386 first. Maybe r27 contains one or two 386 instructions that makes it break on your 286 if it isn't loaded.

Edit: I added EMU386 to the youtube description. I forgot about it since I tested Loonies 8086 shortly before it. Sorry about that! 😦

Here's a 8086-compatible build (the "normal" builds are usually 80386 builds), r28 should work on any x86, and it should work without EMU386, maybe that brings some performance boost.

Did you set your MT-32 to map the channels so that the first channel is also used? I read somewhere that by default, MT-32 ignores the first channel and just uses the second channel onwards. But the in-game still seems quite slow, maybe this new build is better as it doesn't need EMU386, and with that potentially can avoid the slow emulation part of it.

I'm having a hard time figuring out how many cycles this program needs in DOSBox for operating at its intended speed. Since I have no reference all I can do is to fiddle around but it seems there is only a very thin line between too many cycles and painful slowness...
Will test on a real 486 DX-2 66 later this week but assume it is overkill for this tiny thing.

thp wrote:

Here's a 8086-compatible build (the "normal" builds are usually 80386 builds), r28 should work on any x86, and it should work without EMU386, maybe that brings some performance boost.

Did you set your MT-32 to map the channels so that the first channel is also used? I read somewhere that by default, MT-32 ignores the first channel and just uses the second channel onwards. But the in-game still seems quite slow, maybe this new build is better as it doesn't need EMU386, and with that potentially can avoid the slow emulation part of it.

Works: https://youtu.be/bj8e5vyqzSY

Feels a bit faster. I have a Vibra16 lying around. DB15 to MIDI cable is still in the mail. But when I get it, I will run it through my new SC-55.