All-Terrain Combat

[Zach]

Remember when the playfields in Combat were limited to symmetrical 40x24 mazes? Thanks to Thomas' Skipdraw, you will soon be able to make an asymmetrical playfield with maximum resolution!

 

Have you ever seen a 2600 game with two sprites, two missiles, and an asymmetrical playfield in the same scanline? I didn't think it was possible until I learned about Skipdraw. This new version of Combat has a completely redesigned kernel.

 

The attached binary is still preliminary work. There are issues to work out, most importantly why it won't run on hardware. But I think you'll agree, it looks great in an emulator.

 

EDIT: May 24 binary attached, where a simple syntax error was fixed.

atcombat_May24.zip

Edited July 10, 2005 by Zach

[kisrael]

Nice work!

Though doesn't Armor Ambush have Assymetrical Playfield, and can get all that stuff on one line? Or am I missing something?

[vdub_bobby]

Remember when the playfields in Combat were limited to symmetrical 40x24 mazes? Thanks to Thomas' Skipdraw, you will soon be able to make an asymmetrical playfield with maximum resolution!

 

Have you ever seen a 2600 game with two sprites, two missiles, and an asymmetrical playfield in the same scanline?  I didn't think it was possible until I learned about Skipdraw. This new version of Combat has a completely redesigned kernel.

 

The attached binary is still preliminary work. There are issues to work out, most importantly why it won't run on hardware. But I think you'll agree, it looks great in an emulator.

857975[/snapback]

Combat uses a two-line kernel, right? Well, if you really want to push things to the limit, use SwitchDraw instead of SkipDraw - save you a couple more cycles, and it is perfectly suited to a 2LK.

 

Oh, and: it looks fantastic!

 

What problems are you having with real hardware?

[StanJr]

very, very cool. Looks like this year's Stan Awards will be cooler than ever (for those of you in a cave, Zach did the awesome award BINs for last year's awards!).

 

Looks awesome.

 

Is this an offical hack for the database, or are you just showing off?

[Zach]

Nice work!

Though doesn't Armor Ambush have Assymetrical Playfield, and can get all that stuff on one line? Or am I missing something?

858027[/snapback]

 

Thanks Kirk, it's always nice to hear from established homebrewers (gods or not). I took a quick look at Armor Ambush, and it's an impressive kernel. It appears the terrain is drawn with a clever combination of reflected and transposed playfields instead of complete asymmetry. Yes, there might be some changes to the PF on the fly, but I don't think the Armor Ambush kernel could draw something like this:

[Zach]

@Bob, yeah Combat uses a two line kernel, if you are referring to the fact the the graphics for each tank are updated on alternate scanlines. When I try to run the binary on a K Cart, I just get a black screen. Sometimes I see the playfield for a split second before the screen goes black. I'll post the code soon to see if anyone has an idea of what's going on. If not, I'll just do a brute force commenting out of code.

 

@Stan, once it is finished, I think it will fit into the database just fine. We all appreciate the work you put into maintaining the list.

[vdub_bobby]

@Bob, yeah Combat uses a two line kernel, if you are referring to the fact the the graphics for each tank are updated on alternate scanlines. When I try to run the binary on a K Cart, I just get a black screen. Sometimes I see the playfield for a split second before the screen goes black. I'll post the code soon to see if anyone has an idea of what's going on. If not, I'll just do a brute force commenting out of code.

858390[/snapback]

I'll take a look at it, unless some else gets to it first

[Zach]

@Bob, yeah Combat uses a two line kernel, if you are referring to the fact the the graphics for each tank are updated on alternate scanlines. When I try to run the binary on a K Cart, I just get a black screen. Sometimes I see the playfield for a split second before the screen goes black. I'll post the code soon to see if anyone has an idea of what's going on. If not, I'll just do a brute force commenting out of code.

858390[/snapback]

I'll take a look at it, unless some else gets to it first

858397[/snapback]

 

Cool.

ATCOMBAT.ASM_May18.zip

Edited May 24, 2005 by Zach

[+batari]

Great hack!

 

I have no idea why it won't work on real hardware, but I did find a graphical glitch with an easy fix. The left tank, when traveling near the right edge of the screen, will look distorted at a particular spot. This is due to the write to GRPx occuring during the visible portion of the scanline. Looking at your original code:

ReturnFromSkipDraw       ;3 
     sta GRP1        ;3              
     cpy NewMissileY1;2   ; Assumes Y is your kernal line counter
     php             ;3     
     cpy NewMissileY0;2       
     php             ;3
    ;( ------------ second line ------------------)
     dey             ;2

All you need to do is move the STA GRP1 down a bit, maybe after the stack pushes or the "dey" and the glitch should go away. I have not tested this, but I see no reason why this wouldn't work.

[Zach]

I made an interesting discovery today. When I load the binary as part of a multicart, it runs just fine on my KC. If I load it as a single file, I get the blank screen described earlier.

 

At this point, I think it's safe to say we don't need to examine the source code anymore. I'd like to ask the members of the community to test on their own hardware. I'm curious what the results are with other Krokodile Carts, Superchargers, Cuttle Carts, and maybe even EPROMS. Thanks.

 

Edited May 26, 2005 by Zach

[+batari]

I made an interesting discovery today. When I load the binary as part of a multicart, it runs just fine on my KC. If I load it as a single file, I get the blank screen described earlier.

 

At this point, I think it's safe to say we don't need to examine the source code anymore. I'd like to ask the memebrs of the community to test on their own hardware. I'm curious what the results are with other Krokodile Carts, Superchargers, Cuttle Carts, and maybe even EPROMS. Thanks.

 

861192[/snapback]

 

It could be specific to the KC, but if it is, the original Combat probably should also not work on a KC. Have you tried the original game?

[Zach]

Just tried original Combat. It works.

[Zach]

I just successfully loaded the new Combat on a Supercharger. It is becoming evident that the hardware issue has something to do with the Krokodile Cart. (It's still a great piece of equipment, though.)

[Atari_Jaguar]

I just successfully loaded the new Combat on a Supercharger. It is becoming evident that the hardware issue has something to do with the Krokodile Cart. (It's still a great piece of equipment, though.)

861380[/snapback]

I concur wholeheartedly wth mister zach.

[+SpiceWare]

When I try to run the binary on a K Cart, I just get a black screen.

858390[/snapback]

Just tried it on my Krok Cart and it worked fine as a stand-alone 4K game. I'm loading it with KrokCom, my Mac OS X program. Mine doesn't set the bankswitch type automatically yet, so I have to explicity tell it "4K", perhaps the Windows program is setting the wrong bankswitch type?

Edited May 25, 2005 by SpiceWare

[bjk7382]

Works fine on the cc2. It's still just combat though

 

I like how the planes are tanks.

[Zach]

Thanks to everyone who tested on hardware. Today I finished up the Tank version. Assuming no problems are found, the plane version will be posted soon. When that is done, I will release a tool for making your own playfields.

 

Updates to this version include:

• Removed airplane levels.
  
• Made game reset from attract mode possible with left joystick button.
  
• Made game variations selectable with left joystick.
  
• Reduced picture size from Combat's original 263 scanlines to the standard 262.
  
• Sprite data stored more efficiently.
  
• Fixed a subtle bug that was only apparent when rotating a tank in slow motion.
  

at_tank_jul9.zip