Ray Casting

faz808

@pianofire Got it. That was easy. Thanks.

pianofire

@faz808 That has been approved now. You can just share the code either publicly e.g by posting on here or however else you want to

faz808

Raycasting example. N9LKAMND15

WhiskeyJack

This is neat. I’m still learning FUZE. How do you determine your frame rate?

Something

@WhiskeyJack In the options menu in Fuze, there is an option to have frame rate and memory displayed.

faz808

The next step is texture mapping the walls. This could be extremely tricky - but not, I think, impossible!

faz808

I'm trying to convert a C+ program colour to Fuze's format. The colour number, 8421504, is light grey. I've worked out that this is
(128) + (256 * 128) + (65536 * 128) which is Blue/2 + Green/2 + Red/2. I can't see how to convert this to {1,1,1,0.5}.
I'm sure there's a simple solution but for the life of me I can't see it. Any ideas anyone. Thanks.

PB____

I think that you're looking for {128/256, 128/256, 128/256, 1} or in other words {.5,.5,.5} :)

EDIT:
If you're looking for something more generic, I think this could work, but haven't tested it in Fuze itself:

function getColorForNumber(nr)
return { (nr & 255) / 256, ((nr >> 8) & 255) / 256, ((nr >> 16) & 255) / 256 }
getColorForNumber(8421504) // should return { .5, .5, .5 }

took a couple of edits because it's late, but hope that helps :P

faz808

That looks good. I'll try it.
I've got as far as red = ( int( 8421504 / 65536 )) / 256. This gives 0.5.
I'm trying to convert the C code texture mapping example for Ray Casting and this is one of the stumbling blocks. I'll get there … he hopes !

faz808

Just tested your function and it works Thanks for your help.

faz808

I should have remembered that >> 16 is the same as divide by 65536 etc... Thanks again.

PB____

I think it's a good idea that I explain my code (>> 16 does not do division).

First you need to know, how binary counting works. If you don't know that yet, you can probably best google that (it's not as hard as it sounds).

The binary representation of 8421504 (so from base 10 to base 2) is 100000001000000010000000, so each color has 8 digits (called bits) to represent their value. And in this case, each color has the value 10000000.

Now it's good to know that the base 2 value of 255 is 11111111 (also 8 digits, all 1).

the & operator checks the binary representation on both sides, and compares them digit by digit. If both digits are true (hence the &-sign for and), then the resulting binary digit is also true. You can imagine lower values to be zero filled from the left (just like with our counting system, base 10, you don't write 0255 for 255, you leave out the leading 0's, you do that in binary too).

So when we do 8421504 & 255, we check 100000001000000010000000 & 000000000000000011111111. Lets put them below each other so it's better readable:

100000001000000010000000 &
000000000000000011111111 =
000000000000000010000000 // only the last 1 of the larger number occurs on both sides

If you leave out the leading zero's of the result, you'll end up with 128: 10000000.

So this way we get 128 for the red value, but since colors in FUZE are expressed in percentage, we divide by 256, this leaves us with a nice round .5 (you probably want to divide by 255 to be accurate, since we start counting with 0, not 1, but that would lead to a slightly higher number than .5, so it depends on what you try to do).

Now we want to do the same thing for the other bits in the source value (basically it represents bbbbbbbbggggggggrrrrrrrr in RGB). So to do this, we shift the binary representation to the right 8 positions, using the bitshift operator: nr >> 8, so this would leave us with bbbbbbbbgggggggg or in this case with: 1000000010000000.

Once again below each other:

100000001000000010000000  >> 8 =
000000001000000010000000  //assuming bitshifting in FUZE is Zero-fill
// then:
000000001000000010000000  &
000000000000000011111111 =
000000000000000010000000 // It leaves us with the same result, but this time it's from the middle 8 bits

So now we have the 128 of the green value, divide it by 255 and you end up with the color percentage value that FUZE uses.

If you understood all this, then you probably also get that >> 16 moves the bits 16 positions, in stead of 8, leaving us with bbbbbbbb (or 10000000) or in this case, the blue value. Not by division, but by shifting bits (there could have been 1's before the number, they'd stay in):

0100000001000000010000000  >> 16 =
0000000000000000010000000  // or just 10000000 if you leave out leading zero's
// then:
0000000000000000010000000  &
0000000000000000011111111 =
0000000000000000010000000 // Still the same result, but this time it's from the first 8 bits

So I hope that explanation made sense, and also, you might want to use the following function in stead (depending on what you try to do):

function getColorForNumber(nr)
return { (nr & 255) / 255, ((nr >> 8) & 255) / 255, ((nr >> 16) & 255) / 255 }

getColorForNumber(8421504) // should return { 0.5019607843137255,0.5019607843137255,0.5019607843137255 }

DomDom

This post is deleted!

faz808

I didn't fully understand the binary business till now. Thanks for the time you put in to explain this in a clear and concise manner. Have a great weekend.

mario.bodemann

Hey,

great project, I am looking into something similar my self and am happy to see others also doing RayCasting. 🧙

I think the texture mapping could be doable with drawImage with it's source and target parameter version. Then finding the exact intersection point between the wall and the ray should determine which part of the texture to copy where... 🥳

I'm also curious if sectioning the code into functions could be helpful for readability, or if you would expect any downsides to splitting the code into smaller chunks. 🤔

Discostew

@PB____ said in Ray Casting:

function getColorForNumber(nr)
return { (nr & 255) / 255, ((nr >> 8) & 255) / 255, ((nr >> 16) & 255) / 255 }

getColorForNumber(8421504) // should return { 0.5019607843137255,0.5019607843137255,0.5019607843137255 }

That function can be further optimized for the latter 2 elements if you don't care much for readability.

function getColorForNumber(nr)
return { (nr & 255) / 255, (nr & 65280) / 65280, (nr & 16711680) / 16711680 }

It's basically doing a l-shift on the mask, and using that value as the mask and division. The removal of 2 operators should speed it up.

255 << 8 = 65280
255 << 16 = 16711680

faz808

@mario-bodemann
I agree about readability being a problem but I'm just basically copying Lode's code as starters then I'll think about tidying it up !
Looking at the basic texture mapping (see Lode) - not the Wolfenstein section - I'm having extreme trouble with the multi dimensional array part. For example if I do texture[7] = 8421504 followed by mycol = texture[7] I get 3.7 fps. OK that's bad but I can speed that up somewhere along the line. BUT if I do texture[7][7] = 8421504 again followed by mycol = texture[7][7] I get 0.2 fps ! These are just example array elements of course. Fred[8] = 9 seems to be faster than fred[8][8] = 9 - if you see what I mean.
As for this section of his code - well I'm completely baffled ...
std::vector<Uint32> texture[8];
for(int i = 0; i < 8; i++) texture[i].resize(texWidth * texHeight);
This is going to take time to get working. Not sure if I'll pop off before I finish it !
Great that someone else is keen to get ray casting up and running.

faz808

If we had getPixel texture mapping would be a doddle. I think I'll play Witcher 3 while waiting for the next Fuze update. Please Fuze team, we need a getPixel command. Thanks

faz808

Is there anyway to convert this C code snippet to an equivalent in Fuze …

std::vector<Uint32> texture[8];
for(int i = 0; i < 8; i++) texture[i].resize(gWidth * gHeight);

I'm still battling with this texture mapping problem. Not giving up yet !

mario.bodemann

Hmmmmmm.

I'm thinking something like this:

output = createImage(gwidth, gheight, false, image_rgba)
setDrawTarget(output)
drawImage(input, {0,0,input_w, input_h}, {0,0,output_w,output_h})
setDrawTarget(framebuffer)

Could be doing the trick. It's drawing the input image in the size of the output image. (output_w etc is the width of the output, etc)

That said: Usually the scaling of images shouldn't be a big bottleneck on the code. Usually the math takes way longer. (GPU vs CPU). So I'm not very sure that you'd need to scale beforehand...