Pseudo 3D Starfield

Here you can ask questions or provide insights about how to use efficiently 6502 assembly code on the Oric.
Post Reply
User avatar
Game master
Posts: 819
Joined: Sat Jan 07, 2006 12:07 am
Location: Luton, UK

Pseudo 3D Starfield

Post by Twilighte » Tue Mar 11, 2008 5:36 pm

I'm looking for good 6502 examples of pseudo 3D starfields. I guess i'll also look at C64 or BBC games with 3D starfields in them too, if only to capture the code they used.
The accumulative methods i am experimenting with atm are not accurate or variable enough.

For example i am currently using a fractional stepping method in order to move the trajectory in all angles, but 8 bit fractional stepping is not sufficient..

Code: Select all

lda reference
adc frac
sta reference
Depending on FRAC this provides a sequence of regular 1's amongst 0's like 0000100001 in the Carry flag

Code: Select all

lda XOffset
adc #00
sta XOffset
Add this to XOffset which ranges 0-119 and then branch to add or subtract from 120 will provide the x position of the star.
Then by increasing the frac value i am able to increase the regularity of carry's and so increase the velocity of the star.
however wherther it be the random routine i am using to store the original FRAC for both x and Y trajectories or the limits of 8 bit fractional stepping i only ever get a limited number of trajectories and the result looks false.

What is most annoying is that i was sure i have done a good 3D starfield many years ago but have since lost the source.

User avatar
Posts: 1349
Joined: Sat Jan 14, 2006 12:44 am
Location: Paris, France

Re: Pseudo 3D Starfield

Post by Symoon » Sat May 19, 2018 9:45 am

Anyone ever found something about this?
Theres was a great starfield at the beginning of Mercenary, which existed on C64 and many other machines. I suppose we could find the code.

Flying Officer
Posts: 136
Joined: Thu Oct 13, 2016 9:55 pm

Re: Pseudo 3D Starfield

Post by ThomH » Mon May 21, 2018 5:12 pm

In Elite stars have a current (x, y, z). They are currently plotted directly at (x, y). z isn't a factor in plotting.

To move a star closer by a delta 'd', the engine computes offset = d/z. It then subtracts that offset from the stored z, and adjusts (x, y) to (x', y') = (x, y) * (1 + offset).

So it's actually storing (x/z, y/z, z), then mapping deltas into (1/z) space to patch up x and y. Precision is very approximate, but they're just stars so it's hard to notice. An advantage of that representation is that even if you have to redraw your complete frame from blank every tick, you still don't need to spend a divide on every star. Just update as many as you have time for.

Rotation is handled by the simple observation that stars should move in a circle around the centre. The vector from the screen centre to (x, y) is the normal to that circle. The tangent is then that rotated by 90 degrees. So e.g.

Code: Select all

t = (x, y) - centre
t' = (-t.x, t.y)
(x, y) += [rotation speed]*t'
As long as 'rotation speed' is low and/or you have a sensible amount of fractional precision, that tends not to throw stars too noticeably far away from where they should be.

EDIT: glancing at some Elite screenshots it looks like there are generally something of the order of 16 stars in action at any one time. You won't see exactly that many because they're not recycled just for going off the edge of the display, they actually need to drop below the necessary distance. If that weren't true, rotating would slowly clip all those that were near the corners.

User avatar
Game master
Posts: 2241
Joined: Tue Jan 17, 2006 10:55 am
Location: Gijón, SPAIN

Re: Pseudo 3D Starfield

Post by Chema » Mon May 21, 2018 5:52 pm

Elite's version should do. In fact the thing is avoiding the real projection and just move stars faster when they are further from the center of the screen. Or something along that line.

In 1337 I adapted the routines made by Stephen Judd and described here

The article is called "Starfields" and he used the idea on his implementation here

The adaptation I had to make and which is running in 1337 is ... NE/stars.s

Same idea, but using some global variables for the rotation angles and moving speed of the current player's ship.

I move just 16 stars, but that is because I have to do other things and remember 1337 draws with double-buffer. Plotting/erasing with EOR (a matter of keeping two tables with old/new positions) would be MUCH faster, so more stars can be moved.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests