Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


UnshavenBastard

Member Since 08 Nov 2001
Offline Last Active Nov 23 2014 04:05 PM

#5073203 Help with floorcasting

Posted by UnshavenBastard on 27 June 2013 - 06:00 AM

"the distance from a pixel in the center of the screen to the floor is infinite" What?

This makes sense when you assume the ceiling or floor is not at the same height as your camera. The exact center of the screen would be the point where the ceiling or wall touch the depth axis (e.g. 'Z'), but they don't, so the distance where the screen center meets the floor is... infinitely far away.
But there is no vertical center of the screen if you have an even number of pixels in the vertical dimension... not sure why the guy brings that up at all.
If his explanation for some of the things are confusing, try to figure it out yourself.

"You can also precalculate a lookup table for this instead, since there are only h / 2 possible values (one half of the screen in vertical direction)."

This is true, if he means the difference of distance (e.g. Z coordinates if Z is your depth axis) from one horizontal row of the screen to the next, or easier for later use, the difference to the bottom row, i.e. if you assume you would draw your floor completely from bottom row of your screen to the "center" row, each next row will be a bit further away. And since this sort of rendering has the restriction that you cannot look up/down and thus all floor / ceiling planes are parallel to your viewing direction, you have constant-height all over e.g. a floor plane. So you can make a table for each row from bottom to center, holding the difference in depth from bottom row. When rendering, you have to add those to e.g. the actual depth value of your bottom row which you calculate based on current camera height. So, you quickly have the real current depth values for each row.

You also need to rotate your floor plane based on camera angle. Then, if you go row by row, e.g. from bottom to center for the floor, imagine each row is layed on the rotated floor plane, at a start and end positions (first and last pixel of current row) which you determine with the camera position on the floor plane, and the rotation. So to say, actually you rotate those points about the inverse camera angle, not the floor itself.
Then when you move along the pixel row, from first to last pixel, you can compute where on the floor plane the current pixel would "hit", and thus compute the current texture index (assuming you have some grid specifying what texture some "cell" of floor has) and texture coordinates.
If you draw sketches of that on paper, you'll see how this works I hope, I can't draw anything here right now.

Hope this makes sense ^^




#5032602 Inclusion Guards

Posted by UnshavenBastard on 15 February 2013 - 07:07 AM

Sigh, silly stuff like that reminds us how ancient that language really is ;-)

I'd use #pragma once, some people object, for it not being standard, but I haven't met a compiler in at least the past 5 years that didn't support it.




#5004491 Whats a reasonable timestep

Posted by UnshavenBastard on 27 November 2012 - 06:31 AM

Something tells me that the simulation frequency vs. display frequency ratio is an important aspect, as in, sampling theorem, aliasing artifacts and such, which may surely be a 'nice' contributor to perceived jerkiness of movement.

After all, changes in position over time, generated by the physics engine, is a signal, which is output by the physics engine, and sampled again by the graphics engine, at a possibly different frequency. Now if the resampling method used is not good, the end result, i.e. graphics output, will have artifacts.
From my experience I'd say, as others have noted, odd ratios like 67 Hz : 60 Hz, make simple resamplers produce especially bad results.

Upping the simulation rate, i.e. samplerate of the "source" (physics engine), certainly is one approach that works, but it's a low-tech one, imposing high computational cost - such goes the common wisdom in DSP land I think. (I'm no expert, but dabbling in that sort of stuff recently).
There would have to be some sort of filtering / interpolation going on as an alternative.


#4756277 What Does Everyone Think About The New Site Layout?

Posted by UnshavenBastard on 09 January 2011 - 04:36 PM

Do not want.


This.

My eyes are "burning" already, and it's *really* bad for me to stare on a white page in the late hours of the day - when I usually read gdnet - since this reduces the likelyhood that I will sleep well, for physiological reasons.
Staring at lightbulbs for hours in the evening is no good!

But maybe the option to change the color scheme with logging in comes back...
just as I assume that the menus will stop their current strange behavior ^^

As for the layout, to put it bluntly: I think it sucks.


PARTNERS