Page 7 of 18 FirstFirst ... 5678917 ... LastLast
Results 61 to 70 of 179

Thread: nxPascal

  1. #61
    For 3D pathfinding I would recomend using A* pathfinding algorithm or even Near Optimal Hierarchical Patfinding (HPA*) http://aigamedev.com/open/review/nea...l-pathfinding/

    If you decide to use A* pathfinding there was news post from Will regarding example for using A* pathfinding algorithm http://www.pascalgamedevelopment.com...How-A*-Is-Done
    While the example shows A* pathfinding algorithm on 2D surface it can be easily converted to be used in 3D world becouse it bases on node system.

    As for HPA* I haven't found any examples writen in pascal jet and that is a shame becouse HPA* is much more optimized and uses lots less memory than plain A*.

  2. #62
    Quote Originally Posted by SilverWarior View Post
    For 3D pathfinding I would recomend using A* pathfinding algorithm or even Near Optimal Hierarchical Patfinding (HPA*) http://aigamedev.com/open/review/nea...l-pathfinding/
    A* path-finding is a special case of Search Algorithms, specifically Dijkstra's algorithm. There are many more such algorithms and each can be better or worse depending on the given situation.

  3. #63
    PGD Staff code_glitch's Avatar
    Join Date
    Oct 2009
    Location
    UK (England, the bigger bit)
    Posts
    933
    Blog Entries
    45
    Personally this is what I do - although I've never thought of the problem in a 3d plane to be honest, this is what I found to be my 'simplest' efficient self hauled design, which turns out to be a little like an A* search pattern... I'll write it in pseudo-code to make it shorter and easier to understand

    Code:
    The records I use are as follows:
        A 'path' which contains -
           A boolean array the same size as that of the area to navigate but empty at the start.
           The final number of 'steps'/waypoints used to reach the destination
           Array of X,Y cooridnates of each waypoint
        An array of bits the same size as the area to navigate.  0/False signify space that can be moved into, 1/True designate an  obstruction.
        Another array of bits the same size as the area to navigate.
    Thus the algorithm goes:
    Code:
    proc algorithm.run()
    1. Input sensor data into the area grid (ie. Flip the bits so that the array now contains the obstructions.
    2. Determine how many options the algorithm should consider - dependant on avilable memory/cpu time. Call this integer MaxRoutes
    3. while c < MaxRoutes do //where c is the current route being processed
       3.0 c += 1 //forgot to add at first, so thats why its 3.0 XD
       3.1 AddNewRouteToArrayOfRouteOptions() //Adds a new, empty route data type to the array
       3.2 NewRoute.Process() //see below
    4. while c > 0 do
       4.0 c -= 1
       4.1 ArrayOfRouteOptions[c].Optimize(OptimizeLevel) // see below
    5. ShortestRoute := GetShortestRoute() //a simple loop that checks all the considered options' lengths and finds the shortest
    6. FollowRoute(ShortestRoute)
    7. CleanMemory()
    end;
    
    proc Route.Process()
    1. RouteGradient := GetRelativeGoalOrientation() //Work out the 'angle' from the robot facing straight up to the goal as the crow flies. If there are no obstructions, this is the fastest route and trunc it to either of:
       -1.0: Goal is directly to the left
       -0.5: Goal is diagonally up to the left
       +/- 0: Goal is straight up
       +0.5: Goal is diagonally up to the right
       +1.0: Goal is directly to the right
    2. If RouteGradient > 1 or <-1 then 
       2.1 (Rotate180)
       2.2 RouteGradient := GetRelativeGoalOrientation()
       2.3 if RouteGradient > 1 or < -1 then
          2.3.1 You have arrived
    3. TryDirection := RouteGradient - 0.5 //we add 0.5 on the first cycle of the while loop
    3. CanAdvance := False //forgot to set so 2 number 3s.... sorry :D 
    4. while CanAdvance = False do
       4.0 TryDirection += 0.5
       4.1 if GlobalBinaryMap[ RobotPositionX + round(RouteGradientToChangeInX), RobotPositionX + round(RouteGradientToChangeInX)] = false then //convert our TryDirection to a vector type deal...
          4.1.1 AddWayPoint(RobotPositionX + round(RouteGradientToChangeInX), RobotPositionX + round(RouteGradientToChangeInX)) //adds a waypoint for that empty 'cell' in the 2D array as the path to follow. ALSO flips the bit at that position in the local array to say its part of the route.
          4.1.2 CanAdvance := True
    5. If LastWayPointIsAtGoal = false then
       5.1 Process() //please use a loop rather than this... I'm lazy :D
    end;
    
    proc Route.Optimize
    This is getting long so heres the deal: ::)
    Follow the routes waypoints and each waypoint check if any adjacent cells are not empty. If so, we have a shortcut so find which waypoint to jump to and wipe everything in between. Update the 2d array at the same time.
    Rerun as you like as it 'smooths' the route though can be CPU intensive...
    
    end;
    Long confusing and personally I have similar - though longer - pseudocode on paper in a messier font of my own hand since I've never had to implement it... My enemies always go from point to point and I collision detect so... Enjoy - and if there are any question fire away

    Sorry for the long post guys

    Edit: seeing this makes me wish we had syntax highlighting in that... even just a little bit ...and maybe I should code it up, and make it look nice as an article for the PGD library too O.o
    I once tried to change the world. But they wouldn't give me the source code. Damned evil cunning.

  4. #64
    I think i might be able to make heuristic node finding. What i looked, was that A* general version gets the perfect path, but it can come at a great cost. Current algorithm already reminds A* actually, if i understood the logic from wiki. I'm not yet completely clear on how it selects the final path in the end. Maybe that goes from goal to start, by the node weights. Just thought about it... Definitely not possible to use weights from start to end.

    But also i have thought of a optimization trick for the already visited nodes. I can have "Visited: byte", instead of bool. I don't need to clear every node before search, i can simply increment the comparison value once when search starts, and then set that when visiting nodes. ...
    *scratches head* Scrap that I could come across search paths which have been left unused for 255 search turns, and mess up next search. It really depends on needed path.
    So my current optimization feels most viable, where i write false to visited node each time 1 is removed from search at the end. Still no full map-clear begin of search. I mean, the search arrays are best to keep allocated in memory all times. Using function variables would be a waste of precious cpu-time.

    edit: Also, 3D is more complicated for path finding when you consider flying. Maybe it's a high step that you can only jump down, but not go up. So for some part it would be best for programmer himself to make path finding that best fits his game. Simple 3D-path finding with grid, expanded from my current one might aswell consider air tiles as "walkable" places, fitting to make path to. That is naturally wrong... Nodes are smarter in that sense. But maybe it would still need some sort of maximum and minimum Y angles for nodes, to consider moving possibilities. Some character might be able to jump from high place and glide down, but some would die and so should not be possible path to take.

    Other solution might be link properties, or just making more pathing maps per world for each case. And still, i am very curious if i can implement pathing map generation at least for 2D. That is way more difficult for 3D, and almost feels impossible to generalize.
    Last edited by User137; 07-09-2012 at 05:36 AM.

  5. #65
    I don't think you need to make more pathing maps if you use nodes. The best think about nodes is that each node contains information about pathways to other nodes. This pathways don't need to be leading only to adjenct nodes but can actually lead to any node. This might come in handy esepcialy if you are implementing some kind of portals into game.

    For instance lets take next example:
    For the sake of easier understanding I will use 2D platformation example.
    Lets say that in your game you have tile based map. You have node in each tile. Nodes are conected with pathways. Each node contain cost information.
    Each unit is one tile wide and two tile tall. Units are capable of jumping heights.
    So now for units capable of jumping one tile up you use pathway which is conecting origin tile with nearby tile which is positioned one up and one left or one up and one right.
    For units able of jumping two tiles up you use pathways which conect origin tile with some other tile whose position is two tiles up and one tile left or right.
    The same cane be done for using desends.
    Now you can limit certain paths to be used only by certain units with pathways cost infromation. You can do this by using pathway cost information. This can be done easily by defining this information into differen ranges. For instance:
    1. 1-10 is used only by units which are not capable of jumping
    2. 11-20 is use by units capable of jumping one tile high
    3. 21-30 is used by units capable of jumping two tiles high
    .....
    x. 255 is used by units which are capable of slowly gliding down

    Now this won't reqiure you to have different pathfinding maps for ach type of unit, but only some aditional pathways between the certain nodes.

  6. #66
    There is now a pretty powerful TCamera class, that is capable to simulate everything glTranslate, glRotate and so forth do. 3 different Lookat()-functions, simplest one only taking target-point as parameter, and extracting rest information from its modelview-matrix. This is yet another step to make nxPascal able to do most things by itself, without needing to use OpenGL-header directly. It's propably impossible to completely make engine self-sufficient though, or not worth the effort. If i'd ever want to use custom camera in shaders, that is now possible.

    New TCamera is now used in Model and Picking demos, which now has nearest focused object clickable. It didn't come clear in earlier demo how to prioritize if mouse-ray passes through many objects.

    Another helpful change is changing all angle-parameters in math functions to either degrees or radians. Less guessing...

  7. #67
    Very nice.

    What do you think, are these changes or this new camera help me make the camera thing i asked you by PM, more easily now? Do you recommend me to use this new camera instead of directly using glRotatef and glTranslatef ?

  8. #68
    That is up to you, i know i will now on use the camera on every project even if it's just 2D. Commands used for camera are really almost same syntax as those OpenGL commands, but there is last parameter doSet: boolean (true by default), which also applies the camera changes to OpenGL modelview. doSet being false, it only changes camera internally. It is recommended to use doSet (or SetCamera manually) only once before rendering or mouse-ray reading starts happening.

    You can have multiple cameras. Camera can Push/Pop too, but having 2 instances of modelview is totally different thing. Where in OpenGL you go glLoadIdentity, glTranslate, glRotate on every frame, but with camera you can simply do camera.SetCamera and that would be all there is to it. It can be moved in timed or mouse events and so on.

    But also with doSet true you can call OpenGL matrix functions inbetween. I guess example is needed:
    Code:
      cam.SetCamera;
      glRotatef(45, 0, 1, 0); // Now the rotation is going directly to OpenGL, camera doesn't know about it
      model.Render;
      cam.GetFromModelView; // You can read the OpenGL changes into camera, so it can continue where it left
      ... assume something more happens here ...
      cam.SetCamera;
      model.Render; // Now it's rendered in same spot again. If i didn't call GetFromModelView, it would go -45 degrees other way.
    Lastly, i intend to add camera pathing, possibly using Catmull-rom. Also maybe i could give it possibility to add camera slots, so you could save and load positions without making multiple TCamera.
    edit: Added all that in new SVN version. There's 3 camera-interpolation modes: linear, smooth, catmull.
    Last edited by User137; 20-09-2012 at 09:29 AM.

  9. #69
    Started (and almost finished) a little game project with nxPascal today - Blocksmasher. I am well aware of copyright issues regarding Tetris. I didn't name my project as such, it is extremely simple and must not be used for commercial purposes. Educational or private entertainment only.

    Screenshot:
    https://docs.google.com/open?id=0B7F...2RlUVhxVkk4bEE

    Source code (select File->Download):
    https://docs.google.com/file/d/0B7FI...BUMkluXzQ/edit

    Oh, as always please let me know if this or any nxPascal project doesn't compile and run as is. Especially nxPascal demos should compile straight away without modifying anything at all (just Delphi needs path set once for "nx\src\", Lazarus should have even all that already set).
    Last edited by User137; 17-10-2012 at 01:11 AM.

  10. #70
    i really like your unit and here are my two question:

    1) How start application in fullscreen ?
    2) Generation font take a (little) time at application startup, is possible load font texture from file ?

Page 7 of 18 FirstFirst ... 5678917 ... LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •