Jump to content
Sign in to follow this  
Retrospect

Arcade HunchBack Released!

Recommended Posts

(That said, solving it the old fashioned way is something I'm very much in favor of, but flicker is straightforward enough).

 

  • Like 1

Share this post


Link to post
Share on other sites
5 hours ago, Tursi said:

You know, all you need is a small interrupt routine to rotate the sprites for you, and you'll get automatic flicker. I believe the compiler still allows for assembly interrupt routines, @senior_falcon?

 

We'd need to steal a little extra VDP RAM to store a "shadow" copy of the sprite table - one for XB to update, and the real one for the VDP to display.. unless we put the flicker into the XB256 package itself (then the shadow sprite table could live in CPU RAM)? ;)

 

sounds good Tursi, I might be able to get by with just the characters and player sprite at the moment though. I'll see how things go once I start programming the guards & spear chars.

  • Like 1

Share this post


Link to post
Share on other sites

More progress made on the non-F18A version.  Coming along nicely now.  Pit and rampart drops are detected, and the climbing pikeman is doing his thing too. As in the arcade version, he lays out his own set of bricks as he walks.  Reason Century did this is to stop it looking silly when he walks over rampart gaps and pits.  Well that's good enough for me! And invisible sprite acts as the timer for the pikeman's movements rather than any incrementing variables. :)

 

  • Like 6

Share this post


Link to post
Share on other sites
Posted (edited)

Now the guards & spears are functioning as characters not sprites - and they are more or less accurately killing the player.

Literally the only sprites so far are the player, the bells, and an invisible timer for the climbing guard.

 

This makes me question if the original arcade was using sprites for the guards & spears.  They used really old tech on the board for this game so maybe it had similar 4-in-line issues and they used characters.  It works anyhow. :)

So next on the to-do list is sort out the timing for the player's movement.  Each screen has it's own "timer maximum" value.  A variable counts up to that value before it lets the player move.  Obviously some screen are going to be more "busy" than others so in that case the "timer maximum" will be halved, this way we won't see too much slow-down from the player at least.

 

Edited by Retrospect
  • Like 8

Share this post


Link to post
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.

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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...