Ray Casting

faz808

Cracked it! Just did line ({ x ..……etc}), line ({x + 2 ……etc}), and line ({x + 4 …..etc}). Now I'm getting nearly 30 fps. I reduced the screen width to gWidth()/1.3 and left the height as normal. For the main loop (across the screen) I'm doing x = 0 to w step 6 loop. I'm motoring now. Thanks Fuze Team.

faz808

Sorry, forgot the link …

https://lodev.org/cgtutor/raycasting.html

John

Jaywalker

Nice work! :)

faz808

If someone could explain step by step how to get a friend code and how to submit code snippets I'll push the raycasting example over. Thanks.

pianofire

Friend code sharing just uses the Nintendo system and only shares with your friends. You can now create a download code that can then be downloaded by anyone that you give it to. Details are here: https://fuzearena.com/forum/topic/725/new-community-sharing-on-fuze4

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. 🤔