Jump to content
  • entries
    657
  • comments
    2,698
  • views
    899,139

Big Otto


SpiceWare

3,237 views

  • New look for diagonal shots.
  • Robot explosions back in place, utilizing the new 2x sprite feature.
  • Doors are back in place.
  • Special room objects for Frenzy (Left Difficulty = A) in place. Only Big Otto does anything at the moment.
  • Evil Otto can be killed in Frenzy variation. Still some work to be done on this feature.

Sleeping until something happens

blogentry-3056-0-17235000-1332209726_thumb.png

 

Happy the humanoid was neutralized

blogentry-3056-0-39898200-1332209733_thumb.png

 

mad that little otto was destroyed, so launched the hench-ottos (still some work to be done on hench-ottos)

blogentry-3056-0-14143200-1332209737_thumb.png

 

ROM

frantic_20120319.bin

 

Source

Frantic20120319.zip

 

 

Edit: Sprite corruption mentioned in comments

blogentry-3056-0-93256900-1332602026.png

9 Comments


Recommended Comments

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

Link to comment

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.

 

s_Berzerk_2.png

 

 

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.

Link to comment

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.

 

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

Link to comment

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.

Link to comment

Looks FANTASTIC!

 

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

Link to comment

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.

Link to comment
Guest
Add a comment...

×   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...