Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Feb 2013
Offline Last Active Feb 24 2013 12:47 PM

#5033971 Why is collision cast expensive?

Posted by on 18 February 2013 - 07:16 PM

the main difference is that an oct-tree divides the space into 8 regions in each step, so requires less recursion, but has to do a few more checks at each step (since there are 8 possible regions to step into). dividing the space in a binary-fashion allows simpler logic, but a larger number of internal nodes.


That's not necessarily true, you can implement an "oct-tree" with a b-tree under the hood; your recursion step should cycle over each axis.  Thus the number of recursive steps would be similar in complexity to a BSP-tree.


But I think my question was poorly worded.  Simply put, I'm curious about if it's worth it to "choose" a splitting plane versus naively cutting it down some midpoint in the dynamic real-time situation you were describing.  The obvious difference is that choosing the latter would be O(1), and the former would be (presumably) at least O(N).  That of course would pay off as searching would be faster.  If the tree were generated before-hand and kept static, then of course it'd be better to load the cost up front, but in the case of a real-time dynamically generated tree, I'm wondering if, generally, such an approach is still worth it.


It's a bit of a subjective question and it begs more for intuition/experience than a purely academic response, I suppose.


It's not about memory it's about how much CPU time doing a lot of ray casting takes really.


I'm wondering if there's a subtle point here that you're also describing.  If you're just talking about memory allocations, then of course it's almost never an issue, but isn't memory bandwidth is a large bottleneck for speed these days?  I don't work in the games industry, so I'm not aware of the current state, but isn't it a challenge to maintain cache coherency in collision detection systems, too?  Or is cache coherency kind of a solved issue at this point?

#5031970 What effects are being used in this game?

Posted by on 13 February 2013 - 01:41 PM

Take a look at Screen-Space Ambient Occlusion (SSAO), it's a relatively cheap way to achieve AO.


I'm not sure what effect you're referring to in particular, as there are a lot of things going on in those screenshots..  specular maps, reflections, lens flares, to name a few

#5031965 Why is collision cast expensive?

Posted by on 13 February 2013 - 01:31 PM

If you want a normal vector like the one he describes, then you need to know the polygon that the player is "standing" on.  This requires a much finer calculation than a bounding box, as you need the exact polygon to get that normal vector.  How expensive it is depends on the complexity of the world, but when compared to the super-cheap alternative of  subtraction of two vectors, it's extremely expensive.


It's not that you shouldn't do collision casts per frame, as you do these all the time for things like shooting projectiles and such.  It's just that you only have so much processing power to spare if you want your game to run smoothly, so you'd rather save calculations for other things.  One of the guys mentions that the reason why there are only so many monsters in the game is because more would be too much for the hardware.


Also, keep in mind that this hardware is the PS1 (I believe) so we're talking about much worse hardware than today.

#5031919 Game programming - Using vectors called forward, left/right and up

Posted by on 13 February 2013 - 12:07 PM

You're talking about different concepts.


Practically every 3d game will find a use for forward, up, and right vectors.  But they also need direction, position, velocity vectors for each entity.


In the context of the video, forward, up and, right are are constantly changing (as opposed to most games which can hardcode "up" to an arrow pointing along the positive y axis, meaning that only forward and right are changing.)  The three directions are a basic inputs used, among other things, to orient the player and to orient the camera (set up a "view matrix" and "projection matrix").  Their optimization was that in a spherical world, the up vector could be calculated simply by taking the position of the player and subtracting the center of the world.  This makes it cheap to calculate the right vector.  This is compared to a more general approach of finding the normal vector that corresponds to the polygon that you're standing on (the collision approach he describes as super expensive).


I watched the entire video (thanks, it was interesting), but they did not compare forward, up, right to direction, position, velocity, directly.  They are not competing concepts.  Defining forward, up, and right are useful constructs to describe orientation, in general.  Where as direction, position, velocity are useful to describe movement and physics and such.


Sounds like just semantics. I think you might be over-thinking the concept if you understand vectors, cross products, and dot products (and other basic ideas in linear algebra).  These are super, SUPER basic ideas, so if they are confusing you then you're probably thinking about them the wrong way.


Again just to make it clear.  EVERY 3D game will use vectors that represent forward, up, right, direction, position, velocity, acceleration, etc.  These are just terms to describe what a particular vector is trying to describe.  Unless I missed something, there aren't "two approaches" here.  


Don't even think about vectors as "a direction and a magnitude," that idea will be limiting and it conveys them as being special in a sense.  Really, the best way to think about it is that a vector is just a number.  (Sure it's actually 3 numbers, but just think of it as a bloated "number".)   So a vector *could* be used to describe a point, or a direction, or a direction and a magnitude, but that's giving them special meaning.  It just happens that in a 3d world, it's convenient to use 3 numbers at a time to describe things.  That's really all there is to it.


(Tangential side note: In higher mathematics, they are useful because often you want to describe things in higher dimensional space or even n-dimensional space, meaning that you don't define whether the problem lies in 1-D, 2-D, 3-D, 12,345-D.  To grasp these concepts, you'll have to "unlearn" that stuff about "directions" and "magnitude" if you've internalized it too much.)

#5031696 Memory Leaks

Posted by on 12 February 2013 - 10:53 PM

It may be not as efficient, but I tend to use STL everywhere (until I need to optimize).  It's much easier to maintain/read.

const int NUM_THINGS = 10;

std::vector<int> myThings(NUM_THINGS);

for( const auto& thing : myThings ){

It also makes it quite difficult to accidentally overrun your buffer.

#5030170 Incorrect Vertex Shader float input values (NaN or 0.000000000).

Posted by on 08 February 2013 - 01:50 PM

Also, are you using those values (texcoord and bytewidth)?  If not, the shader compiler could optimize those variables away.

#5030138 Fixing buggy movement

Posted by on 08 February 2013 - 12:29 PM

I'm not sure what you mean by smooth movement, but I would remove the move___ = false; statements so that you don't have to keep pressing the buttons over.  Once you do this, you would have to add another event listener for 'keyup' and set the move___ = false when that happens.  This way, as long as you're holding down a direction, the gameloop will update your position, but as soon as you let go, it will stop.  If you do it this way, you can change the 6 to a smaller number like 1 to achieve a less "jumpy" motion.


Also, typically you'd want to keep track of your delta_time in the game loop (how much time has passed since the last run of the loop).


Then to update position, you would add (velocity * delta_time) to your position.

#5030129 Alpha Testing: I manage to "scorch" my edges

Posted by on 08 February 2013 - 11:55 AM

It looks a lot like you're not setting the blend mode correctly.  


The black borders is a sign that your texture is stored with pre-multiplied alpha.  (Since you're not handling alpha blending correctly, it'll look black because the color is being pre-multiplied by an alpha close to 0)  This is most likely fine.


With pre=multiplied alphas, you probably want to set your blend mode to something like: S + D(1-Sa)


Hope this helps.

#5030059 Anyone here a self-taught graphics programmer?

Posted by on 08 February 2013 - 07:04 AM

Wow this is a cool topic!  I joined up just to post this.


I learned graphics programming when I was in 10th grade or so.  mostly because it seemed like everyone on IRC was programming games back then.  So I started off with some OpenGL tutorials.. which led me to look into the OpenGL redbook, Windows API, X11 Libraries, etc.  Sooner or later I was going through the Doom and Quake source code trying to understand everything line by line.  After enough of that, it just started to click, and I put together a homegrown physics engine, rendering engine, and some basic multiplayer code.  Resulted in some "tech demo"-like games back then.  When I hit college, I went a completely different (and non-technical) route, only doing non-game programming on weekends as a hobby.


Then after about a decade, I began picking it all back up again... but the landscape is completely different now from back then.  People are using C++ instead of C, forward rendering is out, immediate rendering is out, fixed function pipeline is out, so I had to relearn most of the stuff from scratch, again.  On top of that, there are new priorities now: multicore, async, mobile, crossplatform.  The only thing that has seemingly stayed the same for the most part was Win32 API (and even now, that seems like it's on its way out with Win9).


The beautiful thing about learning game programming these days is that resources are everywhere, from beginner to expert level, the modern internet has it all.


Now here's a bit of unconventional advice, but also the best advice I can give.  To get good at graphics programming quickly, really throw yourself into the deep end; and the deepest information comes from looking at high-quality (professional and production-level) source code.  So once you have your basic syntax principles down, just choose a good graphics library, choose an interesting section, and go through it line-by-line until you understand _everything_ about it.  Then repeat.  This approach is probably the most grueling, but it'll get you there the fastest.  If you can't do that, the second fastest way is literally reading and memorizing documentation.


Like I said, it's unconventional wisdom, but it has worked really well for me and for everyone I know who has tried it.  I only have a limited amount of time to work on this sort of thing, but I feel my grasp of these technologies is pretty deep.  If those approaches don't work for you, then you'll have to settle for the conventional approaches: trying to code a bunch of projects, and (the slowest) reading and learning from tutorials.  These last two approaches are probably the easiest to do as a beginner, but learning that way is generally really slow (there's a lot of boilerplate and overhead to learning those ways).


Oh and to answer your question: I do it (mostly) as a hobby.  I'm working on a game engine built from the ground up with high-level bindings for easy prototyping and high mod-ability.. and also I'm incorporating a bunch of neat "cutting edge" tech from articles and papers I found interesting.