On Sat, 03 Jun 2000, Laurens Holst wrote:
> > Look at the sample kit value in MBM files. I never used it to find the kit
> > file name in my own programs.
>
> Is it there??? Ahhh... If I had know it...
If I remember correctly, it's at offset #140.
> 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.
> > Source doesn't have to be assembly. You could use XML or a simple ASCII
> > format. Or use assembly with all macros so it is readable.
>
> Yeah, right. Do it yourself.
I will.
But let's leave the "where to store the palette" discussion sleeping for a
while. Once the structure of all the components (tile map, tile GFX,
script) becomes more clear, I hope to be able to give more concrete
evidence that storing the palette separately is a good idea. And if I
can't, then maybe it isn't a good idea.
> [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 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.
> > 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.
> 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.
> > 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.
Actually, I don't move much data at all, because I usually combine all data
in 16K blocks when creating the data files. Maybe a song is LDIR-ed, but
that's about 4K.
> > 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.
> 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.
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).
So a palette change is stored like this:
dw setPalette ;command
dw palette1 ;parameter: pointer to palette
dw playSFX ;next command
...
setPalette:
ld e,(hl)
inc hl
ld d,(hl)
inc hl
ex de,hl
call sendPaletteToVdp ;HL = pointer to palette
ex de,hl
ret
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
****
