Metalmickey

on the subject of cells, i feel we need to talk about the elephant in the room... or more accurately, ask people's opinion on it; the darker red water cells in Dr Jones Will Never Believe This look (to me at least) a little malformed, for those who have not noticed i have already made the 'corrections' in my most recent release. The attached shows the difference, the one on the left being the original...
 
 
 

I had thought of this a while back but did wonder if it was intended so as to make the blocks stand out as though the sun was shining on them ... on reflection (no pun intended) it would seem that this is another little 'bug' where the background colour was incorrectly set as black, I think it's worth putting in so i'll include it in my next version .. oh by the way, yes Ian i think i did make the correction to the flashing conveyor in 'To The Kitchen / Main Stairway' i think you provided a fix for it as, if my memory serves me rightly, it also had other effects elsewhere as the cells stopped flashing in 'Nomen Luni' when the game was paused

I had thought of this a while back but did wonder if it was intended so as to make the blocks stand out as though the sun was shining on them ... on reflection (no pun intended) it would seem that this is another little 'bug' where the background colour was incorrectly set as black, I think it's worth putting in so i'll include it in my next version .. oh by the way, yes Ian i think i did make the correction to the flashing conveyor in 'To The Kitchen / Main Stairway' i think you provided a fix for it as, if my memory serves me rightly, it also had other effects elsewhere as the cells stopped flashing in 'Nomen Luni' when the game was paused

That is an excellent suggestion. :) I was aware of what it would do but before I saw it "in action" I was not really aware of how much it does improve it.
 
For those who prefer it in decimal it is 62121 , 14
 
Here is an expanded 'combi' pic of before / after so you can see the Water cells clearly to compare:
 

 
Out of curiosity I took a quick look at the C64, Amstrad and BBC versions of this screen in JSW1 and all of those also have the same Water cell 'paper' colour as the background which matches this 'new change' :)
 
I was not able to confirm the MSX/Einstein variant however given its cell design I suspect that will have black paper due to the way it was 'built' from the Spectrum version at least as I understand it.

Regarding the 'loader space' , there are quite a few things you can do to save a few bytes, and these *do* add up quite well.
 
Let me provide some random examples, there are more but these may help, read them as 'before vs after'
 
PRINT AT 0,0 ; ... PRINT AT NOT PI, NOT PI;
 
LET A = 0 ... LET A = NOT PI
 
LET A = 1 ... LET A = SGN PI
 
CLEAR 28000 ... CLEAR VAL "28000" ...or... CLEAR 28E3
 
POKE 23659,2 ... POKE VAL "23659" , VAL "2"
 
FOR X = 0 TO 64 : PRINT " TEST " : NEXT X ... FOR X = NOT PI TO VAL "64" : PRINT " TEST " : NEXT X
 
GOTO 50 ... GOTO VAL "50" ...or... GOTO CODE "2" (use CHR$ value to figure this out, CHR$50 = Ascii "2") , obviously only works with some values but it can be a bit of a saver sometimes.
 
 
Variables seem a fraction faster in upper case, although I've yet to figure out why.
 
There are also some good ways of saving having to type border/paper/ink/bright/over/inverse/flash if you want to simply set the screen colours, it can be done in one or two pokes.
 
EDIT... Added a splash of colour. I'm happy to check out any bit of Basic (or part of) if you wanted me to suggest any 'space saving' , can always PM it or perhaps just copy/paste it rather than attach a tape file, either here or a PM if you only wanted a 'partial' thing.
 
Obviously you lose readability the more you do this and it can be annoying to try to debug issues too, but it does save quite a bit of space potentially. Try saving a tiny bit of Basic (then see how big it is) then save it again once you've 'adjusted' it. CLEAR recommended before save too.

as previously mentioned, rather than attempting to finalise this project and assume it to be complete, i've decided to just leave it as an ongoing concern (if that's the right word), i think that as long as this website continues to attract interest then someone somewhere will at some point be discussing an issue, oddity, quirk, bug within the game or some other point of discussion that perhaps i can look into tackling and perhaps improving somehow, for me this is good practice as it is helping me to understand assembly language which i am (very) slowly but (not so) surely beginning to get to grips with, i'm a long way from where i started but still a million miles from considering myself in any way competent, my next step now is to add a big chunk of info to the blurb, this will include all of the address changes to the game code. I am also developing BASIC loader that will convert the original version to the new patched version at the press of a key, the challenge here is of course to make it small enough to squeeze into the system memory without going into the game area, there are quite a lot of changes now....

as previously mentioned, rather than attempting to finalise this project and assume it to be complete, i've decided to just leave it as an ongoing concern (if that's the right word), i think that as long as this website continues to attract interest then someone somewhere will at some point be discussing an issue, oddity, quirk, bug within the game or some other point of discussion that perhaps i can look into tackling and perhaps improving somehow, for me this is good practice as it is helping me to understand assembly language which i am (very) slowly but (not so) surely beginning to get to grips with, i'm a long way from where i started but still a million miles from considering myself in any way competent, my next step now is to add a big chunk of info to the blurb, this will include all of the address changes to the game code. I am also developing BASIC loader that will convert the original version to the new patched version at the press of a key, the challenge here is of course to make it small enough to squeeze into the system memory without going into the game area, there are quite a lot of changes now....

peculiar, i just re-did that RZX for my own purposes and yet i can now quit the game during Willy's toilet dash ... although i am using SPIN now i can't remember if i created the RZX with it or Spectaculator, i know Spectaculator can create a few odd effects when making RZX files...

Interesting ... will implement that to the 'rebuild' i'm currently working on

painfully slow at present, still finishing rewriting the disassembly, not currently re-assembling properly, there's a load of typos to correct .. on the plus side i've now been able to make more detailed notes about all the potential free space in addition to what Skoolkid has documented

I never noticed that, i have changed emulators now, i'm using SPIN since i am re-assembling the game at the mo .. can't think of anything i have altered but maybe i've incorrectly copied over an opcode or something..

painfully slow at present, still finishing rewriting the disassembly, not currently re-assembling properly, there's a load of typos to correct .. on the plus side i've now been able to make more detailed notes about all the potential free space in addition to what Skoolkid has documented

Mickey, I've just spotted a minor bug in the JSW 'Game Over' routine - the 'AND #FA' at #8CAF should be replaced with 'AND #F8'.
 
This doesn't affect the original game, it's more of a 'game engine' fix, but it allows a full range of INK colour choices for the Barrel on the Game Over screen.  With the AND #FA in place, the choice of INK colour for the Foot/Willy can restrict the possible colours for the Barrel.

Would be worth trying to see. :D

I did read this but it did not quite "sink in" at the time. I have just watched the .rzx as I downloaded it at the time then had to go and sort something else out.
 
Anyway I see what you mean about the 'pig frames' vs 'willy frames' now. How odd as they are both 4 'each way' as such. There is code to force the sprite change in that room and a random guess would be as that is likely being checked constantly (otherwise he'd change sprite during play when you moved) then it is likely just overriding it.
 
The 'fast time' when in the toilet is also appreciated too. :)
 
I note that 'break' does not work actually *during* the 'dash' either, another useful change. The original does (I just tried this, do not recall ever having tried that before)

Danny's right, the protagonist is still only drawn using two of the four available sprite-frames if he is running for the toilet whilst in The Nightmare Room, although those two sprite-frames look more distinctive than the two Willy ones that are normally used during that stage in the game (which are identical except for being horizontally shifted).

This is controlled by the code at #8A00 to #8A0A.  I think I played around with that part of the code when I was attempting to laterally-invert the toilet dash for 'Jet Set Mini'.
 
If I recall correctly, I managed to get the code to use the other two of Willy's frames (legs together and legs wide apart), but then he wouldn't progress past a cell-column boundary so he got stuck on the spot!
 
I haven't tried this, but I believe the way to get this to work would be to relocate #8A00-#8A0A to sit in between the commands at #89D6 and #89D9 in the Main Loop. i.e. after Willy has been moved, but before he is drawn.
 
(Of course, that wouldn't fit in situ within the available space unless you did a lot of code-shifting, so you would have to CALL a subroutine, probably by displacing the three-byte command at #89D9, and then reinstating the command from #89D9 at the end of the subroutine, just before the RET.  And of course, NOP out the existing code from #8A00-#8A0A.)

See i think this is another type of bug, i guess if i was to resolve it, i would use the alternate frames where Willy's legs are completely together and fully apart, might make him look a bit like Mr Benn but i still think it would be an improvement .. i'm going to try an experiment...

Apparently this happens because frames 1 and 3 of the rightward animation are always used, and in the case of Willy they are exactly the same as far as graphics go (only moved within the 16-per-16-pixels sprite space), while in the case of the flying pig they are visibly different (wings up - wings down).
 
So I guess you're right that Willy's running ability could be improved, although I couldn't suggest an exact solution at this moment.

Whilst messing about with the DEFB value that changes the game status at  34271 i've noticed something odd.
As we all know, on completion and during his toilet dash his animation is limited so it looks like he's skidding or skating as his legs appear to be still, i'm guessing this is because the game code skips every other animation frame in order to double his speed .. but look what happens when we set DEFB to 2 (34271,2) whilst in the Nightmare room. Willy still travels at double the speed but his animation as a winged pig seems not to be affected by the frame skips... at least not in the same way ... his animation still only seems to be of 4 frames here so i'm wondering now if i can somehow improve his running ability when he is his normal self
Untitled114.rzx

Whilst messing about with the DEFB value that changes the game status at  34271 i've noticed something odd.
As we all know, on completion and during his toilet dash his animation is limited so it looks like he's skidding or skating as his legs appear to be still, i'm guessing this is because the game code skips every other animation frame in order to double his speed .. but look what happens when we set DEFB to 2 (34271,2) whilst in the Nightmare room. Willy still travels at double the speed but his animation as a winged pig seems not to be affected by the frame skips... at least not in the same way ... his animation still only seems to be of 4 frames here so i'm wondering now if i can somehow improve his running ability when he is his normal self
Untitled114.rzx

By the way, if anyone wants to use the improved game engine for their own projects they're welcome to do so and if it helps in some small way then so much the better  :)

By the way, if anyone wants to use the improved game engine for their own projects they're welcome to do so and if it helps in some small way then so much the better  :)

By the way, if anyone wants to use the improved game engine for their own projects they're welcome to do so and if it helps in some small way then so much the better  :)

True, but then that would somehow detract from the 'story' of the game, Willy collects all the items before heading off to bed, so if he was to begin his frantic dash for the lav at the bottom of the first landing then he would never make it into the bedroom, and besides, i think it adds to the challenge that he has to go to the Master Bedroom to see if Maria is still on guard...