Pole Position modest sprite hack !

[TIX]

Ahem.. after the glorious technicolor images above, mine looks pretty lame

buuut I'm really proud of them, so there:

 

(this is the first revision, they are going to improve further down the road)

 

 

[+Stephen]

E-Type is in Antic 4, which is 5 color (4 + 1 toggled color) character mode.

 

You could use Antic 2 interpretted as GTIA 10 (with an E-Type kind of "engine"), which will give 9 colors,

but at 80 pixel width resolution. The resolution is good enough with so many colors, though; 2x wide pixels

are better than 4x wide pixels too.

 

I did this mockup to see what it might look like. The upper part of the screen is in Antic 2 (hi-res character mode),

middle part is in Antic 4 (160 width, 5 color character mode), and the bottom is Antic 2 interpretted GTIA 10

(80 width, 9 color character mode). [Edit: note that no P/M's have been used, so all are available for use on the

signs; that means higher-res multi-color signs would be possible as well.]

 

As you say, the window would have to be scaled to the size of E-Type; but at least this gives some idea.

[Edit: Although, as you said, E-Type was a port; so, something built from the ground up on the Atari might not

need such a small viewport.]

 

Anyway, back to the thread subject...

 

pp car 9 (scaled).png

 

pp dual cars 9 (scaled).png

 

pp explosion 9 (scaled).png

Holy crap! That looks incredible.

[+Philsan]

We should remember that Atari wanted many games to be compatible with the lower memory machine (600XL, 16KB).

On the other hand, the competitor only had a 64KB machine therefore its software didn't have memory limitations.

 

So, a better Pole Position could be made back then, and even more so today (see MrFish impressive mock-up).

 

Meanwhile, we can enjoy TIX improvements.

I don't like very much the fourth car's frame, because there's a very big one color (light blue) only part.

Perhaps it's impossible to improve it.

[_The Doctor__]

he has room to put a line or two in there of his choosing to break it up

Edited November 21, 2018 by _The Doctor__

[kiwilove]

I will say the obvious - that hopefully a programmer (easily said - but probably a headache to take on) can get involved - so that more extra frames can be added in.

This would make a heck of a lot of difference.

 

But you're doing an excellent job within the limitations you are confined by.

 

Harvey

[EnderDude]

Pitstop 2 looks quite aesthetically impressive, and I would play it if it weren't so slow-paced, and ear grating.

[_The Doctor__]

I remember that game! You're right... the engine drone was too much... it needed to lessen and the game was in need of speed..... based on what we see today It's a sure bet this could be done way better today... and the car could also be made to 'turn' by shifting things.

Edited November 21, 2018 by _The Doctor__

[+Stephen]

Pitstop 2 looks quite aesthetically impressive, and I would play it if it weren't so slow-paced, and ear grating.

That's the problem. You don't get to choose the "awesome looking graphics" and get the best speed available in another compromise mode. Remember, these machines can do 320*200, they can do 256 colours, they can so 60fps, but you don't get all 3 combined.

[_The Doctor__]

oh but we've seen some great titles that do very close to all that at once... lol light years better than these for sure.

[Heaven/TQA]

The tech pole position uses with kernel shifting road is ace (though could be improved as Rybags stated with his prepare to qualify sample).

 

The core of the game is based on that tech. So changing that like having pm for the road and use antic e/4 for car etc is a complete different engine and would not be easy as its a complete new game code.

[Heaven/TQA]

 

Bitmap even with little horsepower.

[+MrFish]

I created a Graph2Font version, to see how it would look with actual Atari colors,

in emulation and on real hardware (mockups were just in Photoshop).

 

Its looks good, except I'm getting the the famous 1/2 pixel shift between Antic 4

and GTIA 10. Is there a way to adjust/eliminate that in Graph2font?

 

 

Edited November 23, 2018 by MrFish

[peteym5]

 

Bitmap even with little horsepower.

Reminds me of my attempts to make a racing game on the Vic-20 with Basic when I was learning to program as a kid.

The ML probably could work better with some optimizations.

[peteym5]

I created a Graph2Font version, to see how it would look with actual Atari colors,

in emulation and on real hardware (mockups were just in Photoshop).

 

Its looks good, except I'm getting the the famous 1/2 pixel shift between Antic 4

and GTIA 10. Is there a way to adjust/eliminate that in Graph2font?

 

pp 9.png

 

Are the cars still going to be drawn with player/missile graphics or screen graphics. Would be pretty hard to do with Hoz Scroll + Load Memory Address on each line shifting each pixel line left or right. Might be CPU intensive to try to redraw the track at 50 frames per second.

[+MrFish]

Are the cars still going to be drawn with player/missile graphics or screen graphics. Would be pretty hard to do with Hoz Scroll + Load Memory Address on each line shifting each pixel line left or right. Might be CPU intensive to try to redraw the track at 50 frames per second.

 

I'm completely aware of how the original game generates the road and car graphics. Go back and read what I wrote in the first post where I displayed the mockups. This has nothing to do with the current hack of Atari Pole Position.

Edited November 24, 2018 by MrFish

[+MrFish]

Is there a way to adjust/eliminate that in Graph2font?

 

pp 9.png

 

Alright, I just shaved off some pixelage here and there and problem solved.

 

[_The Doctor__]

help me see the difference between both images....

[Rybags]

An idea to increase the fidelity of the cars though whether it'd work or look good ?

 

Change the screen layout where the track is to alternating scanlines of track and playfield to augment the cars.

The player's car could be kept on in a constant state where only the bytes required for whatever animation is wanted are changed. The computer cars could be rendered as softsprites.

The rendering requirements shouldn't be too high as only half the lines are shown.

 

A couple of PF colour registers would need to be changed, I think that should be doable as they'd likely just be immediate load+stores.

[+MrFish]

An idea to increase the fidelity of the cars though whether it'd work or look good ?

 

Change the screen layout where the track is to alternating scanlines of track and playfield to augment the cars.

The player's car could be kept on in a constant state where only the bytes required for whatever animation is wanted are changed. The computer cars could be rendered as softsprites.

The rendering requirements shouldn't be too high as only half the lines are shown.

 

A couple of PF colour registers would need to be changed, I think that should be doable as they'd likely just be immediate load+stores.

 

Good idea. I'm not sure how good it would look either, as any part of the track or grass could be combined

with the players horizontal space at any time (i.e.: if the player were on the red and white sidelines, his sprite

would be shaded by those colors), which would have some effect on how the player looks. But, it's an

interesting enough idea as to try and put something together.

 

Essentially, the vertical resolution gets cut in two, but the horizontal resolution gets quadrupled, which is a

big overall gain.

[Rybags]

The priority would need to be changed per scaline too.

 

The game already changes PF2 per scanline then does AND #$0F / STA PF1 - so the colours required could be just stuffed into the existing table.

Though I suspect the table data is moved to achieve the vertical road movement so a save/restore operation would probably be needed.

Edited November 24, 2018 by Rybags

[+MrFish]

OK, I didn't exactly get you at first. So, you're suggesting to keep the PM's for the players car and use playfield to enhance them;

and then have the opponent cars as softsprites only, but using every other scanline for their data, or every line for their data

(I'm unsure on you here, as it seems you can't, if you want the track to be manipulated the way it currently is)?

 

At first, I thought you meant to use softsprites for all cars, on every other scanline, which is why I said what I did about their look being

affected by whatever playfield areas they might be over top.

 

So, with the player, you're talking about changing the priority every other line in order to keep the PM's behind the enhancement graphics,

but in front of the track graphics? If that's the case, you could just window shade the PM's too (no PM data on the car enhancement playfield

lines) and you would need to change priorities every other line.

Edited November 24, 2018 by MrFish

[+MrFish]

Assuming I understand you right -- here's about what we could get for the player car with the quad-width PM's and alternating playfield lines.

 

 

 

And here's how just the playfield data looks -- give or take a few pixels I changed when adding the PM lines (the air fin is narrower here).

 

Edited November 24, 2018 by MrFish

[+MrFish]

BTW, any of the gray on the tires and body of the car would not be "see-through" (as in seeing the road markings or grass through them),

since these appear on scanlines that would only be drawn for the vehicle(s).

Edited November 24, 2018 by MrFish

[+MrFish]

The above dimensions were based on a direct conversion of the arcade sprite. It would require PM's to be 27 pixels tall (counting blank lines).

 

Here's a shortened version that would require PM's to be 24 pixels tall (counting blank lines), which is what they are in the Atari version.

 

 

BTW, if you want to discuss this further, maybe we should open up a new thread, so we don't overtake this one.

Edited November 24, 2018 by MrFish

[+MrFish]

One last thing...

 

Here's how everything would look together (shortened height car used, and lighter gray road).

 

Edited November 24, 2018 by MrFish