Jump to content
  • entries
  • comments
  • views

Special Room updates



  • Moved routines from Vertical Blank to Overscan to fix screen roll problem
  • Special object animation in place
  • Big Otto's face will update, launches extra Evil Ottos with very primitive movement logic
  • Hit the Power Plant and robots can't move, but can still shoot
  • Hit the Central Computer and robots can't shoot and will randomly move (even into walls)
  • Factory doesn't do anything yet, but if you hit it the animation stops

Big Otto



Power Plant



Central Computer







  • RESET = start game
  • SELECT = return to menu
  • Left Difficulty, Frenzy Special Room Test1: B = Off, A = On
  • Right Difficulty, Stress Test Mode2: B = Off, A = On

1Frenzy Special Room Test will always put a special object in the room.

2Stress Test Mode is infinite lives and max robots. Score will be red when active.


ROMs (the vbos build outputs 10 extra scanlines to show processing time remaining)








Edit: Stella Debugger enhancement idea



Edit: progress on Stella Debugger enhancement


  • Like 2


Recommended Comments

While play testing last night I noticed the humanoid briefly drawn 2X after having been shot. I'd revamped a number of routines, including 2X sprite size detection, so it looks like I have a bug to track down.


The original routines used code that checked to see if the image was in the double-size image range (all 2X images were grouped together in the table) like this:

NUSIZ1 =  (imageID >= DOUBLE_SIZE_START_ID && imageID < DOUBLE_SIZE_END_ID) ? 5 : 0;
I changed it so that the gSpriteStatus[] array uses 16 bit values, instead of 8, and used one of the extra bits to flag for a 2X sprite to simplify the code. New code is this:

NUSIZ1 =  gSpriteState[index] & SS_2X ? 5 : 0;
That should be faster, and the 2X detection logic is run a lot - especially during collision checks.


I suspect I missed updating one of the gSpriteState[] updates when I revamped the code and it's still using logic for an 8 bit value.


Another possibility is I exceeded the valid index range when updating the Y value for a sprite. I should always use index values of x where 0 <= x < MAX_SPRITES. If I updated gSpriteY[MAX_SPRITES] I would have overwritten gSpriteState[0], which is the humanoid's sprite state.

Link to comment

Saw that bug last night, too. Couldn't reproduce it though, so glad you saw it. For me it happened when I was exiting the maze through the top of the screen.

Link to comment

Thanks! After work I was going to start reviewing the code for the Humanoid Death Sequence, but if it happened to you during a room exit then the problem won't be there.


Had the room started shifting? If not, do you recall if Otto or any robots were onscreen? I know there were robots onscreen when it happened to me, don't recall if Otto was in play.

Link to comment

I'm sure there were robots onscreen. Probably Otto, too - since that's usually when I leave. ;) I don't recall if the room had started shifting. Maybe just started. It happened very quick - blink and you miss it.

Link to comment

Same here, only lasted a frame or two. I posted about it in the homebrew topic, hopefully additional eyes on the problem will help to narrow down when it occurs.

Link to comment

While reviewing gSpriteState I found something else that's potentially a problem. In function WallAvoidance I noticed these lines of code:

        // for Frenzy, or 7/8th the time in Berzerk, avoid the wall
        if ((MAZE_TYPE) || (Random32b() & 7))
            id = (gImageHeight[id] == 13) ? FRENZY_AVOIDANCE_ID : FRENZY_AVOIDANCE_ID + gImageHeight[id] - ROBOT_HEIGHT;
            // This allows robot in Berzerk variation to collide with end of wall 1/8th the time
            id = (gImageHeight[id] == 13) ? BERZERK_AVOIDANCE_ID : BERZERK_AVOIDANCE_ID + gImageHeight[id] - ROBOT_HEIGHT;
and realized that since ROBOT_HEIGHT is 13, I didn't need to do the test, so I simplified the code to this:

        // for Frenzy, or 7/8th the time in Berzerk, avoid the wall
        if ((MAZE_TYPE) || (Random32b() & 7))
            id = FRENZY_AVOIDANCE_ID + gImageHeight[id] - ROBOT_HEIGHT;
            // This allows robot in Berzerk variation to collide with end of wall 1/8th the time
            id = BERZERK_AVOIDANCE_ID + gImageHeight[id] - ROBOT_HEIGHT;
When I recompiled, the compiler issued warning: 'id' may be used uninitialized in this function. I looked at the routine and sure enough, id wasn't initialized. Not sure why it didn't warn that with the original code.


While I don't think this was the source of the 2X problem, I haven't seen the humanoid 2X since fixing it.

Link to comment

Saw it again - exiting the room through the top wall. Also thought I briefly saw one of the robots near the bottom of the screen become double-wide, prior to exploding.

Link to comment

I'm thinking about taking a diversion and see if I can't get Stella's debugger to show me DPC+'s 5K of extra RAM. There's 4K of Display Data and 1K of Frequency Data. The Frequency Data is divided in half if custom ARM routines are in used, 512 bytes for frequency table and 512 for C variables and stack (the division can be adjusted in custom/src/custom.boot.lds, I did that with Stay Frosty 2 and gave C variables and stack 1000 bytes to work with, which left 24 bytes for the frequency table). I'm hoping to do it by adding an extra tab (see screengrab added to bottom of blog entry) in the Disassembly area that could be used to show the extra RAM of any bankswitch format.


Being able to see that RAM might help me figure out what's going on.

Link to comment

I downloaded the latest Stella source during my lunch break but got almost 4000 compile errors.

Based on the 'SDL_Keymod' does not name a type error for this line in StellaKeys.hxx:

typedef SDL_Keymod StellaMod;

and this bit from the SDL 2.0 Migration Guide:

SDLMod is now SDL_Keymod and its "META" keys (the "Windows" keys) are now called the "GUI" keys.

I tried changing from SDL 1.2.15 to 2.0.1. I then got a different set of compile errors, so I suspect stephena's mid SDL-migration. I dropped him a note, hopefully it'll be easy to resolve.

Link to comment

Yep, stephena's mid SDL migration and the Mac source doesn't build at the moment. He had me get the source from the release branch for my changes and he'll integrate them into the development branch when I'm done.

Link to comment

Didn't have much time for computer projects this weekend, been doing Spring Cleaning tasks like scrubbing down the outside of the house and power washing the driveway & sidewalk.


I did manage to make some progress on the Stella Enhancement though, current screenshot has been added to blog entry.


One thing I wasn't aware of was Stella will already show extra RAM in the RAM display. Load up a game like Burger Time, Defender 2 or Omega Race and the scrollbar next to the ZP RAM display will become enabled.


The existing routines appear to tap into how the RAM is access by the 6507, which doesn't work for DPC+'s 5K of RAM as the 6507 can't access it. The 6507 can indirectly access 4K used for Display Data via a datafetcher which asks the ARM to read the RAM. The 1K Frequency (and C) RAM can't even be indirectly seen by the 6507.

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