RealFun

Pagina 4/12
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9

Van sjoerd

Hero (602)

afbeelding van sjoerd

06-08-2004, 01:15

I like easy solutions Smile

Van Sonic_aka_T

Enlighted (4130)

afbeelding van Sonic_aka_T

06-08-2004, 02:11

Additionally I'll just say that "OR A, JR Z NEXTCH" 'trick', although the most common, is a slow solution SmileWell, if you can tell me what could possibly be faster than "OR A, JP Z"??? I'm very interrested...

Van Arjan

Paladin (766)

afbeelding van Arjan

06-08-2004, 13:08

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 Smile 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 Smile

Van anonymous

incognito ergo sum (116)

afbeelding van anonymous

06-08-2004, 13:27

That's right, Arjan Smile

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 Smile

Van sjoerd

Hero (602)

afbeelding van sjoerd

06-08-2004, 13:55

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 Smile The oraljpz trick is used for empty steps on channels that will be used.

Van anonymous

incognito ergo sum (116)

afbeelding van anonymous

06-08-2004, 14:03

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?

Van anonymous

incognito ergo sum (116)

afbeelding van anonymous

06-08-2004, 14:10

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...

Van Arjan

Paladin (766)

afbeelding van Arjan

06-08-2004, 14:18

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. Smile At least using another (de)compressing for the data is a lot easier now.

Van sjoerd

Hero (602)

afbeelding van sjoerd

06-08-2004, 14:30

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 Smile 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 Smile (No need to keep those things to myself Tongue ).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 Wink

Van anonymous

incognito ergo sum (116)

afbeelding van anonymous

06-08-2004, 14:40

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!!

But don't worry, the Realfun replayer will be fast enough. OTOH Moonblaster is used in lots of games, so it may be fast enough after all Wink
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. :\

Pagina 4/12
1 | 2 | 3 | | 5 | 6 | 7 | 8 | 9