Jump to content





Photo

Elite-like Line Drawing

Posted by Thomas Jentzsch, in Atari 20 December 2009 · 89 views

Elite Line Thargon Damned Tag Clouds
Inspired by this blog entry, I spend spend some time with the line drawing part of Elite.

Since there is no double-buffer (like Elite), I experimented with 3 ways of line drawing:
1. Clearing the whole screen and then drawing all lines.
2. Plotting pixels with XOR, erasing the old and immediately redrawing the new line
one by one.
3. Plotting pixels with XOR, erasing all lines first and then redrawing all new lines.

The constant clearing time in variation 1 slows down the frame rate when there is not much to draw, but would increase it when there are more than ~140 pixel to plot in a frame. The problem is, that unlike in variation 2 and 3, the screen is flickering quite a lot as a whole and not all lines are displayed for the same amount of time.

Variation 2 displays all lines but the one currently redrawn. Unfortunately this leads to a lot of artefacts.

The 3rd variation is a compromise between 1 (all lines displayed the same amount of time) and 3 (less artefacts), which IMO looks best and seems to be the way Elite draws its lines too (maybe someone can confirm this?).

Attached are NTSC and PAL binaries (using E7 bank switching) plus the source code (if anyone is interested, nothing too special) displaying a single Thargon. The code tries to use the free CPU time (pretty imperfectly) which is much larger for PAL. Therefore the PAL version runs much faster.

Still both are not running very fluently even though the status display and any 3D movements and transformations are still missing. There is a little room for improvement (like self-modfying code and better CPU time utilization), but I am not very positive this would gain enough to get close enough to an acceptable frame rate.

Attached Files







cd-w
Dec 22 2009 4:43 AM
This is a nice demo, but the flicker is quite painful. Would the framerate be acceptable with double-buffering (if there is enough space in E7 to implement it)?

Chris
  • Report

Thomas Jentzsch
Dec 22 2009 5:46 AM
The frame rate wouldn't benefit from double-buffering, but the result should look a bit better.

E7 has exactly 2k of RAM, so the current 1020 bytes screen buffer would fit. But then there would be only 128 bytes ZP and 8 bytes extra RAM left. That seems not sufficient.

One could reduce the vertical height a bit and gain RAM that way, but the status and radar display still has to be drawn somehow.

I still have ~21 cycles/line left in the kernel, I wonder where those should be spent. Either for a nice cross-hair display (using BL + PF), or use the screen buffer for the cross hair too and spend the CPU time for some other stuff? I could clear parts of the frame buffer when using variation 1, but that's the only idea I have come up until now. ;)

BTW: The Thargon displayed has 331 pixel, so variation 1 would definitely be faster here (~25-30%).
  • Report

cd-w
Dec 22 2009 6:11 AM

Thomas Jentzsch, on Tue Dec 22, 2009 11:46 AM, said:

The frame rate wouldn't benefit from double-buffering, but the result should look a bit better.
The flicker is the main problem for me - a slow framerate wouldn't be too much of an issue (depending on how slow it is).

Quote

E7 has exactly 2k of RAM, so the current 1020 bytes screen buffer would fit. But then there would be only 128 bytes ZP and 8 bytes extra RAM left. That seems not sufficient.
One could reduce the vertical height a bit and gain RAM that way, but the status and radar display still has to be drawn somehow.
More RAM could be made available later by using the Harmony?

Quote

I still have ~21 cycles/line left in the kernel, I wonder where those should be spent. Either for a nice cross-hair display (using BL + PF), or use the screen buffer for the cross hair too and spend the CPU time for some other stuff? I could clear parts of the frame buffer when using variation 1, but that's the only idea I have come up until now. ;)
You don't have to use the extra cycles ;)

Quote

BTW: The Thargon displayed has 331 pixel, so variation 1 would definitely be faster here (~25-30%).
So clearing the whole screen is faster than xor-ing the lines to delete the previous image?

Chris
  • Report

Thomas Jentzsch
Dec 22 2009 2:58 PM

cd-w, on Tue Dec 22, 2009 1:11 PM, said:

More RAM could be made available later by using the Harmony?
Sure, but that wouldn't be 1980ies tech, would it?

Quote

You don't have to use the extra cycles ;)
If I can improve the frame rate, I will use any free cycle. ;)

Quote

So clearing the whole screen is faster than xor-ing the lines to delete the previous image?
Yes. Clearing a whole screen costs ~5500 cycles, drawing e.g. 300 pixel costs ~11000 cycles. So we would gain maybe 25% more frames per second. But that would require double buffering to looks acceptable.

I suppose Elite used the XOR variation because of the higher resolution. If you double the resolution, line drawing costs about twice as much time, but clearing requires 4 times as much.
  • Report

EricBall
Dec 22 2009 7:04 PM
Could the extra cycles be used to clear the the screen?
  • Report

Nathan Strum
Dec 22 2009 10:24 PM

Thomas Jentzsch, on Tue Dec 22, 2009 12:58 PM, said:

cd-w, on Tue Dec 22, 2009 1:11 PM, said:

More RAM could be made available later by using the Harmony?
Sure, but that wouldn't be 1980ies tech, would it?
It depends... could enough RAM have been added to a cart using 80's technology, even if it wasn't done back-in-the-day?

I would think if it was technically feasible in the 80's, then that's not really using the Harmony to cheat. It's just using it to accomplish something that might have been cost-prohibitive. (Now using the Harmony as a co-processor or something... that's cheating. Unless it's capable of emulating an off-the-shelf processor from the 80's that could have been incorporated into a cart.)
  • Report

cd-w
Dec 23 2009 5:43 AM

Thomas Jentzsch, on Tue Dec 22, 2009 8:58 PM, said:

Sure, but that wouldn't be 1980ies tech, would it?
The Supercharger had 6KB, so a little extra RAM wouldn't be too much of a problem?

Quote

I suppose Elite used the XOR variation because of the higher resolution. If you double the resolution, line drawing costs about twice as much time, but clearing requires 4 times as much.
I think it would be useful to see how it looks with double buffering. I know that Elite didn't use that method originally, but then there was no 2600 port ;)

Chris
  • Report

Thomas Jentzsch
Dec 23 2009 1:12 PM

Nathan Strum, on Wed Dec 23, 2009 5:24 AM, said:

It's just using it to accomplish something that might have been cost-prohibitive.
But using something which was cost-prohibitive back then is like cheating too, isn't it? I mean, the programmers back then had to adapt to the existing, affordable hardware too.
  • Report

Thomas Jentzsch
Dec 23 2009 1:21 PM

cd-w, on Wed Dec 23, 2009 12:43 PM, said:

The Supercharger had 6KB, so a little extra RAM wouldn't be too much of a problem?
Sure, but it was pretty expensive and the RAM was reused for several games. And it was very difficult write too, though I am not sure if that was done to cut costs.

Quote

I think it would be useful to see how it looks with double buffering. I know that Elite didn't use that method originally, but then there was no 2600 port ;)
I see what I can do. The 2nd 1k are split into 4 256 bytes blocks, so I have to change my code to work efficiently with the different memory layout too.BTW: After measuring some Elite screen shots, I think I could reduce the height of the buffer quite a bit. The Elite cockpit view is 256x143 pixel, while my current version displays 96x85 (double height) pixel. So maybe 64 vertical pixel will work too. This would gain some vertical space for the cockpit display (without loosing even more CPU time) and some RAM space for the game play. What do you think?
  • Report

cd-w
Dec 24 2009 2:09 AM

Thomas Jentzsch, on Wed Dec 23, 2009 7:21 PM, said:

BTW: After measuring some Elite screen shots, I think I could reduce the height of the buffer quite a bit. The Elite cockpit view is 256x143 pixel, while my current version displays 96x85 (double height) pixel. So maybe 64 vertical pixel will work too. This would gain some vertical space for the cockpit display (without loosing even more CPU time) and some RAM space for the game play.
What do you think?

Sounds like a good direction to go - the current screen size is quite large, and a smaller size would still be perfectly visible. Also, 64 is a nice number to work with ;)

Chris
  • Report

Thomas Jentzsch
Dec 28 2009 2:02 AM
Ok, now it double buffers and uses variation #1 and no XORing the pixels. This looks much better IMO.

I also optimized the CPU utilization quite a bit, so we got ~15 FPS in NTSC now. I think this speed would be sufficient.
  • Report

cd-w
Dec 28 2009 4:14 AM

Thomas Jentzsch, on Mon Dec 28, 2009 8:02 AM, said:

Ok, now it double buffers and uses variation #1 and no XORing the pixels. This looks much better IMO.
I also optimized the CPU utilization quite a bit, so we got ~15 FPS in NTSC now. I think this speed would be sufficient.

Nice work - much easier on the eyes - and it runs faster too. This looks like it would make a nice 2600 Elite game - a fitting sequel to Thrust ;)

Chris
  • Report

Thomas Jentzsch
Dec 28 2009 6:21 AM

cd-w, on Mon Dec 28, 2009 11:14 AM, said:

Nice work - much easier on the eyes - and it runs faster too. This looks like it would make a nice 2600 Elite game - a fitting sequel to Thrust ;)
Maybe, but it wasn't my idea to port it, so I would ask Trogdor first.

And then I wouldn't like to do it all alone. I am mostly interested into the tricky parts, like efficient line drawings (almost done) and 3D calculations (next on my list), task scheduling (already implemented) etc. I am afraid all the other stuff will bore me soon.

The collaboration with Andrew doing Boulder Dash was perfect. I was allowed concentrate on what I like. So for Elite I would need a partner.

Anyone?

BTW: I am not sure if I should OR or XOR the pixel. OR looks a bit better for close objects (no gaps at the intersections of lines), but for distant objects it would result into an unstructured, completely solid object, while XOR would at least give this object some kind of structure. What do you think? ;)
  • Report

LS_Dracon
Dec 29 2009 5:22 PM
When I try to download the version 0.02.zip, return-me an error...File missing or something like that...Can you upload the file again, please? ;)
  • Report

Thomas Jentzsch
Dec 30 2009 6:56 AM

LS_Dracon, on Wed Dec 30, 2009 12:22 AM, said:

When I try to download the version 0.02.zip, return-me an error...
File missing or something like that...
Can you upload the file again, please? ;)
All Blog attachements are broken ATM. ;)

Al is working on it...
  • Report

cd-w
Dec 31 2009 1:27 PM
[quote name='Thomas Jentzsch' date='Mon Dec 28, 2009 12:21 PM'] [quote name='cd-w' date='Mon Dec 28, 2009 11:14 AM']
BTW: I am not sure if I should OR or XOR the pixel. OR looks a bit better for close objects (no gaps at the intersections of lines), but for distant objects it would result into an unstructured, completely solid object, while XOR would at least give this object some kind of structure. What do you think? ;) [/quote]

How about combining both OR for close objects and XOR for far objects?

Chris
  • Report

EricBall
Dec 31 2009 6:36 PM
The typical reason for using XOR is so the same algorithm can be used to plot and erase the same line. Unforutnately, it does have the side effect of causing pixels to be unset when two lines cross. (Not bad when it's only one pixel, but if the angle of intersection is shallow then lots of pixels can get removed.)

If you're clearing the bitmap separately then I'd go with OR. Sure when the object is far away it turns into a blob, but that's kinda what happens in real life.
  • Report

Thomas Jentzsch
Dec 31 2009 6:43 PM
Using XOR and OR won't work due to space limitations. And with double buffering OR works nicely. So I'll stick with OR.

BTW: If you haven't noticed, I posted my latest updates in the homebrew forum.
  • Report
  1. AtariAge Forums
  2. → Community Blog
  3. → For whom it may concern
  4. → Elite-like Line Drawing
  5. Guidelines