Re-visiting Defender...

[+Yurkie]

1 hour ago, PacManPlus said:

As mentioned, new video

 

 

Holy Shit! That is so awesome!

[+Stephen]

Looking great!

[Trebor]

Looks gorgeous.. scrolling is so silky smooth!

[TrekMD]

That looks awesome!

[RevEng]

4 hours ago, PacManPlus said:

As mentioned, new video

You've completely nailed it, Bob.

 

Just like we all expected you would.

[Jinks]

I had to watch twice I am so sleep deprived I heard sound the first time in the game. Looks great!! Good night!

 

[PacManPlus]

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 December 10, 2021 by PacManPlus

[RevEng]

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.

[+Defender_2600]

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.

 

[PacManPlus]

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)

 

Thanks!

Bob

 

[+Karl G]

I often fall into the trap of assuming the new thing I'm working on is the source of my problems, and failing to look for more mundane causes. "When holding a hammer, all problems look like nails".

[Trebor]

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.

[mimo]

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

[MrBeefy]

Yup. Sometimes taking a step back leads to the best solutions.

 

Looks great so far.

[Atariboy2600]

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?

Thanks,

Bob

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 

 

Berzerk.

Defender.

Galaxian.

Jungle Hunt.

Kangaroo.

Missile Command.

Moon Patrol.

Pengo.

Super Breakout.

Vanguard.

 

 

 

 

 

[+groundtrooper]

I love those 1984 style labels @Atariboy2600. Great work as always. 

 

Also Bob, amazing work so far. Take your time. It will all come together like all of your other amazing titles. 

 

 

[gambler172]

Hi Bob

Maybe you are a little bit too perfect....first try,what is possible....i am sure 7800 Defender will become a good game....even if not erverything is like in the Arcade version.Look at the 5200 version.It is a good game,even if it is not perfect

Arcade like.

 

Greetings Walter

[Zonie]

Amazing

 

[PacManPlus]

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 December 13, 2021 by PacManPlus

[Eagle]

It seems to be repeating in the same place.

When the highest hill is on the screen.  Maybe page boundary?  I lost 2 hours yesterday because one CLC in my code ?‍♂️

[Trebor]

Much easier said than done, but down the road, if the slowdown with every thing in 320 mode cannot be resolved, any chance of revisiting, keeping the status/scanner top area at 320, but the playfield 160?

[+Karl G]

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

[PacManPlus]

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 December 13, 2021 by PacManPlus

[PacManPlus]

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:

;	CLEAR_SCANNER - BLANK OUT ENTIRE SCANNER
CLEAR_SCANNER
	LDX #$00
	TXA
CLR_SCANNER_LOOP
	STA SCN_ZONE1_LINE1+$00,X
	STA SCN_ZONE1_LINE2+$00,X
	STA SCN_ZONE1_LINE3+$00,X
	STA SCN_ZONE1_LINE4+$00,X
	STA SCN_ZONE1_LINE5+$00,X
	STA SCN_ZONE1_LINE6+$00,X
	STA SCN_ZONE1_LINE7+$00,X
	STA SCN_ZONE1_LINE8+$00,X
	INX
	CPX #SCANBUFLINESIZE * 4
	BMI CLR_SCANNER_LOOP
	RTS

(SCANBUFLINESIZE = 16)

 

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.

 

Thanks,

Bob

Edited December 14, 2021 by PacManPlus

[Eagle]

Lda #0

Ldx #$3F

loop:

……

……

……

dex

bpl loop