As part of SilverSprite there are now two rendering methods - the old Silverlight Canvas style and the new Bitmap-based rendering. They both have their pros and cons, so I've hacked in a quick toggle to change renderer mid-game. This is how Awakener looks playing in Google Chrome at x2 scale using both styles:
- Quicker - runs at 100% on my atom netbook.
- Ugly aliasing, makes text harder to read.
- Visual glitches (transparency especially).
- Outstanding memory leak when using bitmap fonts(?).
- No aliasing or visual glitches, looks practically identical to xbox and native pc.
- Much more processor-intensive - choppy performance on my netbook but runs at 100% on a fairly low-spec dual core pc.
Bitmap rendering adds (at the moment) a higher hardware requirement than I'd like, but it's really helping push XAGE's cross-platform viability. Again, it's likely that there are further optimisations to be made in both SilverSprite and XAGE, and perhaps the recently announced Silverlight v4 will offer further performance improvements.
Edit: There exists a third option that hadn't occurred to me - using bitmap rendering for the backbuffer and canvas rendering for the rendertarget. This provides a happy medium - a few visual glitches but looks better than pure canvas and runs faster than pure bitmap. This translates to three Silverlight visual quality options - Low (canvas), Medium (canvas/bitmap) and High (bitmap).
Oh, would be awesome to play the games in a browser!
I've been able to implement A* pathfinding using walkboxes now. But I've been using the boxes corners as nodes as seen under Vertex movmement here:
But what I'd want, and what I'm guessing that you're using is what's described as "Hybrid movement". Don't know how to generate the nodes at each edge center tho :\\\
Ok I managed to find a way to add nodes on each edge. I'm having some trouble figuring out what heuristics to use tho. Right now I'm using
int H = (int)(Vector2.Distance(currentNode.Position, nodeToAdd.Position) + Vector2.Distance(nodeToAdd.Position, targetNode.Position));
Which seems to work ok.
I've also been running in to some problem with the way I check if a point lies within a walkbox:
When I've found a path using A* the character walks at the very edge of a box sometimes which is considered outside of the box. Which makes my A* return a null path the next time I walk somewhere (since there's no walkbox to start from).
Guess I could fix it using some kind of collision detection, or tweaking the algorithm.
03:26 AM okok time to sleep ^_^
I had the same problem. If I remember correctly I think I allowed for a certain degree of leeway around each box vertex for character movement, but not for when the waypoints were being calculated.
Thanks for the links - they'll come in useful as I need to revisit XAGE's pathfinding algorithm eventually as it's not infallible.
Here's how my pathfinding looks so far:
Think I need to tweak the heuristics and line of sight algorithm as it doesn't work like It's supposed to all the time :\\\
Nice video. It's fair to say that your pathfinding is already more advanced than XAGE's, which has some limitations when it comes to the angles and organisation of walkboxes. Likewise it only ever looks one box ahead rather than finding the optimal waypoint, as yours seems to do. Good work!
I read a book called Game Programming Gems 1 which had a chapter about navigation meshes and I decided to rewrite what I had.
Imho this feels more stable :P Using triangles made some of the calculations a lot easier.
It also accounts for clicks outside of the navigation mesh and forces them inside the closest cell.
Looking good. The line-of-sight aspect is something XAGE definitely lacks. One other thing you might want to consider is whether your pathfinding handles what XAGE calls 'WalkLines' (i.e. the same as a walkbox but two of the points are the same as two others). It's something used quite commonly in Lucasart games, especially for traversing maps.
Post a Comment