Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Oct 2008
Offline Last Active Mar 05 2016 04:07 AM

#5271789 Pathfinding and Databases

Posted by on 18 January 2016 - 10:04 PM

Are we talking pathfinding within rooms, or between rooms? I'm guessing between rooms, because pathfinding in a 3x3 grid is pretty trivial and you could basically brute-force it, try all permutations, and still perform pretty well.


I think the problem you're having is that the way you store your room layout (in a database) isn't really conducive to most path-finding algorithms, which assume that it's easy to load and traverse every node in the graph, right?


You've probably got a couple of options here:

  1. Limit the number of rooms you search, which limits how many rooms you're going to have to load. You're going to have a bunch of rooms in memory already to display them to the user, as a first pass you could just limit your path finding to whatever you've already got loaded. The downside here is that you might not find a path which twists through rooms that are not loaded.
  2. Pre-calculate some fraction of possible paths when you generate the level. This could potentially mean you have a whole lot more data to store.
  3. Some other data structure/storage mechanism for your level (e.g. a quadtree). This could be a lot of work...

As always, there's never a perfect solution.

#4531949 Getting the absolute mouse position with SlimDX

Posted by on 24 September 2009 - 06:28 PM

Original post by Narf the Mouse
Original post by jtagge75
Why? Getting/setting the mouse position has nothing to do with the graphics API that is being used.

Gee, maybe it's the Mouse class in the SlimDX library. Having a Mouse class is generally a sign of Mouse-related data.

Now go dogpile on someone else.
SlimDX is open source. If you don't like the way they've implemented certain features, I'm sure they'd appreciate patches.

#4375840 Interaction of Clear(), BeginScene(), EndScene(), Present()

Posted by on 05 January 2009 - 12:13 PM

You're always working on the "backbuffer" (I put it in quotes, because it a bit more complicated but conceptually you're always working on the backbuffer).

So Clear clears the back buffer. BeginScene tells the driver "I'm about to start with the Draw calls". Each time you call Draw (or any DirectX call, really), the DirectX runtime queues that call to the driver - the driver runs in a separate threads and pulls work off the queue as fast as it can. EndScene will wait for that queue to empty so that when you call Present to swap the back buffer to the front, it knows that the scene has finished.

The whole Clear/BeginScene/EndScene/Present basically allow the DirectX runtime to run asynchronously to the rest of your application.

Note that it's a bit more complicated than that in practise (mainly because the queue can actually last a couple of frames) but that's conceptually how it works.

Also, in DirectX 10, the BeginScene and EndScene calls are gone.