pouët.net

oh, well, the debugger-picture shows its two textures. i am tired i guess ;)

also in absolute inebriation by virtual dreams (1992)

so far I like barrel rotator the best.

In this one no real memory/speed issue since it's always the same repeating 15 colors texture, and only the adress and colors are changed at each scanline. I'm not sure it's even perspective correct. The real difficulty is to make it look good, and here it's the case!

There's also a cool one in arte by sanity (1993).

can we say this effect is basically done using ray casting (calculating z for a given y screen position) + hardware tilemaps / sprite for the rendering part (as nitro2k01 suggested)

It's not really ray casting. You never see two objects rendered on the same line. What about "line ray casting" or "rayline casting". But I like 4mat's suggestion "barrel rotator".

I believe it's still raycasting. With one depth per scanline one would expect that there only be one object per scanline.

annieeee called it "precalculated scanline"

Say a screensize (pretend ever other scanline) of 128 and 256 angles with a scanline depth of 256. that's 32k worth of precalc that could be easily compressed. you're depth is probably less then 256 so that helps a lot.

is it really precalculated, annieeee? I imagine not on this 4k- not enough space.

So let's call it barrel rotator?

spelling and such

I worded that badly. Of course it's raycasting or (if you want to get into a fight about definitions) something close to it. My point was that it's not your standard raycasting and could use a prefix. Words...

Raycasting, raymarching, raysomething. Just a confusion of terms.
The old wolfenstein we called it raycasting and it's maybe something similar to find the distance/scale of horizontal lines.
But of course the modern glsl 4ks with the new methods, we call them raycasting or I call them raymarching(?) or whatever.
Anyway, I always precalculated the scales for animations for this effect.

That's nice to hear. I've been trying to get a raycaster/rayjomama fast enough to fill a buffer during video draw on the megadrive with no luck. Just can't get it fast enough, I might precalc it.

For me, what nitro2k01 told makes clearly sense. Maybe this is not the case for this prod, but it's relatively easy to do it with a simple precalc scrolltable (scrolltable[y][frame]) & palette table & custom plane filling (palette giving texture feeling & depth). And surely an intelligent tool could find those data based on the custom bitmap & final renderer as well, this could be really cool (when its only vertical scrolling / x rotation case, could be applied to y rotation for some hardware as well...). But yes, scrolltable[y][frame] may be computed in realtime which, in this case, may be strangely named "vertical raycasting". Hoping to see this again anyway ;)

i am sorry, but calling it raycasting is utter nonsense! ( gargaj, please tell em kids what is wrong here, or maybe let me try to: )

rayCasting implies you need to find an object in open space, so you can define how and where you hit it, so you can define its color and illuminosity etc etc.

how the heck does that apply to simply choosing a line from a texture per scanline?

this absolutely is nothing even close to rayCasting!

sigflup: even if you are a woman, you arent allowed to choose names by just "sounding good!" :p

its a simple texture-lookup, altered per scanline! get it, get how easy it is and be done!

NOPE!
those terms arent invented just to confuse you, they were invented to differentiate different techniques :p

i still hate when ppl use the wrong term on anything with "ray" in it.

its the same as if you´d state:
"i dont listen to rock! so grunge, punk, metal...its all the same to me, just rock!"
(while that would be true for sure, its all rock! as its all "ray" in them techniques, but differentiating them makes sense, doesnt it?!!)

Ok, this effect doesn't necessary need raycasting. You can rotate instead some vertices on 2d (around X, so you have Y and Z) and interpolate the Z for each scanline to get what you want.

But they used to call wolfenstein engines 2d raycasting. I forgot the 2d. You cast rays in a 2d map and when hit you get Z to find scale, and the column of the texture but of course you didn't calculate luminosity (although you could, why not?). Then again, when I first read the scientific definition, raycasting was when you shoot rays and you stop after the first intersection (so a raytracer without reflections and stuff is a raycaster?) and raytracing when you continue tracing the rays and have several reflections. So, I joke about it, if I made a wolfenstein where it has mirrors and follow the same algorithm to continue with the ray, would it be then a 2d raytracer? Heh :)

All I said was that they are confused among the programmers. I didn't say they were invented to confuse ourselves. So, what's the difference between raycaster and raytracer for you?

I'll be curious to re-create the smallest code to reproduce this (using same technique not polygons of course). now we have horse power to do that totally realtime (maybe its possible using a shader)

I sense my 128b intro senses tingling.

maybe it already have been done. isnt that effect similar to what is we are talking about in this thread ?

@sigflup: it IS precalculated, it needs 1MB memory machines, 4k is the size of the program which probably contains a routine doing the precalcs at runtime.


@hArDY: but can't it be done exactly this way here to compute the object number, the size of line, the texture offset and illumination? Ie which precalculated scanline and colors you will draw? If not please tell me if hospital since friday is 2D raycasting to you? if not i need more explanations... Of course it can be done as Optimus said with computations of vertices and interpolation (as i did in cakehead but with only one object).


@Preacher: there was a 1K raycaster on Acorn Archimedes doom1k, and a 256b on m$do$ neon. Good luck for 128b!

it's a lookup table with a fancy indexer.

You just scale any graphic you want to n widths. Usually the width decreases by 2 (from maxwidth to minwidth) in the precalculation, since it's symmetrical. If long precalculations (and/or palette depth) isn't a problem for you, you could of course make more width-steps and antialias them. If you code for a modern platform, you make a blocky 3D object and put a texture on it and spin it around one axis only.

You don't have to precalculate it; this example scrolls text very slowly and so there's time for scaling each pixelline of a char as it scrolls into the n buffers (char backgrounds are precalculated, though).

Basically, it's an "X-Scaled-scanline picker".

The visual of it I saw first in Dropzone (C64), but it must be determined that there's actual picking going on, like in eminent C64 demos.

baah: one word: overEngineering!

Optimus: REAL programmers dont confuse anything here, as they exactly know how to differ between techniques :p

let your brain eat it already: its just a pointer into a texture, altered every scanline! its one of the most easy illusions to be coded!

If only there is enough memory of course to store different scaled versions of every bitmap line. The way I did it on the little CPC is to write a very fast realtime X-stretcher. I've precalculated the texCoord V and scale size for each line in a sort 90 degrees rotate animation. But if you want to do more variations, that's why people mentioned the raycasting (2d like wolfenstein) or rotating vertices and interpolating Z as alternative methods to determine what texture row and scaling to select at each line and frame.