> > It was probably hardly used because the replayer didn't support it.
>
> One problem is that not all MBM files have the proper value filled in.
That's something we should in that case ofcourse avoid.
> > [about notes in MBWAVE]
> > > The problem may be that the file size would increase rapidly if you
store
> > > frequencies (2 bytes instead of 1).
> >
> > As if I care about that.
>
> 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).
> > It gives the composer more possibilities, and on a
> > somewhat slower system (which the MSX is imho) preprocessing can be a
very
> > good thing. 24 wave channels are really consuming lots of time... This
way
> > it can be lookup note, send it to OPL4, lookup next note.
>
> Precalculation is a good way to save CPU time, but it costs memory. For
> example Unknown Reality by NOP needs 256K because it uses so many
> precalculated tables.
Ofcourse there's a limit. But I think it's really useful (especially in the
case of such a terribly-slow MWM replayer) to do some concessions on space
to speed.
(...and this probably isn't correct English...)
> > > In the Almost Real Copper Bars part, the music is played MSX-AUDIO
only if
> > > you have both MSX-AUDIO and MSX-MUSIC, otherwise the replayer would
take
> > > longer than the V-blank period.
> >
> > :) Well I also need the V-blank period so... shriek...
>
> In a game, you'll probably want to play music outside the V-blank. But if
> you program a demo that uses line interrupt effects (more accurately:
> raster effects), you need all the CPU cycles outside the V-blank period
for
> the demo effect.
Yes.
> > By the way, I would really like to see someone actually starting to code
the
> > editor instead of only all this talking. Otherwise, at some point the
> > discussion will be kind of over (not in the near future though, seen the
> > amount of messages on this topic :)), and it will be forgotten...
>
> I'll try to code something in the near future. Although I am pretty busy
> (study and MCCW), so it may take a while.
Okay. Just wanted to hear that.
> > > I always load to #8000. I think there was a reason for this, but I've
been
> > > doing it for so long, I can't remember why I started.
> >
> > Terrible. Bad, bad habit.
> > Moving 16k takes up an awful lot of time (it is even noticable!).
>
> I never move 16K. If it's 16K, you don't have to move it, simply load it
> into the right mapper page directly.
Well, anyways, it's useless to do it indirectly if it can be done directly.
> > > Not run-length... SQueeZe!
> > >
> > > My own variation on the POPCOM algorithm. It gets very good
compression
> > > ratios. Sometimes better than GIF. It's based on storing repeated
patterns
> > > as "offset -x, length n" references.
> >
> > Is it fast?
> > Gimme info about it (private?).
>
> SQueeZe is faster than POPCOM. I think it is almost as fast as RLE.
Loading
> plus decompressing a SQueeZed file from floppy is usually faster than
> loading the uncompressed version.
Yes, that's indeed probably true... Less data to load...
Sounds good.
> > Besides, the same limit also goes if you use scripts. Do you think
> > theengine will have even anything to do with the word 'fast' anymore if
you
> > start reading (and animating) the palette (and a lot of other things)
right
> > from the script? Yuk....
>
> I don't see any performance problem.
>
> 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.
> Executing a script can be done very fast. A simple way is to store
commands
> and parameters. The command is stored as a pointer to the routine that
> handles that command. The parameters depends on the command. When a
command
> routine is called, HL points to the parameters. When the command routine
> returns, HL should point to the address after the parameters (where the
> next command pointer will be).
The speed difference is the difference between interpreting and compiling.
See chapters MSX-Basic and Kun-Basic.
Your small example didn't handle the interpreting, which is unnessecarily
slow.
~Grauw
--
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<
email me: [EMAIL PROTECTED] or ICQ: 10196372
visit my homepage at http://grauw.blehq.org/
>>>>>>>>>>>>>>>>>>>>>>>>><<<<<<<<<<<<<<
****
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
****
