Forum archive
Hello All
- Hello all,
I was surfing Ken's site at work today and found a link to this forum.
Anyway, nice to meet you all, I hope to hang around for a while.
Ken, all of your projects are sweet. The Build Engine was one of the reasons I wanted to start programming. I started a my own raycast engine a couple months ago, partly inspired by Ken's Lab one of the games that made me like that technique. Bought it for my bro at Wal-Mart around '94 or '95 :lol:
Anyway if you all wouldn't mind me asking a question I currently have the raycast algo firing rays in a 64 degree arc and then drawing the walls in 5 pixel wide rectangles. The untextured version works great. Now, I'm about ready to start texture mapping the walls but I'm not sure if I should keep it only firing 64 rays and then draw the texture in 5 pixel wide chunks or scale it up to 320 rays that draw in pixel wide chunks.
I'm working on a 320 ray version, it's almost perfect I just multiplied everything by 5, I figured that would cover me. It looks almost perfect but there's a lame discrepency at a certain angle of the player's heading I have to work out. It's weird it doesn't draw the walls and there's like a mirror image that starts right in the center of the screen where you can see a mirror on the left and right of the center line.
*waves arms* Anyway, sorry for the long winded questioning and introduction. Feel free to kick me if I'm out of line too.
Anyway, have a good evening everybody. - Well, I went back and this time with my old pre-Calculus book and looked in the Trig section. I think I got the math and such ironed out now. It seems to be working rather stable at 320 rays. Runs a tad slower which may be annoying when I port it to GBA but I may have to have it like that for Texture Mapping.
I still am curious if it would be wise to attempt texture mapping with only 64 rays and that 5 pixel gap every ray.
Anyway, thanks guys.
Your still Awesoken.
Oh, on an unrelated note, we played Duke today at work since it was a slow day. We had a nice LAN game going with 5 people. We were playing one of the Rooftop maps that was made by someone, it was really getting on my nerves that one of my co-workers kept putting those annoying Trip Mines all over the place. :P I came in about 3rd after it was all said and done. BUT anyway your network code is really great Ken, not a bit of lag. Ken, all of your projects are sweet ... Ken's Lab ... Bought it for my bro at Wal-Mart around '94 or '95
Thanks, and thank you for your support : )the raycast algo firing rays in a 64 degree arc and then drawing the walls in 5 pixel wide rectangles.
64 rays in 64 degrees? I suspect you are making a common error in projection. If you are shooting your rays in linearly spaced angle increments, that is wrong. The correct way to generate raycast vectors (for a flat screen) is to use linearly spaced vectors. Study this code:------------------------------
//incorrect projection: (vertical cylinder)
for(a=-31.5;a<=31.5;a++)
{
vecx = cos(angle + a*PI/180);
vecy = sin(angle + a*PI/180);
...
------------------------------
//correct projection: (flat projection; 64 rays in 64 degrees)
d = 32/tan(32*PI/180); //this constant controls the field of view
c = cos(angle*PI/180);
s = sin(angle*PI/180);
for(a=-31.5;a<=31.5;a++)
{
vecx = c*d - s*a;
vecy = s*d + c*a;
...
------------------------------
In these snippets, vecx and vecy specify the raycasting direction. In flat projection, the vector <vecx,vecy> is not unit length, so you will need to normalize it if your raycasting code requires that.I'm not sure if I should keep it only firing 64 rays and then draw the texture in 5 pixel wide chunks or scale it up to 320 rays that draw in pixel wide chunks.
That's a matter of speed vs. quality. The best choice depends on what your goals are.It's weird it doesn't draw the walls and there's like a mirror image that starts right in the center of the screen where you can see a mirror on the left and right of the center line.
I don't recall having bugs like that. A screenshot would help.- Wow, thanks so much for the speedy reply. That means a lot.
I don't recall having bugs like that. A screenshot would help.
I conjured up a little comparision shot for you and from what I can see after looking at it is that my math may be off or something because to me it looks like it is drawing the FOV twice or something to that effect in the 320 version. ;) At least the 320 ray ver. is a bit less blocky than the 64 ray ver. Also, these are both looking at about the same spot.
http://mypage.mtaloy.edu/~jjnst1/raycast.pngThanks, and thank you for your support : )
Anytime, I should be thanking you :P After all, I was still a bit young at the time and my parents thought Wolf3D was a bit violent so I saw your game and said "Wow, this looks pretty sweet." So now I didn't have to goto my Aunt and Uncle's house to play an FPS.64 rays in 64 degrees? I suspect you are making a common error in projection. If you are shooting your rays in linearly spaced angle increments, that is wrong. The correct way to generate raycast vectors (for a flat screen) is to use linearly spaced vectors. Study this code: <CODE>
Mine looks similar to the bottom portion, but my math is a bit different. That may be why I've been having trouble with the math even though I've been using my Pre-Calc book and it's Trig section. My wrong math. I'll try the math and see what kind of results I come up with.That's a matter of speed vs. quality. The best choice depends on what your goals are.
You are absolutely right, and since my Target platform currently is the Gameboy Advance I guess speed is more of my priority. ^_^
Thanks again, I really appreciate the input and assistance. You know a lot more about Raycasting than I do so your offering advice is really really appreciated. I've really been working hard on this raycaster and am pleased with how far I've gotten. It's actually in all seriousness one of my life goals to make a raycasting engine/game because you and the guys at id made me like the technique so much. :wink: Plus I want to see how far I can push it.
Anyway, I hope you all enjoy your Memorial Day if I don't hear from you.
Thanks again, Godspeed. - First of all, why is the 320 ray version blocky at the left and right sides?
With the screenshot, I was hoping to see whether the tops and bottoms of walls were warped. In correct pespective, the tops and bottoms of walls should form a straight line. They look fairly straight in yours, although with a field of view of only 64 degrees, it may not be noticable. Texture-mapping is also good at revealing warping problems.
Sometimes I'm able to guess problems from images or vague descriptions. In this case, I'm not having much luck. I don't know what to say other than "maybe you forgot to multiply by 5 somewhere?". Really, the only practical way for me to find your problem is to look at your code.
Alternatively, you could look at my code : ) I put some examples on my website that show how to do a raycasting engine. They're much smaller and simpler than the Ken's Labyrinth source code. You probably already found my Microsoft QuickBasic implementation. I also made an EVALDRAW version (see LAB3D.KC). You may also be interested in BLOCKSCAN.KC, which shows how the inner loop of my raycasting algorithm works. First of all, why is the 320 ray version blocky at the left and right sides?
Well, I was thinking that wasn't right as well. I thought that increasing the number of rays cast would make it look a bit more fine. I did some investigating via google and found some insight. 'Joe King's' Raycasting Tutorial 3 mentions that his Tutorial 2 and 3 raycasters had the same problems of being blocky even with an increased number of rays cast. I compared my code to his 1 & 2 raycasting algos and they look similar. So that leads me to believe that my method of casting rays and hitting grid blocks isn't as accurate as it should be."maybe you forgot to multiply by 5 somewhere?".
This was exactly the first thing I thought of investigating but, I went over it a couple of times and fiddled with some values, nothing. I even copied the 64 ray version and re-multiplied those values and still nothing. Ultimately though, I think I'm going to restart my raycaster, back up the old versions for future reference and try a different implementation. Start off fresh now that I understand the raycasting process a lot better.Alternatively, you could look at my code : )...You probably already found my Microsoft QuickBasic implementation.
That's actually what I was thinking of doing. Your LabDemo2 was actually the first raycaster I looked at, I understood what your code was doing, I just didn't understand why it was doing it at the time. So then I found some theory about what a raycaster does and I took that theory and implemented it, and after about a month and a half I had my 64 ray raycaster. I printed your LabDemo2 source out a while ago, so I think tomorrow I'll take a look at it again now that I have a better understanding of raycasting. Plus, you made some of the best raycasters ever.
Anyway, thanks a whole lot for all your help and advice. I really appreciate it. It's a real honor getting advice from somebody who's work really got me interested in programming.
UPDATE: 5/28/06
I didn't wanna post again and waste space so I thought I'd put an update here.
Anyway Ken, I was just reading through your LabDemo2 that I printed out a while ago and now that I understand Raycasting a lot better I'm blown away by how awesome it is implemented. Just reading through it made me pretty excited. I mean, the way I was doing it was similar to the way you were incrementing your rays and casting them out, but overall your algo is about a million times more accurate in striking the grid blocks and drawing walls. Heh, mine had nice gaps between walls if you put two blocks diagonally to each other. :lol:
http://mypage.mtaloy.edu/~jjnst1/gapwalls.gif
Nice huh?
UPDATE: 5/29/06 Memorial Day
Well, I started fixing my raycaster today. I didn't get a whole lot finished, but I should have a working update by Friday if all goes well.
My current 64 ray raycaster was pretty good except for it's well, inaccurate math. So I decided rather than throwing the whole thing away, I would just amend the Raycasting Function. This is good, because once I am finished fixing the math I can load up the maps from my Map Editor and compare them to the 64 ray non-fixed version. Plus fixing my existing raycaster by learning how you did your math will help me more than just porting your LabDemo2. ;)
I'll post some comparison shots once I have something going and we'll see how night and day difference it looks. :lol:
Anyway, thanks again for being so cool to us up and comers.