Jump to content
  • entries
    39
  • comments
    621
  • views
    148,283

Elite-like Line Drawing


Thomas Jentzsch

3,319 views

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.

Thargon.zip Thargon v0.02.zip

18 Comments


Recommended Comments

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

Link to comment

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%).

Link to comment
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).

 

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?

 

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 ;)

 

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

Link to comment

More RAM could be made available later by using the Harmony?

Sure, but that wouldn't be 1980ies tech, would it?

 

You don't have to use the extra cycles ;)

If I can improve the frame rate, I will use any free cycle. ;)

 

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.

Link to comment

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.)

Link to comment

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?

 

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

Link to comment

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.

Link to comment
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.
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?
Link to comment

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

Link to comment

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.

Link to comment
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

Link to comment

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? ;)

Link to comment

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? ;)

Link to comment

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...

Link to comment

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? ;)

 

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

 

Chris

Link to comment

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.

Link to comment

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.

Link to comment
Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...