New home res games

[VladR]

Give me a road that looks this cool. Shit - don't give me a road. Give me a planetary shooter that looks this good!!! (See thumbnail of this embedded video).

https://youtu.be/qE-UrcmsbeU

That's a simple but powerful Antic effect- you just skip scanlines based on table, and just update LMS pointer to each scanline-easy at 60 fps, leaving plenty cycles for gameplay.

 

Are you thinking along the lines of The Last Starfighter's planet sequence? That might work.

[VladR]

Actually, thinking about it, I just realized one of the first jaguar 's road versions might work on Antic too- I am just unsure if 64 Kb Ram would be enough - I need to spend some time in excel, but have a feeling that pretextured road at 128x96 might work at almost zero CPU computational time - the only time would be spent on moving texels to second frame buffer - which can be unrolled very well...

So, here goes:

-160x96x4

- road takes up 32 scanlines

- lowest scanline is 128px, gradually decreases towards 1(for simplicity of calculations)

- 1 frame of road thus has 128x32/2=2048 pixels, which is 512Bytes, e.g. 0.5 KB

- if we target 20 fps, we need 20 x 0.5 = 10 KB for all texture frames- easy on 64 KB

- at runtime we just need to copy those 512 Bytes to FrameBuffer

- a bruteforce copy of lowest scanline, which is 32 bytes, would take 17 cycles per byte, e.g. 544

- with 32 road lines, the total is then 544*32/2=8,704 cycles and that's like the slowest possible version, yet we still have 2.6 frames worth of cycles available

- this could scale to 30 fps - with 30 frames in Ram taking 15 KB, yet still leaving us with 48000-8700= 39300 cycles for game

 

There would be some padding-e.g 2 more bytes per scanline, for edges, which is 64 bytes per frame, so no problem either.

 

The texture frames are precalced offline, of course. At runtime, we just copy it to frame buffer.

 

I'm just wondering, why the hell, no one bothered to do this yet?!?

[emkay]

Wait, I thought we were talking about road with perspective like in Outrun / Pole Position. Not the simple 2D rectangular road like in FireChief

That's the "lack of imaginations"

 

Where's the difference, to change the PMg per scanline, or to change the scanlines?

 

Let the background use for the road, you have to use a fixed DL mode. You put the best part for details to a flat road projection and need to put a complex multiplexer to the PMg , lose a lot of details and moving objects.

 

Let the PMg do the road, it help to do that half the way. Then you get the possibility of changing ANTIC modes on the fly. if it is wanted. And you could put "free moving objects with best details" to it.

In theory, you could place a Gr. 0 line in a upper part, displaying small objects, switch to color mode the next time to zoom it over several lines.... and so on...

 

not to forget: You could do full lines of moving objects just by setting LMS....

Edited October 14, 2017 by emkay

[VladR]

The idea to switch gradually from single scanline mode to double and then quadruple is interesting- this would definitely be very Atari-specific, In fast movement it might look okay, though it'd look bit funky.

 

But how do you want to adjust road's curves? Via Antic, it's fast. But for Pmg you need DLI, which will kill all performance via WSync, so in the end there's no performance advantage.

[Heaven/TQA]

Give me a road that looks this cool. Shit - don't give me a road. Give me a planetary shooter that looks this good!!! (See thumbnail of this embedded video).

https://youtu.be/qE-UrcmsbeU

Thats my fave scene from our demo....

 

Its good example of how you get a nice consistent look with low tech...

 

The music is perfect fitting while Aliens pixel artwork fits with the layered sprites on top and shaking...

 

All simple fx, same with the battle star....

 

I was inspired by the SNES games (obviously Axelay) and their intermission screens... good times.

 

Ah the readme on the YouTube says it all;)

Edited October 14, 2017 by Heaven/TQA

[emkay]

The idea to switch gradually from single scanline mode to double and then quadruple is interesting- this would definitely be very Atari-specific, In fast movement it might look okay, though it'd look bit funky.

 

But how do you want to adjust road's curves? Via Antic, it's fast. But for Pmg you need DLI, which will kill all performance via WSync, so in the end there's no performance advantage.

You don't need wsync there

 

vice versa.... even if WSYNC were wasting CPU cycles, you could move the whole background with some pokes...

Edited October 14, 2017 by emkay

[NRV]

... But for Pmg you need DLI, which will kill all performance via WSync, so in the end there's no performance advantage.

Remember that you could also use IRQ's if you want to sync some changes to a specific horizontal position.

It's not perfect (there is some jitter, according to what instruction was interrupted), you lose one audio channel (well, you can use it for samples..), but you can avoid stalling the cpu for some cycles.

[emkay]

Remember that you could also use IRQ's if you want to sync some changes to a specific horizontal position.

It's not perfect (there is some jitter, according to what instruction was interrupted), you lose one audio channel (well, you can use it for samples..), but you can avoid stalling the cpu for some cycles.

Using IRQs is another option. Losing one POKEY channel could still result in a listenable tune, but the benefit is there, as ANTIC modes could be used completely free ....

[Sheddy]

Indeed. Wsync is fine too - before writing it there're some cycles to do stuff. It's just that you're having to interrupt every few scanlines or so which is the terrible drain. At that point you may as well do a screen kernel

Problem with wiggling playfield scroll for road is how do you do loads of soft sprites then?

Edited October 14, 2017 by Sheddy

[emkay]

Indeed. Wsync is fine too - before writing it there're some cycles to do stuff. It's just that you're having to interrupt every few scanlines or so which is the terrible drain. At that point you may as well do a screen kernel

Problem with wiggling playfield scroll for road is how do you do loads of soft sprites then?

A Kernel is "only" needed for the height of the road. Game logics and screen handling can be done "the other time".....

Soft Sprites?

Using char-mode playing with LMS and changing parts of the screen memory there, saves a lot of CPU time.

Driving through a bridge with a Ferrari could be done "1 frame" ... which means 50fps on a PAL machine. This wouldn't be needed as the low resolution needs less updates for the "sprites"

[Sheddy]

If things were kept flat then there could be some milage to that for sure. Outrun hills and sprites hidden by hills might be too complex.

[emkay]

If things were kept flat then there could be some milage to that for sure. Outrun hills and sprites hidden by hills might be too complex.

What you're talking about?

Have you watched the C64 ...cuff.. version? Cars flying in the Air , Objects move uninspired beside the road... and so on....

 

"Softwaresprites behind a hill" ? this solves itself by the selection of the LMS positioning.

[Sheddy]

Exactly. If you want to do it so it looks nice, it is more complex.

...And the large sprites in front of the hill at the same time as those behind it will need to take that LMS into account.

[emkay]

Exactly. If you want to do it so it looks nice, it is more complex.

...And the large sprites in front of the hill at the same time as those behind it will need to take that LMS into account.

selecting the range via LMS and to change about 8 bytes in that line will do more than to change 32 bytes of a line "visually....

 

The main problem is that there is no other version usable for a game conversion.

If someone wants to put such games to the A8 , he had to do all from scratch.

Edited October 15, 2017 by emkay

[Sheddy]

If more limits on positioning cars and road(s), are imposed, something a bit like Outrun could be possible. Getting nicer results than Pole Position, Pitstop or Elektraglide would be very difficult though. Free placement of colour would be limited with hills and massive sprites.

[emkay]

If more limits on positioning cars and road(s), are imposed, something a bit like Outrun could be possible. Getting nicer results than Pole Position, Pitstop or Elektraglide would be very difficult though. Free placement of colour would be limited with hills and massive sprites.

As the car should be build on Antic 4 (... or even 5) , it should be no problem to have some separated colors.

[VladR]

You don't need wsync there

 

vice versa.... even if WSYNC were wasting CPU cycles, you could move the whole background with some pokes...

I don't think we're talking about same scenario here. If the road is done as PMG, you need every road scanline at different xpos (because of the curves) - which must be interrupted each scanline via DLI, hence WSYNC.

 

 

Remember that you could also use IRQ's if you want to sync some changes to a specific horizontal position.

It's not perfect (there is some jitter, according to what instruction was interrupted), you lose one audio channel (well, you can use it for samples..), but you can avoid stalling the cpu for some cycles.

Right! I keep forgetting about IRQ. Thanks - I'll look into them again.

 

 

Indeed. Wsync is fine too - before writing it there're some cycles to do stuff. It's just that you're having to interrupt every few scanlines or so which is the terrible drain. At that point you may as well do a screen kernel

Problem with wiggling playfield scroll for road is how do you do loads of soft sprites then?

True - that time is not completely lost to CPU being idle - and thinking about it now again, by the nature of the road rendering, each screen scanline corresponds to road scanline, so we might as well do the horizontal positioning inside DLI. Probably it could be done very fast - by indexing the current scanline number (the array of XPOS offsets per each scanline, would have to be already prepared, of course)...

 

 

If things were kept flat then there could be some milage to that for sure. Outrun hills and sprites hidden by hills might be too complex.

Was there ever a racing game on 8-bit Atari that had proper hills ? I don't remember playing any game like that. Otherwise, hills are not too complex to implement, well - as long as we don't need 60 fps

 

 

Getting nicer results than Pole Position, Pitstop or Elektraglide would be very difficult though.

Technically, it's actually easy to get nicer looking results. It's just the resulting framerate that is the problem

 

But I agree - for me personally, ElektraGlide represents the visual maximum of racing games achievable on Atari at 60 fps.

[emkay]

I don't think we're talking about same scenario here. If the road is done as PMG, you need every road scanline at different xpos (because of the curves) - which must be interrupted each scanline via DLI, hence WSYNC.

Partly right. If you put all the "road creation" into a kernel, which can start at the upper line of the road and runs through the whole height of the road, you need exactly one WSYNC, for 100% stability. Using a char- mode in that range offers the most movement on the screen... including the car positioning.

The rest of the screen should be done by less cycle intense modes. So game calculations, controls, and "zooming" objects may find their time.

[VladR]

Partly right. If you put all the "road creation" into a kernel, which can start at the upper line of the road and runs through the whole height of the road, you need exactly one WSYNC, for 100% stability.

I have in past implemented DLIs, not kernels, so my understanding of kernels is limited - what I recall is that in a kernel you turn DMA off, so Antic doesn't steal your cycles (though then you gotta do all its work yourself).

Then you need to compose each screen scanline, and you have fixed amount of cycles per each screen scanline (e.g. 1.79 Mhz / 60 / 224 (or similar)).

If I interpret it right, a road could be simply "drawn" by changing background color register at the right cycle spot [within the screen scanline] - e.g. no writing to no framebuffer needed.

 

But this ray-chasing cannot be generalized for a racing game, where each frame takes different amount of cycles, as the number of objects on the screen differs, as well as their computational expense.

 

What if you run out of cycles for current scanline, but need to display a sprite's scanline ? You're screwed.

 

That's why I believe a double-buffer approach gives you most flexibility. If the current-frame's combination of sprites takes more time, the framerate will temporarily fall, but at least it will work (not the case with kernel, as they simply must run at 60 fps). If we run out of time during kernel, we either don't display scanline (ugly artifact), or it will flash or jitter.

 

 

That being said, a non-playable racing compo demo could be, indeed, painstakingly timed, ray by ray, from within a kernel - but putting that much work into something that cannot be extended seems very counterproductive.

 

The rest of the screen should be done by less cycle intense modes. So game calculations, controls, and "zooming" objects may find their time.

I don't think that's gonna work that way. Those "zooming" objects (e.g. signs, shrubs, trees, people) cross the exact same scanlines that the road occupies. So, if we're chasing the ray, we must handle them at the given screen scanline, no ?

 

 

Thinking about it, plan B would be to use the kernel just to change the PMG/color register values, and leave the gameplay and sprite code for the vbl (~4,000 cycles or so). But that's not going to be enough for racing game, I believe - you gotta compute the curve offsets, update HUD, check input, collision, play audio, let alone sprites). Maybe in some super low resolution like 80x48, where vbl should be much longer than those ~4,000 cycles (well, if that's how it works - I just presume that vbl should be much longer in a much lower resolution, as Antic does not steal as many cycles)...

 

 

 

What's the most interactive playable kernel that was ever done on A800 ?

[emkay]

I have in past implemented DLIs, not kernels, so my understanding of kernels is limited - what I recall is that in a kernel you turn DMA off, so Antic doesn't steal your cycles (though then you gotta do all its work yourself).

????

Who said that? The Kernel is for the PMg without DMA.... not the playfield!

 

 

 

 

 

I don't think that's gonna work that way. Those "zooming" objects (e.g. signs, shrubs, trees, people) cross the exact same scanlines that the road occupies. So, if we're chasing the ray, we must handle them at the given screen scanline, no ?

 

 

 

I cannot believe reading this.

ALL in the playfield needs less than 50 or 60 fps (possibly 12 fps), and since it's using standard ANTIC modes, they were displayed at the same time when the kernel handles the road "adjustment" . To save CPU time there, it is useful to bring the car handling in the kernel ... the music replay could also fit in there, actually everything that could run in the VBI, till the kernel time is full...

 

 

 

 

 

 

What's the most interactive playable kernel that was ever done on A800 ?

 

 

 

There isn't much, except in some demos...

Edited October 20, 2017 by emkay

[VladR]

????

Who said that? The Kernel is for the PMg without DMA.... not the playfield!

Well, that must be my (mis)interpretation of Kernel's description in DeReAtari, which spans a whopping 2 paragraphs [page 5-7], so I've obviously interpreted things wrong.

 

Correct me, if I'm wrong, but kernel is a 6502 code that takes as many cycles as the whole visible screen (e.g. ~75% - depending on visible scanlines count), so via careful timing you can tell for each 6502 instruction, where the ray is on screen (X,Y).

Thus, you know what kind of color/position you want for each player/missile (based on X,Y) and adjust the given register accordingly.

 

But why couldn't I change the register also for the 5 (playfield+Bk) colors ? Isn't that exactly what RastaConverter does ? Changes both PMG color/size/pos registers AND Playfield0-3+ColBk registers based on the (X,Y) ?

[Heaven/TQA]

Kernel in 2600 Land means building the display in a long racing the beam cycle.

 

In a8 mainly feeding the PM registers without DMA by Antic or setting color registers.

 

As Vladr pointed out it will be challenging to achieve that in a game scenario where game play etc comes into way.

 

But shuffling LMS instructions around for the road incl up down in a VBL plus gameplay like cars and zooming objects will be nice task.

 

Kernel would set the road colors plus curves.

 

How is that C64 game called from System 3? Turbo charge?

[Heaven/TQA]

[emkay]

Well, that must be my (mis)interpretation of Kernel's description in DeReAtari, which spans a whopping 2 paragraphs [page 5-7], so I've obviously interpreted things wrong.

 

 

Correct me, if I'm wrong, but kernel is a 6502 code that takes as many cycles as the whole visible screen (e.g. ~75% - depending on visible scanlines count), so via careful timing you can tell for each 6502 instruction, where the ray is on screen (X,Y).

Thus, you know what kind of color/position you want for each player/missile (based on X,Y) and adjust the given register accordingly.

Look at the time, when that book has been written. There were a lot of misleading informations put in. One is the "High Pass Filter" of POKEY, which actually is none.

Similar with "Kernel" , which means to put the "full range" of CPU to race the beam , to change content "on the fly" on the screen.

If you use that for the PMg only, this will not interfere the ANTIC stuff. And if you do that for the height of the displayed road, a lot of cycles will be free for other stuff. It's just that every 1st line of a char-mode, 40 cycles weren't usable for manipulations.

 

But why couldn't I change the register also for the 5 (playfield+Bk) colors ?

In which case? From the Atari hardware it is no problem.

Edited October 20, 2017 by emkay

[Heaven/TQA]

Power drift has nice zooming but player seems char based as it changes colors to background colors?

 

And absolutely bad is the road going up the sky without border left right