On Mon, 05 Jun 2000, Laurens Holst wrote:
> > If the size of the song exceeds 16K, fitting MBWAVE music in a 128K game
> > will become very hard. And maybe 2 bytes is optimistic, it could be 3
> > (because you also have to store the sample number).
>
> It will greatly decrease the replayer-size, resulting in some extra space.
> Also, I think that if the music data is formatted the right way, it
> shouldn't be too large. I don't know exactly how MB did it, but I bet it can
> be done better. What I recall from KousTracker is that the musics really had
> to be extensively large before they would exeed 16k (in fact, they even
> couldn't exeed 16k).
What about pitch bends? Are they easy to store as operations on the last
played frequency? If not, you'll have to store a frequency every step of
the pitch bend, which costs a lot of memory.
> > A palette animation will never be executes more than the screen refresh
> > frequency, which is 60Hz maximum. Most palette animations will probably be
> > executed only about 20 times per second.
>
> Maybe this doesn't go for palettes, but it does for other things. And you
> have to be consequent... Everything in the script, or nothing in the script.
> Scenarios like the palette in the script but that outside and something else
> inside again but that and that outside it are very unwanted.
I want to be consequent: put everything into the script.
A game that only uses the built-in features of the engine should be able to
function with a script only, no additional code. I think this is possible,
but I haven't made a complex game yet, so I cannot be certain.
Ofcourse, if you want to add features to the engine, you'll need to add
code to the engine itself. This could be implemented as plug-ins to the
engine. There are advantages to plug-ins over changing the actual engine
code:
1. You can release the plug-ins for other people to use in their games as
well.
2. When a new version of the engine is released, your plug-in will fit
right away, while modified code would have to be integrated with the new
engine.
> Your small example didn't handle the interpreting, which is unnessecarily
> slow.
It isn't. Here is a script interpreter:
scriptLoop:
;push return address
ld de,scriptLoop
push de
;call command routine
ld e,(hl)
inc hl
ld d,(hl)
inc hl
push de
ret
By the way, it is possible to compile a script, but while you gain some
speed, you lose on memory. Since the game script is used for relatively
large execution units, its performance is not as critical as parts of the
engine that are executed more often.
Bye,
Maarten
****
MSX Mailinglist. To unsubscribe, send an email to [EMAIL PROTECTED]
and put "unsubscribe msx [EMAIL PROTECTED]" (without the quotes) in
the body (not the subject) of the message.
Problems? contact [EMAIL PROTECTED]
More information on MSX can be found in the following places:
The MSX faq: http://www.faq.msxnet.org/
The MSX newsgroup: comp.sys.msx
The MSX IRC channel: #MSX on Undernet
****
