Looks FANTASTIC! I am so glad you've chosen to continue work on this project!

You are making very rapid progress!    Those diagonal shots look good now.  

I'm not very familiar with the arcade version, but should you die if you hit the explosion of the robot?

Chris

Thanks!

Rapid now, but it'll slow up soon.  At the moment I've mostly been bringing over code that was already in place from before the reboot.  Some of it gets reworked as I bring over, like the robot explosions - I used to use 2 sprites so they'd be 16 pixels wide.  In the original kernel only NUSIZ1 could be changed during the reposition, so I limited it's use to the special room objects like Big Otto otherwise flicker would be worse because I'd lose the flexibility of being able to use either player when drawing most any sprite(ie: the humanoid might be drawn with player0 this frame, but player1 next frame).  After the reboot I was able to squeeze in NUSIZ0 as well, so I changed the explosions to use NUSIZx.  It simplified the explosion logic as it used to have to scan the list for an unused sprite to use for the right half of the explosion.  The simplification should help with performance, screen jitter was an issue pre reboot and will most likely be again once I add back in the speech.

Yes, shrapnel is deadly.  Chain reactions were one of the things the home version was missing - the robots were vertically separated and explosions were constrained to the size of the robot.




I think I'm going to work on bringing back the speech routines next.  I'll have to go back to an earlier build for that code as it was removed last summer.  Another issue is I've used up to much of the RAM, I need to have a 2K buffer for the audio sample, but at the moment there's 1152 bytes free.

Hmm - I do see an issue I'd forgotten about:
digitized sound disabled. I tried to make it work, but had garbled screens and other odd results. I suspect the IRQ routine to update the audio when the ARM code was running didn't like being in MAM1 mode.

SpiceWare, on Tue Mar 20, 2012 8:23 AM, said:

Fred should be able to modify the interrupt routine to set MAM=2 at the beginning and restore it back to MAM=1 at the end (assuming the interrupt executes from RAM)?

Chris

That's an idea, though I did get to thinking that we didn't have an issue with music playing in Chun-Li and the routines are basically the same (the difference between DPC+ and DPC+DA is one of the three voice's waveform buffer size was changed from 32 to 2048 bytes).

I've got the 1152 bytes of Display Data RAM free to 2080 so I'm now able to get the waveform buffer back in there.  I also added back some animation.  However, last night I noticed some sprite corruption.  I'm trying to track that down before I post the next build (so I'll have a roll-back point).  After that I plan to work on the audio.

I added a screen grab of the corruption to the blog entry.  In capturing that image I think I figured out that it's related to changing the sprite variables (ImageID, State, X, Y, etc) values from INT to UNSIGNED CHAR (which saved 648 bytes of display data) as it looks like it's occurring when a sprite's Y position is above the top of the screen (ie: what used to be -1 is now 255).  I noticed it last night when Otto was entering from the top door, his bouncing causes negative values.  In the sceenshot I added, the humanoid had just shifted off screen, so it has the same negative Y issue.

Looks FANTASTIC!

I can't pinpoint the problem but little otto is much more sinister looking than his big brother..

Yeah, it is off a bit.  I think it's just the "mad" image, it looks kinda like a goofy face you would make at a baby.  I'll look into that whenever work resumes on Frantic.  Odds are that won't be until next year.

What editor are you using to draw the sprites ?
maybe I can contribute something..

I don't know what editor is used, I just get GIFs from espire8 and run them thru my converter.