Light/Shadow Casting with rays for OpenXCom

[Skybuck]

So phase 1 should be something like:

Map::drawTerrain

modify such that, for each pixel that it blits to the screen:

mColor[X,Y] := color of surface/sprite/wall/etc.
mXYZ[X,Y].X := voxel x across map
mXYZ[X,Y].Y := voxel y across map
mXYZ[X,Y].Z := voxel z across map, computing this is the hard part... perhaps you know a formula... how to calculate this... for walls and maybe also sprites.

This is probably the only thing that needs to be stored.

The reason why I was trying to store surfaces and tiles is to try and compute the Z later, which is difficult, but if it can be done at once, then don't need to store tile and surface and such.

[Yankes]

Do not try mix voxels with surfaces, both are independent, `Map::drawTerrain` will put pixels where is no voxel and voxel will be on places where no surface pixel is draw. Another thing is that as voxel is 3d and surface is 2d you will have lot of collisions.

Beside for given tile data there is static relation between voxel in given tile and surface draw for given tile. You do not calculate it each frame, this could be precalculated before game starts. And during game you will need only add voxel offset for given tile.

[Skybuck]

I need a relation from screen x,y back to voxel x,y,z.

Since the screen can also move, it seems necessary to re-compute which screen pixel x,y is related to voxel x,y,z.

Also since screen x,y are in "diamond space" and the voxels are in regular grid space, a conversion needs to happen I think.

(Doing it this way prevents the need for a ray-tracer)

Since the drawTerrain/Bitmap drawing routines known and convert voxel space, grid space, screen space, and also sprite space to diamond space, screen space, pixel space whatever, there should be a way to create this relation ship and store it.

Basically this relationship is an index or pointer from screen to voxel space. This is usefull so that only the visible voxels need to be "light/shadow traced" later on.

So it seems this relationship needs to be build inside the bitmap draw routine... it knows where the final screen x,y is and it also indirectly knows where it is coming from, a certain tile, which has a certain sprite or unit inside of it which ultimately decided the color of this screen x,y.

The difficult will also be to convert the sprite/screen x,y/color to a voxel x,y,z, sometimes this may be easier for certain walls, for sprites this will be more tricky, unless the lofts could be used to figure out which sprite pixel corresponds with which loft voxel. This relationship may also need to be build later... for units.... where the loft may need to be rotated to correspond to a certain sprite direction.

[Skybuck]

I tried this idea a little bit in this branch, maybe we can cooperate in this branch:

https://github.com/SkybuckFlying/OpenXcom/tree/ShadingEngineYankes

So far it seems to be drawing the floor a little bit.

If you see a way to improve on it that be great !

(So far these just some experiments, later after some good night sleep, I may give it some more serious try and maybe try out different things, maybe even a ray tracer... might be simpler than dealing with bitmap clippings and what not... not sure yet... though I also still kinda like this painter algorithm... but the conversion from screen to voxel might get expensive if this has to be done per screen pixel... there might be a better way though, but again it will get a little bit complex with the formulas and loops and the efficiency...).

[Yankes]

I only can give you suggestions or answer simple questions, analyzing your code or contributing it out of question. I have my own project to do.