Jump to content
  • entries
  • comments
  • views

Big Otto



  • 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



Happy the humanoid was neutralized



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










Edit: Sprite corruption mentioned in 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?



Link to comment



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.

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)?



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



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

  • Recently Browsing   0 members

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