is anyone making a conversion Antarctic Adventure for the Atari 8Bit

[emkay]

The moment we invoke beam racing (for more colors, and more positions of PMG), all performance for flatshading is gone, even halting 10 scanlines is pushing it...

It's a bit hard to count the fps of that game in the video ... seems like 8-12 with some interleaved displayed objects.

If it's possible to get up to 20 fps with sheer "3d rendering" , the game itself shouldn't drop the fps too much.

Also, when using the PMg , there is no need for WSYNC, just add the DLI bit to the range for coarse adjustments. That shouldn't also take too much CPU cycles.

The scene should be build on full software, including the penguin ... for the main "bytes" . the borders could be filled with missiles. Same with other objects... Draw the main part in the background and overlay the needed parts for some details and or colors.

[VladR]

It's a bit hard to count the fps of that game in the video ... seems like 8-12 with some interleaved displayed objects.

Yeah, I usually notice that it must be under 10 fps, if you can recognize discreet frames and your eye has enough time that it can stay fixed on the frame for a bit.

But with charsets, there's really not much choice without requiring 128+ KB, unless the game engine can actually draw the scene into those charsets at loading time.

 

 

If it's possible to get up to 20 fps with sheer "3d rendering" , the game itself shouldn't drop the fps too much.

The reason why we can get close to 20 fps is that:

1. 0 cycles : ClearScreen

- we don't have to clear the framebuffer, as the sea and land cover 100% of the gameplay area

- that's quite a substantial portion of the first frame time (up to 75% actually, depending on how much RAM you want to sacrifice for unrolled clearing)

 

2. 3,200 cycles : Sea

- the sea polygons are by definition flat, which can be used to great performance advantage, e.g.:

- we don't have to engage in an expensive fixed-point scanline traversal involving edge computations, lots of tables and temporary arrays

- the sea starts at left edge of screen and ends at middle of screen (e.g. 20 Bytes), then with each other scanline , we store 1 Byte less

- there's about 40 scanlines of sea, so we need to store 40*20/2 = 400 Bytes on left side of screen and if visible, also 400 Bytes on right side of screen

- this can be done via completely unrolled code, no indexing, just a fastest 4-cycle STA $3017, as we know exactly each address of each pixel's byte

- thus the sea will take only 800*4 = 3,200 cycles and as an added bonus, it takes care of erasing the edges of the land polygons

- RAM costs would be 3 Bytes per STA, so 800*3 = 2,400 Bytes. Quite acceptable

- So, we've spent so far only 3,200 cycles out of our budget of 60,000 and handled clearing and sea, and about 40% of the 3D viewport (looks to be around 58-64 scanlines)

 

3. 7,160 cycles : 3D Transform of vertices

- So, now we're left with rendering the land, holes, and characters (in that order, using the painter's sorting approach). There's about 15-20 quads for land and roughly 30-40 vertices.

- The transform stage of pipeline thus will take 179*40 = 7,160 cycles, as I need 179 cycles to read, transform and store the vertex in a loop.

 

4. 13,782 cycles : Inner scanline quad-pixel fill

- let's go with the worst-case scenario : 66% of the viewport needs to be filled for land

- 0.66*160*64 = 6,758 pixels, that's 1,689 quads (4-pixels via STA)

- my last benchmark shows I can do 789 quads across multiple polygons, in 6,435 cycles, hence 6,435/789 = 8.16 cycles per quadpixel

- 8.16 * 1,689 = 13,782 cycles

 

5. 7,552 cycles: Scanline loop traversal

- 118 cycles per scanline

- we have 64 scanlines, thus 64*118 = 7,552 cycles

 

6. 1,920 cycles: Scanline Edge draw

- doing OR with framebuffer, for nice, blending of colors across byte boundaries

- 15 cycles per edge

- 64*2 = 128 edges, thus 128*15 = 1,920 cycles

 

All together: 1,920 + 7,552 + 13,782 + 7,160 + 3,200 = 33,614 cycles out of 60,000 budget, so we still have about 27,000 for the things like holes in ground and characters, input and still retain 20 fps.

 

Hell, it even looks, like a simple scene could hold 30 fps (~40,000 cycles), especially if we have PMG-only characters. Not sure right now, how many cycles it takes to draw transparent characters onto the background via CPU. That's going to be a lot, probably - haven't looked into that yet. Maybe we could try a 3D penguin ?

For sure on PAL, as 2 frames there result in roughly 50,000+ available cycles.

 

 

Also, you can't avoid the differences in the amount of cycles it takes to render the frame. It's just the nature of the beast - with so many different pipeline stages, each having different performance characteristics, it's just the way it is.

But as long as the scene complexity - especially the scanline count (that's the one which accounts for majority of time taken) - stays roughly constant between the frames, it shouldn't oscillate more than, say, ~20%, from frame to frame. At least that's the number I got when testing the tunnel flythrough. This does look very similar.

 

I am, however, convinced, that even larger framedrops would be acceptable, as the speed of movement is slower than in a car racer, plus you can literally only jump and go left/right

 

 

Also, when using the PMg , there is no need for WSYNC, just add the DLI bit to the range for coarse adjustments. That shouldn't also take too much CPU cycles.

But without WSYNC, there's going to be jitter. What kind of coarse adjustment without WSYNC to PMG can you do that won't be an ugly jittery glitch ?

 

We can easily do about 4 register changes per scanline during DLI, correct ? At the very least, I'd sacrifice few scanlines-worth of CPU time time to get:

1. Skybox colors

2. Fog in distance colors

3. Regular colors for 3D viewport

 

The above, at the cost of only 3 scanlines (~250-300 cycles per frame) will enhance the 4-color look substantially. Any additional color enhancement would cost us a lot more CPU time, as we'd need way too many DLIs after that point to get those additional colors noticed, I suppose.

 

 

The scene should be build on full software, including the penguin ... for the main "bytes" . the borders could be filled with missiles. Same with other objects... Draw the main part in the background and overlay the needed parts for some details and or colors.

Or, we could go for 15 fps, but would be able to spend another 50,000 cycles on additional objects - e.g. buildings, snow plows, barrels, boxes, planes, ship on sea....

Of course, not at the same time on one screen, it's 1.79 MHz after all

 

That's the beauty of 3D graphics, the full control you have over the scene and adding/removing things, adjusting resolution, creating 3D art in notepad...

[Spanner]

Any luck with this, I know its a old post now, but you never know someone might of tried to do it...?

[José Pereira]

On 9/12/2016 at 1:40 PM, José Pereira said:

Hi.

It was easy , the game doesn't seems hard and is really possible.

 

All in charmode, less c.p.u. comsumption and DLIs for changing PFs colours between the different zones:

-> The top status is an easy GR.0 using 1charset;

-> The sky/horizon in GR.12/ANTIC4 with hardware horizontal scrolling to move left & right the mountains/icebergs when there's the walkways turnings using other charset;

-> The playing area again in GR.12/ANTIC4 where:

BAK: darker;

PF0: middle gray;

PF1: white;

PF2: blue;

PF3: light gray;

 

I decided to use dark gray (04) instead of a pure black (00) for BAK because of the crevices doesn't have their inside 3colours too much difference netween the 2grays and dark.

And this same reason gives 'our guy' penguin then the pure black because he's only 2PMGs. So for PMGs we'll have:

-> [P0/P1]: black for the penguin and underneath him the shadow is MISSILESin 5th Player mode/PF3 light gray colour;

-> P2 and P3 for the flags, fishes and seals multiplexing them across the screen (seals have use the PMGs over the PFs pixels but it doesn't seem there is flags and fish on its scanlines);

Is simple as many PMGs frames and zooming from horizon untill they reach the bottom ...

For the flags, and we can also invent new and other things, have green and red that would be the ones we could or not cross over (penalty for red and points for green ). Also the fishes can have each any colour across the screen would look very nice .

 

Here's the result (didn't do much, just get the original 1:1 ratio into directly conversion to 2:1):

 

 

At the end of each level the house wall is a simple 2colours DLIs with the country flag with PMGs and the penguin seeing from front can use all 4PMGs to have the red for the tong and a pale green for his bik:

 

 

I'll post this soon and also the map screen so stay tuned ...

 

 

 

 

 

P.s.- And when this one done then the 2nd part is a little bit harder but the same guys PMGs multiplexer and we'll get to the 2nd on the series that is Penguin Adventure ...

 

On 9/12/2016 at 2:04 PM, José Pereira said:

Regarding P2/P3 it is:

-> Each seal: must use the two but there is always only one per line;

Then on other lines and because fish and flag only use one they can be two per line.

 

On 9/12/2016 at 5:42 PM, José Pereira said:

From exactly what I posted here's with only PFs and only PMGs and the two real seen screen for you to get a better idea and how simple I think it would be (following this I did also the map and end of each level, here's with the example of the U.S.A. base):

-> In-game screen:

-> Map screen:

-> Final of level:

 

 

And I can say this one is the simpliest one I ever 'thought on' because it only needed around 6hours to all: watching videos, play, no need for too much thoughts and do the stuff on G2F .

 

On 9/12/2016 at 6:07 PM, José Pereira said:

Now there is only missing one part... the coder , o.k. are missing two parts because is also need someone for the sounds.

 

On 9/14/2016 at 2:30 PM, José Pereira said:

That pictures are all real A8 done with G2F: http://g2f.atari8.info and what I post is my usual ideas 'How it can be done' that sometimes there are coders that catch them and hopefully will happen on this one.

 

On 9/15/2016 at 10:06 PM, José Pereira said:

Got the real size [256x192] screen and this one was simple to, using P.C. Paint program got it into 5colours.

Of course that you need to know that on A8, for example, PF2 and PF3 colour registers can't be on the same char, that you have to watch game videos and play, that the sky blue is same PF as the light gray on the ground just a DLI, that penguin is simple as 2PLAYERS but because is always in front over anything you have to use Prior1 and he must also be P0+P1 to overlap others that use PLAYERS, 2 and 3, that are the flags, fish and seals, that all that use PMGs are 8 or 16pixels wide (1 or 2PLAYERS) so there are MISSILES free to use and the best and we need is to combine them in 5th PLAYER for the penguin shadow but then because of this the PF3 colour register is/was set to the light gray and and so many other things for this and other games.

It's trial and start with something then years and many games after we get into this 'How to' like me and may also find and colaborate with coders.

You just have to start ... and there's always people here and on other places for you to ask and upset with your ideas .

At least I tried showing the possibility and it doesn't seem anything hard and/or that A8 can't do...

[Sinjinhawke]

It was recently ported to Intellivision and looks decent.  Would look great on the A8.

 

 

[MARIO130XE]

If this game can't convert to the A8, the A8 self shoud go to graveyard.

[emkay]

29 minutes ago, MARIO130XE said:

If this game can't convert to the A8, the A8 self shoud go to graveyard.

This only belongs to people with your knowledge.

Atari programmers come regularly from some contra C64 camp. Of course the Atari could do the game. But it won't run by sprite shifters. 

You'd need some real programming professionals. 

If a programmer codes the game for the Atari directly, without being biased by C64 , the game will be outstanding on the A8. 

 

 

 

 

...

 

 

 

....

 

 

..........................................

 

 

.,....................................................................................

but...................................................................................................................................................................................................................................................................................................................................................................................................................................................... . . . .

[glurk]

This is actually something I "could" do.  But I don't really have the time to invest in it.  But I did a little thing.  Here's most of the font to cover the top two lines, without even getting into graphics characters.  Mostly pulled direct from the NES ROM:

 

 

aa.fnt

[glurk]

So I've been messing around with this, just to see what I could come up with, and I got some bits working pretty well.  I'm NOT in any way guaranteeing a completed game, but it's kind of fun to play with.  Here's a "map demo" which is the whole working map, basically.  I think I got 9 distinct colors in there, and it looks very NES-like to me.

 

It's an 8K cart ROM, just because I assembled it like that, but it's mostly blank space right nowAntArc.rom.  I think it looks pretty cool:

 

 

[Mr Robot]

I saw this topic surface and for a moment thought it was about this game!

 

 

 

[VinsCool]

17 hours ago, glurk said:

So I've been messing around with this, just to see what I could come up with, and I got some bits working pretty well.  I'm NOT in any way guaranteeing a completed game, but it's kind of fun to play with.  Here's a "map demo" which is the whole working map, basically.  I think I got 9 distinct colors in there, and it looks very NES-like to me.

 

It's an 8K cart ROM, just because I assembled it like that, but it's mostly blank space right nowAntArc.rom.  I think it looks pretty cool:

Looking good!
Very NES-like, indeed.

[glurk]

Here's a little animated GIF of a "scroll test" bit.  Again, just playing around to see how feasible this all might be....

 

[VinsCool]

That's already a good chunk of the entire screen already! Very nice.

[glurk]

There's an awful lot left...  Like actual gameplay, LOL.  And I dread putting those clouds in, although I know how.  But I'm just flat-out incapable of doing sound or music, so (if that time comes) I'd HAVE TO have some help there.

 

I use my "eating an elephant" approach to coding - "one byte at a time..."  I put in a few elements and get them working, and pretty soon have some kind of a foundation to work with.  As long as it remains fun, I'll probably keep at it, just to see what I come up with.  It's pretty fun to get some stuff on screen, and working, and looking nice. 

 

[glurk]

I'm still playing around with this one in my spare time, so here's a new "demo" or "screensaver" or whatever....  I'm going for the NES/Coleceo/MSX kind of look, like the original, and this has some transitions that look similar to me.  It's only visual, just a demo for my testing:

 

aatest.rom