original-music version of CustLemm now available

Started by ccexplore, August 22, 2005, 11:51:19 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ccexplore

in fact, maybe it's easier if you instead just write a batch file to do the job, something like this

copy %1 levelpak.dat
custlemm.exe

If the batch file is called, say, custlemm.bat, you can launch it like this in DOSBox

custlemm.bat mypack.dat

[note: you need the .bat since there's already a custlemm.exe.  Or you can choose to rename custlemm.exe to something else]

And it will run the batch file, which copies mypack.dat over to levelpak.dat and then run custlemm.exe

DOSBox should support batch files.

Mindless

I guess that'd work too.  It's much simpler...  B)

Mindless

Quote from: ccexplore (not logged in)  link=1124711479/0#11 date=1124759380Well, that's what I heard anyway, that the unknown is used to indicate SuperLemming status.  I'm not sure if I ever verified it myself.  But in any case, CustLemm does not support SuperLemming, so I plan to use it instead to support indicating which music the level designer wants.
Just tested this and CustLemm does support SuperLemming... just set the first unknown byte to 0xFF, and SuperLemming mode is enabled...


Mindless

Modplug has MIDI capabilites, but they're rather hard to use...

finlay

Quote from: ccexplore (not logged in)  link=1124711479/0#6 date=1124742463
No.  I actually have no idea yet how the game decides which music to play.  However, it does keep track of the currently played music in a fixed location in the game's memory, and I did locate the piece of code that actually makes the "play this music" call passing in that memory location.

The plan is to change it to look instead at a memory location within the level data itself.  Specifically, the level data has 2 bytes that aren't currently used in CustLemm as far as I can tell, namely the one that marks the level to use Superlemming vs. normal speed.  The plan is basically to store the music track in that location.

Why don't you implement it in the double-byte next to it which is for the special graphics levels? Or can they be used in CustLemm? And then you could reimplement Superlemming speed! (which may be a slight problem, cos I think lemedit puts something there which, when I imported levels into Mac ONML, makes them go at superlemming speed)

or maybe i'm talking crap...

geoo

Superlemming mode does work.

One of my levels uses it, my pack will be released soon.

EDIT: You could use the second of those bytes I think, as far as I tried it out Superlemming mode already works when only the first of these bytes is set to FF.

ccexplore

Quote from: finlay  link=1124711479/15#20 date=1128271397(which may be a slight problem, cos I think lemedit puts something there which, when I imported levels into Mac ONML, makes them go at superlemming speed)
Yep, the bonehead that is the author of LemEdit put the LemEdit version number into those 2 bytes.  It didn't seem to have an effect in CustLemm despite its support of SuperLemmings according to Mindless, but it's quite possible that Mac ONML checks the bytes differently (eg. check for 0 vs. check for FF).

I suppose I could try hacking CustLemm to leave those 2 bytes as 0s, although it's probably easier if you just use a hex editor yourself to fix it.

ccexplore

Quote from: finlay  link=1124711479/15#20 date=1128271397Why don't you implement it in the double-byte next to it which is for the special graphics levels? Or can they be used in CustLemm?
You can use special graphics in CustLemm (in fact, I even made a program allowing you to create your own special graphics for CustLemm use).  But I think only 1 of the 2 bytes reserved there are actually used.

Anyway, it's simple to change which bytes to use (and thanks all for the valuable information on this), the reason I haven't finished this yet is because I wanted to first finish a few more MIDIs Ahribar requested.

Mindless

Quote from: ccexplore (not logged in)  link=1124711479/15#22 date=1128286898
Yep, the bonehead that is the author of LemEdit put the LemEdit version number into those 2 bytes.
:D  I always wondered if LemEdit was putting random data in there, I didn't know it was the version number... that explains a few things...