Moving the room data

[Spider]

There was no 'real' reason for this other than plain curiosity really.

 

As I had quite a bit of free space towards the end of the sprite area (I'll explain why in another topic later) I thought about the code to load the room:

 

The code at 35090 / #8912 effectively reads:

 

 

 

LD A (current room number)

OR 192 / #C0

LD H,A

LD L,0

 

At this stage, HL is 49152 / #C000 , simply as 49152/256 = 192.

 

It then sets up an LDIR to copy the room definition to the status buffer

 

I set mine a bit lower down, I actually set the OR instruction to be 181 / #B5 which means it 'starts' at 46336 / #B500 as that space onwards was actually 'free' and then proceeded to move the room data 'up' (or down, depending on which way you want to count) externally to be sure it was intact from 49152 to 46336. This worked until I left a room ( ! ) as I had an IDS and I noted that the objects were not moved but I half expected that.

 

I'm not 100% sure why the room ID's changed though :unsure: as logically unless I've missed it, it is only really looking at that address, I do not see anything in the "move Willy to the room above/left/right/below" that could directly influence the 'room exit ID' as such.

 

I can't provide a file for this at the current time until I finish something else within a day or two, I just need to do a small writeup of it first.

 

I wonder if I have overlooked something. I do realise in effect it "locks" those 8 or 9 rooms in this case outside the remit of JSWED however manual editing or using one of the other editors with a few tweaks (as they are usually written in Basic) would no doubt work. I may try this to see if I can force the changes through if nothing else.

[Norman Sword]

Shifting the room base

 

ld a,(room_num)

or 0c0h
ld h,a
ld l,0

 

looking at #c0 in binary we have 11000000b, notice the lower six bits are free.

The room number is between 0 and 63  or 00000000b and 00111111b, note the top two bits are not used

when the two valued are or'd together the composite value is the addition of the two values.

 

if you want to move the base value then add it

ld a,(room_num)

add a,#b5
ld h,a
ld l,0

Edited July 17, 2017 by Norman Sword

[Spider]

Thank you. :)

 

I'll have a play with this tomorrow (well, later today really now I guess)

[IRF]

Norman Sword, you have reappeared here at a fortuitous moment!

 

We are about to release a game called 'Jet Set Mini' (possibly later today, or tomorrow), which includes a fairly comprehensive readme file.

 

This is an excerpt from the readme, which relates to a contribution that you made on jswmm.co.uk

 

If you would care to have a quick read and pass comment, then we can take any such comments on board prior to the game's release.

 

 

- The 'Jagged Finger'/'Delayed Attributes' imperfections. These flaws are caused by the fact that the copying of the display and attribute buffers, to the display and attribute files, can instantaneously fall 'out of sync' with the physical updating of the screen's 'raster' scan lines. As a result, moving sprites can momentarily break up and flicker, and can partially (or, in the case of arrows, entirely) be rendered in the wrong colour attribute for a brief but perceptible moment. By changing the sequence in which elements of the display and attribute buffers are copied across to the physical screen, these effects can be greatly reduced or eliminated.

 

There is also an individual credit for you, see below.  (We can change it if you would prefer to be credited as Derrick P. Rowson - if indeed you are he?)

 

 

- 'Norman Sword' for his work on fixing the 'Jagged Finger' and 'Delayed Attribute' flaws in the original JSW game engine.

Edited July 17, 2017 by IRF

[Spider]

if you want to move the base value then add it

ld a,(room_num)

add a,#b5

ld h,a

ld l,0

I'll have a play with this tomorrow (well, later today really now I guess)

I got held up with other tasks however this did work very well for my tests, thank you. :)

[Spider]

It does work well however it can cause much mayhem with JSWED it seems. I was able with a little bit of careful sprite movement to have a theoretical 71 or so rooms without any loss of sprite data (or moving them "out of normal range" either) simply by removing the gaps and re-arrangement.

 

You'd have to either split the room data up and edit it peacemeal or more sensibly would be to set the first 9 or so rooms correctly, move them and then edit the rest of the game, with the finished code you'd then (in theory not tested) just add that room data section to the 'first' save.

 

Final minor tweaks may be needed for which one of the elderly Basic editors would more than suffice I think as they would be very easy to modify to allow for the initial room data location. This method in theory means you'd get the advantage of 'friendly' JSWED to use for the majority of the game but you could also 'tidy up' (item location and oddities) the 'full set' afterwards with another editor.

 

I will investigate this a bit closer as and when time allows. A more simpler 'fix' would be to permit JSWED to accept a different value for the room starting data instead of it being hardcoded to 49152... :unsure: hmmm