Jump to content

Re-visiting Defender...


Recommended Posts

This game is kicking my behind. 


I have an array of all objects permanently on the planet (i.e. humanoids and enemies).  At the latest level of the game there are 4 waves of 5 landers (20 in total), 5 bombers, and 4 pods.  It looks like there is some space at the end for baiters (although the more enemies you kill, the more baiters can appear).  So 32 at most.  There are 10 humanoids, so that leaves 42.  My array is 48 (mostly because I like to see $30 instead of $2A).  


Then there is a separate array of the objects just appearing on the screen on each frame.  I have an array of 16 for that (besides the player, player's shot, and the enemy shots).  I try to build the DL dynamically from that list for each frame, and I get nothing each time (I think it takes too long and locks up).  If I use the pre-made DL and update positions, I'm VERY limited on what I can show per zone. 


I've tried a few different ways, and I keep scrapping it and going back to my 'known state' version (i.e. the one I posted the video for).  I feel like I'm getting stupid(er) as I get older ? 


Edited by PacManPlus
Link to comment
Share on other sites

A few thoughts... 


I'd make sure that crashing in your dynamic code is a result of timing, rather than something else. Unless you're completely starved by DMA, you should be able to pump out a fair bit more than a dozen sprite updates (2x DL updates per sprite) within any given frame. Without double-buffering, the dynamic DL generation in 7800basic manages around 24 moving sprite updates. (on a 160A tiled background. Maybe a little more with no background. Definitely much more with double-buffering, but that's another kettle of fish)


The thing is, 7800basic has it's DL update running outside of the NMI. (when objects need to updated, I check for a flag that indicates the end of the visible zones has been reached, and wait if it's not yet good.) That architecture is pretty forgiving for missing a frame here and there, since it will never clobber itself due to too many objects being pumped to the screen. Worst case result of taking too long for a frame is you get a mostly duplicated frame with a few sprites missing and one corrupted. Typical case result is you get the duplicated frame, and as long as it doesn't happen too frequently, nobody notices.


Hopefully there's something useful in there for you.

  • Like 4
Link to comment
Share on other sites

Hey Bob,


your video is absolutely spectacular, you are doing an AMAZING job with all the beautiful color animations! Please don't give up!



I don't know if this helps but if you have run out of cycles and are using only 320B mode, maybe you could try to check if the game works without the terrain graphics and, if everything starts working fine, then try to use 320D for terrain graphics. Maybe, if you need to, you could use 320D for the player's laser beam as well. Just an idea.


  • Like 4
Link to comment
Share on other sites

Thanks guys!


Oh, I didn't mean to imply I was giving up, I'm just having a hard time.  I was hoping someone would give some ideas, which you both did.  Thank you! :)


This one is going to take a bit longer than usual...  After the quickness of Galaxian, it's disappointing (to me at least)





  • Like 10
  • Thanks 1
Link to comment
Share on other sites

23 hours ago, PacManPlus said:

This one is going to take a bit longer than usual...  After the quickness of Galaxian, it's disappointing (to me at least)

The only deadlines are the ones you set. ;)

Take all the time you need. :)


Factoring the radar, wraparound scrolling playfield, among other items, this is considerably, if not vastly, more complex than Galaxian; you're being too hard on yourself. 


I'll admit though, selfishly, I actually like seeing the development drawn out a bit. For one thing, often the developer's involvement with the community and the sharing of what has being done, is being tried, during the game development process is greater, and that is very cool to me.  Plus, I get to witness one of the wonderful things about this community.. the helpfulness and sharing of resources and ideas.

  • Like 6
  • Thanks 1
Link to comment
Share on other sites

Take your time. Walk away from it for a while and the solution may find you.

Work on something else for a while?

We really appreciate the work you do for the 7800 community, your games are the reason I still keep a 7800 (or 4) in my collection

  • Like 5
Link to comment
Share on other sites

On 11/16/2021 at 8:47 AM, PacManPlus said:

Hi guys:


For those of you that don't know, I have re-started porting 'Defender' to the 7800. 


I started from scratch as I wanted to use 320B mode and I had an idea for the terrain (use 320A mode for that).


However, I'm finding that I'm having issues with the scanner area:




As you can see, I have a 16x4 tile grid, which works out to be 64x30 pixels. (The bottom two scan lines are the scanner box itself).

When I did this the first time, I blocked out an area of (added) memory, made the DL point to that area of RAM and just updated it each frame.


This time, I would really like to not use expanded memory (I want to see if I can do this within the limits of the vanilla console).

I tried using DL entries for each of the 'dots', but because of the character modes used (score, ships in reserve, etc) I can only get 4 sprite DLs in the zone before I run out of Maria cycles.

Flickering at 30Hz is not out of the question, but even then I'll only get 8.  I won't go more than 30Hz as then it gets bad.


I know Atari has done this with Defender and Defender II on the 2600 (with  Defender II only adding 128 more bytes of memory), so there has to be some sort of trick of doing this without using much memory.

(I would try and read the Defender II code but there is no disassembly of it that I know of).


Does anyone have any ideas?



Defender for the 7800 was one of my TOP TEN most wanted games posted on the Atari 7800 and made so many mock up screen shots and label art for this game XD


My top ten was 





Jungle Hunt.


Missile Command.

Moon Patrol.


Super Breakout.











  • Like 5
  • Thanks 1
Link to comment
Share on other sites

Well, there's good news and bad news.


The good news is that I got the dynamic DL creation working, and I was able to resolve the little issues that resulted from it.


However, I decided to do a stress test. :(

I started to see a slowdown issue with 10 enemies, so I decided to do the maximum (32).  This video is the result. There are scanner blips disappearing / reappearing, enemies in the playfield doing the same...  And that's without shots or humanoids on the screen yet.

This one, unfortunately *is* a show stopper if I can't get past it, which means I won't be attempting this one again.



Edited by PacManPlus
  • Like 1
  • Sad 2
Link to comment
Share on other sites

Is it from the CPU time of processing enemy movement for all of the enemies on the wave, whether visible or not? Just as a shot in the dark perhaps this can be broken into several frames, especially for ones that are not currently visible (e.g. they move e.g. 4 frames worth of movement every 4 frames when off screen, this wouldn't be noticed at the resolution the scanner would show). 


Of course, I have no idea how you are processing things already, so feel free to disregard if none of this applies.  ? 

  • Like 1
Link to comment
Share on other sites

Thank you all for your ideas. I'll give a few things a try.  What makes me hopeful is that I added all 10 humanoids and it wasn't much worse.  I wanted to see the absolute worst-case scenario.  (The enemy shots are static in the DL - up to 5 per frame with 2 alternating, so 10 enemy shots total).  I may make those dynamic as well, and count the number of entries.  They max out at 13 (not including the player or the player's shot which *are* static and need to stay that way).  Anything over the max per zone gets pushed to the other side of the planet (like the arcade does).  If I can only get this working, that means we can have 13 enemies / shots per zone by 18 zones...


The thing that worries me is that the landers are supposed to move; and they do when I don't max out the enemies ? 

I do think it's too much stuff per frame.


However I'm going to have to step away and come back to this anyway; I've promised @Tempest I'd take a look at something for him and I want to make sure I do that before I forget again. :( 


Edited by PacManPlus
  • Like 2
Link to comment
Share on other sites

In the middle of doing other things, I used an excellent utility made by RevEng (7800Heat) showed me an area of concern:


D9A0: ldx #$00       (1689)
D9A2: txa            (1689)
D9A3: sta $1f00, x   (108097)
D9A6: sta $1e00, x   (108097)
D9A9: sta $1d00, x   (108096)
D9AC: sta $1c00, x   (108097)
D9AF: sta $1b00, x   (108097)
D9B2: sta $1a00, x   (108096)
D9B5: sta $1900, x   (108097)
D9B8: sta $1800, x   (108096)
D9BB: inx            (108096)
D9BC: cpx #$40       (108096)
D9BE: bmi $d9a3      (108097)
D9C0: rts            (1689)


This section of code is where I clear the scanner to re-update it each frame:

	LDX #$00



Is there a faster routine to clear memory?  When I write to it, I am 'OR' ing each blip on the scanner so I don't overwrite any other objects already written to the scanner.




Edited by PacManPlus
Link to comment
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.

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.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...