SpiceWare's Blog

But I wanted a room with a view.

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.

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.

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.

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.

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.

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;
        }
        else
        {
            // 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;
        }
        else
        {
            // 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.

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.

And again. This time Otto became double-wide briefly as he bounced along the top edge of the screen.

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.

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.

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.

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.