IRF

Something else I've just thought of: the three images that Norman attached in the third post of this thread, were taken in the First Landing where the Air's INK and PAPER are both set to black. I believe that both phenomena would have been visible if the Air INK had been set to another colour. (N.B. It might be worth pointing out that the first of those three images was captured at the point when Willy is passing from the top third to the middle third of the screen. i.e. from the top half of the playing area to the bottom half). EDIT: I've just captured a screenshot, using my emulator's pause function. Please see the attached image, and in particular the Monk guardian. Hopefully you can see that I have replicated what Norman's previous images showed, in terms of the 'Jagger Finger' effect. i.e. the top part of the Monk's head and the upper part of his body have been moved on to the next animation frame, but his jaw and his legs haven't yet been updated (as per the previous discussion). Thus capturing a moment midway through the implementation of the LDIR loop which copies the graphic bytes from the Display Buffer to the actual screen. But because I have changed the Air INK to Red in First Landing, you can also see that the foremost pixels of the Monk (the tip of his long nose and the front of his belly) are drawn in Red INK. That's because he has just crossed a cell-column boundary, and the screen attributes haven't yet been updated to ensure that the cells into which the Monk is advancing is rendered with his Yellow INK.

One other point which I forgot to mention last night: both the Jagged Finger and Delayed Attribute Effects can be clearly seen if you are playing on an emulator and you pause the game using the emulator's pause function. That way, you can capture a 'moment in time'. However, if you pause 'in-game' by using one of JSW's defined pause keys (A-G), then you won't capture either effect, because the Main Loop only checks for pause keys being pressed after it has finished copying to both the Display File and the Attribute File.

Having thought a bit about the above, perhaps another check could be inserted just prior to the JR NZ, LOOP command: Copy L into A, apply an AND #0F, and if that sets the Zero Flag, then it's time to update the attributes for the cell-row under consideration. (N.B. the code to achieve that should be bookended by PUSH HL and then POP HL, to preserve the pointer to the lookup table at #8200). I'm not sure whether it would fit into those spare 16 bytes which Norman identified? (Which could be 18 bytes if you didn't need the JR 35366 / #8A26 at the end of the code which makes Willy run double-quick during the toilet dash.) EDIT: Actually, there would be another 11 bytes to play with (so 29 in all), since the function of the code at #8A26-#8A30 would have been performed instead by the new intervention. So it should be doable within the available space in the Main Loop - I might have a go at it when I get a moment. It would kill two birds with one stone - eliminate the 'Jagged Finger Effect' AND the 'Delayed Attribute Update Effect' (I'm still open to suggestions on the name for that one!)

I appreciate the order in which the screen lines are updated (thanks to explanations given in the past on this very forum by Dr Andrew Broad). I think where I failed was in my interpretation of what your previous diagram (the one with the red and black squares) was trying to represent. And possibly in my lack of knowledge of computer terminology. (I thought 'raster' was something to do with Bob Marley before I Googled it! :D ) EDIT: I think I've grasped what your diagram is showing now (having looked at the diagram on a bigger screen - I was on my tablet earlier). Please excuse my general ignorance! I'm just a humble EHO, dabbling in a bit of coding in my spare time!

I have thought some more about the above, and carried out some investigations. It seems to be a related phenomenon to the one which Norman has identified. PREAMBLE: For my investigations, I inserted several arrows of the same 'Guardian Class' into a room, in which I had assigned differing values for the Air's INK and PAPER settings. (Red INK on Cyan PAPER - both of which contrast well with each other, and also with the White colour of the arrows.) The effect described above was clearly visible, whereby an arrow's graphic bytes are drawn to the next cell along the arrow's path, in advance of that cell's INK setting being updated in the attribute file. This causes the arrow to flicker for the briefest of moments in red (the background's INK setting). Furthermore, the effect was much more pronounced for an arrow that fired along the top of the screen, than for one which traversed along the bottom of the screen. For two arrows which occupy the same cell-row, but different pixel-rows, the effect was more pronounced in the arrow that passed along the upper pixel-row. But within the same vertical half of the screen, an arrow in the top pixel-row of a cell-row at the bottom of the screen (row 15) displayed the effect more prominently than an arrow in the bottom pixel-row of a cell-row higher up the screen (row 8). This pattern is not surprising, bearing in mind the previous discussion about how the screen is drawn in JSW. The prominence of the effect is proportionate to the time delay between the arrow being drawn, and the colour-attribute of its host cell being updated. (With Norman's alternative screen-drawing routine in place, I suspect that the prominence of the effect would follow a simple linear progression down the screen, although I haven't checked that.) ****** This gives rise to the possibility of coming up with a further rearrangement of the code to diminish this effect, building on Norman's methodology. Could Norman's new code be modified so that the attributes along each cell-row are updated from the attribute buffer immediately after all eight pixel-rows for that cell-row have been copied from the display buffer? i.e. Pixel-rows 0-7 of cell-row 0 are drawn, and then the updated attributes are inserted across cell-row 0, before cell-row 1 is considered? EDIT: If such an approach were to be implemented and if you wanted to use the unused 'Screen Flash' routine [a relic from Manic Miner, where it is enacted once an extra life is gained] within a project, then the Screen Flash part would need to be reinserted in the Main Loop (to overwrite the PAPER colour of every screen cell in the secondary attribute buffer) before any of the screen (graphic bytes or attribute bytes) is updated during the Main Loop. ****** Incidentally, I gave the example of arrows because the effect (which we should probably think of a suitable name for) is most noticeable, since arrows are so fast-moving. But you can also observe it with guardians (especially fast-moving vertical ones) in rooms with non matching INK and PAPER settings for the background. See the Cyan Security Guard in the blue rooftop room 'I'm sure I've seen this before' - the top of the guard's helmet or its feet, at the point when those elements cross into a new cell-row - or the horizontal Green Bird in same room - watch its beak as it flies into a new cell-column. You can also observe the effect quite prominently when Willy falls through 'Entrance to Hades' (where the background has Green INK on Yellow PAPER). It isn't generally as noticeable with Willy whilst he is walking, because his sprite is quite narrow, and so his colour-attribute actually moves forward in advance of the inked-in part of his sprite. (That's why he can perch on the edge of a block when it appears there is nothing underneath him supporting him.) But in 'The Nightmare Room', where Willy is in Flying Pig mode, his sprite is quite a bit wider than usual, so if you POKE the Air INK in there from the default Black to Magenta, then as it walks around you can sometimes catch the pig's snout turning pink (appropriately enough!)

Is that example drawing pairs of graphic bytes, vertically-paired? If so, I don't think that's what happens? Except (sort of) during the transition from the top half of the playing area to the bottom half - the bottom pixel-row of character-row 7 is drawn immediately before the top pixel-row of character-row 8. When I said "pairs of graphic bytes", I was referring to a byte from the left half of Willy's sprite, followed by the adjacent byte from his right half.

I can't get the file which you uploaded to work. But thanks to the disassembly which you also provided, it should be a relatively easy task to insert the alternative 'screen-drawing regime' myself into a test file to check it out. :) ****** I think I've got my head around how it works... Considering Willy's sprite (although the effect is also manifested in moving guardians): In the original code, pairs of Willy's graphic bytes are drawn in the following order when he is cell-row aligned: 1st pair of bytes [top of his hat], 9th pair of bytes, 2nd, 10th, 3rd, 11th, 4th, 12th, 5th, 13th, 6th, 14th, 7th, 15th, 8th pair of bytes, 16th pair of bytes [bottom of his feet] This is further complicated when his sprite isn't cell-row aligned (when he is climbing a ramp/jumping/falling/on a rope). e.g. at times when he is exactly half a cell-row (four pixel-rows) out of alignment with the screen cells (such as when he's fallen downwards by one increment off a platform), then the pairs of Willy's graphic bytes would be drawn in the following order: 5th, 13th, 6th, 14th, 7th, 15th, 8th, 16th, 1st, 9th, 2nd, 10th, 3rd, 11th, 4th, 12th. ****** Now, with Norman's fix in place, Willy's sprite is simply drawn a pixel-row at a time [along with the rest of the screen, but I'm just concentrating on Willy here] from top to bottom, regardless of how he is aligned within the cell-rows: 1st, 2nd, 3rd, ... 15th, 16th Is that right?

Doesn't Andrew Broad use something called SPECSAEIE or something, for this purpose?

There's a bug in the 'Cycle the colours' routine (#8AEB): - If you pause the game in 'To the Kitchens...Main Stairway', the non-flashing Conveyor starts flashing once the screen colour cycling effect starts to take place; - Conversely, the normally flashing room elements in 'Nomen Luni'/'Under the Roof' (i.e. Earth blocks in the former, and Fire cells in the latter) stop flashing whilst the screen colour cycling effect occurs when you pause the game. Richard (SkoolKid) has come up with a simple fix: insert an AND #B8 command prior to the ADD A, #18 at #8AFA. For it to work properly, that needs to be followed by the existing AND #B8 at #8AFC, and so two additional bytes need to be squeezed into the routine. The easiest way that I can see is to insert a CALL at #8AF9-FB to elsewhere (somewhere with six spare bytes). Then at the new location, have: LD A, (HL) AND #B8 ADD A, #18 C9

Fair enough, it was more of a 'wondering out loud' type question. It's just that I haven't observed the issue occurring on the online emulator (QAOP) that I tend to use most of the time. Then again, maybe I haven't trained my eye to look for it? I have noticed the separate issue whereby the screen's display file is updated slightly before the attribute file. This is most noticeable in rooms where the background's INK and PAPER settings are different, and fast-moving elements traverse the screen. e.g. arrows in a room with a rope, where it manifests itself in the arrows flickering in a different colour to the usual white (in that example, the arrows would be seen for the briefest of moments in the same colour as the rope).

Does the extent of the problem depend on which emulator you use?

Well #9590 resets the minute counter to zero, so you could put some code after that which gets the thing you want to happen to occur when the minute counter to #FF. That make it recur EVERY minute though, depending on what it is?

Indeed, how would you know that it looked like [resembled] a game which you haven't seen (because it didn't happen!) :D

The way Mickey has it set up is that you have to enter a correct code on the first occasion to get through, if not then you are asked a second time for a code, and that time it will let you through whatever you input. I think that's a good compromise which still keeps the Code Entry facility (you can enter a correct code first time round if you want to), but without inconveniencing the player if they don't have the Code Sheet handy. :)

Or the simplest way to achieve Brightness consistency would be to make the Blue and Red numbers on the left (1 and 2) non-Bright - the opposite of Andy's fix!

Although for consistency, shouldn't the coloured squares on the right be printed with Bright Flashing PAPER colours? http://skoolkid.github.io/jetsetwilly/asm/873C.html POKE #879D, #48 POKE #87A3, #50 POKE #87A9, #58 POKE #87AF, #60 (Sorry the POKES are in hex - I can't work in decimals any more!)

Another possible idea here Mickey: http://jswmm.co.uk/topic/293-keypad-graphics-bright-bug

I've never noticed that before. The original images (with two Bright, two non-Bright) can be seen here: http://skoolkid.github.io/jetsetwilly/asm/9B00.html I wonder if Metalmickey might want to tweak this in his 'as manufacturer intended' project?

Actually, the Main PV routine in later* Geoff Mode games is called from #89F2, with earlier calls to other routines shifted upwards (space is made in the code because the CALLs to the original Master Bedroom/Bathroom special code is actually enacted via patch vectors for those rooms). [* In earlier Geoff Mode games, the Main PV routine is called at the point where the Master Bedroom/Bathroom special code was originally called from, which means that the routines to Draw guardians/animate the conveyor/Draw items actually comes after the Main Loop PV is enacted in early games. Not ideal if you want to have special effects involving those elements, as Geoff presumably figured out in time for his later games.] Another step which you omitted to mention there, Danny, would be to edit the 'Kill Willy' routine at #90D6 so that the jump back into the Main Loop at the end of that routine points at #89F8, instead of #89F5. Otherwise, if you have a Patch Vector in a room which edits the value of the Airborne Status Indicator at #85D1 (which is also used later in the Main Loop to tell the program to remove one of Willy's lives, if it holds a value of #FF), then it actually can prevent Willy from losing a life. (Of course, you could use that 'quirk' to deliberate effect...)

Perhaps Willy is under surveillance - the authorities are suspicious as to how he gained his new-found wealth?

I've since noticed that John Elliott came up with a similar method on Yahoo! to control the lethality, although not in the context of fixing the bug.

I like it just as 'Special Branch', which isn't just a geographical descriptor but has an alternative meaning in its own right (which might not immediately be obvious to a non native English speaker?) https://en.wikipedia.org/wiki/Special_Branch

Maybe you're right regarding the contrast with 'Under', Danny. I agree that there's no need for a comma. Another example would be 'On a Branch Over the Security Guard'... As for centralisation of the room names, I think the convention we used in TNE was that if there are an odd number of characters, then we placed it slightly left-of-centre (e.g. 5 spaces to the left of the name and 6 to the right if the name is comprised of 21 chars, etc).

Tiny detail: in terms of the capitalisation of room names, I wonder if the word 'over' in 'On a Branch over the Drive' should be lower case, as it's a preposition like 'in' or 'on'. (Of course, the 'On' in the room name is capitalised in that particular room, because it's the first word of the name.) Then again, your new room 'One Flew Over the Cuckoo's Nest' does seem right with 'Over' capitalised; perhaps because it's the title of a film? What do you think?