pouët.net

hence c64 does wolf clones about twice as fast as what you linked to, that means about 70x2 pixels can be done in 3d on a c64, in crawl speed.

wolf is basically raycasting, which is a magnitude faster than raycasting, which again is faster than raymarching.

Has anyone tried penguin marching?

What's this?

When I hear "raycasting" I think of 2d map/intersection+1d buffer calculations in the classic id software games sense. Anything else is not "raycasting" in my mind.

Regarding raytracing on 8-bit platforms: While completely impractical, I'd like to see some implementation of this on a c64. Just to see how long it takes to render a full non-trivial hires/multicolor picture. Probably a week or so. :)

There was a raytracing program on Atari ST

And then you have the marching cubes and you think this :)

Actually, I just remembered a Smash Designs 4k, raytracer but maybe it's a fake? Can someone confirm? You could cheat easilly with blocky pixels anyway.

Few thoughts about it, it's interesting to see what can be done in 8bits. In a voxel landscape I almost started to do (for CPC), if your camera doesn't rotate, the marching points are stable offsets from the viewing start, so all you could do is write unroll code for every sampling point that samples "player position + offsets". Also, even with rotation it would work, just make different unroll codes for rays for the whole 360 degrees and you only run the selected unroll codes for rays that are inside your viewing window. So I am wondering, an 2d array of unroll codes with precalced sample points on X and Y for a 3d raycaster? Yep, much more stuff to sample, but maybe with a crappy 16*16*16 resolution? And you should sample on some voxel data (small resolution of course) or maybe easy function, would be much easier than distance based raymarching (don't really know how to optimize sqrt in old computers besides huge precalc luts), only matter how many size iterations you allow.

That 4k is really slow (1fp), low-res (32x22?), has no shadows, reflections or anything. That's raytracing in name only.

Then it would make sense nobody commented for this prod either on pouet or csdb.

At least he tried :)

Just saw it, you can even see the redraw :)

Might be definitely raytracing in the traditional sense, solving analytical ray-sphere/plane intersection, but without reflection/shadows as you say, which would be current definition of raytracing. But still doing the hard per blocky pixel calcs.

Anyway, just an idea how hard it is on the old platform. Maybe we will have it a bit better but still blocky and slow with fixed steps raymarching unrolled codes I described.

@Optimus,

good thinking with the prerolling for rotation, but wont fit into 64k, nor 128 :P because of the limited memory you have to work with tables and only one "ray" unrolled, for a rotating cam.

3d raycasting/marching whatever would only work in the SPF (seconds per frame) domain. With huge pixels.

There was voxel landscape on Speccy in Insane, Over the Top, and Eye Ache 2.

over the top seems like an anim, the other 2 is badly balanced. I think there's room on the speccy for a nice looking realtime voxel.

Over the Top is controlled with 6,7,8,9. It's not anim.

Size, depends on how many steps per ray, and usually you can have small number like 32. And say 32 or 64 columns, so it's 1024 to 2048 multiplied by how many bytes(?) per sample code. Maybe rotation you do a full 256 loop if 64 is for 90 degrees view, so 4096 or 8192 samplings. Ok,. you are right, it might be tight this time depending on the code size. So, maybe the other solution is to use the non rotated camera option and just make a 2d rotation on the heightmap data.

2d rotation is again a huge task for a 8 bit alone. what you'll doing here is a rotzoomer without zoom AND a fixed voxel engine. A c64 is happy if it can even reach 10-20 fps with either of those alone. So, tables is the way to go.

I'd prefer a rotating cam one tho, as its rarely done because of these problems. fixed cam is quite easy.

I've heard of 3D landscapes made back-to front in curves, filled between these curves. That's faster than raymarching.

@Oswald: I think there were already some landscape engines in C64 and Speccy (but not on CPC yet) with rotation too. I guess too blocky and very few steps with precalced then.

lots of landscapes out there, but none managed to both be higher res and rotate, and have texture or so, and also keep speed. you can always pick out what the compromise was.

as for landscapes, i still think the one in rescue on fractalus beats everyone elses. pretty damn awesome for its time.

Agreed, and while I've figured out the basic fractal generation method, what I never figured out was how they rotated and projected it so damn quickly.

it's a handful of vertices arranged in a grid (calc one vector only and use it to get all grid points by adding) 16 bit mul and div is not rocket science either to get the projections. I'd think clipping is a bigger challenge. I'd also think it could be done faster with todays knowledge.