Draconian (2600)

[+SpiceWare]

I'm honestly flabbergasted he was able to include it in the final build. It was one of those spur of the moment suggestions that I knew had like zero chance of becoming reality. Thanks Spice for proving me wrong!

Actually, thanks go to cd-w for his numerous optimizations which freed up enough space to include it!

[Andromeda Stardust]

---

just isn't room for it. Additionally when we had 4 quadrants the data perfectly fit into 1 SaveKey slot (4 quads * 4 levels * 4 bytes per score = 64). Adding the Epsilon Quadrant changed that (5 * 4 * 4 = 80 bytes).

 

Remove Epsilon Quadrant would solve both issues, ROM space and amount of data to save, but I think the inclusion of Epsilon is the better choice.

 

Perphaps save scores on sectors Alpha through Delta and not Epsilon? I understand it doesn't fit perfectly into the save key but also randomly generated levels means it's not the same game every time so some players will get luckier than others in the score department while playing epsilon.

[+SpiceWare]

That would be an idea; however, free space is now 106 bytes so there's not even enough room for the 109 byte SaveKey driver, let alone the code I'd need to add for Draconian to call the driver.

[Keatah]

Stations on the edge:

 

I think the collision detect needs a bit more polishing, OR, there is a problem with the level. See the attached zip of some PNGs, just view them in sequence. I was able to fly the ship through the outer part of the left side of the station. I think I could get closer in toward the core by a few more pixels if I tried really ultra super hard.

 

The shots fired from the ship seem to work ok. They detect and blow up the part of the station as soon as they hit.

 

The right side of the station detects ship collisions ok.

Stations in the middle don't have the problem. It's the wrap-around thing it seems..

 

I didn't pay attention to any enemy behavior here. I gotta run.

 

 

 

 

stations on the edge.zip

[Keatah]

Load this save-state #3 to see it in action.

draconian_20171009_RC2_savestate.zip

[+SpiceWare]

Good find!

 

Stations have a separate collision detection routine, to deal with the 4x size. I tried to put the world-wrap logic in it, but didn't have room. Thought it wouldn't matter, as the station cannot straddle the wrap-around points like the enemy ships can - I neglected to consider the Star Fighter straddling it.

 

I'll have to do some more optimizing tomorrow so I can add world-wrap to the 4x collision routine.

[+SpiceWare]

Nice thing is this makes for a great test case to confirm the fix - the other collision routine's fix is untested as its difficult to make it occur. Since the code for the fix is the same for both routines (literally copy/paste), confirming it for the stations will confirm it for the ships.

[+SpiceWare]

Hmmm, might need to update this

 

[Keatah]

This sounds like it will work in the vertical direction (top of the station) too?

 

[+SpiceWare]

Yep, world-wrap occurs in both X and Y directions.

[+SpiceWare]

Nice thing is this makes for a great test case to confirm the fix - the other collision routine's fix is untested as its difficult to make it occur. Since the code for the fix is the same for both routines (literally copy/paste), confirming it for the stations will confirm it for the ships.

I've temporarily commented out the world-wrap from Collision and uncommented it out in CollisionQuad used for the stations. Doing this allowed me to confirm that yes, this fixes the problem.

 

After that I was able to uncomment the Y world-wrap in Collision, but when I also uncomment it for X I encounter this:

 ---- -35 bytes free for ARM Code, samples, & graphics

stationary_data.asm (4): error: Origin Reverse-indexed.

---

which means I'm short 35 bytes to have the fix fully implemented. I actually have enough space, it's just in the wrong place:

 

 ---- 5 bytes free for ARM Code, samples, & graphics
 ---- 7 bytes free for table data left
 ---- 4 bytes before FirstResbl
 ---- 42 bytes of Bank 6 left

---

 

That's the results when the Y fix is in place but the X isn't. I need that 5 bytes free to be 40 bytes free. I took a look and believe there's a few things I can move from the ARM code space into bank 6 (where the 6507 code lives). I also need to run the image data through DOOD again as the Game Over image didn't exist when I last did that and DOOD might be able to free up a few more bytes with it.

 

Time for work though, so that'll all happen this evening.

[+SpiceWare]

Did some rearranging during lunch, fix is in place:

 ---- 17 bytes free for ARM Code, samples, & graphics
 ---- 1 bytes free for table data left
 ---- 4 bytes before FirstResbl
 ---- 0 bytes of Bank 6 left

---

I also did a quick run of DOOD for the above. I kicked it off again though as the longer you let it run the more it finds:

D:\DOOD v0.94>"DOOD v0.94.exe" images.asm images.dood -s
 
ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³                                                          ³
³    *** DOOD - Data Overlapping Optimizer for DASM ***    ³
³                                                          ³
³    (C) 2013 - Thomas Jentzsch            Version 0.94    ³
³                                                          ³
ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ
 
reading input data... 139 blocks
calculating overlaps... 0.1 bytes average
theoretical minimum size: 2067 bytes (14.8% savings)
optimizing overlaps...
  size: 2425   (0 iterations)
  size: 2117   (1 iterations)
  size: 2115   (8 iterations)
  size: 2113   (16 iterations)
  size: 2112   (102 iterations)
  size: 2110   (122 iterations)
  size: 2109   (735 iterations)
  size: 2108   (9308 iterations)
  size: 2107   (10001 iterations)
  size: 2106   (201526 iterations)

---

so I'll let it run until this evening. I believe I stopped the quick run when it was at 2108, so it's already found a couple more bytes on the extended run.

[+SpiceWare]

While play testing I noticed the explosions of the stations were sometimes odd, with more flicker than there should be. So I started looking and spotted something odd in the code. Station Destroyed routine, in pseudo code:

 

StationDestroyed(int station)
  create 4 explosions
  disable station sprite
  increase score 1500 points
  trigger sound effect
  if E-Type is attached
    EnemyDestroyed(station + 
  endif

---

Enemy Destroyed routine:

EnemyDestroyed(int index)
  if sprite is E-Type
    if E-Type is attached
      detach from station
      StationDestroyed(index - 
    endif
    increase score 70 points
    trigger sound effect
    trigger explosion sequence for sprite(index)
  endif

---

 

The thing I spotted was in EnemyDestroyed the routine detaches the E-type from station, but it doesn't in StationDestroyed. What that means is if you hit a docked E-Type this would happen:

• EnemyDestroyed() - 70 points
• StationDestroyed() - 1500 points

but if you hit the station while the E-Type is docked, this would happen:

• StationDestroyed() - 1500 points
• EnemyDestroyed() - 70 points
• StationDestroyed() - 1500 points

So I did a recording:

 

 

1650 + 200 (pod destroyed) + 1500 (station destroyed) + 70 (e-type destoryed) + 1500 (extra station destroyed) = 4920

 

So StationDestroyed is now this:

StationDestroyed(int station)
  create 4 explosions
  disable station sprite
  increase score 1500 points
  trigger sound effect
  if E-Type is attached
    detach from station
    EnemyDestroyed(station + 
  endif

---

Which fixed the scoring as well as the flicker issue. The excess flicker was because 8 explosion images were being created for 1 destroyed station when it should have been just 4.

 

This also means your scores are most likely going to decrease in the next RC.

[+SpiceWare]

• World-Wrap logic added to Collision Quad to fix collision issue Keatah found
• Minor tweak to ∆-11
• Fix scoring/flicker issue with stations

This is the new Release Candidate. Please play it as much as you can over the next few days and report any bugs right away.

 

For Harmony or Stella (requires Stella 5.0.2 or newer)

draconian_20171010_RC3.bin

[mckafka99]

I've my eye on this since the beginning but hadn't tried it out until now. Really liking this so far. Are there plans to add the background 'ship moving' sound effect as well as the 'battle stations\attack formation chasing your ship' sound effect? Or are they already there and I have missed an option to toggle somewhere? I will definitely be picking this up asap!

[+SpiceWare]

Thanks!

 

No, those sound effects didn't make the cut. That's one of the tradeoffs that comes up with only having 2 audio channels, compounded by the fact that one of them gets interrupted all the time to play the speech samples.

[+SpiceWare]

Looks like another RC will be coming. Nathan had me make a minor change so that "Condition Red" repeats periodically like it does in the arcade. I dropped it in during lunch and while testing it I noticed this:

• 1 pod explosion
• 4 station explosions
• 1 ship explosion !?!?

4890 + 200 (pod) + 1500 (station) = 6590

so the mystery explosion didn't earn any points, but still puzzled me. Then I recalled I had to add a special routine to handle station explosions taking out enemy ships and took a closer look:

        // station explosions are deadly to enemy ships but not the player.
        // They reuse stationary sprites, but aren't in the correct vertical
        // band to be processed with the normal collision handling, so we'll
        // handle their collision processing here.
        if (i >= FIRST_STATIONARY_SPRITE
            && ((gSpriteState[i] & (SPS_DEADLY_TO_PLAYER| SPS_DEADLY_TO_ENEMY)) == SPS_DEADLY_TO_ENEMY))
        {
          for(j=ETYPE_SPRITE;j<FIRST_STATIONARY_SPRITE;j++)
          {
            if (j != PLAYER_SPRITE)
            {
              if (Collision(gSpriteImageID[j],
                            gSpriteX[j] >> X_FRACTION_BITS,
                            gSpriteY[j] >> Y_FRACTION_BITS,
                            i))
                EnemyDestroyed(j);
            }
          }
        }

---

and realized it was missing a rather important bit:

        // station explosions are deadly to enemy ships but not the player.
        // They reuse stationary sprites, but aren't in the correct vertical
        // band to be processed with the normal collision handling, so we'll
        // handle their collision processing here.
        if (i >= FIRST_STATIONARY_SPRITE
            && ((gSpriteState[i] & (SPS_DEADLY_TO_PLAYER| SPS_DEADLY_TO_ENEMY)) == SPS_DEADLY_TO_ENEMY))
        {
          for(j=ETYPE_SPRITE;j<FIRST_STATIONARY_SPRITE;j++)
          {
            if ((j != PLAYER_SPRITE) && (gSpriteState[j] & SPS_DEADLY_TO_PLAYER))  <<<---- important bit after the &&
            {
              if (Collision(gSpriteImageID[j],
                            gSpriteX[j] >> X_FRACTION_BITS,
                            gSpriteY[j] >> Y_FRACTION_BITS,
                            i))
                EnemyDestroyed(j);
            }
          }
        }

---

I forgot to make sure the sprite was still active. So the mystery explosion is most likely because another sprite was taken out of play right next to the station. So I backed up the recording:


and sure enough, the leader of a formation was taken out right there. The reason no points were earned is because EnemyDestroyed() checks the Image ID of a sprite to figure out points. It looks for E-Type, P-Type, etc but not for explosion images, which was the last thing drawn with that sprite.

Minor issue is I'm 3 bytes shy so need to come up with another optimization to fit the fix in.

[+SpiceWare]

• The phrase "Condition Red" will repeat periodically, like the arcade
• fixed mystery explosions

This is the new Release Candidate. Please play it as much as you can over the next two days and report any bugs right away.

 

For Harmony or Stella (requires Stella 5.0.2 or newer)

draconian_20171011_RC4.bin

[+Nathan Strum]

The stations can shoot each other. I thought I'd seen this some time ago, but haven't been able to reliably reproduce it until now.

 

 

First one:

 

 

 

 

 

Second one:

 

 

 

 

[+SpiceWare]

The stations can shoot each other. I thought I'd seen this some time ago, but haven't been able to reliably reproduce it until now.

Nice find, these ∆ sectors sure are shaking out the bugs!

 

Looks like what's up is the station's taking out the E-Type missile, but since it's docked its explosion takes out the station...

 

I gather the question becomes should the station shots not be able shoot E-Types at all? Or they can, but only when the E-Types are not docked?

[+SpiceWare]

I have a fix in place where the stations can shoot E-Types, but not when they're docked. If you prefer it's a simple change to make them never can shoot E-Types, though E-Types in a formation would still be fair game.

[mmervine]

Just spent some time playing RC4...did not identify any new issues...will try to get some more time in tonight.

[+Nathan Strum]

I have a fix in place where the stations can shoot E-Types, but not when they're docked. If you prefer it's a simple change to make them never can shoot E-Types, though E-Types in a formation would still be fair game.

 

 

I think it's fine if the stations can shoot them once they've been launched.

[+SpiceWare]

• Fix issue where stations could take out another station's docked E-Type missile, whose explosion would take out the station it was docked too.
• Condition Yellow now includes "station onscreen". Before it was only tied to the presence of enemy missiles. This oversight was mostly noticeable when playing KIDS or EASY.
• Reduced the number of directions an I-Type and P-Type missile will enter the screen. This makes it less like a missile will show up then immediately fly offscreen.
• updated AA Jingle

This is the new Release Candidate. Please play it as much as you can and report any bugs right away as I hit the road for Portland first thing Saturday morning.

 

For Harmony or Stella (requires Stella 5.0.2 or newer)

draconian_20171012_RC5.bin

[CPUWIZ]

Are you trying to kill Al?