Moonblaster is full with 'easy solutions' as well... (though a few less than FST )

I like easy solutions

Quote:

Additionally I'll just say that "OR A, JR Z NEXTCH" 'trick', although the most common, is a slow solution

Well, if you can tell me what could possibly be faster than "OR A, JP Z"??? I'm very interrested...

for example, the opl4 replayer in bombaman has support for 16 and 24 channel musics (and any other number, actually). I could simply have the replayer do the "OR A, JP Z,blaat" "trick", but not having to do that trick saves more time Since you know the number of channels, you can do less iterations. Plus, in this case I even optimized the mwm files to save 16 bytes per pattern in 16 channel mode, allowing the replayer to decompress less data

That's right, Arjan

And, there are even solutions for channels that aren't playing at the moment, but will play later in the song, and so-called 'empty steps'.

Sure, OR A JP Z is the fastest solution for the algorithm in which you check each step for data. So what you can do to make it faster is change the algorithm

In a editor environment, it's not that easy to change the algorithm. You have to check each step for data. But who cares as long it's fast enough? Playing music data is the only thing it has to do... I wouldn't use it for games, though.

Moonblaster does use the oraljpz trick, afaik. But why doesn't the moonblaster replayer just play the crunched data? Why decompress it first?

And using less iterations (and thus less channels) is cheating The oraljpz trick is used for empty steps on channels that will be used.

Quote:

In a editor environment, it's not that easy to change the algorithm. You have to check each step for data. But who cares as long it's fast enough? Playing music data is the only thing it has to do... I wouldn't use it for games, though.

Sure that's a possibility for an editor environment, but the whole point of this discussion is that we (the MSX scene) need a FAST and CAPABLE player for games and demos.

So the solution is: slow player for inside the editor (save in EDIT format), fast player for finished songs (save in USER format).

This would work for Meridian too. In fact, you could even write a convertor for the moonblaster format to something that's able to be played faster. But the question is: do you want to keep bolting stuff onto a inherently inflexible program, or do you want a completely new and flexible program.

To me both Meridian and RealFun could be that new and flexible program with fast players suitable for games and demos.

What do YOU want, Sjoerd?

Quote:

Moonblaster does use the oraljpz trick, afaik. But why doesn't the moonblaster replayer just play the crunched data? Why decompress it first?

Because 'stepbuf' is specified to contain the step being played. Playing the crunched data directly adds a few problems to demos that read the 'stepbuf' for say, music analyzers (equalizers, whatever), etc...
Ofcourse any programmer not wanting to use the 'stepbuf' himself can reprogram the player to play the crunched data directly. It's not that hard.
I'm not convinced that would speed up anything though...

Don't forget you have to push/pop lots of registers when using decrunched data directly. Also, at some point you have to stop optimizing the code, unless you want to sacrifice too much readability, maintainability, changeability etc. At least using another (de)compressing for the data is a lot easier now.

Quote:

Sure that's a possibility for an editor environment, but the whole point of this discussion is that we (the MSX scene) need a FAST and CAPABLE player for games and demos.

I knew I was missing the point But don't worry, the Realfun replayer will be fast enough. I'll even include the replayer I intend to use for my own gameprojects (No need to keep those things to myself ).

Quote:

This would work for Meridian too.

And for Moonblaster. Why haven't anyone made a new replayer, with moonblaster-to-replayer-format converter? I for one would never even consider to use the moonblaster replayer, or even my own Realfun-format for use in games. OTOH Moonblaster is used in lots of games, so it may be fast enough after all

Quote:

Why haven't anyone made a new replayer, with moonblaster-to-replayer-format converter? I for one would never even consider to use the moonblaster replayer, or even my own Realfun-format for use in games.

Well, Arjan made a highly optimized moonblaster replayer, and IC is working on optimizing it too, coz it's too slow!!

Quote:

But don't worry, the Realfun replayer will be fast enough.

Quote:

OTOH Moonblaster is used in lots of games, so it may be fast enough after all

These are confusing statements (what else is new :\ )...

'fast enough' is a relative term. Almost anything is fast enough for Tic-Tac-Toe, but for high-action games like shoot'em-ups you need a really really fast player.

I guess we'll just have to wait for what you come up with, and see if that'll be sufficient. :\

Quote:

Well, Arjan made a highly optimized moonblaster replayer, and IC is working on optimizing it too, coz it's too slow!!

Still, I prefer my own replayer. Also because all the music is written with Realfun, ofcourse.

Quote:

These are confusing statements (what else is new)....

Sorry about the confusion.
I meant: The Realfun replayer will be fast enough for tic-tac-toe, and the Moonblaster replayer is obviously fast enough for the games it was used in.

The Realfun replayer (the one called SIRR ) will be faster than the highly optimized moonblaster replayer Arjan made. (Uhm, as long as you mean the one that's downloadable from the bomba-site or so )
EDIT
Uhm, I think. The replayer I use for Hamaraja may be somewhat slower, but the data is crunched much better. The new Realfun replayer won't use a postion table per channel, so it will be faster.
/EDIT

Quote:

I guess we'll just have to wait for what you come up with, and see if that'll be sufficient. :\

It will be great. Raise the expectations! No, really. It will be fast enough.

Anyway. Is there anybody who thinks a limit of 32 voices or instruments is a problem? This is the total number of voices that can be used in a song. (In the trail version of Realfun you could use 32 4op, 32 2op and 32 wave voices.) How many voices do you use in mbwave?

Hmm .. depends on many things ..

Is it a problem to raise this number to 64 or 128 ?

Yes

Realfun uses two bytes per step, one byte for the note, and one for the command. All command should fit in the command byte, so taking 128 values for the voice change command leaves just 128 values for the other commands, like pitch bend and panning.
I think there's room for 64 voices, though. (90 in fact). But still, is it neccessary? And of course, the voicedata will take a lot of space. And it takes space for other commands...
On what does it depend? I don't think I have ever used more than 16 voices in a song.