New Game: Laser Puzzle

[D3thAdd3r]

So it's not possible to store the different sections as different midi songs, and just start one when another finishes?

Two initial thoughts on it are the best I have.

It might be less work to remake it as a MOD, a total guess there, but MOD is essentially the format you stated with predefined patterns and tokens to indicate order/repitition of the patterns. OpenMPT can apparently import MIDI, and if some messing with quantification yields decent results, it could then presumably export to MOD in a format usable by the converter. I have not even looked if the code was ever added to midiconv, as Alec is the only one that has ever made MOD songs on Uzebox. The only plus here is that I am pretty sure the MOD player which is in the current kernel does what you want without modification/custom music player, as Alec had made some large songs fit in very little flash by this method. I have been meaning to look into all this for a while but never got around to it, so I am saying all that is theoretical at best.

The other idea you mentioned is clever, and I never considered that in all the years I have been saddened by the massive space music takes. I think it can work, and you would need to of course convert the songs sections without any -s -e tokens. Then you would need to check the kernel's song pointer to see where it was to do the repetition counting and redirection of the song pointer. I don't see any obvious complications with that except for possible some timing aspect. I do imagine the idea could be made to work, if MIDI->MOD conversion proved to be impractical. You probably just need to:

Code: Select all

extern const char *songPos;//from uzeboxSoundEngine.c 

and you have all the manual control of the kernel you need to pull it off. Probably just comparing it to the address of the pattern, and the address+sizeof(pattern) to determine where it starts and ends.

[Artcfox]

That kernel trick looks like it would be awesome! The original format of the song was a variant of MOD, and it took me three days to convert it by hand into a MIDI, so I could use MidiConv, and now I discover there was a MOD player in the kernel this entire time…

[Jubatian]

By the way did anyone look into FoaD's code? I implemented a radically different music format there, although a bit tedious one (just like everything in that game, lots of manual work involved). The in-game theme is just about 300 bytes! (Not that it was anything exceptional, after all it was about the first time I did any composing, but I think some more "sane" music would also be a lot smaller using this format)

For the solution check why didn't you just count the non-boulder / non-blank tiles the laser succesfully entered? (Or even better: why didn't you just count the non-boulder / non-blank tiles the laser didn't enter? You have a solution when this count is zero. As far as I see the laser only enters the tile when it has the right orientation, mirror capable to reflect it, target capable to receive it, so it seems like some property is already there which you would be able to count to determine whether the setup was a solution)

[Artcfox]

By the way did anyone look into FoaD's code? I implemented a radically different music format there, although a bit tedious one (just like everything in that game, lots of manual work involved). The in-game theme is just about 300 bytes! (Not that it was anything exceptional, after all it was about the first time I did any composing, but I think some more "sane" music would also be a lot smaller using this format)

I haven't looked at the code yet, I was just going for something simple.

For the solution check why didn't you just count the non-boulder / non-blank tiles the laser succesfully entered? (Or even better: why didn't you just count the non-boulder / non-blank tiles the laser didn't enter? You have a solution when this count is zero. As far as I see the laser only enters the tile when it has the right orientation, mirror capable to reflect it, target capable to receive it, so it seems like some property is already there which you would be able to count to determine whether the setup was a solution)

My motto was to keep it simple, and easy to verify against errors. Also, when I was experimenting with the photon simulation, I tried various numbers of iterations, before settling on 100. For a long time it looked like 10 would be sufficient, but when I tested the pathological cases that used multiple beam splitters arranged into loops sometimes the random numbers were chosen in such a way that every possible path wasn't drawn every time the laser was turned on. Checking against a hard-coded solution means that can never happen, and it allows me to display the solution for any level with the press of a button (which is only enabled in my debug builds).

[Jubatian]

I was just going for something simple.

The midi format and the related job of channel allocation etc. isn't something exactly simple, either (I didn't tamper with Uzebox's solution, but quite a while ago I implemented a midi player for the OPL-3 chip. The midi format can be a very nasty beast to cope with).

...every possible path wasn't drawn every time the laser was turned on.

I see that then it would arrive to "not a solution". I thought that your comparison involved the laser's path in the equation, but I now realize that the laser itself is just "eyecandy" (You can match the solution without actually checking what the laser is doing, that case yes, it is simpler. I assumed you needed the laser's path). I wouldn't think it exactly the right thing to do either is to eliminate the possibility of alternate solutions which you didn't think about (it would be a nasty experience for someone who thinks differently, and comes up with one, unaware of the intended hard-coded solution, then he would think the game was defective).

[uze6666]

So it's not possible to store the different sections as different midi songs, and just start one when another finishes?

The midi engine doesn't support that and it would not be so useful since all channels goes into one stream. so you'd have to repeat blocks will all 5 channels. That said, adding a callback when song ends could be done to help you do that, but you would have to make a block player top of the midi player.

If you are interested, I will finish the mod converter tool I made and commit it. Normally, the patterns are 64 rows x 5 channels but internally the converter chops them to 16 rows x 1 channel sub patterns. The converter then builds a global table of unique sub patterns across the whole song. If you craft your song accordingly, most repetitions of things like base lines and drums are eliminated and the size of the song is dramatically reduced.

Ideally it would nice to have a tracker that works like this (sub patterns), but alas, I could only find one for NES chiptune tracking.

[Artcfox]

So it's not possible to store the different sections as different midi songs, and just start one when another finishes?

The midi engine doesn't support that and it would not be so useful since all channels goes into one stream. so you'd have to repeat blocks will all 5 channels. That said, adding a callback when song ends could be done to help you do that, but you would have to make a block player top of the midi player.

If you are interested, I will finish the mod converter tool I made and commit it. Normally, the patterns are 64 rows x 5 channels but internally the converter chops them to 16 rows x 1 channel sub patterns. The converter then builds a global table of unique sub patterns across the whole song. If you craft your song accordingly, most repetitions of things like base lines and drums are eliminated and the size of the song is dramatically reduced.

Ideally it would nice to have a tracker that works like this (sub patterns), but alas, I could only find one for NES chiptune tracking.

Check out the MONOTONE tracker, that is how the repeated sections are (across all channels). A callback when the song ends would be awesome, as long as the more from the next section could be scheduled in time, otherwise I suspect some kernel hackery might be required.

This was my first experience with a MOD-like thing (my understanding is that .MON files are similar to .MOD, so I'm not sure if the converter program would apply. Had I known this existed, I would have tried that first though. That converter sounds pretty cool if it can break up sub patterns independently of channels.