Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Mar 2000
Offline Last Active Today, 10:39 AM

Posts I've Made

In Topic: Local scope benefits

Today, 10:40 AM

By keeping a variable's scope limited, you make the code easier to read (because you don't have to scroll so far to find a variable's declaration). It also removes a small class of errors such as accidentally using a variable where you shouldn't be able to (e.g. because you made a typo and intended to refer to some other variable). It will also declutter debugging since a debugger will only show you the variables in scope.


However, the variable is constructed when it is encountered and destructed when that scope is left. In your first example, CoolObject is created once, assigned to 5 times, then destroyed later. In your second example, CoolObject is created and destroyed 5 times - although whether that is significantly different from being assigned to 5 times depends on the object. (And in languages other than C/C++, assignment often has quite different semantics.)

In Topic: Fullscreen sometimes throws DXGI_ERROR_NOT_CURRENTLY_AVAILABLE

Today, 10:03 AM

Okay, I guess that qualifies as a 3rd party launcher. Do Steam offer any tech support, because this might be a common issue with their software. This combination does seem to be quite common, if what I see on Google is any indication.

In Topic: thread closure probably not the best action

Today, 10:00 AM

It looked to me like most of the replies in the last page were calling each other idiots, or heavily implying that, and I don't think that's what the Lounge is there for.

In Topic: Fullscreen sometimes throws DXGI_ERROR_NOT_CURRENTLY_AVAILABLE

Today, 07:18 AM

Are these users maybe launching the app from some 3rd party launcher (eg. Launchy, Wox, Keypirhina)? They could be holding on to the focus after they launch the app, until they consider the launch operation complete. Repeating the SetFullScreen process a little later (maybe 500ms) might fix it, if so.

In Topic: collision and astar maps, variable entity radius

Today, 02:55 AM

so are there any other options available besides: 1. clearance based 2. enlarging obstacles on the astar map 3. no diagonal movement


Personally I would ditch the grid and partition the space up in a more efficient way, but it's your choice. The A* algorithm has nothing intrinsically to do with grids and they're usually a poor choice unless you already have that grid for some other purpose.


If you want to treat 2 squares as adjacent even though the route between them is diagonally and thus infinitely narrow, you need a special-case workaround - simply checking the 2 squares either side of the diagonal for passibility should be sufficient. As an example, looking at a keyboard's numeric keypad, you can't move from 5 to 9 unless both 8 and 6 are clear too. 9 shouldn't be generated as a successor node to 5 if 6 and 8 are not both clear.