Let's bring ELITE to the VIC-20

[AndyH]

... If the line-removal-method from the BBC-master-version is also applied, which instead of first removing *all* lines and then redrawing all lines again, it just does this on a line-by-line basis, flicker show be minimal...

Doh, yes this exactly

[Mike]

[...]

Doh, yes this exactly

As follows from my preceding post, being able to use page flipping will allow for a higher frame rate, as clearing the bitmap in the shadow/drawing buffer is already faster than undrawing more than 4 lines of medium length.

One arrives at that result regardless of the order the lines are undrawn with a single screen buffer.

112x112 pixels are about 68% of the other proposed cockpit size, 128x144 pixels. With the smaller screen, the lines are still about 82% of their lengths in the larger screen. Of course, handling a smaller bitmap and having slightly shorter lines put the odds even more in favour to page flipping, but most time will be saved by not needing to undraw the lines one by one but being able to just clear the drawing buffer. The time spent in the geometry engine and other business logic remains the same.

Finally, the page flipping is synchronized to the screen refresh - so there's not just 'reduced' flicker, but no flicker at all.

[pixel]

Yeah. The tiny amount of screen memory is quite a game changer compared to the later models. Some speed code in expanded memory would be a cool option, too.

[AndyH]

$1000 .. $108B: "Text" screen 1 (top: $3C..$9D, bottom: $09..$1F, $29..$3B)
$1090 .. $11FF: Scanner bitmap 1st part (23 Characters, $09..$1F)
$1200 .. $128B: "Text" screen 2 (top: $9E..$FF, bottom: $09..$1F, $29..$3B)
$1290 .. $13BF: Scanner bitmap 2nd part (19 Characters, $29..$3B)
$13C0 .. $19DF: Cockpit 1st bitmap page (Chars $3C..$9D)
$19E0 .. $1FFF: Cockpit 2nd bitmap page (Chars $9E..$FF)

That is ingenious, I'm now thinking of other applications for this screen memory layout.

...
112x112 pixels are about 68% of the other proposed cockpit size, 128x144 pixels. With the smaller screen, the lines are still about 82% of their lengths in the larger screen. Of course, handling a smaller bitmap and having slightly shorter lines put the odds even more in favour to page flipping, but most time will be saved by not needing to undraw the lines one by one but being able to just clear the drawing buffer. The time spent in the geometry engine and other business logic remains the same.

Finally, the page flipping is synchronized to the screen refresh - so there's not just 'reduced' flicker, but no flicker at all.

Interesting. So you calculate it will be faster to clear that area of the screen and then draw rather than eor draw the lines of a typical model twice? The screen size is fine from my point of view and I would definitely agree that aspiring to optimise for speed is preferrable to a slower but larger screen.

I don't have any timing information for either, but something to consider between the two approaches:

1. Clear screen, draw, wait VBL and flip buffer: A constant minimum speed, and potential fewer frames on busy 3D views. But no flicker as stated.
2. Erase/redraw line routine, no VBL: will benefit from running faster on simpler 3D views, slower on busy 3D views, and all dependent upon timings to draw lines twice.

Method 2 would rely on delta timing for translation of the game world, although method 1 would benefit from that approach too.

Edit: also method 2 can help give an impression of greater speed in certain situations as the screen refresh and 'micro' changes are perceived by the player. Method 1 would suffer the slide-show effect if the frame rate is constantly low. Not an issue if the refresh speed can be maintained at an acceptable level and the benefit would be a solid looking display.

[Kweepa]

Some of Aleksi's progress:
https://www.youtube.com/watch?v=eR7df9rrbyQ

[Rich]

Looks amazing!!!! Is that a vic20 surely not

[Mike]

Some of Aleksi's progress: [...]

Well, nice. In the video description, Aleksi at least contributes most of his port to the recent works in Mark Moxon’s digital archaeology project of Elite. In particular, the relevant contributions of Aleksi himself are adapted graphics routines for the VIC-20, and of course the necessary fair share of time in the last two weeks to let action follow the word.

I suspect though that this port of ELITE will remain a one-man project. Aleksi didn't even bother to post the YT link here in Denial by himself.

It is also quite ashaming, that the YT video already has more commentary posts than this thread here. Perhaps, if people wouldn't believe all that Wikipedia bullshit about the VIC-20's 'missing' graphics capabilities (see Mr. Spongmans post: "ok, fast line-drawing on the BBC was impressive enough with its memory laid out as character cells, but with no bitmapped graphics at all, that's just insane..." - to note: the BBC has a linear addressing of the bitmap, it's the C64 that has the character cell layout, and the VIC-20 is perfectly able to put a bitmap on display!), more in that regard would happen here in Denial.

The community spirit of Denial once had made projects like Mega-Cart possible. In particular that means that not always the same people should need, or be expected, to put their time and resources into such projects!

[darkatx]

I find most forums are growing silent as places like Discord take over so seeing more commentary on a Youtube posting shouldn't be surprising. As for the misinformation floating around, that comes with the territory with most social media.

I was impressed with the results so far as there were no doubts in my mind that the VC-20 could receive a port considering all the amazing software pumped out in the last 15 years for the Friendly Computer.

I think he shared he was having RAM/compression issues trying to get as much into the final product as possible.

[aeb]

I was going to post about it, but Kweepa got first because I didn't want to post just a YouTube link to the demanding, more technically oriented audience here I'm away from my computer for 2 days - please don't tell anyone I'm sketching up pieces of the remaining dashboard code with the pen and paper method on a napkin here right now

Mark Moxon posted the link on his Bluesky, so there may be lot of views (and comments) from people who know Elite, but don't know VIC 20 at all. Also, there's so many views actually that I suspect some retro gaming site has already shared the link, bringing in views (and comments) from people who are into retro games but have less (8-bit) programming experience. I'll reply to some of the comments there to get the bitmap facts and such straight!

Obviously, this port is 100% dependent on Mark Moxon's source release, in-depth analysis, and commentary.

I got started by spending a day reading through the main code and data source files, and marking up things that would require changes for VIC 20, be that rewriting or adapting or relocating or flagging out stuff. Converting the keyboard matrix (as both keyboard row/col layout and ASCII), and reducing the ship blueprints (to make space for K% and TS% workspaces) were two operations that took some manual effort and thought.

For blueprints, I've currently flagged out Dodo station (the biggest object in the game, around 400 bytes, replaced by Coriolis station like on BBC Cassette and Acorn Electron), ships that never or extremely rarely appear on C-64: Constrictor (mission only), Cougar (super rare), Moray (bug in spawn code), reused blueprints for some ships but keeping their original behavior bits (Cobra MK I -> Cobra MK III, Shuttle -> Transporter, Anaconda -> Boa, Rock Hermit -> Asteroid); and used the same blueprint for trader and pirate versions of Cobra MK III and Python, but added a two lines of code rewarding the bounty only if the pirate flag is set in ship properties, etc.

Then, actually, the VIC 20 port "became alive" surprisingly quickly when I put just a few graphics calls in place. It's highly motivating to see that fixing just one thing fixes 100 things in the game!


Current progress:

Stuff already done, but not shown in the video: All the 4 sights, sound fx for all lasers, explosion "sprite" - Most of the gameplay is really already there and working!

Stuff under work: dashboard bars, compass, missile indicators, E/S bulbs, docking computer music, stripping unused extended tokens code (DETOK, IANTOK) to free up some 600-1000 bytes of space, load/save commander functions - Mostly just general, less rewarding grunt work

Bugfixes/refinements yet to be done: fix the black lines appearing in sun draw by using the original drawing order (see deep dive "sun draw"), remove dashboard flicker during switching views by only clearing only the top area of bitmap if dashboard is visible, clamp upwards sticks in radar view before they reach the space view, implement the flicker-free ship draw mod - All less critical, but important for the overall feel of quality of the port


Lines, discussed previously:

I'm still using the same Hein's bresenham line draw, which seems adequately fast, because we've got only half of the pixels to draw or erase: C-64 original has an unrolled line draw for all bit positions, and 2 or 4 segments repeating the code (I didn't read it all, just flagged it out and replaced it with a call to the VIC code). Also, C-64 bitmap mode has a much more complicated byte order, I'm using just straight 208-pixel-tall columns in the bitmap configuration, which makes plotting super simple and no registers need to be preserved.

Line draw or plotting dots is probably not the bottleneck, it's the maths. With maximum 10 ships in the local bubble of space, there's more number crunching happening than there was on the actual Apollo Mission Computer during moon landing or orbit (maybe a little exaggerated, but you get the idea) I read C-64 improved over the earlier 6502 versions by implementing log-based multiply/division, and all of that is brought to VIC 20 as well. I dared not even touch the math routines, except for halving the X1 and X2 coordinate values of lines just before drawing them.

There may be space for an improved line draw after everything else is done, but it might not improve the overall game much, if at all. I remember reading Kroc, who's writing Elite Harmless, was feeling discontent after spending big effort on optimizing drawing with not much gains in gameplay. Maybe it's better to bring back the Dodo station and the Shuttle, or some other blueprints, if there's space remaining in the end?


One interesting question in the scope of interest of Denial is why there was no VIC 20 port of Elite in the 80s! What do you think?

Maybe it was that the most common RAM expansions were only 16K, and only a few users had those? Even smaller fraction of users had 32K+3K or even 24K, and possibly had to build those themselves? 16K was enough for a bit more complex games on tape, but not enough for Elite. Maybe a VIC 20 port was discussed, but they decided there was no market for it?

Apple II was introduced 4 years earlier than VIC 20, but had a much longer lifespan thanks to its expanded memory configurations on later models, a big user base in the US, and not having a dominant follower, like C-64 was after VIC. Apple II got their Elite as late as 1986, and it's arguably the best version of Elite on home computers (not including the perhaps superior NES version).

Well, that's my old man ramblings for the day, now back to coding on pen and paper! Right on, Commander!

P.S. To replace the SID sound effects, I wrote a tiny 184-byte, IRQ-driven sound FX routine from scratch, that's perhaps worth releasing on its own, for everyone to use in their projects. It's a bit "laser-oriented", but can produce all sorts of beeps and boops

Some of Aleksi's progress: [...]

Well, nice. In the video description, Aleksi at least contributes most of his port to the recent works in Mark Moxon’s digital archaeology project of Elite. In particular, the relevant contributions of Aleksi himself are adapted graphics routines for the VIC-20, and of course the necessary fair share of time in the last two weeks to let action follow the word.

I suspect though that this port of ELITE will remain a one-man project. Aleksi didn't even bother to post the YT link here in Denial by himself.

It is also quite ashaming, that the YT video already has more commentary posts than this thread here. Perhaps, if people wouldn't believe all that Wikipedia bullshit about the VIC-20's 'missing' graphics capabilities (see Mr. Spongmans post: "ok, fast line-drawing on the BBC was impressive enough with its memory laid out as character cells, but with no bitmapped graphics at all, that's just insane..." - to note: the BBC has a linear addressing of the bitmap, it's the C64 that has the character cell layout, and the VIC-20 is perfectly able to put a bitmap on display!), more in that regard would happen here in Denial.

The community spirit of Denial once had made projects like Mega-Cart possible. In particular that means that not always the same people should need, or be expected, to put their time and resources into such projects!

[tokra]

One interesting question in the scope of interest of Denial is why there was no VIC 20 port of Elite in the 80s! What do you think?

Maybe it was that the most common RAM expansions were only 16K, and only a few users had those?

Original Elite was released at the end of 1984, when the C64 was already on the market for nearly 2 years and most Commodore-folks would have moved on by then. Add to that the memory requirements - 16K was pretty common I think (had one myself back then), but larger than that was only for absolute enthusiasts. So, effectively there was no audience left for a VIC-20 release, I think.

[AndyH]

My vixen 16k switchable RAM cart was a major purchase for me in 1984 as an 11 / 12 year old. I would have loved to have had this game but the memory required would have made it unobtainable for me. Thankfully RAM is a bit cheaper today.

Would love to see the sound routine, I'm always re-writing mine and sound isn't my strong point. And I don't suppose you'd consider releasing the Vic source at the end? While 3d math is far beyond my limits I'd love to try to learn a bit more and possibility of making minor tweaks for my own enjoyment.

[huffelduff]

...back to coding on pen and paper! Right on, Commander!

Now that's old school!
Anyway fantastic work Alexi.

Greetings

H

[MrSterlingBS]

Hi,

thanks for converting the game that changed everything in 3D grapphics for home computers to our VIC-20.

I think there was a VIC-20 version possible in 1984. If we take a look at the website from Mark Moxon we can see the Electron version is about of 24.000 bytes in size.
https://elite.bbcelite.com/compare/feat ... rison.html Scroll down for more information.
If Commodore had made a good deal with Acorn, a few thousand 24kb expansions or 16kb (most probably had the 16kb extension + 8kb game module +Cassette) would definitely have been sold.

Thanks again Aleksi for the conversion.

BR
Sven

[MrSterlingBS]

We see in some other post the discussion that the line drawing routine is not the bottleneck.
But if we calculate the difference between an 22.000 pixel/s (50 cycles per pixel)or Mikes super fast 30.000 pixel/s (33 cycles per pixel) routine a huge different.
If we assume that Elite is drawing about 300 pixels per frame as line drawing we can save about 6.000 cycles each frame.
And if we assume that Elite has 5-8 frames per second, it counts a lot. 6.000 cycles can be used for other task.

That's just my opinion.

As Michael Abrashs said. https://www.phatcode.net/res/224/files/ ... 35-01.html

BR
Sven

[aeb]

Here's the latest update:
https://www.youtube.com/watch?v=Bw39FR4Ao2U

If you have a VIC 20 with 35K expansion and want to go on a test flight, send me a message or email (email in the video description)!