"This application has failed to launch because zlib1.dll was not found. Re-installing the application may fix this problem."
I found a blind spot! You can just stand here and keep pressing the space bar. (Until I won and accidentally skipped the "You Win" message, anyway ).
Something I just learned......Ah well. I'll just comment on it, then.
Quote from: Mooch on December 17, 2013, 07:31:32 am"This application has failed to launch because zlib1.dll was not found. Re-installing the application may fix this problem."I have no clue what you are trying to do. Just extract into a new folder and play. It's really not that hard... Why are you always running into these DLL errors???
Performances of Pathfinders in Sphere:- Kamatsu's (A*, priority queue): 950ms to traverse 100*100 map.- Radnen's (A*, binary tree): 600ms to traverse 100*100 map.- Beaker's (DFS): 400ms to traverse 100*100 map.- Radnen's (sorted list + table lookup): 200ms to traverse 100*100 map.These are remarkably slow. In a better language these should be magnitudes faster, especially the binary tree and priority queue, which should be near instantaneous for even 100000*100000 sized maps (due to log performance). I fully expected the sorted list version to be the slowest. Sphere just can't handle - at all - any complex data structures. I remember when Kamatsu made a quadtree in Sphere and couldn't get it to do something smart (pixel collision in his terrain tech demo), because it was just way too slow, despite being a perfectly good and efficient data structure to use.Therefore, I'm definitely going to add A* pathfinding as a stock function call straight into Sphere-SFML.
Hmm, wouldn't these make good benchmarks for testing in TS and SSFML? Just so you can see the benefits already (and diagnose performance problems, if any).
I'll tell you what: I agree with you wholeheartedly and feel that having some pathfinding written natively into the engine for speed and exposed to the API is important enough that I will make an official recommendation for conditional pathfinding to be written into future versions and forks of the Sphere engine, starting as soon as possible. The conditions are:Pathfinding must be built into the map engine on a pixel level and a tile level (ie, TWO map engine pathfinding functions exposed in API, one for pixel level and one for tile level); ALL obstructions (sprite, tile, AND obstruction lines) must be taken into account in both cases, possibly with a toggle to ignore/not ignore triggers and/or zones in the calculationsNon-map engine pathfinding must be available anywhere else (ie, pass some network mapped obstruction list, start and end points, and return...something, probably the "shortest path" as an ordered array of nodes or something)Any working pathfinding algorithms may be used, but we could probably conditionally branch which to use based on list size vs performance vs whatever other factors like how FFTW conditionally switches FFT algorithmsSo yea...pathfinding!