Jump to content
SpiceWare

Draconian (2600)

Recommended Posts

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!

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

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.

  • Like 3

Share this post


Link to post
Share on other sites

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:

post-3056-0-78983200-1507683857_thumb.jpg

 

post-3056-0-46801000-1507682861_thumb.jpg

 

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.

  • Like 1

Share this post


Link to post
Share on other sites

  • 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

  • Like 3

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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:
post-3056-0-11648700-1507756096_thumb.jpg

post-3056-0-44078500-1507756099_thumb.jpg

  • 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:
post-3056-0-21431300-1507756103_thumb.jpg

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.

Share this post


Link to post
Share on other sites

  • 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

  • Like 4

Share this post


Link to post
Share on other sites

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:

 

post-2641-0-86196700-1507765752.png

 

post-2641-0-54342800-1507765753.png

 

post-2641-0-23375300-1507765754.png

 

post-2641-0-99914200-1507765754.png

 

Second one:

 

post-2641-0-70615900-1507765755.png

 

post-2641-0-59668100-1507765756.png

 

post-2641-0-26230900-1507765757.png

 

post-2641-0-00222600-1507765758.png

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

  • 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

  • Like 3

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

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

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...