Reversing to Orion - project 1oom

[Juffos]

I also find it interesting, that running the game with orion.exe from 1.40n has the scout and colony ship refits premade but 1classic.exe doesn't. I suppose these designs are coded right into the .exe? (remaking the exact same scout design reduces the cost from 10bc -> 8bc and the colony ship from 600bc -> 570cm, though the coloship is 591bc in 1classic.exe)

[1oom_aaron]

Project coder replies:

I made this video to showcase my findings - the music just doesn't seem to work.

Any particular reason for using the DOS version of 1oom? One of the biggest points of this projects is to get rid of DOSBox.

The music in the video does sound a lot worse than what I hear in my Linux setup. Sounds a bit like the drums are cut short (wrong note off velocity?) and maybe some pitch bend wonkiness. I'll take a look at those and looping. Anything else I'm missing?

EDIT:
Turns out to be two MIDI delay en/decoding bugs from times way before v0.1. Took only 4 months for anyone to notice. Fixed in v0.7-2.

1oom does not care about the configuration made with INSTALL.EXE. The allegro.cfg file has some sound options.

I also find it interesting, that running the game with orion.exe from 1.40n has the scout and colony ship refits premade but 1classic.exe doesn't. I suppose these designs are coded right into the .exe? (remaking the exact same scout design reduces the cost from 10bc -> 8bc and the colony ship from 600bc -> 570cm, though the coloship is 591bc in 1classic.exe)

1oom replicates v1.3 out of box, but provides some optional fixes. See doc/pbxin_fixbugs.txt for this one (and others).

[Juffos]

I used dosbox just to see if I could get GUS to work easily with this.

I did some additional, more precise testing with the ticksperq as requested, and it seems like that the main menu theme is most accurate to the DOS original with 54. However, this only applies to the main menu as far as I know - testing showed that both the planet colonization and hostile Mrrshan would be accurate with 87.5 (87 too slow, 88 too fast), which would make most of everything speedcore.

[1oom_aaron]

The project coder replies:

I used dosbox just to see if I could get GUS to work easily with this.

As a former GUS user I can kind of see the point. Would have loved to have that hacked snddrv.lbx some 23 years ago...

The troubles with the DOS version are:

• no mouse wheel support
  
• -uiscale is (likely) limited to 2
  
• all those precious CPU cycles going to waste
  
• no development builds
  

I did some additional, more precise testing with the ticksperq as requested, and it seems like that the main menu theme is most accurate to the DOS original with 54. However, this only applies to the main menu as far as I know - testing showed that both the planet colonization and hostile Mrrshan would be accurate with 87.5 (87 too slow, 88 too fast), which would make most of everything speedcore.

Was this with v0.7? The music fixes done in v0.7-2 (and -13) affect all the timings. Please test again with v0.7-2 v0.7-13 or newer.

If you can only test DOS for some reason, please say so and I'll upload a test build somewhere. Having automated development builds for the MSDOS version is a rather tall order but I can try to arrange it if there is enough interest.

EDIT:

It seems that dropping the MIDI events for tempo changes fixes things. v0.7-13 adds the option xmid_tempo which controls how the events are handled (0 = drop, 1 = keep (v0.7-12 and older behaviour), others = set specific tempo).

Please test if this fixes things and if it still works in the Windows version. The correct ticksperq value needs to be determined too.

1oom_lbxview can be used to play the tunes. To test MOO1, copy orion.exe to foo.exe, edit foo.exe offset 0x5f59 to select the tune played at main menu (default value is 1) and run foo.exe.

Suspicious tunes: (music.lbx index)

• C (ground battle win/lose?) changes tempo near the end
  
• 20 (Sakkra neutral) changes tempo a lot
  

I hope v0.7-13 is sufficient and no tempo conversion code is needed. I've attached a MSDOS dev build just in case.

[Juffos]

The testing was done with v0.7-12win32.

v0.7-13 seems to balance the tempo between different tunes. The best ticksperq I discovered was 60, it differs the least from the original. Some of the tunes, such as military tech discovery and galactic election, seem to have samples cutting out prematurely ingame.

Your devbuild page is down for me, so I had to use the one you attached, which is DOS.

[1oom_aaron]

The project coder replies:

v0.7-13 seems to balance the tempo between different tunes. The best ticksperq I discovered was 60, it differs the least from the original. Some of the tunes, such as military tech discovery and galactic election, seem to have samples cutting out prematurely ingame.

Thanks for the report! I'll set ticksperq to 60, remove the xmid options and see what I can do about the too short notes.

Your devbuild page is down for me, so I had to use the one you attached, which is DOS.

Sorry about that. The page is hosted by a generous individual. I have no control over it.

EDIT:

Fixed ticksperq to 60, removed the options and fixed a stuck notes on looping bug in v0.7-15.

I can't reproduce the prematurely cut out samples problem. I can't hear it (which doesn't say much) and I can't see it when comparing MIDI files produced by MOO1 DOSBox General MIDI output capture and 1oom_lbxview Shift-Enter. Does it happen only with the DOS version, and if so, what is the emulated sound card and what does 1oom_log.txt say about it? Does the problem persist if you get the MIDI file with 1oom_lbxview and play it outside DOS?

[Juffos]

Happened with the DOS version, I cannot test the win32 unless you attach it or the devbuild page returns. Log file says:

Audio: Sound Sound Blaster 16: SB 16 (22727 hz) on port 220, using IRQ 7 and DMA channel 5
Audio: Sound 16 bit, 22727 Hz, 2 ch
Audio: Music DIGMID: Software wavetable synth

The problem doesn't exist outside the game or 1lbxview - playing the midis with either playmidi.exe from GUS or foobar2000 with sc55 soundfont the samples work fine. Could the problem be within the soundfont the game uses and thus actually a feature?

I will attach an image to clarify the issue - you should see how the samples cut out during the 10-20 seconds part.
Since I cannot attach the audio files, tell me if you wish to have them uploaded somewhere else.

Also an unrelated matter - seems like my dosbox freezes at cwsdpmi.exe each time I try to run 1oom or 1lbxview after running 1lbxview, no idea why.

[1oom_aaron]

The project coder replies:

Happened with the DOS version, I cannot test the win32 unless you attach it or the devbuild page returns.

I'll ask the host. Attaching builds is unsustainable and I really dislike that non-members are not allowed to download them.

Audio: Sound Sound Blaster 16: SB 16 (22727 hz) on port 220, using IRQ 7 and DMA channel 5
Audio: Sound 16 bit, 22727 Hz, 2 ch
Audio: Music DIGMID: Software wavetable synth

Seems that it's using some (DOS) software synth for music. Try editing allegro.cfg to force it to use the emulated MT-32, MPU-401/General MIDI or (shudder) Adlib.

The problem doesn't exist outside the game or 1lbxview - playing the midis with either playmidi.exe from GUS or foobar2000 with sc55 soundfont the samples work fine. Could the problem be within the soundfont the game uses and thus actually a feature?

The DOS version autodetects the sound card unless something is set with allegro.cfg. That DIGMID must be broken. No idea what it is or why it is selected.

The non-DOS versions use whatever the platform SDL_mixer uses, with the added option to select a soundfont (which may or may not affect anything based on platform).

The game itself does not use any specific soundfont but relies on the supporting libraries to do their thing. I'm not going to debug DIGMID.

Also an unrelated matter - seems like my dosbox freezes at cwsdpmi.exe each time I try to run 1oom or 1lbxview after running 1lbxview, no idea why.

Perhaps it leaves VGA to a funny state after using 320x400. Not going to debug that either. I've wasted way too much time on the DOS version.

Thanks for the report!

[Juffos]

Seems like copying the empty allegro.cfg into the game folder made it freeze. Game started working with proper music as well by enabling MPU from the .cfg. Attempting using the GUS patches with DIGI enabled results in silence. I wonder if it's related to the "cannot open swap file cwsdpmi.swp" I am getting each time I run the game - the patches take 11mb?

It definitely is - I fixed the swap file issue with cwsparam.exe (problem was it trying to write the file into c:\, which isn't mounted in my dosbox) and now attempting to load GUS patches results in the same previous cut-offy sound. Oddly though downloading a customized GUS patch set .dat from the liballeg.org site and pointing the allegro.cfg to it results in silence once more.
Oh well, it was a fun try.

[1oom_aaron]

The project coder replies:

I think there's a memsize option in dosbox.conf. Increasing that should avoid swap trouble. The .dat support may be a feature that was added after Allegro 4.2 (the last one for DOS). Shame that there's no real GUS support. Oh well, problem worked around and music conversion fixed.