Jump to content

Photo

Defender II Hack Attempt - Trying to find 2 portions of code


35 replies to this topic

#26 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,966 posts
  • Location:The land of Gorch

Posted Thu Apr 25, 2019 8:46 AM

Dunno what you are saying.  The images are all defined. The stargate can be a bit lower in the page since it it is called at a specific position that is not at maximum altitude.



#27 rallyrabbit OFFLINE  

rallyrabbit

    Space Invader

  • Topic Starter
  • 30 posts
  • Location:North Carolina (USA)

Posted Thu Apr 25, 2019 2:40 PM

Let me see if I can clarify what I mean.

 

The title screen, End of Wave screen, etc are all built with about 6 sections of images that are pieced together in lined segments.  Like, Bonus x100 defined almost as BO NU Sx 1 and then 00.  In the current definition, most of this exists in the same general area.  Between F700 and F7FF, or F800 and F8FF, etc; depending on the screen being built (that's an example and not the truth).

 

I guess I'm asking, is there a reason for the ROM addresses to be close together or does the length away from each other matter?  Meaning can I logically put BO as f700, NU in f900, Sx in Fd00 and so on (again, a sample not real positions).  I know this isn't a physical media where seek times matter, I'm just unsure of the segmenting of these ROM parts that cause a lengthier read time depending on the addresses used in one page.  I can't image that is the case, just more curious about it.



#28 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,966 posts
  • Location:The land of Gorch

Posted Fri Apr 26, 2019 2:22 AM

It doesn't matter if everything is referenced correctly.  As I said, I'm still figuring it out.

 

< Not Debro

 

#Hackem took 6 years



#29 rallyrabbit OFFLINE  

rallyrabbit

    Space Invader

  • Topic Starter
  • 30 posts
  • Location:North Carolina (USA)

Posted Sat Apr 27, 2019 6:46 AM

Ok, I don't want to be one of those statistics of things that never complete for games or hacks.

#30 rallyrabbit OFFLINE  

rallyrabbit

    Space Invader

  • Topic Starter
  • 30 posts
  • Location:North Carolina (USA)

Posted Sat Apr 27, 2019 8:22 AM

2) Within the display code itself.  You'll find many instances of ENAM1 followed by ENABL.  This is what produces the hills.  The M1 and Ball sprites both start at the same horizontal location.  The missile is given a horizontal motion value 3 pixels left, the ball is given 3 pixels right.  HMOVE is drawn on every scanline, so they move apart as the screen is drawn downward.  Kind of a neat solution to draw Defender's hillside (rather than use a playfield cityscape like the original did).  Not so good if you are looking to change it into something different, tho.

 

My focus is in two places now:

1) finding where enemy speed is increased in each wave and how that is calculated.  I am suspecting this in page 0 in the LDD12 area, but working that out on what is what potentially

 

2) Mountains - removing

 

Like I said, I got a bad cityscape put in just to show myself I could change the playfield.  But it definitely needs to be made to be better.  But I didn't take out the mountain effect to do that.  I used your tip above to find all these areas of concern.

1) LF405 - looking at this code i think this has to do with enemy missiles

2) LF444 - Unsure what this one is doing - startfield maybe?

3) LF492 - This looks like part of the mountains - like maybe the top?

4) LF4E4 - This one I have yet to identify

 

 

So, I am looking at the mountain creation and trying to see the rough difference between "planet" vs "planet destroyed"



#31 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,966 posts
  • Location:The land of Gorch

Posted Sat Apr 27, 2019 4:34 PM

To remove the mountain, you just need to erase the low nybble at addresses $FE00 to $FE1C.  Ram vector $9B/$9C creates the mountians as well as the starfield.  This normally points at the data starting at $FE00 (so the mountain is drawn as the scanline counter counts down to zero).  When address $A9 is non-zero, it alters the LSB of this vector...counting upward to $1C.  When $1C is reached, the flashing stops...no mountain is left.

 

Bit 5 in this data table is used to set the width of ball and missile.  It extends a little further in the data table because the sprite size is not set on every scanline up to this point.

 

So $A9 = 0 for planet OK, $A9 < $1C currently being destroyed, $A9 = $1C fully destroyed.

LD41C:
       LDA    rA9                     ;3
       BEQ    LD430                   ;2 branch if planet is still OK
       CMP    #$1C                    ;2 Reached the end of mountian data?
       BCS    LD430                   ;2 branch if so
       INC    rA9                     ;5  or, increase the pointer to slowly eat away mountian
       AND    #$03                    ;2
       BNE    LD442                   ;2
       LDA    #$05                    ;2
       STA    r90                     ;3
       BNE    LD442                   ;2 always branch

BTW:

Tag LFBD0 is calling the data at $FC00 (used for sprite positioning and motion values).

 

So add label LFC00 to that data table and replace all instances of LFBD0 with LFC00-$30

 

 

Q:

If you are using playfield to draw the city, how will you then fire at enemies that go that low?  Playfield is used for player's laser...the playfield collision register is used to record hits.


Edited by Nukey Shay, Sat Apr 27, 2019 4:48 PM.


#32 rallyrabbit OFFLINE  

rallyrabbit

    Space Invader

  • Topic Starter
  • 30 posts
  • Location:North Carolina (USA)

Posted Sun Apr 28, 2019 8:42 AM

Q:

If you are using playfield to draw the city, how will you then fire at enemies that go that low?  Playfield is used for player's laser...the playfield collision register is used to record hits.

 

not sure I've through that far ahead, but that's a good point.  I think you could technically let the humanoids reside in the top of builds, therefore its not a problem, or I'll illegitimately have to figure something else out which will take a bit of research.



#33 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,966 posts
  • Location:The land of Gorch

Posted Mon Apr 29, 2019 3:47 AM

Could just draw the city where standing humanoids are, and prevent any enemy from going that low.  Landers just need to lock on to their position without touching them.  Not sure how "friendly fire" would work, tho (this was N/A for Atari's Defender...as only humanoids were shown in the city).

 

Current progress:

Attached Files


Edited by Nukey Shay, Mon Apr 29, 2019 3:52 AM.


#34 rallyrabbit OFFLINE  

rallyrabbit

    Space Invader

  • Topic Starter
  • 30 posts
  • Location:North Carolina (USA)

Posted Mon May 6, 2019 6:16 PM

Now back to this after work has calmed down....

 

What all have you changed overall.  Just a did a diff with my code and trying to figure out what to merge.  Added a bunch of comments.  Which I am incorporating.  But running the program is pretty much a blank screen (so assuming you are ripping stuff out)?  Looks like just title screen, end of wave screen and the radar/score?

 

I've done a bit of work trying to get graphics like the original defender with a newer twist (not sure I like it yet), isolate enemy speeds (not adjusted yet), changed a lot with colors, things like graphic area consolidation and reduction of sapce, changed some screen, no dogfights, no warps (got rid of warp screens), no stargate (reused that graphic area), took some of the defender arcade lessons form the enemy tables, trying to isolate sounds (not sure I like my enemy shot sound yet, but it is what it is for now), trying to do some color adjustments elsewhere and all over the place.  Fixed the score on the end of wave screen.  Made the digits look like original defender.  Took out my cityscape that didn't work.  Removed inviso mode stuff so far.  Tried to comment the code based on what I think is going on.  Took some mountains changes from defender arcade as well that'll go away eventually.  Added my initials to title screen until I get closer to completion.

 

Again, scalpel.  So I finally see how mountains vs destroyed planet are done (its an adjustment to the index).  not I am trying to see how I can do a simply cityscape and see what are the base cycles I need to do it to see if I kill everything and scanline time.  Working out ideas for now.

 

 

 

That leaves some of the bigger things left:

1) Figure out how to do smartbomb from joystick 1 below mountain level (still working this out)

2) Cityscape algorithm and see if I can do it in space available and without killing scanline timeframe

3) Adjusting enemy speeds across waves so that the game doesn't get so impossible so fast

 

 

Attached Files


Edited by rallyrabbit, Mon May 6, 2019 6:46 PM.


#35 Nukey Shay OFFLINE  

Nukey Shay

    Sheik Yerbouti

  • 21,966 posts
  • Location:The land of Gorch

Posted Thu May 9, 2019 5:03 AM

I've stayed away from data table changes because I know that you are moving those around.  Although I did merge table LFA00 with the empty area at $FE67 to $FE7B (bit0 is ignored for ball/missile sprites), and used an additional bankswitch at the end of each bank to eliminate the redundant score routine in the display bank (used during the # humanoids remaining tally).  If you already noticed, I've switched the 2 banks so that $F000 occupies the first bank, and $D000 occupies the second (this takes advantage of the hotspot jumps to save a little Romspace).  Otherwise, I've only been doing code optimizations.  So you should be able to take all of your data tables and paste them directly into the current assembly.

 

NOTE: there was a timing glitch present in the previous assembly I did which caused HMOVE to hit 1 cycle too late on occasion (fixed).

 

Current progress:

Attached Files



#36 rallyrabbit OFFLINE  

rallyrabbit

    Space Invader

  • Topic Starter
  • 30 posts
  • Location:North Carolina (USA)

Posted Mon May 13, 2019 9:08 AM

I've stayed away from data table changes because I know that you are moving those around.  Although I did merge table LFA00 with the empty area at $FE67 to $FE7B (bit0 is ignored for ball/missile sprites), and used an additional bankswitch at the end of each bank to eliminate the redundant score routine in the display bank (used during the # humanoids remaining tally).  If you already noticed, I've switched the 2 banks so that $F000 occupies the first bank, and $D000 occupies the second (this takes advantage of the hotspot jumps to save a little Romspace).  Otherwise, I've only been doing code optimizations.  So you should be able to take all of your data tables and paste them directly into the current assembly.

 

NOTE: there was a timing glitch present in the previous assembly I did which caused HMOVE to hit 1 cycle too late on occasion (fixed).

 

Current progress:

 

Ok, cool, I was trying to go through the code and see what you did.  I wasn't sure what the intended result was, so I was going through line by line to see what changed.  I'll start merging now.

 

So, while I am working on combining, let me ask your opinion.  I was wanting to do some similar to defender that once your ship gets below a certain point, that allows the smart bomb use (although that would have some challenges in game such as this where it stands now.  So, I'd have to remove the checks for joystick 2 for this, but would have to have a "height" check somewhere to replace the use of it.  Any opinions here?






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users