Manic Jet Set Willy.

[Spider]

Thank you for the comprehensive explanation and your findings! @jetsetdanny

@Norman Sword , one thing I did mean to ask about actually, you mentioned the Attic Bug and said that with the previous to last version I'd not found it. I'm assuming this is still there to be discovered ? , I'd guess its not also going to corrupt the game fatally. 🙂

Again before I forget! , Conservatory Roof: Thank you for the small re-arrangement of the 'roof' to allow items to be collected without fatalities, as you said Matthew would of likely rectified this had it been noted at the time. I did actually take a look at JSW1 and JSW2 on at least half a dozen different machines to see how they dealt with this screen, my conclusion here was (there's a topic somewhere but its ancient) the majority either left JSW1 'as is' or used the JSW2 layout for the items/fire cells, the latter I did in the 'bug fixed' edition. I ought to redo that really as I'm much more versed in the intracies of it since then but I'll probably wait for @Metalmickey to see what he has planned for his "As manufacturer intended" variant first.

[Norman Sword]

Speed.

The routine that changes the speed, is self contained. It has no interaction with any other routine. This means that the game plays in exactly the same way, no matter what speed is selected. (apart from the obvious change in speed)

The Attic Bug.

The DATA and all the code listed in the skoolkit dissassembly of JSW, will if reconstructed give the original game. Which has all the known bugs (as released by Software Projects).

The starting point for Manic Jet Set Willy, was the listing I generated called RAW6JSW.asm (stored somewher on this site) Which can be assembled and create's the original game (with the attic bug etc) I edited this file and forgot that it had not been corrected to remove those bugs. And  as my editing progressed I started to experience strange errors and crash's. I assumed that those crash's were caused by the new code I was adding. Oblivious to the already installed bugs from the original code.  So I experienced the attic bug directly in my new code, caused by the original data. Once I realised the problem, it was easy enough to remove, along with the associated problems - invisible objects, multiple objects, uncollectable objects and the consrvatory death collecting objects. 

So the attic bug was consigned to the bin a long time ago (in this version). It is the primary reason that demo room flick throughs are written into the versions I write. 

Demo room flick through.

Matthew has told me he did not write a room editor for JSW.  So it is probable that the cheat code or the start room being changed was the primary means of testing out a new room. Unfortunately that, in the case of the attic does not alert the user to the bug that room creates. It allows you to see the room and play it, it allows the room to be jumped out of, and into. In the evolution of the JSW manor by Matthew it was just another room, drawn tested and forgotten about as the room count increased.

The idea of the demo room flick through is that it plays and activates all of the main sprites in the game, and keeps on activating them for as long as the game is run. It also checks so many aspects of the code, that it worth doing. Remember I was switching between two games and having a routine that kept on switching between the two games, showed up every change that I did when altering the graphics, ,sprite compaction, sprite order, sprite action etc. For those checks it was worth the effort of writing the routine. The version that was left behind, has had the sprite animation routines in the demo removed. And replaced with an  alternating screen redraw from right to left then left to right.

So no attic bug waiting to happen in Manic Jet Set Willy 

 

Edited January 10, 2022 by Norman Sword

[jetsetdanny]

4 hours ago, Norman Sword said:

Speed.

The routine that changes the speed, is self contained. It has no interaction with any other routine. This means that the game plays in exactly the same way, no matter what speed is selected. (apart from the obvious change in speed)

Norman Sword, if I understand your words quoted above correctly, you are saying that the game plays identically at all speeds, only the speed is different.

However, I am quite convinced that in my experience that one solar ray which sapped some money away when I was playing at the slowest speed did *not* appear when playing at a high/the highest speed, which is why my final money score when playing at the slowest speed was inferior to the other two scores.

I am not sure if the videos I uploaded before are viewable/can be downloaded (they now seem to be embedded but unplayable). I am re-uploading them below in a ZIP file. Please (@Norman Sword or anyone else) have a look at them (they are only a few seconds each) and let me know if I'm imagining things or if there really is a difference (the unavoidable ray at the slowest speed which doesn't appear when playing at a faster speed).

comparison.zip

[jetsetdanny]

Just to make sure we're on the same page:

This is the moment I mean, when Willy gets hit by the solar ray (when playing at the slowest speed). It's at 00:16.182 in the "Slowest speed.mp4" video.

AFAICT, this ray does not appear in the same position at the same moment of the game when playing at a fast/the fastest speed. Please have a look at the file "Fast speed.mp4" and tell me if you can see it there.

[A theory: This ray appears when playing at the slowest speed only for a split second. Perhaps with the game running at a higher speed there is no time for it to appear? Or perhaps it appears for such a minimal fraction of time that it does not affect Willy (does not exist for a time long enough to be able to affect Willy, so to speak)? Please disregard if it's a stupid theory 😄 LOL].

[Norman Sword]

When you posted the video's I went back to the code to see if it did interact with any other routine. 

Part explained else where, the speed routine is self contained, within the  normal sound routine. Its only variable is the speed. That variable is only used to draw the speed bar and set the duration of the sound. (either on or off) speaker being driven back and forth or silence via not altering the speaker state. The only exception being the fastest posible state that just drops through without bothering to toggle the speaker at all. 

No other routine reacts to the speaker state and therefore the delay.

Code wise it makes no change in the way a room or screen is updated (apart from the time between updates)

Having said the above, I will look into what is happening. It should be possible to duplicate the beam as displayed at any speed (ignoring willy and his interaction with the beam). Not something I will do tonight, but I will write a routine to freeze the beam at the exact frame shown above, and see if the speed does have an impact. I will be suprised if it does. More likely a variable not being set to a fixed state. But until I confirm one way or another tomorrow, any real change  is open to speculation.

 

Edited January 11, 2022 by Norman Sword
Repetition, Repetition, Repetition of text.

[Norman Sword]

I have not written or looked at any code yet.

When I turned my computor off last night, one of the images shown on my screen was the solar ray and its interaction with the screen sprites. That particular room has four horizontal sprites and 3 vertical sprites. The beam is seen deflecting off one of the horizontal sprites and zapping around the cavern.

The change from JSW to MM involves adding and removing sprite actions and tile interactions. I actually just added the new changes and left intact the old events. The game JSW has ramps that are not used in MM, rather than stop their action in MM the code is still run, but has little impact since ramps are not present. The tile count is increased to allow for collapsing floors, switches and extra nasties. The sprites have extra types added being Kong, Eugene and Skylabs. The actions of the sprites is also increased to allow for variable speed, immunity from collision, flashing and switching off completely. The original game clock is left running in both JSW and also in MM. In MM  an air supply is also added to display his remaining air. Trivial other changes take place such as a change in Willies definition. These changes do not affect JSW as the data is not present in the JSW rooms. In a similar way to the ramps from JSW in MM

In the solar power room the solar ray is switched on by the routine that also checks for the toilet in jsw and Maria guarding the bedroom. Those type of events being switched on and off, by the actual room number.

So what is changing in the solar power room?

As I stated at the start of this explanation I have not written any code or looked at any data. (yet) The image of the deflecting beam was enough to actually allow me to process through what is changing. 

The beam is deflected by a red "beam shover." (< a new name for the sprite) That sprite, I remember from when I wrote the code, is slightly different to the other 3  "beam shovers" In that it does not run at full velocity. The velocity is controlled by the clock. The clock is not reset between caverns in JSW or in MM and runs all the time. This does introduce a variable into the room that is changing from room entry to room entry.

Since the clock ticks with each and every game loop, the status of the "beam shovers" movement is affected by what value the clock is. 

Conclusion.

The entry into the Solar Power room is with a game clock that is changing as the rooms/caverns are being played. That change dictates what status the sprite movement is for slow moving sprites. This also means that any other room with slow moving sprites will also be affected. (Endorin forest, Attack of the mutant.., ore refinary etc)   The change is down to the exact time that the cavern is entered and will only set in action one of two possible room playing states. Nothing to do with the overall speed set for the game, but it is a function of the time on entering the room.

I have made a note of this feature and it could be removed (if needed) by a few lines of code. Which I could release sometime perhaps in December 2022.

=======================================

Since I now know what is setting up the change in playing state, I have little reason to write the code to freeze the game at the exact moment of beam deflection.  I will see if any enthusiasm exists to write the code when I eventually look at the code in my editor/assembler.

 

 

 

.  

Edited January 11, 2022 by Norman Sword

[Norman Sword]

Exactly as I predicted. The deflection is caused by the change in the game clock. 
Clock odd no deflection. Clock even beam deflects. No change via speed setting.

 

Edited January 11, 2022 by Norman Sword
Captions on pictures.

[jetsetdanny]

Norman Sword,

Thanks for all these explanations 👍. It's quite fascinating to go into this kind of detail about the game mechanics 🙂 .

If I understand your messages correctly, I was not seeing things, i.e. I indeed encountered a solar beam that appeared in one of my playthroughs but not in the other two.

Taking this into account:

> The clock is not reset between caverns in JSW or in MM and runs all the time. This does introduce a variable into the room that is changing from room entry to room entry.

> Since the clock ticks with each and every game loop, the status of the "beam shovers" movement is affected by what value the clock is. 

> The entry into the Solar Power room is with a game clock that is changing as the rooms/caverns are being played. That change dictates what status the sprite movement is for slow moving sprites. (...) The change is down to the exact time that the cavern is entered and will only set in action one of two possible room playing states.

Does it mean I could try to avoid the appearance of the solar beam when playing at the slowest speed by entering "Solar Power Generator" one tick of the clock earlier (or later) than I did in this particular case? In other words, by waiting one tick of the clock at the end of "Amoebatrons' Revenge" to enter "Solar Power Generator" one tick later?

[Norman Sword]

3 minutes ago, jetsetdanny said:

Does it mean I could try to avoid the appearance of the solar beam when playing at the slowest speed by entering "Solar Power Generator" one tick of the clock earlier (or later) than I did in this particular case? In other words, by waiting one tick of the clock at the end of "Amoebatrons' Revenge" to enter "Solar Power Generator" one tick later?

Yes. The visual feedback for the change would be miniscule. But it would change how the room plays. (swapping from one state to the other)

[jetsetdanny]

Thanks, I will definitely try to improve my recording of the game played at the slowest speed by taking advantage of this feature!  Will report back soon 🙂 .