Top Games You'd Like to Have for Atari 8-Bits

[+MrFish]

Just thought of another fun game which would be a breeze to convert judging by it's graphics and sound:

 

Space Taxi from the C64:

 

Nice simple fun game

 

To my knowledge, someone is already porting this to the A8. Have to search on the forum,

but I recall Philsan having direct info from the developer. Not sure where it's at now; it seems

it was at least a couple of years ago that it was being worked on. I seem to recall there being

some videos of it too.

[VladR]

As you said, shouldn't be a problem to draw all those sprites.

Example of what can be done in 25fps is here. Char mode with 5th color. Enough time to add scrolling and background animation of water and such. Enough chars left free to draw detailed background.

 

 

ps. I would still prefer Galaga over 1942

That's really nice demo! I presume those 14 sprites are pre-shifted ? Roughly how many could you brute-force in 20,000 cycles ? I'm asking, as I'd prefer having as varied background as possible, and only spend 4 chars for each moving sprite (as it can cover up to 4 on-screen chars - well, more if sprite is bigger).

 

Makes you wonder, if we rather chose some slow-moving game, e.g. not a fast-moving plane/car, but a slow-walking human (good useable example might be Aliens movie - the marine segment, where they move very slowly - so the screen shouldn't really scroll more than 10px / second), then we might get away even with 10 fps scrolling (e.g. 60/10 = 6 vblanks). That's over 120,000 cycles for CPU to brute-force any sprites over the background. How many sprites would then be possible ?

 

I suppose we'd run out of 128 chars real quick, so we would need about 4-6 DLIs ? In a way, while a complication of Atari, if we just avoid sorting, then we can have a unique char per each screen position. DLI costs - what- ~125 cycles ? 6*125 = 750 cycles per frame. For 6 frames, we're down 6*750 = 4,500c out of 120,000 - so still over 115,000 cycles. And we can still move the main player at 60 fps (during vblank).

 

Has anything like the above been done on A800 ?

[+Philsan]

I'm completely opposite....1942 over Galaga any day.....

 

 

Just thought of another fun game which would be a breeze to convert judging by it's graphics and sound:

 

Space Taxi from the C64:

 

 

Nice simple fun game

 

 

 

To my knowledge, someone is already porting this to the A8. Have to search on the forum,

but I recall Philsan having direct info from the developer. Not sure where it's at now; it seems

it was at least a couple of years ago that it was being worked on. I seem to recall there being

some videos of it too.

 

Good memory Paul.

 

A friend of mine, White Circus programmer, worked on Space Taxi and I was a tester.

Unfortunately he didn't have the time to continue to work on it.

 

Speech apart, 8 levels were finished, as you can see in those video I recently made:

Level 4 5 6 7 8

[emkay]

The interesting Part of Scape Taxi is that the design allows to have a version on the Atari, using Hires and PMg for the platforms.

 

Also, people shouldn't mix up technical experiments with running games.

 

How about a closer look what could be real ?

 

This is done in Turbo Basic. It also has clean digis available.

 

 

Imagine it , done in Assembler, with additional PMs , DLIs.... lot's of moving objects...

Edited April 13, 2018 by emkay

[Level42]

 

 

 

Good memory Paul.

 

A friend of mine, White Circus programmer, worked on Space Taxi and I was a tester.

Unfortunately he didn't have the time to continue to work on it.

 

Speech apart, 8 levels were finished, as you can see in those video I recently made:

Level 4 5 6 7 8

 

Man that looks as good as finished !

 

Just add some speech and stars in the intermittent screens.

 

I have a feeling Space Taxi was a pretty old C64 game, it certainly doesn't "make the best" of it's graphics and sound capabilities.....but it's still a load of fun

[carlsson]

The original game is dated 1984, then two different German magazines had type-in clones in 1985 and 1986.

[emkay]

I have a feeling Space Taxi was a pretty old C64 game, it certainly doesn't "make the best" of it's graphics and sound capabilities.....but it's still a load of fun

Space Taxi is one of those games that needed the 320 pixel precision for playing through.

Some of those older games seemed to shoot directly against the Atari. Remember? Also Impossible Mission was only done to show the "high resolution sprite" .

Several games could use 320 pixel precision on the Atari aswell. But things had to be done vice versa: Using the PMg at it's strength, to easily fill up the screen with colors, and the hi res (in this case) for all moving objects and screen information...

 

For now only some conversions do that as a side effect. But it always was there to have some neat hi res games natively on the Atari.

Edited April 13, 2018 by emkay

[+Stephen]

Space Taxi is one of those games that needed the 320 pixel precision for playing through.

Some of those older games seemed to shoot directly against the Atari. Remember? Also Impossible Mission was only done to show the "high resolution sprite" .

Several games could use 320 pixel precision on the Atari aswell. But things had to be done vice versa: Using the PMg at it's strength, to easily fill up the screen with colors, and the hi res (in this case) for all moving objects and screen information...

 

For now only some conversions do that as a side effect. But it always was there to have some neat hi res games natively on the Atari.

Can we ever really have 320 pixel precision though? Even hardware scrolling only moves in colour clock (160px) resolution. Although if everything was done with soft sprites, we could alternate chars single pixel to achieve it.

[emkay]

Can we ever really have 320 pixel precision though?

Everytime, when hires is the used mode.

 

Even hardware scrolling only moves in colour clock (160px) resolution. Although if everything was done with soft sprites, we could alternate chars single pixel to achieve it.

Most High Resolution based games don't use 320 Pixel exact scrolling.

 

If games use the hires mode for the software sprites, they can be moved at this resolution for sure, and you get the benefit of a better playability by more precise visuals .

[carlsson]

Given that Epyx supported both the C64 and Atari 8-bit where possible (and even more formats), I doubt that Impossible Mission was developed in order to pour salt in the eyes of Atari owners.

[emkay]

Given that Epyx supported both the C64 and Atari 8-bit where possible (and even more formats), I doubt that Impossible Mission was developed in order to pour salt in the eyes of Atari owners.

Are you kidding? That game was THE answer , if someone asked for the better computer .

[+MrFish]

Good memory Paul.

 

A friend of mine, White Circus programmer, worked on Space Taxi and I was a tester.

Unfortunately he didn't have the time to continue to work on it.

 

Speech apart, 8 levels were finished, as you can see in those video I recently made:

Level 4 5 6 7 8

 

Maybe you can convince him to release a public beta?

[+MrFish]

Possible or not... here's the missiles added for the bullets and also

final changes that were done to the right side of the ship in the last

post.

 

Edited April 13, 2018 by MrFish

[Level42]

I love all 194X games so a 1942/43 hybrid it absolutely fine with me. Maybe you could make a setting for one bullet deaths ?

 

Looking great by the way !!!!

[Level42]

Are you kidding? That game was THE answer , if someone asked for the better computer .

Yeah I remember being a bit envious of the large animated sprite.

 

But then I started playing and realized the game was only that animation and aside from that it was a very very mediocre game.

Edited April 14, 2018 by Level42

[popmilo]

That's really nice demo! I presume those 14 sprites are pre-shifted ? Roughly how many could you brute-force in 20,000 cycles ? I'm asking, as I'd prefer having as varied background as possible, and only spend 4 chars for each moving sprite (as it can cover up to 4 on-screen chars - well, more if sprite is bigger).

 

Makes you wonder, if we rather chose some slow-moving game, e.g. not a fast-moving plane/car, but a slow-walking human (good useable example might be Aliens movie - the marine segment, where they move very slowly - so the screen shouldn't really scroll more than 10px / second), then we might get away even with 10 fps scrolling (e.g. 60/10 = 6 vblanks). That's over 120,000 cycles for CPU to brute-force any sprites over the background. How many sprites would then be possible ?

Yes, they are preshifted. Each sprite size is 8x16 pixels. So preshifted frames are 3 bytes wide, 16 high. That's 48 bytes plus 48 bytes for mask.

So 96 bytes per shift, 384 bytes per sprite frame. Sounds a lot but there are ways to reduce memory usage. Unpack (preshift) only needed sprites as game scrolls (or player goes from level to level, screen to screen). Load sprites from extra ram or disk. Also could go with automask with sprites using only three colors.

 

"Real time shifting" with six times less memory used (masked 8x16 pixels sprite is 64 bytes vs 384 bytes) is also possible with noticeable slow down, but still good enough imho. Shifting is done by loading sprite data into x reg, fetching shifted value from table and combining with neighbor column before storing into chars that make sprite.

 

Think you're on right track with not chasing high fps. There are games that don't require 50-60 fps to be playable. As you said, large sprites, slow action, plenty of cpu time to draw it all and make something that will stand out among all games done so far. Speccy and Amstrad pulled it of like that many times, why wouldn't we

 

I suppose we'd run out of 128 chars real quick, so we would need about 4-6 DLIs ? In a way, while a complication of Atari, if we just avoid sorting, then we can have a unique char per each screen position. DLI costs - what- ~125 cycles ? 6*125 = 750 cycles per frame. For 6 frames, we're down 6*750 = 4,500c out of 120,000 - so still over 115,000 cycles. And we can still move the main player at 60 fps (during vblank).

 

Has anything like the above been done on A800 ?

Nooooo, don't be afraid of 128 chars, it's a solved problem

 

Have you seen that multiple charset method (José Perreira first mentioned I think). This demo of mine uses that method. Each screen line is different charset. You use as much charsets as your sprite vertical size is (with shift). So for sprites 16 pixels high, you need 3 chars to fit it in. So you make 24 DLI routines, each switching charset like 0,1,2,0,1,2..... etc. So single sprite 8 pixels wide uses only 3 chars per charset. So that demo of mine that has 14 sprites needs only 14x3=42 chars per charset. That leaves you 86 chars per charset for background.

 

And those 86 chars don't have to be same in each charset (although it simplifies map design). With clever map layout you can have same char code have different gfx per charline and increase gfx variety.

 

As far as I know, serious game with such design hasn't been done yet. But at least one will be soon

ps. Soon could mean a year or two based on experience so far....

[Tezz]

Nooooo, don't be afraid of 128 chars, it's a solved problem

 

Have you seen that multiple charset method (José Perreira first mentioned I think). This demo of mine uses that method. Each screen line is different charset. You use as much charsets as your sprite vertical size is (with shift). So for sprites 16 pixels high, you need 3 chars to fit it in. So you make 24 DLI routines, each switching charset like 0,1,2,0,1,2..... etc. So single sprite 8 pixels wide uses only 3 chars per charset. So that demo of mine that has 14 sprites needs only 14x3=42 chars per charset. That leaves you 86 chars per charset for background.

 

And those 86 chars don't have to be same in each charset (although it simplifies map design). With clever map layout you can have same char code have different gfx per charline and increase gfx variety.

 

As far as I know, serious game with such design hasn't been done yet. But at least one will be soon

ps. Soon could mean a year or two based on experience so far....

We used that method for Bomb Jack in 2007 also my current project will be using that method although I don't need any shifting this time.

[Tezz]

There are games that don't require 50-60 fps to be playable. As you said, large sprites, slow action, plenty of cpu time to draw it all and make something that will stand out among all games done so far. Speccy and Amstrad pulled it of like that many times, why wouldn't we

Absolutely!

[+MrFish]

I love all 194X games so a 1942/43 hybrid it absolutely fine with me. Maybe you could make a setting for one bullet deaths ?

 

Could even make it semi-realistic: a bullet could. 1. inflict small damage, 2. rupture a fuel tank, or it could 3. go through the pilots head.

So, in order, you have 1. damage meter decrease, 2. explosion, 3. plane crashing to whatever's on the ground below. A simple randomization

variable could be used, but then it doesn't make sense to have a "bullet through the pilot's head" when the shot contacted the plane on the wing.

So, better to use some impact location variable too, with the randomization variable weighted towards small damage infliction.

 

Having player settable options is always a good idea.

 

 

Looking great by the way !!!!

 

Thanks. The larger aircraft are next on the list.

Edited April 14, 2018 by MrFish

[Tezz]

Thanks. The larger aircraft are next on the list.

Nice plan and artwork, looks workable. I prefer your version without the outline

[+MrFish]

Nice plan and artwork, looks workable. I prefer your version without the outline

 

Thanks. The more I've been looking at the outlined version, I find it a little heavy-handed.

The main reason I've been toying around with the outlining, as I've mentioned, is in order to

avoid the inevitable color clash with the complex background pattern, and also to make the

sprites themselves look a little larger, particularly horizontally (as this is where one of the P/M

graphics limitations lies).

 

There actually isn't much clash, though, except you can see some on the large, green plane's

wings. This may become unnoticeable when it's animated, with the background underneath it

constantly changing.

[popmilo]

Thanks. The larger aircraft are next on the list.

Any chance you could draw those sprites (smaller and larger) as "normal" gfx ?

Like a sprite sheet in single or multiple images.

I could convert those and replace gfx in my sprite demos so we could see how it would look in a moving scenario.

[+MrFish]

Any chance you could draw those sprites (smaller and larger) as "normal" gfx ?

Like a sprite sheet in single or multiple images.

I could convert those and replace gfx in my sprite demos so we could see how it would look in a moving scenario.

 

Wouldn't you just need the silhouette (as that's the part I'm proposing as a softsprite)?

Or is it that it makes no difference programmatically, and it will look better for the sake

of viewing in a test?

Edited April 14, 2018 by MrFish

[popmilo]

 

Wouldn't you just need the silhouette (as that's the part I'm proposing as a softsprite)?

Or is it that it makes no difference programmatically, and it will look better for the sake

of viewing in a test?

As long as it's clear image I can extract info about mask and pm part. Anything that I can make sense of (what is background, black as mask, couple colors for pm).

I can make masking part as soft sprite, and add PM where needed.

 

Something like this (just dozen of different ones ):

 

[emkay]

Think you're on right track with not chasing high fps. There are games that don't require 50-60 fps to be playable.

 

If you want to have 50 lines vertically scrolled in a second, you had to update all Softwaresprites with 50fps, independent of the speed of the moving objects, to prevent

twitching of the moving objects.