Jump to content





Big Otto

Posted by SpiceWare, in Frantic 19 March 2012 · 810 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
Attached Image

Happy the humanoid was neutralized
Attached Image

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

ROM
Attached File  frantic_20120319.bin (32KB)
downloads: 60

Source
Attached File  Frantic20120319.zip (546.71KB)
downloads: 42


Edit: Sprite corruption mentioned in comments
Attached Image




Looks FANTASTIC! I am so glad you've chosen to continue work on this project! :thumbsup:
  • Report
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
  • Report
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.

Posted Image


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.
  • Report

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
  • Report
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.
  • Report
Looks FANTASTIC!

I can't pinpoint the problem but little otto is much more sinister looking than his big brother..
  • Report
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.
  • Report
What editor are you using to draw the sprites ?
maybe I can contribute something..
  • Report
I don't know what editor is used, I just get GIFs from espire8 and run them thru my converter.
  • Report

Search My Blog

Recent Entries

Recent Comments

Latest Visitors

2 user(s) viewing

0 members, 1 guests, 0 anonymous users


Yahoo (1)