Jump to content

  • Log In with Google      Sign In   
  • Create Account


zacaj

Member Since 18 Sep 2008
Offline Last Active Sep 28 2013 03:05 PM

Topics I've Started

Billboard and multi-perspective sprite algorithm

12 August 2013 - 03:11 PM

I'm working on a DOOM-esque game in opengl for 7dfps and I need to make the billboarded pickups and enemies.  Is there somewhere which documents the 'correct' way to rotate the quads and to choose which sprite of the enemy to show?  If not, can someone tell me if there's anything wrong with the algorithms I've come up with?

 

For billboards:

I have made the billboard perpendicular to the player's view angle.  I also tried making it perpendicular to a line pointing at the player's position, but it looked worse.  

 

For enemies:

radiansToSide=PI*2/8  (8 is the number of sprites I have for enemy)

angle=atan2(enemy.y-player.y,enemy.x-player.x)

angle+=radiansToside/2   

angle/=PI*2

angle*=8

angle=floor(angle)

//angle is now an int 0-7


Help with floorcasting

26 June 2013 - 02:08 PM

Been trying to make a little textured raycaster for fun the past few days.  Walls went fine, but I hit a wall when it came to floor texturing.  No idea how to do it.  So I found http://lodev.org/cgtutor/raycasting2.html , and I was able to adapt their floorcasting code quite easily.  It worked, except that it couldn't handle it when I changed the camera height.  Looking at their section on computing the 'currentDist' (from current pixel to floor, I'm assuming vertically), none of what they say makes any sense.

 

 

The distance the projection of the current pixel is to the floor can be calculated as follows:
  • If the pixel is in the center of the screen (in vertical direction), the distance is infinite.
  • If the pixel is at the bottom of the screen, you can choose a certain distance, for example 1
  • So all the pixels between those are between 1 and infinite, the distance the pixel represents in function of it's height in the bottom half of the screen is inversely related as 1 / height. You can use the formula "currentDist = h / (2.0 * y - h)" for the distance of the current pixel.
  • 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).

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

"for the bottom of the screen, you can choose a distance" I'm assuming this would be where my camera elevation goes in

"for example, 1" oh, thank god they chose 1 as their magic number.  It's not like that ever comes up anywhere else

"the distance the pixel represents in function of it's height in the bottom half of the screen is inversely related as 1 / height."  that wasn't even proper english.  Plus, when they say 'inversely' and then use 1/x I assume the 1 is from standard math, but it's the only place on the page where they make any reference to the camera height which they so helpfully chose as 1 earlier.

"you can use this formula" no explanation on how they got that, or anything.

 

Is it even possible to have different camera elevations with this technique?  


How to determine object depth for sorting

16 January 2013 - 12:53 PM

For transparency rendering you're supposed to sort your objects by depth, however I'm having trouble finding a good method of choosing each object's depth.  Just using the position doesn't work for objects that aren't centered, getting the center of the bounding box doesn't work much better.  I also tied getting the smallest depth from all six corners of the bounding box, but even that has problems.  Has anyone come up with a good way to do this?


Simulating PS1 "shaky vertices" with shaders

04 January 2013 - 04:04 PM

I'd like to get the game I'm working on to look like it uses an old software renderer, and one of the artifacts I'd like to reproduce is how in many old games (specifically on the PS1, but also many computer games) the vertices would shake slightly.  From what I can find this was because the coordinates were passed from the math hardware to the rasterization hardware in integers.  I tried to produce a similar effect by flooring the calculated positions in my vertex shader:

gl_Position.xy=floor(gl_Position.xy*256)/256;

 

but it doesn't seem to produce any noticable effect unless I lower the 256 down to less than 10, and then it is EXTREMELY wobbly to the point of being unusable.  (I chose 256 because my window is 1024 pixels wide, and the position ranges from -1 to 1 (unless I'm remembering this incorrectly?))

 

Any ideas?


Object orientation/position best storage method

21 May 2012 - 03:13 PM

I have been working on a 3D game engine for fun and at the beginning of development I had the idea to store objects with an abstract "Transform" class instead of any definite type of position/orientation (xyz+quaterion, for example). This way you could have a normal QuaternionTransform that would be used for most objects, a PhysicsTransform for objects in a physics engine, a OrbitTransform, etc. All they need to provide is functions that give their current position, orientation (3x3 matrix) and transformation (4x4 matrix).
This had been working fine until I started working on the in game editor. I started by coding a "move" tool but after getting everything set up with picking working, etc I realized that this would work horribly with my Transform system. Any system for moving (let alone rotating!) my objects would have to conform to a single Transform type, etc. How would you move an OrbitTransform that is relative to another object 10 meters left?
So my question is, what is the standard method of dealing with this?

PARTNERS