Playing around.

[MtM]

The only released mod of JSWII - if you can call it that - is John Elliott's "Jet Set Willy 2: Super Pre-School Edition". The room "Shouldn't this be the Attic?" [039] was the first completely edited new room in a game using the JSW2 game engine since the original JSWII. 

Thanks for this, that is interesting, I did check your site but when I saw no entries for JSWII never thought of looking elsewhere.

I stand corrected!

 

Is the JSWII engine more difficult to work with than the original MM & JSW engines? I have read that the room data is not compressed/

encrypted in JSW so it is easy to edit etc., but from what I have read about JSWII, particularly on

 

http://www.jdawiseman.com/papers/games/jsw2/jsw2_updated.html

 

it looks like the author of JSWII is still an active and very able programmer, and maybe JSWII reflects this, making it harder to edit or use

the engine? Are there possible copyright issues?

 

Just wondered, mainly because so far as I can tell JSWII is the biggest of all the JSW games room wise, or am I wrong about

that too? I would love to see something on that scale again anyway, with mainly easy screens (!) Or skill levels like Manic Panic.

[andrewbroad]

Are there possible copyright issues?

There are always copyright issues with MM/JSW. We should really be releasing our games as patches against the originals, or writing our own game engines from scratch.

[jetsetdanny]

My replies are in green below.

 

Is the JSWII engine more difficult to work with than the original MM & JSW engines?

 

It would think it is, but it really depends on how one wants to work on it. If you use John Elliott's JSWED, you can load any type of game it works with (which includes, among others, both the original JSW48 engine and the JSWII engine) and edit the game using JSWED's GUI. In this sense, editing a JSW48 game or a JSWII game is pretty much the same, I would think. The differences are in the way one edits the rooms, e.g., to quote from JSWED's manual,

 

"19.5.2 Editing cells

Rather than editing individual cell graphics, you have to choose the graphic for each cell type from the list of all possible cell graphics. JSW2 supports 9 elements rather than the four in JSW48. These are:

[Norman Sword]

The biggest versions of JSW in 48k are in descending order

JSW2+ around 147 rooms - expanding the game +83 rooms

JSW2  around 134 rooms - expanding the game +70 rooms

JSW128 VM 128 rooms - expanding the game +64 rooms

then the next best is around 75 rooms - expanding the game +11 rooms.

 

JSW 60 rooms designed to store 64 expanding the game -4 rooms
 

Edited May 30, 2020 by Norman Sword

[Norman Sword]

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

Edited July 20, 2020 by Norman Sword

[Spider]

One thing I am pleased to see is the 'fall off the platform' effect that plagues JSW2 (Spectrum) and MM + JSW (Amstrad) is thankfully not present! :)

 

By this I mean if you stand M.W at the far end of a platform and press jump then attempt to move left/right you simply fall off rather than jump in that direction. The Spectrum version of JSW1 and MM behave more sanely (imo) in that regard. Lost far too many lives in JSW2 by this.

 

Realise the answer is simply to stand one frame in then operate the controls but with timing sometimes critical its not always easy to retrain my mind for this.

 

As I say thankful to see this 'effect' is not present. Although I've not looked into the cause it seems almost as if the left/right vs jump keys are tested in the opposite order.

[MtM]

My replies are in green below.

 

 

The biggest versions of JSW in 48k are in descending order

 

JSW2+ around 147 rooms - expanding the game +83 rooms

 

JSW2  around 134 rooms - expanding the game +70 rooms

 

JSW128 VM 128 rooms - expanding the game +64 rooms

 

then the next best is around 75 rooms - expanding the game +11 rooms.

 

JSW 60 rooms designed to store 64 expanding the game -4 rooms

 

 

Thanks for clearing the 48 k issue up Norman, I appreciate your expertise on this. I will have to go back and finish JSWII+ at some point.

 

 

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.

 

It is very interesting to hear your thoughts on the coding process. Has anyone ever just written a new engine for making MM & JSW

games from the start, so that in theory it would benefit from all the refinements that have been made over the years, rather than keep

patching or altering the original code? Or is the JSW128 engine that?

 

Are you saying Normal that you cannot prepare the music in the format you say above? Have you got a tune in mind?

 

 

One thing I am pleased to see is the 'fall off the platform' effect that plagues JSW2 (Spectrum) and MM + JSW (Amstrad) is thankfully not present! :)

 

By this I mean if you stand M.W at the far end of a platform and press jump then attempt to move left/right you simply fall off rather than jump in that direction. The Spectrum version of JSW1 and MM behave more sanely (imo) in that regard. Lost far too many lives in JSW2 by this.

 

Realise the answer is simply to stand one frame in then operate the controls but with timing sometimes critical its not always easy to retrain my mind for this.

 

As I say thankful to see this 'effect' is not present. Although I've not looked into the cause it seems almost as if the left/right vs jump keys are tested in the opposite order.

 

That is a very good point, and reminds me of the frustration of playing JSWII to completion earlier this year!

 

 

There are always copyright issues with MM/JSW. We should really be releasing our games as patches against the originals, or writing our own game engines from scratch.

Ah, so maybe no-one has written a complete engine from the beginning then? Yet it seems to me like there are several people on here

who are more than capable of doing that, though I guess real life gets in the way some times. Would copyright these days not have

reverted back to the original author in absence of a liquid concern holding the copyrights? Didn't Elite plan to release a new version

in some way, I know they had a modded version from 1985 they were on about releasing, but it all seemed to go very quiet and has

been since.

 

Sorry if the size of this post breaks the forum rules :-0

[Norman Sword]

Nothing to do today---- so i wrote the music.

 

 

 

---------------------------------------------------------------

 

Final game version accessible via  This Link

Edited July 20, 2020 by Norman Sword

[andrewbroad]

Ah, so maybe no-one has written a complete engine from the beginning then? Yet it seems to me like there are several people on here

who are more than capable of doing that, though I guess real life gets in the way some times.

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.

[Norman Sword]

 

 

 

So in the end it was just quicker to write all my own routines.

 

 

 

 

Did you miss that statement.