Jump to content
IGNORED

Cosmic Ark Starfield


glurk
 Share

Recommended Posts

So, let's say there was a one million dollar prize for any programmer who could create that effect on the A8.  Just hypothetical, of course.  How would you do it?

 

I think my idea would be 20 lines of ANTIC mode 4, all with HSCROL enabled and loaded with some quotient of the frame count, or an up/down cycle based on that.  Combined with color-cycling, and redefining the characters in RAM, or at least a repeating block of them.  I think it would take a 20 x 4 repeated block, but it's difficult to tell.  It's obviously a repeating pattern of some X by Y size.

 

It could be done in a bitmap mode also, but the DMA costs would be higher.  Because you know, if you wanted a game on top of it, it should be done in the most efficient way possible.

 

How would some clever programmer win the hypothetical million?!

  • Like 1
Link to comment
Share on other sites

How you can easily do it can depend on what other graphics you want present.

 

The 2600 game seems to have a fairly simple animation sequence which wouldn't be hard to replicate.

But for not too much expenditure something better could probably be done.

One possible cheap way might be using character graphics with chset rotation or just redefining characters.

Another way could be LMS tricks.  But doing that creates a problem if other playfield graphics need to be present.
 

Stuff like kernals repositioning PMGs and the like - very costly for CPU.

 

Bitmap - you earlier mention Mode 4 - it has higher DMA load than an 8K bitmap mode.

 

Maybe a mixed bag of tricks - move into a startfield like Star Raiders at medium speed.  Just render a quarter of a screen worth then use some tricks to replicate it on the whole screen, but in such a way that it doesn't look boringly symetrical.

 

 

Link to comment
Share on other sites

I'm still thinking ANTIC mode 4, and I'd like the create that EXACT star field, or so visually close as to be indistinguishable.  And how to do that?

 

My current thinking is to write a BASIC program to draw the pattern in graphics mode, which I think is 1 pixel (17 blank ones), 1 pixels (17 blank ones), 2 pixels (17 blank ones), 0 pixel (17 blank ones) over and over.  Have to experiment with that offset #.

 

Then, save that image, load it into Graph2Font, and let it make it into redefined characters.  There will have to be some X by Y repeating block of SOME size, based on however that modulo works out to.  Probably easier than even attempting to do it mathematically.

 

I never even program in Atari BASIC, but this looks like the easiest way to do it...   I guess.  Just hoping for ideas.

 

It's like a 'graphic art' issue combined half-and-half with a programming issue, sigh...

 

EDIT: Just to be clear about my goal, what I'm wanting to do with ALL of these 2600 ports is to put the same exact 2600 game on the A8.  Not a conversion, or adaptation, or re-write or any of that.  A 1:1 hardware port.  Of course there has to be a "middle-ware" layer to adapt the 2600 kernel into an ANTIC DL / DLI's, and that's the part I have to do.  Otherwise, I want them running the exact same game code.

 

It's actually easier for me to do it that way.  And I always throw in some "minor" graphics touches, I can't help myself... ?

 

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

I'm very much NOT an Atari BASIC guy (maybe 40 years ago) but this looks pretty close, I think:

 

10 GRAPHICS 15+16:COLOR 1
20 X=0:Y=0:M=0:OFFSET=17
30 SETCOLOR 1,0,14
40 X=X+OFFSET
50 IF X>159 THEN X=X-159
60 M=M+1:IF M>3 THEN M=0
70 IF M=0 THEN PLOT X,Y
80 IF M=1 THEN PLOT X,Y
90 IF M=2 THEN PLOT X,Y:PLOT X+1,Y
100 Y=Y+1
110 IF Y<=159 THEN GOTO 40
120 GOTO 120

 

This is JUST to experiment, but I guess if I run this pattern at 4 different offsets, in 4 different colors, I can color-cycle the 4 colors and get animation AND changing colors for free.  The end result won't be programmed in BASIC, LOL.

 

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

If some helpful ATARI BASIC programmer comes along who wants to help (I hate BASIC) here's something "closer"

 

10 GRAPHICS 15+16:COLOR 1

20 X=0:Y=0:M=0:OFFSET=17
30 SETCOLOR 0,0,15
40 X=X+OFFSET
50 IF X>159 THEN X=X-159
60 M=M+1:IF M>3 THEN M=0
70 IF M=0 OR M=1 THEN PLOT X,Y
90 IF M=2 THEN PLOT X,Y:PLOT X+1,Y
100 Y=Y+1:IF Y<159 THEN GOTO 40
210 COLOR 2:X=0:Y=8:M=0
230 SETCOLOR 1,10,10
240 X=X+OFFSET
250 IF X>159 THEN X=X-159
260 M=M+1:IF M>3 THEN M=0
270 IF M=1 OR M=2 THEN PLOT X,Y
290 IF M=3 THEN PLOT X,Y:PLOT X+1,Y
300 Y=Y+1:IF Y<=159 THEN GOTO 240
1000 POKE 708,0:POKE 709,15
1010 FOR X=1 TO 300:NEXT X
1020 POKE 708,15:POKE 709,0
1030 FOR X=1 TO 300:NEXT X
1040 GOTO 1000

Link to comment
Share on other sites

Can't imagine doing the starfield with P/M graphics, it'd eat a huge amount of the horizontal blank time for rewriting registers.

 

It doesn't look like Cosmic Ark has very high needs graphically, so my instinct here would be to use two quadruple width players for the ark and implement the playfield as LMS-per-line of mode E, reusing different byte offsets of the same star line with four copies shifted by one pixel and cycling through different display lists. This avoids the badlines of mode 4, which otherwise might make the kernel or DLIs difficult at some vertical offsets. It also makes it faster to rewrite the repeated pattern for the game over effect and allows the possibility of reserving a playfield color and patching the display list to do the planetary defense laser instead of using a kernel/DLI to do it.

 

Spitballing on allocation:

 

Playfield: starfield, ground, planetary laser

Player 0, 1: ark, beasties

Player 2: meteor

Player 3: shuttleship

Missile 0, 1: planetary defenses, meteor side masks

Missile 2: ark shot, HMOVE lines

Missile 3: tractor beam

 

  • Like 2
Link to comment
Share on other sites

Yup, I want to get as much "bang for my buck" programming-wise as possible.  But I think I'd rather not require tons of RAM to run a 4K 2600 game either.

 

So it looks (to me) like creating the star field in mode E in BASIC, then converting that to mode 4 for use in the program is the best way.  I could even use HSCROL (maybe with VSCROL) and move the whole area around as one big block to get movement / animation.  I think VSCROL might mess with DLI placement though, for use in coloring the Ark.

 

I was thinking of having a DLI for the Ark at the top, using a variable number of WSYNC's to "get into position" and then "colorize" the Ark with a little kernel like the Activision horizon, reading the color values from a table.  And another little "kernel" DLI down lower for the mountains.

 

Every other player / missile could then be single colored.  I haven't written a single bit of code for any of this yet, just trying to get it all worked out in my head first.

 

  • Like 2
Link to comment
Share on other sites

Yes, I think mode E will be the most easiest way. It's a very repetive, I think some 6 characters mode E can do the trick, copy the dedicted animated characters to the characterset, and use a lot of DLI for the color or to go to black. But there will be a lot of finetuning ?

For some 6 years ago I had thesame struggle while making Cosmic ark as a Javascript game. The animated starfield took lots of time to tweak, and it still wasn't perfect to the 2600 one. I never completed the game, it as far as that the ark can shoot the meteorites. If you're interested to take a look at it I can sent it to you.

Link to comment
Share on other sites

3 hours ago, ClausB said:
On 12/29/2021 at 5:17 AM, Irgendwer said:

AFAIK a similar principle is applied here:

 

Exactly correct.

Sorry to be off topic to this thread (watching with great interest - Cosmic Ark is in my top 5 all time 2600 games).  @ClausB - would you happen to have the source code to this demo?  I know when I met you a few years back I mentioned it was one of, if not the 1st program I ever downloaded with my 300 baud modem.  Would be neat to see what made it tick so to speak.

  • Like 1
Link to comment
Share on other sites

20 hours ago, Stephen said:

Sorry to be off topic to this thread (watching with great interest - Cosmic Ark is in my top 5 all time 2600 games).  @ClausB - would you happen to have the source code to this demo?  I know when I met you a few years back I mentioned it was one of, if not the 1st program I ever downloaded with my 300 baud modem.  Would be neat to see what made it tick so to speak.

Sure!

XMASTREE.SRC.txt

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

Proof of concept for emulating the starfield on GTIA, based on the original. Basic approach is eight pre-shifted scanlines replicated by a massive display list with mode C + LMS on every line; LMS does byte shift, swapping between scanlines does the bit shift. The additional scroll offset from moving TIA M0 back and forth is then done by rewriting the lit-up part of those scanlines. It doesn't replicate the missing or double-width stars that appear in the original, though that can probably be somewhat implemented by sprinking scanline variants. The GTIA playfield is only used for the starfield and the terrain; everything else is mapped to P/M graphics including the ark.

 

There are two additional factors that make the starfield tricky to emulate. The first is that replication is turned on along with changing widths during game over, which makes this the nastiest form of TIA replication I've seen. I have some ideas on how to implement this, but will probably require switching over to HSCROL for the bit shift, assuming that the kernel is now light enough to allow for the extra DMA. The other issue is the planetary laser. It's implemented using a full on TIA playfield, which can't be implemented on GTIA with P/M graphics short of using all players and missiles, so practically only the GTIA playfield can do it. What I did was set COLPF1 and COLPF2 to the TIA playfield color and then temporarily flip the display list lines from $4C (mode C + LMS) to $4F (mode F + LMS). This forces PF1/PF2 to appear since mode F is a hires mode.

 

The spacing for the starfield effect is -17 pixels per scanline wrapping every 160 pixels, btw, which will make character mapping difficult since 17 is a prime number and not a factor in 160. Practically, this means that even just emulating single dots with no variance will require a dot at every possible X and Y offset within the character cell, or a minimum of 32 characters in mode 4 or 64 characters in mode 6. The color of the starfield is also changed every two scanlines based on an XOR against the vertical position, so it practically requires a full-screen kernel -- there's no room for DLIs.

 

These are the TIA allocations used by Cosmic Ark, and how they are mapped in this PoC:

  • Starfield: M0 -> PF0
  • Meteor: P1 -> P1
  • Ark: PF -> P2+P3 (4x).
  • Shot: M1 -> M1 (%10 1x for vertical or %11 4x for horizontal)
  • Shuttleship: P1 -> P1
  • Tractor beam: BL -> M2
  • Beasties: P0/P1 -> P0/P1
  • Beasties in tractor beam: M1 -> M1
  • Planetary defense arms: PF -> P2+P3
  • Planetary defense laser: PF -> PF1+PF2 (hires)
  • Terrain: PF -> PF0
  • Score: P0+P1 triple interleaved -> PF1 via 2 x mode 6, VSCROL hack to get 10 lines
  • Energy bar: P0+P1 triple interleaved -> PF0 (mode B)
  • Score box: PF -> P2+P3

Meteor/shot/ark hit detection use TIA collisions, but interestingly the planetary defense laser does not -- it is done by comparing vertical positions instead. There is some corruption near the bottom due to P/M graphics being erased too early, vertical blank time is tight.

 

cosmic.obx

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

A bit late to this party, I recall reading something in an interview of the fellow who wrote Cosmic Ark and he hinted at the starfield being a quirk of the TIA which he discovered and even guys like David Crane thought was ingenious. I don't know if he shared the trick but it seemed like something he kept in his arsenal of programming. Why not disassemble the 2600 ROM to see what he did? If it was possible to drive the GTIA the same way... Probably doesn't have the same quirk.

Link to comment
Share on other sites

10 hours ago, Mrshoujo said:

A bit late to this party, I recall reading something in an interview of the fellow who wrote Cosmic Ark and he hinted at the starfield being a quirk of the TIA which he discovered and even guys like David Crane thought was ingenious. I don't know if he shared the trick but it seemed like something he kept in his arsenal of programming. Why not disassemble the 2600 ROM to see what he did? If it was possible to drive the GTIA the same way... Probably doesn't have the same quirk.

It's hard to tell what's going on from the disassembly since the game relies on a subtle bug in TIA's HMOVE logic that would be very difficult to figure out without testing it against the hardware. The bug is similar to the abnormal/disrupted playfield DMA bug in ANTIC in that it depends on changing the move value during the HMOVE process so the TIA forgets to stop it and it keeps going. The mechanism is pretty well understood by now, however.

 

GTIA doesn't have HMOVE capability and its P/M graphics are built very differently than TIA's, so it's unlikely that a similar bug exists. The closest bug would be the one that lets you lock a P/M graphics shifter via width 2 so it constantly outputs a solid block of color.

 

6 hours ago, Philsan said:

Am I wrong or you've done the game? ?

Mostly, it has some bugs. There was a game in the way of the starfield. :)

 

5 hours ago, glurk said:

Well, I suppose I need to find a different game to work on now!!  LOL...  ?

Sorry, didn't mean to preempt you -- but it's not done yet, the starfield could be improved a lot to better match the original and you might have some better ideas. Cosmic Ark is a fairly easy disassembly, code and data mostly separated and no nasty tricks like offset indexing. I mostly reversed it by hand but a 2600-oriented tracing disassembler like distella should make short work of it. I'd say getting to this point was probably more difficult than Combat or Adventure but easier than Seaquest.

 

 

  • Like 5
Link to comment
Share on other sites

Hey, I couldn't do a bit better than what you've already done.  Just FYI, Thomas Jenztsch has already disassembled and commented this one, so I was using his disassembly along with the listing and symbol files.  Stella loads them right up, so all the RAM locations are named.

 

One thing I did do was convert the 9-line font into an 8-line font, so the score part could just be a single mode 6 line, maybe with a block on either side.  I was going to do the energy bar same way, or maybe in mode 4.  If it helps at all, here's the font I made, it's only the numbers 0-9:

 

cosmicark.fnt

 

EDIT:  I'm certain you've thought of it already, but you could have just one LONG star field line in memory, with the 2x-pixel and 0x-pixel stars patterned into it, and just LMS to various points along that line.  Basically like what you said already...

Edited by glurk
  • Like 3
Link to comment
Share on other sites

2 minutes ago, _The Doctor__ said:

nothing says you need to stop your work glurk, your approach might be different but the outcome might be the same or better. You other ports prove that you have a great mind for it and can do a wonderful job!

Thanks, but phaeron knocked out most of the whole game while I was still pondering the best way to do the stars.  There's no need for us to duplicate efforts now, I hadn't done much on it anyways.  My inclination is always to use as little RAM as possible, but now that we have this version, using mode C, throwing a little more memory at it to do the "correct star field" might be best.  I think it would take 2K RAM, if I'm calculating right.

 

And just 'guessing' but if the score and score-box area are done in charmode, it might free up enough resource(s) to eliminate that glitch.  I suspect he'll have the whole thing perfect in a day pr so anyways!!  Haha.

 

I'm not nearly as fast a programmer as phaeron, I'm kind of slow at it, and I use a different approach.  He does more of a "kernel" type thing, and I prefer using redefined characters, HSCROL, VSCROL, and DLI's all over the place.  My approach only works for certain games, though, and his is more flexible.

 

If the only thing I contributed to this one is posing an interesting question that "got the ball rolling" I'm totally OK with that!!  And then I can work on something else, and we'll all get more new games.  Win/win for everyone.

 

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

32 minutes ago, glurk said:

I'm not nearly as fast a programmer as phaeron, I'm kind of slow at it, and I use a different approach.  He does more of a "kernel" type thing, and I prefer using redefined characters, HSCROL, VSCROL, and DLI's all over the place.  My approach only works for certain games, though, and his is more flexible.

This is really more out of necessity than anything else. 2600 games have to use a kernel, of course, which in turn means that they tend to do things that are also only possible on ANTIC+GTIA with a kernel. Rampant per-scanline color changes alone are the main reason that removing the kernel simply isn't feasible for many games. It's also an artifact of the way that I bootstrap a port, which is to find the vertical blank routine, bolt the input and sound drivers on it, redirect the color+player writes to GTIA, and try to get the main kernel up and running as the basis for further work.

 

The other factor is CPU time. A kernel sounds bad, until you realize that a DLI also has rather high overhead -- about 1-2 scanlines of CPU time just to get into the DLI, synchronize, and get out. They're also subject to mode line boundaries in the display list and timing problems around IR modes 2/4. Where there are lots of consecutive or closely spaced changes, it often isn't possible to run individual DLIs, so you end up combining them into big chunky DLIs that are essentially the same as a kernel.  Where that doesn't happen, moving to DLIs and P/M graphics can instead put pressure on VBI time. Rewriting P/M graphics every frame is expensive and is one of the bigger problems I end up dealing with after getting the sprites ported, since there just isn't enough time to rewrite large portions of P/M memory and still run the 2600 VBLANK code. Sometimes this results in moving P/M updates back into the kernel because racing the beam there uses CPU time that would otherwise be wasted and frees up more of VBLANK.

 

As for tiled/scrolling playfields, they can be handy to emulate replicated players and IIRC I used them for Seaquest and Stampede. They can be difficult to use at times because 2600 programmers inconveniently don't feel a need to align anything vertically to groups of 8 or 16 scanlines.

  • Like 1
  • Thanks 1
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.

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

  • Recently Browsing   0 members

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