Something special ;)

[emkay]

Well, I allways was wondering, why Rescue on Fractalus wasn't as fast as it should be.

If you read earlier threads, I always suspected "not so optimal" coding on the Atari, while they did optimizations for the C64.

Since Altirra shows the artefacts on the right side of the screen, when the screen is opened, and I recognized that artefacts in the game, I was wondering again .

 

Checking the Displaylist... only got me asking myself : WHY?

 

 

In early threads, I only suspected the screen synchronization.

 

OK let's check:

 

1st :

 

With the start of the gaming screen range, the width is set to 48 bytes. But there is no masking used.

Then, in every Mode D line LMS is set new, to a range of 96 bytes.

 

As there were "only" about 47 mode D lines, the wasted amount of CPU cycles isn't turning that bad.

But it shows programming weirdness.

 

The Info Board is build on Mode 4 in 48 bytes width for no reason.

 

10 lines of Mode 4 at 48 bytes width means 720 wasted cycles per screen and 43200 cycles wasted on an NTSC machine in a Second.

 

Then that solution for an LMS every Mode D line. This means to change all of the 47 Mode D lines in the VBI.

What did they expect? Did they and to make a car racing game out of it ?

 

Why is the screen set to 48 bytes anyways? covering any graphics ? Well, in Koronis Rift they used some PMg masking for the borders...

 

Wasting that real big amount of RAM to have a double buffer does even make no sense.

2*40*47 = 3760 Bytes

2*48*47 = 4512 Bytes

 

752 Bytes lost for what ? Some cycle saving in the double buffer routine?

752 Bytes great coders run Demos in that . So what was the problem to use to different subroutines for setting the buffer to a defined Memory Range.

This would have also saved a lot cycles, because only one LMS Change was needed for buffer switching, and many additional Cycles would have been saved.

[Rybags]

Hmmm... looks like it's wide mode the entire display which is wasteful.

 

And no HSCROL enabled which means using standard width would generate savings.

 

A "fix" might be as simple as modifying a few things then adjusting LMS offsets.

 

A radical modification could be to make the dashboard area smaller and windscreen area larger to take advantage of saved cycles.

 

 

 

ed - for your own proof. Run the game in Altirra. Go into the debugger.

Use the GS <numeric> to stop at a particular scanline then .ANTIC to show Antic's register contents.

.DUMPDLIST shows the display list, and not a single scrolling line to be seen.

Edited April 28, 2019 by Rybags

[emkay]

Quickest Speedups:

Reduce the screen to 40 bytes.
Adjust the screen drawing to one linear framebuffer, and add a memory base changing routine to allow the same calculating engine to draw into a real separated buffer.
Remove all useless LMS from the Displaylist , and set the buffer memory with only one LMS change.

Edited April 28, 2019 by emkay

[emkay]

Depending on how the DL looks, it points to the following:

 

Back then, the games that used LMS looked rather fast. Particular Pole Position was a Game that show that fluent use of LMS ...

 

So , as it seems, they hit LMS into the game engine for some special FX and never used them?

In theory, by using scrolling, the Gamescreen could wobble and shake if the ship has been hit, but there are only lightning FX.

 

But using the LMS for doing a separated framebuffer, always per LMS line is odd. Just like they wanted to build a scrolling game at first.

It could have been interesting, if the LMS per line had been used interleaved. But this only would work , if the calculated frames weren't too different.

 

After the game had been done, without any special FX, they didn't optimize it , because it looked fast enough, back then.

 

Well, the game wouldn't run x times faster, but when the FPS were that low, every additional Frame per Second counts.

[emkay]

Interestingly they did it in the C64 version. This "Interleaving LMS" effect.

This results in frame drawing between the frames. As there is changing a little between the frames, the game suggests a higher framerate to the viewer. It is similar to horizontal banding, but isn't recognized to be horizontal banding, as only some pixel change there (because the rest of the graphics hasn't been changed due to the low CPU speed) .

Edited April 28, 2019 by emkay

[Rybags]

There's 96 bytes seperation betwen lines - I don't know why, maybe it's for the double-buffering.

 

The LMS stuff IMO is trivial - the cost per frame for the extra DList fetches maybe a hundred cycles.

 

But the savings by having standard width screen would be much greater.

 

In fact, wide mode with scrolling enabled then set HSCROL such that the DMA gets cut off would save cycles too (refer Antic timings such as the old text document or Altirra HW Manual)

[emkay]

There's 96 bytes seperation betwen lines - I don't know why, maybe it's for the double-buffering.

For sure.

 

The LMS stuff IMO is trivial - the cost per frame for the extra DList fetches maybe a hundred cycles.

Plus the need of changing all registers for one buffer change.

 

And, I'm pretty sure, it is faster to handle two separated Framebuffers, instead of jumping between two buffers in the 96 Byte range for every screen line.

 

But the savings by having standard width screen would be much greater.

Yes.

 

In fact, wide mode with scrolling enabled then set HSCROL such that the DMA gets cut off would save cycles too (refer Antic timings such as the old text document or Altirra HW Manual)

In Graphics Modes? If ANTIC isn't doing DMA, it cannot show the relevant content.

Reading after that from the internal buffer is always given , and is free from any additional cost of subroutines or special handling, when using Mode D .

Edited April 28, 2019 by emkay

[Rybags]

Refer page 73 of Altirra HW manual.

 

There are "virtual DMA" cycles where the address counter is updated but Antic doesn't actually fetch data on a stolen cycle.

Dependent on HSCROL there can be 1 to 4 of them when h-scrolling is in use in normal or wide mode.

 

So for a 47 pixel high screen the saving is only about 141 cycles per frame.

 

Hardly worth the effort. But the idea of changing the entire screen architecture which would need extra effort re adjusting LMS positions would bring much greater savings.

[emkay]

Refer page 73 of Altirra HW manual.

The weird resulting last byte. OK.

[Heaven/TQA]

96 bytes because of double buffer and not having wasting the speedcode for clear and ora filler twice but just addressing buffer by using X or Y reg. No magic.

 

Getting away of that would gain in more speed then just by using 40 bytes.

 

48 bytes is visually more appealing as the viewport covers whole Tv left and right. And as the enemies are sprites they would cross that normal screen border which would need masking or it would look cheap. Same in koronis rift but here Charlie used missles to mask out the shots and used that as color indicator.

 

Check out NTSC of RoF for real speed as there is no PAL version.

[Heaven/TQA]

Quickest Speedups:

 

Reduce the screen to 40 bytes.

Adjust the screen drawing to one linear framebuffer, and add a memory base changing routine to allow the same calculating engine to draw into a real separated buffer.

Remove all useless LMS from the Displaylist , and set the buffer memory with only one LMS change.

It is linear Master... look and understand the code...

 

Its same linear than without. Its just 2 screens positioned next to each other.

 

RoF drawing/rendering works in byte collums.

[Heaven/TQA]

If you are already in debugger... check out the profiler and you see where the engine is wasting cycles...

 

Btw I have a complete MADS compatible disassembled source and I can tell you exactly whats happening where.

[Heaven/TQA]

Ah and if you understand how the buffer is flipped... no lms changes...

 

Ldx #0 buffer 0

Ldx #48 buffer 1

 

Same routines.

[emkay]

96 bytes because of double buffer and not having wasting the speedcode for clear and ora filler twice but just addressing buffer by using X or Y reg. No magic.

Ofcourse it is no magic. Looks more like laziness

 

Getting away of that would gain in more speed then just by using 40 bytes.

Apples ? Pears? What you explain there, only makes sense if the CPU can do 2 things at the same time.

 

48 bytes is visually more appealing as the viewport covers whole Tv left and right. And as the enemies are sprites they would cross that normal screen border which would need masking or it would look cheap. Same in koronis rift but here Charlie used missles to mask out the shots and used that as color indicator.

???

 

As they used DLI in the game, they also could have used the background color for the "wider viewport experience". In fact: No TV in that time did nearly show the wide screen. .

 

Check out NTSC of RoF for real speed as there is no PAL version.

True. That's why ROF NTSC shows 6 fps and PAL shows 5 fps.

[Heaven/TQA]

Re Laziness

 

Its Charlies first Atari game (and Foxs) compared with yours... yeah totally lazy.

 

Game was written 1982/83 how the hell can we assume what the reason was to code it in that way or why they used 48 bytes etc... 35 years ago... maybe it was simply because we can or the reason was 42.

[Heaven/TQA]

Re:

Apples ? Pears? What you explain there, only makes sense if the CPU can do 2 things at the same time.

 

Well... learn assembly... and you know what I mean.

[emkay]

Ah and if you understand how the buffer is flipped... no lms changes...

 

Ldx #0 buffer 0

Ldx #48 buffer 1

 

Same routines.

Hm. So you mean the screen content is changed by some magical issue?

[emkay]

Re Laziness

 

Its Charlies first Atari game (and Foxs) compared with yours... yeah totally lazy.

You're always for a good joke, aren't you?

Can you calculate how much 1 Million Dollars is today? And they even didn't care of an optimized release for the Atari, but for the C64 they did?

 

Game was written 1982/83 how the hell can we assume what the reason was to code it in that way or why they used 48 bytes etc... 35 years ago... maybe it was simply because we can or the reason was 42.

42 was the answer to the reason .

Edited April 28, 2019 by emkay

[Heaven/TQA]

Hm. So you mean the screen content is changed by some magical issue?

This was referring to your assumption that LMSs needed to be changed per buffer flipped in the display list and I told you no... i told you how RoF is doing it and all drawing routines work like that...

 

RoF is more complex than you think in terms of drawing. It does not draw on screen like in basic... it uses several tables for edges etc and some code puts all together. And a ora filler and sky filler does the final image.

 

But for that you have to understand the concepts of ora/eor fillers etc.

[emkay]

This was referring to your assumption that LMSs needed to be changed per buffer flipped in the display list and I told you no... i told you how RoF is doing it and all drawing routines work like that...

 

RoF is more complex than you think in terms of drawing. It does not draw on screen like in basic... it uses several tables for edges etc and some code puts all together. And a ora filler and sky filler does the final image.

 

But for that you have to understand the concepts of ora/eor fillers etc.

Sometimes I wonder, if you really understood what a computer is doing.

If you don't use LMS to change the content, and you don't have Page flipping available, you only could change the framebuffer, if the whole frame is copied to the framebuffer directly set range where ANITC is reading the memory.

And: the 96 bytes means that they use a subroutine to switch between the first and the second half, to have a double buffer each line. But this also means it is NO LINEAR Framebuffer.

Edited April 28, 2019 by emkay

[ivop]

Hm. So you mean the screen content is changed by some magical issue?

 

No, just switch to an identical DL, except for all the LMS values, which are += 48;

[Heaven/TQA]

Sometimes I wonder, if you really understood what a computer is doing.

If you don't use LMS to change the content, and you don't have Page flipping available, you only could change the framebuffer, if the whole frame is copied to the framebuffer directly set range where ANITC is reading the memory.

And: the 96 bytes means that they use a subroutine to switch between the first and the second half, to have a double buffer each line. But this also means it is NO LINEAR Framebuffer.

Dont make assumption... use Altirra and go through the code by yourself....

[emkay]

Or to say it in other Words: If they used that 96 Bytes depending LMS settings ,and then copy the memory content into the framebuffer, how would You name that?

[emkay]

No, just switch to an identical DL, except for all the LMS values, which are += 48;

OK. That's an answer.

[emkay]

No additional comments yet?

 

Fact is: For 3D Engines every free cycle counts. And optimizations for this is hardly to find in the Atari version.

Edited April 28, 2019 by emkay