STUNT CAR RACER?

[Marius]

Thanks for this awesome port. I remember playing this on Atari ST back then. Since I donated all my ST stuff to TXG/MNX ( I do not have room for anymore equipment, It is already entirely filled with a8) I am very glad I can play this game again now on my a8.

 

So very very big thanks to irgendwer, fandal and xxl!

 

It is also great to see that the scene is still alive and kicking!

[twh/f2]

Also from my side congratulations and a big thank you for your immense work and passion in making "Stunt Car Racer" not only perfect conversion but also the best 8-bit version over all comparable platforms.

 

I had the great privilege to be an early beta-tester of Stunt Car Racer. First time I booted up a single file called "a.xex" and I wasn't sure what will show up. But then suddenly I thought I was in the wrong emulation when I saw a near perfect menu of a game which I

knew so well from my Amiga!!! Not to express in words, what I thought, when I saw it was a real playable game!!

 

As beta-tester I wanted to contribute at least one or more bug reports. But that version I got was already close to perfect. I couldn't find any major stuff and could only grumble about cosmetic issues.

 

Funny that I now found in this final version a small but meaningless bug, I couldn't discover earlier:

When crane-lifting the car from ground to the platform and you pause the game (e.g. space key) and you continue, then the crane-sound suddenly disappears .. but as I said: meaningless.

 

So once again and into the public: Awesome job Irgendwer, Fandal and XXL!! You guys rock. To me this single game is a major milestone in the history of the 8bit Atari line. Enough said

 

grüße,

twh

[SS]

I talked myself out of a decently priced 130XE a few weeks ago because I decided that I didn't really need it. This makes me kind of disappointed that I didn't pick it up after all. Beautiful work all around.

[popmilo]

If this could be "easily" converted to use gr.7 like graphics (or the equivalent char mode), how much do you think that would improve the frame rate?

I would hope for something near 12 fps.. like 1.5x faster.

Would be cool to have option in the game to choose vertical resolution.

 

On the other hand this game is not about raw gfx fps. Physics is what makes it great. And you would need to speedup that in order to make gameplay more fluid than it already is. So any speedup you get with gfx would have to be balanced/shared with more cpu calc which is probably harder to improve.

[Yosh]

Horizontal could be selectable too

 

Narrow screen comes to mind. 3d window has exactly that width.Should be not hard to do it - i wonder is it worth though? any insights? "cockpit details off" option, as it would strip 2d borders.

 

But don't get me wrong - i'm not nitpicking, I'm amazed, but even more - THANKFUL .

 

EDIT - heh... it's already that way I suppose:) PMG as borders...

Edited March 4, 2018 by Yosh

[pseudografx]

Horizontal could be selectable too

 

Narrow screen comes to mind. 3d window has exactly that width.Should be not hard to do it - i wonder is it worth though? any insights? "cockpit details off" option, as it would strip 2d borders.

 

But don't get me wrong - i'm not nitpicking, I'm amazed, but even more - THANKFUL .

 

EDIT - heh... it's already that way I suppose:) PMG as borders...

Yes, it is. Originally it used 40-byte width just like the original, but Fandal managed to rewrite it for the narrow screen, which was really not trivial. But it helped to improve the framerate by a few more percent.

[emkay]

EDIT - heh... it's already that way I suppose:) PMG as borders...

That's the advantage here. While other computers need to shrink the screen to 32 bytes, to have the calculations right, the Atari offers that mode natively. It's a nice decision to have the PMg used for the enhanced Border.

[emkay]

Would be cool to have option in the game to choose vertical resolution.

 

On the other hand this game is not about raw gfx fps. Physics is what makes it great. And you would need to speedup that in order to make gameplay more fluid than it already is. So any speedup you get with gfx would have to be balanced/shared with more cpu calc which is probably harder to improve.

The reduced cycle stealing, when using gr. 7 would free 2560 CPU cycles per VB (in PAL that means 128000 cycles per second) to calculate physics faster.

Using the double lined character mode would add 256 CPU cycles available for physics. Half the screen handling, half the screen clearing, also gives more cycles to calculate physics.

[VladR]

You keep forgetting that there is no source code - it's all just backconverted from hexa (I presume, as just editing opcodes inside monitor would be highly unproductive, longterm).

 

Also, it's highly likely that the constants, tables and data was adjusted to the low framerate already. So, just because you have more cycles, does not necessarily mean it will run code faster - all depends on how it was written in the first place...

[Rybags]

The usual method is to use a memory dump or program file and put it through IDA Pro or other decent disassembler.

Then you work towards usable source code. Some reverse-engineering usually needed.

First major objective is get source that will assemble to reproduce the original program on the original machine.

Then get it going on the target machine.

 

An interesting mod might be to just put a Graphics 7 DList into the game, using LMS to skip every 2nd scanline. That should give about 3700 cycles saving per frame. So the codebase could be left unmodified for a slight overall speedup.

[VladR]

I would be curious to know if they used IDA Pro, too - or some other tool. I personally like IDA very much - hacking out the license check with it is very quick. Took me about a day with a 2 MB PC executable last year, so I presume that a 64 KB image must be a breeze, for IDA Pro.

 

Exploring all variables and what they do, however, that must have taken forever

[Irgendwer]

An interesting mod might be to just put a Graphics 7 DList into the game, using LMS to skip every 2nd scanline. That should give about 3700 cycles saving per frame. So the codebase could be left unmodified for a slight overall speedup.

 

Please do not forget this is char mode to have the very fast filling of areas (7th bit)!

Like said, Sir Geoff has already very elaborated routines and you find hardly places to enhance speed.

Furthermore it's an illusion to believe (I mean not you) that halving the resolution halves the calculations.

Going from GR.15 to Gr.7 halves the number of pixels of a vertical line, but the set-up time where to start and where to end stays unaffected - and drawing doesn't even take the major part in SCR.

 

Edit:

For all of you, who think we left more or less major optimization potentials untouched, please visit

http://atariage.com/forums/topic/273016-sv2k17-256-bytes-of-blues/

and try to reduce the code size further as a practice.

Someone could get the impression that good is not good enough...

Edited March 4, 2018 by Irgendwer

[+CyranoJ]

 

Like said, Sir Geoff has already very elaborated routines and you find hardly places to enhance speed.

 

 

I couldn't agree more. I've just got the ST version ported to the Jaguar are there really isn't much to optimize on the 68000 side without resorting to completely re-writing routines on the GPU. Sir Geoff was one great coder.

[grzybson]

Hello guys,

 

I've managed to preare a hacked version of Stunt Car Racer that is able to load from any device under DOS. It was tested with DOS II+/D and MyDOS under Altirra, as well as Sparta DOSX with SDINIT and it seems to work.

 

Of course there are some disadvantages:

• This version uses additional bank of extended RAM (should be able to run on 192kb machine)
• There is no Hall of Fame, Replayes - all I/O operations are disabled, beacuse there is no xBios
• The animation during loading is corrupted - but when you boot from HDD there is no time to watch it

If you don't accept these limitations, please stay with the original version. I made this for my own fun and all the users who want to enjoy fast load from their HDD interfaces.

 

Of course some things my not work, it was rather a quick and dirty hack. I will appreciate your feedback.

 

StuntCarRacer.DOS.xex

[Mark loves Stella]

Hello guys,

 

I've managed to preare a hacked version of Stunt Car Racer that is able to load from any device under DOS. It was tested with DOS II+/D and MyDOS under Altirra, as well as Sparta DOSX with SDINIT and it seems to work.

 

Of course there are some disadvantages:

• This version uses additional bank of extended RAM (should be able to run on 192kb machine)
• There is no Hall of Fame, Replayes - all I/O operations are disabled, beacuse there is no xBios
• The animation during loading is corrupted - but when you boot from HDD there is no time to watch it

If you don't accept these limitations, please stay with the original version. I made this for my own fun and all the users who want to enjoy fast load from their HDD interfaces.

 

Of course some things my not work, it was rather a quick and dirty hack. I will appreciate your feedback.

 

Works great!

I don't know if you tweaked it or not. But, now it works perfectly using the Rapidus. Better frame rate than the Amiga and ST version.

[grzybson]

I am glad to hear that it works. However I am surprised that stability on Rapidus increased, because it did not alter original code at all! All I did was:

* move low memory segments to ext RAM,

* added code that relocates it to original locations when DOS is no longer needed

* added logic that turns OS off before INIT requests, and turns it on immediately after (something like "decorator" pattern in OOP programming)

Game logic is intact!

Edited March 4, 2018 by grzybson

[Mclaneinc]

Sadly it does not work (like the original ) under emulated Rapidus..

 

Must be something about the emulated Rapidus that is different, I saw the timings are not the same??

 

Not an issue except for exactness only...

[emkay]

Found an interesting video

 

 

probably they should add the Atari version

[+MrFish]

Found an interesting video

 

probably they should add the Atari version

 

The results are as expected, although I'm not sure why they're using boost at all here, especially when they're applying it in unequal amounts. Probably didn't effect things significantly, but it most likely threw things off some.

 

Spectrum version looks the worst, at least on the part of the screen that matters the most -- not to mention that the tires don't even turn.

Edited March 4, 2018 by MrFish

[grzybson]

Speaking of Rapidus, here is a video showing the game running on REAL hardware with Rapidus 65C816 at 21MHz, loaded from IDE+. It was recorded by Pin/Tristesse. Blazing smooth!

 

[emkay]

Speaking of Rapidus, here is a video showing the game running on REAL hardware with Rapidus 65C816 at 21MHz, loaded from IDE+. It was recorded by Pin/Tristesse. Blazing smooth!

 

The indicator that every cycle counts. But, we have "professionals" here doubting it

[xxl]

PC era - hardware upgrade, more memory, faster processor.

I prefer the Atari era and classic optimization methods...

[VladR]

The indicator that every cycle counts. But, we have "professionals" here doubting it

"Every cycle" ? Seriously ? It's a factor of 12:1 (1.79 MHz vs Rapidus).

 

I resisted to respond the first time you mentioned the idea of doubling the framerate with lower resolution. There's quite a few stages in the 3D pipeline. I'm not gonna spam this thread with 5 pages on those technical details (and I already explained those to you at least in 3 other threads) - but actual fillrate comprises only a small (if well optimized, which this one **clearly** is) portion of the whole pipeline, especially at the character modes.

 

Regardless of the resolution, you have to process:

- input + audio

- HUD

- physics

- frustum culling (select just the visible portion of the whole 3D world)

- 3D transformation&projection

- clipping

- For fixed-point line algo - compute StepHi/StepLo for each edge

 

All those stages above are completely detached from the actual resolution (save for the pathological case of 320x192 where you need 2 Bytes for xpos), and whether you render in tiny window 4x4 pixels or 160x192, they will still take the same amount of cycles.

 

 

Only the final scanline rasterizer stage will be affected by lower resolution. At the current target framerate, it's highly unlikely you would even notice it, unless you were watching a benchmark and saw 2 different numbers.

[Gunstar]

I have really been enjoying this game the last couple of days, and have actually gotten good enough to make it to division 3! But, I can't figure out how to save and load games! it says that it can't find the Save.dat file! Well, if you haven't saved yet why should it be looking for one? Anyway, is this a function that was just never implemented? Replay works fine to start a division over, as long as you don't shut off the computer. Help please!

[jefffulton]

I just want to say thanks to the developers for reverse engineering and then creating the Atari 8bit version of this game. I really enjoy the back and forth of how it could be optimized, etc, but let's remember one thing. Only one team successfully took on the project created this game, and it's one of the best Atari 8bit conversion ever. The peanut gallery (no matter how skilled or correct with their analysis) didn't take the time to create the project. These two did and it's a triumph. So give them Kudos and enjoy the game. It plays awesome on the Rapidus, by the way! But it still rocks my 130XE. That's the important part to me.