Jump to content
IGNORED

Elite 3D graphics


Thomas Jentzsch

Recommended Posts

Since the AA blog attachments are currently broken, I thought I should post my latest update here.

 

Most 3D calculations are implemented now and you can spin the Thargon either with the joystick (press fire for z-axis) or let it spin automatically with left difficulty = A.

 

There are still some nasty bugs hidden in there, but it works as it is. Next on my list are 3D projections (incl. zooming) and hidden line removal.

 

For those who didn't follow my blog: use E7 (M-Network) bank switching and enable the phosphor effect for making it look better.

 

BTW: Don't expect this to turn into an Elite remake soon. ;)

Thargon (NTSC v0.03).bin

post-45-126221017722_thumb.png

Thargon (NTSC v0.04).bin

Thargon (NTSC v0.05).bin

Edited by Thomas Jentzsch
  • Like 3
Link to comment
Share on other sites

I have attached an updated version to the first post.

 

This one which fixes some nasty sign flipping bugs and adds projection (disable with right difficulty to see the difference) and zooming (fire button + up/down).

Edited by Thomas Jentzsch
Link to comment
Share on other sites

Last update for now: Hidden lines removed (well, sort of), use B/W switch to toggle. See v0.05 in 1st post.

 

It turns out that 8 bit arithmetics are not sufficient, even for the low resolution we have here. The general imprecise movement of the Thargon and the hidden line bugs are resulting from that.

 

So I'll have to switch to 16 bit, which will require a lot of code to be rewritten. And I am afraid it will cause a pretty massive slowdown of the calculations. The pretty simple Thargon (just 10 points and 7 polygons compared to e.g. a Fer-de-Lance ;) with 19 points and 13 polygons)) runs at current maximum speed and the code already utilizes the available CPU time very well.

 

So after switching to 16 bit we will see what compromises (e.g simplified ships, e.g a Thargon with just 4 points and 5 polygons) are necessary to get a decent speed from the good old 2600 and if that's possible at all. Might take some time...

Link to comment
Share on other sites

It turns out that 8 bit arithmetics are not sufficient, even for the low resolution we have here. The general imprecise movement of the Thargon and the hidden line bugs are resulting from that.

 

 

So after switching to 16 bit we will see what compromises (e.g simplified ships, e.g a Thargon with just 4 points and 5 polygons) are necessary to get a decent speed from the good old 2600 and if that's possible at all. Might take some time...

I use a mixture of 8-bit/16-bit arithmetics in Fractalus, where the perspective work is done in 16-bit until the high-byte is zero, and then switch to 8-bit operations. This along with table driven multiplies/divides allow the 6507 do the job. For my game, just the grid endpoints need to be operated on, so the data set can be kept to a minimum, coupled with not actually doing a full rotation matrix to bank the 3D view, but to shear the values.

 

BTW, excellent work here Thomas!

 

--Selgus

Link to comment
Share on other sites

I use a mixture of 8-bit/16-bit arithmetics in Fractalus, where the perspective work is done in 16-bit until the high-byte is zero, and then switch to 8-bit operations. This along with table driven multiplies/divides allow the 6507 do the job. For my game, just the grid endpoints need to be operated on, so the data set can be kept to a minimum, coupled with not actually doing a full rotation matrix to bank the 3D view, but to shear the values.

I am interested, but I cannot find anything about "Fractalus". Can you give me a link, please?

Link to comment
Share on other sites

I am interested, but I cannot find anything about "Fractalus". Can you give me a link, please?

I haven't released it yet, so still a WIP. It uses the 3D endpoints of a grid to generate fractal lines that make up the 3D viewport mountains (player/missiles along with playfield graphics).

 

Mine also updates the calculations every 3rd frame (so 20Hz), though the display is rendered every frame. I do the viewport calculation in 1/60th, HUD updates 1/60th and then game logic the last 1/60th.

 

I'm currently using 1K of RAM for doing the double buffered 3D viewport and the fractal structures, and the 256 byte RAM windows for the HUD structures... though the original plan was to create my own banking selection on Harmony, to allow exactly what the game would need.

 

--Selgus

Link to comment
Share on other sites

I haven't released it yet, so still a WIP. It uses the 3D endpoints of a grid to generate fractal lines that make up the 3D viewport mountains (player/missiles along with playfield graphics).

That sounds impressive. Anything you can show already?

 

Mine also updates the calculations every 3rd frame (so 20Hz), though the display is rendered every frame. I do the viewport calculation in 1/60th, HUD updates 1/60th and then game logic the last 1/60th.

I've developed a quite nice scheduling algorithm for my demo. I splits the off-screen processing into several tasks (e.g. clear buffer, plot all lines). Each task gets a worst case processing time (TIM64T values). Some tasks are split into repeated sub tasks (e.g plot a line), because they don't fit into VBLANK or Overscan time as a whole.

 

The scheduler is pretty simple. It checks if there is enough time for the next task and runs it if there is. If the task has subtasks, the time checked is the time required for a single subtask. The scheduler is called twice each frame (VBLANK and Overscan).

 

Normal tasks do their job and increase the task number.

 

Task with subtasks, iterate those subtasks as long as there is enough time left. They increase the task number after all subtasks are processed.

 

When all tasks are done the task loop starts again.

 

I'm currently using 1K of RAM for doing the double buffered 3D viewport and the fractal structures, and the 256 byte RAM windows for the HUD structures... though the original plan was to create my own banking selection on Harmony, to allow exactly what the game would need.

That would work with the bankswitching I am using too. :)

 

I am using 2x768 bytes for the frame buffer and plan to use the remaining extra 2x256 bytes other stuff.

Link to comment
Share on other sites

Now a Fer-de-Lance!!! :D

Ok. Now you can see it crawl. :)

 

BTW: At the bottom the current frames per second are displayed.

 

 

Gosh!!! That´s a Fer-de-Lance!!!!!! :thumbsup: :cool:

 

Count me in for an Elite Spacechips cart!!!!

 

BTW: You really make awesome things.............

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

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