Jump to content
IGNORED

Jet Set Willy


Asmusr

Recommended Posts

My Willy has finally arrived, It felt so hard in my hands and I just could not wait to stuff it into my 4a cartridge port, so I rammed it in there and proceeded to play with it for a good hour or so until I was spent and had to pull it out of the machine.

I will just recharge my batteries before having another long session with my Willy :)

  • Like 1
Link to comment
Share on other sites

  • 4 weeks later...

I really love Rik Mayall!

 

I try to download Manic Miner to play it on my TI but I couldn't find any. Where can I find TI version of Manic Miner?

 

There is no TI version of Manic Miner. I believe Willsy has worked on one in Forth, but he hasn't finished it.

  • Like 1
Link to comment
Share on other sites

I need a frame by frame by frame analysis of how willy jumps. How many pixels upwards in frame 0, how many in frame 1 etc. How many frames does he'hang' in the air (at the top of his jump) etc. Maybe you can help? Is exactly the same in jet set willy.

Link to comment
Share on other sites

Here are the y offsets: -4,-4,-3,-3,-2,-2,-1,-1,0,0,1,1,2,2,3,3,4,4

I think in the original Willy moves 2 pixels x every time the y value changes. That's 2 pixels every forth frame ;).

I made the risky decision of smoothing it out so that Willy moves 1 pixel x every 2nd frame, but that was a nightmare to implement.

 

Edit: The Willy hardware sprite is not actually moving every 2nd 4th frame - it is moving by changing the pattern of a 16x16 sprite and the sprite is actually only moved after Willy have moved 4 times. This is also how I did it in JSW.

Link to comment
Share on other sites

Edit: The Willy hardware sprite is not actually moving every 2nd frame - it is moving by changing the pattern of a 16x16 sprite and the sprite is actually only moved after Willy have moved 4 times. This is also how I did it in JSW.

Hey great! Thanks for the offsets. Regarding moving willy left/right, I'm doing it the same as on the spectrum. X coordinate changes by 8 every four frames. During those four games just the graphic data in the sprite changes (or I load a different pattern code into the sprite).

 

Maybe this will inspire me to get back to it. I'll do the guardian movement patterns and animations first. A large part of the engine is already done (in the machine code version). In the video I posted above its all running off the vdp interrupt. The main thread is a jmp $ loop!

Link to comment
Share on other sites

For those interested, I think this is how Manic Miner and JSW works on the ZX Spectrum:

  • In the 1st frame the game logic, character movement, collision detection, etc. is taking place
  • In the 2nd frame the background image (room) is copied to a CPU RAM buffer
  • In the 3rd frame the sprites are drawn to the CPU RAM buffer on top of the room (no hardware sprites)
  • In the 4th frame the CPU RAM buffer is copied to the video RAM

This explains why Willy is only moving every 4th frame.

 

You could do something like this on the TI in bitmap mode, except it would take 6-8 frames to copy the CPU buffer to VDP.

Link to comment
Share on other sites

It all fits into 32 column text mode, with the exception of the very last level IIRC.

 

Sure, I was thinking of potential other games using bitmap mode on the TI (e.g. isometric). For Manic Miner normal graphics mode is fine and we could easily move Willy at 60 FPS if we wanted. The biggest challenge I had with JSW was the swinging rope, for that it was nice to have some free frames available.

Link to comment
Share on other sites

Ah I see. Yes I saw a technique somewhere online where, on the isometric games (like KnightLore on the ZX Spectrum) they have two screen buffers. One is the background (walls, floors, objects etc). The other is a 1-bit deep bitmap. Where there's a 0, you don't draw the corresponding sprite pixel. Where there's a 1, you do draw it (or maybe the other way around, then you can use XOR). Thus it's quite simple to make a sprite move behind an object. As long as you have the memory of course. The screen on the spectrum is memory-mapped to the CPU, so it's quite easy to rapidly write to the screen (there were all sorts of tricks, like setting the stack to the screen area and doing lots of PUSHes in an un-rolled loop, etc). The problems are more severe I think on the TI with it's port-mapped VDP.

Link to comment
Share on other sites

The problems are more severe I think on the TI with it's port-mapped VDP.

 

Just to be precise - the difference is between memory sharing and memory-mapped I/O. The CRU access could be seen as the port-mapped I/O known e.g. from the Z80. The VDP is a memory-mapped device (see Editor/Assembler, p. 402).

 

I admit I used to mix up the terms myself until I had to prepare some slides for my lectures... :-)

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...