Graphics Rewrite
A hangover from the earliest XAGE prototype had become increasingly a problem and the effort required to solve it meant it had been put off not just for months but years. Originally, XAGE required that SpriteSheets be built by hand. The earliest engine runtimes contained hardcoded animation frames (X/Y pos, Offset etc) for borrowed Monkey Island 2 graphics. Later these animation frames were editable via XAGE Editor but were time consuming and fiddly to set up. The situation was eased when converting AGS games, where SpriteSheets were built automatically at the point of conversion, but there were still problems with the whole process:
- The placement of the assets on each SpriteSheet was not optimal which resulted in larger Png & .Xnb files.
- Each object was directly tied to a single specific SpriteSheet, so anything that did not fit onto the specified maximum texture size (e.g. 1024 x 1024) would not be available to that object (you can see the visual glitches this would result in on old TGP videos). SpriteSheets could be shared between objects but each object would need to have its own set of frames, animations and views etc.
- Creating a game from scratch would still require manually building a SpriteSheet.
The solution was to move towards an approach much closed to how AGS handles art assets:
- XAGE Editor will automatically create SpriteSheets on build (rather than during conversion) from the raw image assets. The bundling of these images can still be dictated by the end user by arranging them in different folders or providing overrides.
- Objects are no longer tied to a specific pre-built SpriteSheet, but now can use any image or globally shared animation and view. This should make it much easier to eliminate any outstanding animation glitches found in converted AGS games.
- SpriteSheets are automatically created under the hood using SpriteSheetPacker which arranges the images in a more optimal way, saving space. Performance is improved by using FastBitmap and by only rebuilding whatever SpriteSheet has had a raw image asset change (or recreate everything when the per-platform setting has changed i.e. from maximum texture of 1024 x 1024 to 2048 x 2048).
- Some components that were split out into seperate elements in the XAGE Editor Treeview have now been simplified by using DataGrids, to make it quicker and easier to create animations and views.
- Managing raw assets now uses Cyotek's ImageBox component, which is far more polished than the clunky old custom viewer.
The take away is that everything is far simpler for the end user. The rewrite is about 80% complete but the results are already positive.
This also represents a slight change in direction for XAGE. Previously I'd been reluctant to model both the editor and engine on AGS too closely, which resulted in forcing some square pegs into round holes. Going forward I'll be reworking any sensible AGS paradigm directly into XAGE as an individual component, rather than forcing them into a component that doesn't quite fit its needs (e.g. AGS Regions and HotSpots into XAGE WalkBoxes and Room Objects). Anything I'm still not fond of (e.g. Bitmap masks for walkable areas) will not make their way in, but overall the ease and quality of AGS conversions should improve.
The above means ripping out a lot of old code written five or six years ago and replacing it with something a bit more elegant and appropriate. This should put the entire engine as a whole on better footing for a maintenance perspective.
Other bits & pieces:
- The 'X' in XAGE no longer stands for XNA but instead 'Cross-Platform'. This felt like an important distinction as XNA is essentially dead whereas the libraries that XAGE is built upon, MonoGame and FNA, are very much alive. More importantly, keeping the same acronym meant I didn't have to put any effort into rebranding.
- A simple static website serves as its new home: clarvalon.bitbucket.io
- Bitbucket also hosts a public-facing Issues/Enhancements list and Documentation Wiki. The latter will be fleshed out once the next alpha release becomes available and focus moves away from plumbing towards implementing more of the scripting hooks within the engine itself.
