andrewbroad

I used to have an Amstrad CPC 6128 (in addition to my 48K Spectrum and then Spectrum +2). I didn't have any MM/JSW games for the Amstrad, but I did have a brilliant platform game named Radzone.

Amstrad version of Jet Set Willy 2. 
 
The Amstrad(CPC) version of Jet set willy. Was written as Jet set willy, where the programmers decided to fix the weird layout of Jet Set Willy. By adding some extra rooms into the gaps of a neatly planned layout of jet set Willy. From the outset of  writing the game on the amstrad(CPC) it was decided to use a very simple run line compression. The compression was added to a room designer written on the CPC. This was written in a few lines of basic. Each designed room was then output in  compressed form. As a set of data statements and sent via an RS232 link. The RS232 link was via  a z80dart connected to the CPC. The receiving Machine was a Tandy model 4. All rooms received by the tandy model 4 from the CPC were of the compressed data.  Any room that needed to be edited was either re-drawn or the compressed data was hand edited.
 
This data and the code that was written for the cpc was the basis of the version released on the Spectrum called JSW2 the final frontier. The room data is an exact copy of the CPC data with editing of that data to change the way the spectrum uses colour compared to the CPC four colours.
 
 
At a later date. After JSW2 was released on the zx spectrum. A need arose for the CPC to have a version that was more inline with the other versions of JET SET WILLY e.g. only had 60 rooms.
 
This was necessitated for the release of "they sold a million" compilation tapes. Which had been released on other machines, and a version was planned for  release on the CPC.  For the "they sold a million" version on the CPC it was decided to remove all the extra rooms and leave the game with only 60 rooms. This later version on the CPC was released in the compilation "they sold a million" on the CPC.
 
 
The net result is that the data for both CPC versions are very similar to the spectrum version of jsw2. And all are compressed with that simple run line encoding. Written in a couple of lines of CPC basic.

Reading about the death of Ian Holm, it just occurred to me that the word "hobbit" matches the H***** pattern, but it's not that.

That is wonderful that you are working so hard, Norman, on Manic Panic. The programming insight is very interesting too,
even for non-programmers it is good I think to read about the technical aspect of writing games, here at the lowest level
of programming often.
 
I also like the story you have come up with for Manic Panic, the whole revisiting the original excavations, I think that is a good
addition in terms of being authentic - what is that slightly preposterous phrase they use for Star Wars, something like 'staying within the canon' or 'it is considered lore'. There are some silly stories out there in the MM / JSW world, excellent mods but daft
stories to justify them. I think M. Smith would approve of this particular story. For me, the paragraph or two explaining the story you got on the original tape inlay card when you bought the game was vital for the initial spark of the imagination, which is where the game itself would then hopefully take over. Manic Panic's story has that I feel.

I've seen some cunning uses of the Boolean operators in JavaScript, where they have some quirky behaviour when their operands are non-Boolean.

I've seen some cunning uses of the Boolean operators in JavaScript, where they have some quirky behaviour when their operands are non-Boolean.

A cunning use of the OR command, indeed! :)

I have taken the liberty of editing the title of this topic from 'The AND instruction' [as it was when started by jetsetdanny] to 'The AND, OR and XOR instructions', to reflect more inclusively the discussions of the use of those instructions in the thread as a whole.
 
This is a good place to mention a cunning use of the OR command - namely something which Norman Sword came up with, to fix the bug in the original Manic Miner game engine whereby crumbling cells can sometimes leave ghosts.
 
The original MM engine clears the bottom pixel-row of a crumbly cell when Willy stands on it, then shifts all the pixel-rows above down by one pixel-row, and then checks the bottom pixel-row - and if it is empty, the program considers that cell to be cleared and replaces the crumbly colour-attribute with the air cell attribute for the current cavern.  The problem with that approach is if you have a crumbly cell pixel pattern with a clear (inkless) pixel-row halfway down the cell, with some infilled pixels in the pixel-rows above that blank row - then the program is fooled into turning the crumbly cell to air prematurely, leaving a 'ghost' of the uncleared pixels in the top part of the (now air) cell.
 
Norman Sword rewrote the crumbling cell routine (as discussed elsewhere), so that all eight pixel-rows of a crumbly cell are OR'd together whenever Willy stands on the cell.  After clearing the Accumulator (A register), a loop is set up to apply the OR command to all eight bytes representing the bitmaps for each pixel-row of the crumbly cell.  (i.e. pixel-row 1 OR pixel-row 2 OR row 3 OR row 4 OR row 5 OR row 6 OR row 7 OR row 8).  If a single pixel is infilled in any one of those pixel-rows, then the Zero flag will not be set at the end of the loop.  Only if all eight crumbly rows are clear (all eight bytes which are OR'd together hold the value 00) will the Z flag be set - with the outcome that the crumbly cell gets changed to air [by changing the cell's attribute].
 
In Manic Mixup, I adapted Norman's code, based on the OR command, to be used both in underfoot crumbly cells, and also whenever Willy uses his hard hat to headbutt away an overhead earth block (which causes the pixel-rows to be cleared in the opposite direction i.e. the rows are shifted from the bottom upwards).

I have never interviewed Matthew Smith or anyone else.

I have never interviewed Matthew Smith or anyone else.

I didn't conduct the interview myself [Retro Gamer, Load 48, February 2008]; I merely posted a message about it.
 
Matthew Smith said he was "thinking about tweaking a pixel. I'm not sure if it would be better light or dark. I must have tried it both ways back then."
 
My best guess is that he was referring to the pixel highlighted in the item bitmap below:
 
.#.#....
#.#.#...
.#.#.#..
#.#.#...
.#.#.#..
..#.##..
......#.
.......#

I didn't conduct the interview myself [Retro Gamer, Load 48, February 2008]; I merely posted a message about it.
 
Matthew Smith said he was "thinking about tweaking a pixel. I'm not sure if it would be better light or dark. I must have tried it both ways back then."
 
My best guess is that he was referring to the pixel highlighted in the item bitmap below:
 
.#.#....
#.#.#...
.#.#.#..
#.#.#...
.#.#.#..
..#.##..
......#.
.......#

I didn't conduct the interview myself [Retro Gamer, Load 48, February 2008]; I merely posted a message about it.
 
Matthew Smith said he was "thinking about tweaking a pixel. I'm not sure if it would be better light or dark. I must have tried it both ways back then."
 
My best guess is that he was referring to the pixel highlighted in the item bitmap below:
 
.#.#....
#.#.#...
.#.#.#..
#.#.#...
.#.#.#..
..#.##..
......#.
.......#

Ah, I see!
 
The 'tennis racket' item shape comes from the Cold Room, where I interpreted them as snowshoes!  But magenta snow (the crumbly cells) would be a most unusual phenomenon!
 
Yes, I believe Andrew Broad is a tennis afficionado.

Beta build 0.4 is the most recent build I have seen / played.
 
The tennis room is the one mentioned by IRF as the penultimate screen, the one with lots of crumbling brick.
 
You collect tennis racket objects and the crumbling brick is in a net design, so I thought it was all tennis related,
I think the eye nasties make a kind of court area or something like that / umpires.
 
To collect the rackets you have to approach them from above.
 
Is tennis something to do with Dr Broad, or am I getting confused with someone else who plays a lot of tennis? It
is possible.

I suppose the scrolling messages just make me scratch my head a bit, they seem inconsistent for me with the rest of the game.
Why have scrolling messages on a couple of early screens, then no more throughout the game? I think it makes sense more
on the first screen if there is a single person in the world left who does not realise to pick up the flashing objects and make for
the flashing level portal, so the explanation message works then, but to counterbalance that, this is what the beautiful, precise
precis of an inlay card did, brief scenario and explanation of what to do, so a modern .txt file could likewise do this job. Who can forget
the immortal write up on the JSW inlay - a more beguiling description is hard to imagine. 36 years later it still inspires people to play.
I digress. Just thinking about the scrolling messages, perhaps if the screen sizes changed again throughout the game and more
messages were there to be read that make me get over the consistency idea? Or does that happen on normal mode? Presumably
not. Just my opinion anyway, I hope it is taken in the spirit it is offered.
 
Your comments about diagonals and stairs makes me think - have I seen stairs in any other MM mod? I can't think of any, but
I am sure there are people here who will correct me if I am wrong about it. Anyway, now I would like to see stairs and
short swings in MM!
 
It's okay though, as once Dr Broad has written his H* engine these will be standard features of any further MM / JSW game ;-)
 
As for the Next keypresses, the Next is a quirky machine, it's great for sure and hats off to the team, but not without a few,
well, quirks. I think it could be more of a physical keyboard thing with the Next than an electronic / specification issue.
What the Next really needs is a Next specific version of any of either JSW / MM or preferably a game that rolled them
both into one somehow on the Next. That would be a killer app. Worth crowdfunding.

I think I have worked out what the H* word is ;-)
 
What about developing H* for the Next too? The Next really needs something to make it compelling software wise. The hardware is great,
just need some killer software for it now. There is some good stuff for sure, and with Next emulators everyone can use the software too.
 
It seems a real pity that you have so little free time to devote to something that seems like it gives you a lot of
pleasure and satisfaction, I hope that this situation changes in a sustainable way for you sooner rather than later,
none of us want to wait for long for H*, which I know seems selfish but we are all fans here.
 
Any clues then as to what H* the word is?

H* game engine
 
 
If I could freeze time for everyone except myself, then I would. As it is, I have less than ten hours a year for Spectrum computing while I still have my job. That might be enough to finish a JSW mini-game this year or next, but writing H* would take me thousands of hours.

H* will not be a collaboration. I want the satisfaction of writing it on my own, from the first principles of Z80 machine code, at least until the first game, H* Original, is released.

I expect that I will want to use 128K for H*, so that I can write a feature-length game with a room format as rich as John Elliott's JSW64 room formats.

H* is an abbreviation of H*****: a secret six-letter word. I think that the name H* has an intriguing air of mystique about it.

H* game engine
 
 
If I could freeze time for everyone except myself, then I would. As it is, I have less than ten hours a year for Spectrum computing while I still have my job. That might be enough to finish a JSW mini-game this year or next, but writing H* would take me thousands of hours.

H* will not be a collaboration. I want the satisfaction of writing it on my own, from the first principles of Z80 machine code, at least until the first game, H* Original, is released.

I expect that I will want to use 128K for H*, so that I can write a feature-length game with a room format as rich as John Elliott's JSW64 room formats.

H* is an abbreviation of H*****: a secret six-letter word. I think that the name H* has an intriguing air of mystique about it.

H* game engine
 
 
If I could freeze time for everyone except myself, then I would. As it is, I have less than ten hours a year for Spectrum computing while I still have my job. That might be enough to finish a JSW mini-game this year or next, but writing H* would take me thousands of hours.

H* will not be a collaboration. I want the satisfaction of writing it on my own, from the first principles of Z80 machine code, at least until the first game, H* Original, is released.

I expect that I will want to use 128K for H*, so that I can write a feature-length game with a room format as rich as John Elliott's JSW64 room formats.

H* is an abbreviation of H*****: a secret six-letter word. I think that the name H* has an intriguing air of mystique about it.

You mean hitting his head on the red and yellow (stripy) block?
 
As MtM has pointed out, you just need to walk on a bit further leftwards before jumping.
 
From your comments, I believe you must have assumed that the white square-shaped blocks act like JSW64-style Trap cells (i.e. if you step on one you fall through, even if you are also standing on a solid block with the other half of Willy's sprite).  Whereas in fact, they just seem to behave like Air cells with a pixel pattern (so you only actually fall through if Willy's sprite is spanning two of the white square-shaped blocks).
 
**
 
Something else which I've just noticed in 'Manic Panic' is that the Fire cells (e.g. the spiky 'poisonous pansy' bushes) are solid, such that Willy can stand/walk/jump on them without falling through - although it saps the air supply if you attempt to do that.
 
In contrast, in the standard MM/JSW game engine, if you hack the engine to turn off the fatal outcome whenever Willy comes into contact with a Fire cell, then he will fall through Fire cells as if they are Air - with the added quirky behaviour that, even if the other half of his sprite is atop a solid block, he will still fall through both the Fire cell and the adjacent solid block.  (In fact, that is how John Elliott created Trap cells in JSW64 - they are just non-lethal Fire cells.)

I'll second that!  :thumbsup:

Don't wait until then, start it now! It could be a real boost - you have all this expertise available on this forum, these
must be amongst the most specialised programmers in the world here, think of what could be achieved in such a short
space a time? Particularly if everyone put away their own projects to a degree and contributed to this one if you needed
the help.
 
Out of interest, do you have criteria that your putative H* engine has to meet, such as run in 48k, etc, and if so
could you share them? Apologies for my ignorance, I am sure it is obvious, why 'H*' as a name?
 
 
 
 
I guess I did in all the excitement!
 
 
 
Excellent, what is the tune or is it a surprise?

I plan to write my H* game engine in the 2040s, if I have time between retirement and death.
 
Any games that I might release before then would have to be MM/JSW patches.

Back to the theme of playing around.
 
 
I wrote the screen copy basics, when I was showing how I would display Perils of Willy. 
 
Those screen copy basics were modified into JSW128 VL demo . And expanded again in JSW128VM
 
Using the screen copy routine that was eventually written for JSW128VM. I expanded the data and added some sprites. I designed and wrote a sprite draw routine, and then added my own sprite movement routines. I then added keyboard routines and fleshed it out with a game control part. All this code is new. It was at this point a few days down the line, that I encountered a major problem in the design of the overall program. Up to this point the movement of graphics and the speed of screen update was ok. However as I added more and more routines it became very noticeable that the stack copy was having a serious problem with regards how it updated the screen. The bigger screen was introducing a phase lag across one raster line and only one raster line. The Glitch this introduced had not been noticed before, and once it was noticed i could not carry on and leave it. At first I puzzled over the nature of the glitch, but eventually I worked out the exact nature of what the problem was. The extra size of the screen was just enough to render the method used as unworkable as far as I was concerned.
 
I wrote several differing versions of the stack copy, and the problem would seemingly not go away with the fastest methods I could write. The problem was not speed but the method of implementation. I could cast aside the method I was using and write a bigger routine that used more data. Or use a true raster line stack copy via the Ytable. The problems become the negation of speed with repeated look ups of data or the vast amount of data and space needed for rolled out stack copies - None of these were to me an option.

So after about four/five days from the start of doing these routines and having a working couple of rooms to play. I contemplated pulling the plug. The glitch that I was seeing was not acceptable to me. The update method had a serious flaw, and I was struggling to overcome this flaw.
 
 
By the end of the first week, I was about to give up.
 
 
I decided to scrap the method I was using. My assembler was now littered with dozens of switches and options that implemented various differing methods of stack copy. I tried a new method and copied a lot of macros across and changed the basic method I was implementing. It seemed like every other block of code I had written. I knew the method was not as fast. Yet when I assembled the code and ran it. The glitch had gone. Which proved it was the method implemented originally that was wrong and all the updates and changes could and did not fix it.
 
 
I added a few more rooms and then added game control. By the end of the 2nd week I had more or less what is seen in these demo's.

What I have done in the weeks since is refine the code and re-write some of the routines. In some ways I wish I had not written every routine from scratch. It was just easier to say to myself, what do I want. Then write the routine. It seemed pointless using someone else's code that did not do what I wanted. As an example:- name a version of JSW that permits sprites to cross the background. The only answers that I am aware of are JSW2 and JSW2+, the third answer is JSW128VM.  I knew from JSW128VM that it was not an easy change. And I also knew from JSW128Vm that the changes in that version did not go far enough. The whole sprite usage in JSW2 and JSW2+ was sufficiently different, that I could ignore that. 
 
So in the end it was just quicker to write all my own routines.

The stoppage at this point concerns implementation of Music. Not something I can do. I can write any number of music routines and play the music in my own routines. But I do need a simple file to implement the music as data, along the lines of    O3fs,o3e,o3e,o3f,o3a
 
Which reads as Octave 3 F sharp, octave 3 E, octave 3 E, Octave 3 F and finally octave 3 A.
 
Given a music score in the fashion written above I can happily write the music routine. 
 
 
 
Asking me to write this file myself is not going to happen soon.
 
---------------------------------------------------------------
 
Final game version accessible via  This Link