Playing around.

[IRF]

The arc of fall does not always land on a block (When it has a side component). Think how often you jump trying to land on a platform, and watch Willy pass through it sideways. I was expanding the passage of sprites through movement.

But if I understand this correctly:

 

The best way of describing the above problem. When Wiily jumps his arc goes 4,4,3,2,2,1,1,0 etc. the first part 4,4 we move up one Char, the next part we move up one char with the 3,3,2. And finally we move into the square above by two pixels. Those two pixels are the top of willies hat. The switch is updated and changes the lower three pixels of the switch. If and only if Willies hat (lamp) is/was in this area , then we have a demise of Willy

 

... It is only the bottom three pixel-rows of the switch that can kill Willy, because only those three pixel-rows change when the switch is flipped. So in a scenario where Willy is on the descent phase of a sideways jump, and falls through the switch cell, his legs will enter the upper part of the switch first (at most, the top four pixel-rows of the switch), therefore his legs won't reach the 'switchy' part of the switch until the next time-frame of the game, when the 'flip' has already happened and the potential for a collision has passed.

So the fatal collision wouldn't occur in that circumstance. (It's a purely academic point anyway now that you've fixed the bug!)

Edited June 11, 2020 by IRF

[Norman Sword]

academic... His legs are not tested for the collision, only his upper half. The amount of sideways movement for the upper half passing through a switch would be considerable.

supposing he jumped sideways at a switch. intending to land on it. The switch platform is either one or two characters above his feet. normal arc of passage would allow the sprite to effectively move sideways after missing the platform (switch)  and his lower body would move effectively 4 pixels sideways before the upper part of the sprite is registered as being in the switch square. On a switch block one char higher than his feet.

 

if the switch was  was two chars higher than willies feet then Willy would move effectively six pixels into the char. ----- Not a trivial amount.

 

The area that would now be checked for pixel collision with the switch would be the area around the middle of Willy.

 

 

The original comment about collision was an instantaneous off the cuff remark.  

[IRF]

You have me convinced - all the more reason why it's good that the bug was spotted and rectified.

[MtM]

Any new version approaching release yet Norman, over 0.4 beta?

[Norman Sword]

Even though it might appear as if nothing is happening. I am still adding bits and pieces, and changing what happens and how it happens.

The routines are scanned and have to pass my criteria on what is acceptable.

For example the game completion routine has an addition of data added to the display, it now plays three sequences of noise/music. 

 

The two tunes at the start were re written, the music routine was changed and extended. 

 

The room order is slightly different, one more room added.

 

The sound effect from touch was altered to have more impact from touch. The original made a sound which did not impact on play. (e.g. it was not really noticeable)  touches and falls now impact on play.

 

Playing through all the rooms. Undecided if I go back to the original timer settings. The reason being that in expert mode, the time as now set, which will be based on how long it takes me to do a room, is far too lenient.  Giving some figures for the number of frames needed to finish a room.  Room1-102, room 2-377, room 3-629, room 4-613, room 5-1263     -------    room 8-1479  . If I allow 50% extra time on room 8 that is 700+ frames enough time to finish room 3. The three levels of play are trainer/normal and expert. Hardly an expert if it takes an extra 700 frames compared to me.   Put another way. If i can run a mile in 4 minutes, then an expert is not going to run a mile in 6 minutes, and the normal runner in eight minutes. far too much leeway. Notice I left the trainer mode out of that list. The trainer can run the mile in around an hour.

What I am doing at the moment is playing each room to completion. And taking a note of the frames to completion. (where a frame is a complete game cycle and not a 1/50th sec video refresh cycle).  I will decide at the very last instance what speed the game is set to. 

I have added an extra room, this is done by compressing the game data. I have done this in a convoluted method. Explanation to follow.

 

Room compression:-

Manic Miner has no room compression.

JSW has a 2 bit steam compression.

Manic 40 Miner uses a simple 4 bit stream compression, that enables editing in hex nibbles.

 

Manic Panic . Starts with a 4 bit stream compression . e.g. nibbles

It then takes the stream of nibbles and expands the data out into bytes containing one nibble each. the Data in the lower nibble

It then takes the stream of bytes each with one nibble of data and compresses into a repeat count bit stream of nibbles. 

It stores the repeat count bit stream of nibbles.

Then discards the original data.

 

This allows the original rooms to be edited as hex nibbles and not the awkward repeat stream of nibbles.

 

The program also allows the definition of willy to be edited, the program will then generate the mask needed to play the game.

 

When the game is run... the routines listed above will be overwritten.

 

 

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

 

 

Doing all this on my own, with basically no reason to do so. Means I am not pushing to finish this.

 

By the end of the week I should have set all the rooms to completion times. 

 

 

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

 

 

 

 

 

 

 

 

 

 

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

 

Final game version accessible via  This Link

 

 

Edited July 20, 2020 by Norman Sword

[IRF]

Something I meant to ask before - is there a teleport/cheat function which allows you to skip to a chosen cavern? (Similar to '6031769' in the original MM).

 

I imagine it would be useful for you to be able to go straight to the new cavern to playtest it, for example.

[Norman Sword]

The time between pressing F9 to assemble the program and pressing F10 to run is less than a second. It is very easy to have a variable that specifies a start room and jump the game into that room. It takes no effort to assemble and play doing any room.

The program does have built in, beside the timer display routine, some other routines.  

 

When designing a room we have 16 tiles to play with. The game control uses the colours to assign to each tile a purpose. So we can have conveyor floors or conveyor walls, or even conveyor nasties.  So when designing a room and assigning the colours. I needed to be able to see what tile has what property. e.g. Have I duplicated a colour. So I wrote a routine to display the tiles and their usage.

The routine draws each tile as a graphic in a big square on the screen. For every graphic it scans the playing screen for the usage of that graphic. Then it scans all the other graphics to see if any graphic is defined in a similar colour. If it finds another graphic with the same colour. It places a marker on the screen to show the graphic colour duplicate. It then re scans the playing screen to see if the duplicate colour tile is also used. It then marks it as a duplicate and used and not just a duplicate and un-used, which can be ignored. (just one of the multitude of routines, that has been written. But will never be seen)

The music debug routine (in addition to the placement on the keyboard) shows numerically  the note position in the sequence, the note, its octave, the note  length and the note value eg. F# --- again never seen.

 

The game timer shows the current game cycle and the number of death contacts - not seen

 

The initialisation routine checks memory overflows during compression and program overflow - not seen

 

 

 

 

 

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

 

Final game version accessible via  This Link

Edited July 20, 2020 by Norman Sword

[Norman Sword]

Example of two of those routines .

The big graphic showing duplication of tiles. 2nd picture showing the tile linkage.

And Overwriting the lower status area the game cycle counter and the collisions so far plus air bar value (meaningless when shown in trainer mode)

 

Edited June 16, 2020 by Norman Sword

[MtM]

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.

[andrewbroad]

I think I have worked out what the H* word is ;-)

 

Any clues then as to what H* the word is?

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.