For whom it may concern

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

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

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

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.

Could the extra cycles be used to clear the the screen?

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

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

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.

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?

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

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.

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

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?

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?

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

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

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.

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.