I finally got back to working on XSquawkBox 3 recently, which is the XP11 native, Vulkan compatible, XSquawkBox branch.
Just as a general disclaimer: Any development or features mentioned in this blog post may be subject to change prior to the actual release.
As an additional note: Once again, please do not contact me asking to be a beta tester or asking when it’ll be ready. It’ll be ready when it’s ready.
It wasn’t a simple matter of picking up from where I left off 2 years ago – because of the huge amount of work in to the now stable 2.x family, there was now a huge divergence between 3.x and 2.x that really needed me to go back to scratch and start afresh from the latest 2.x release work.
This weekend finally got things past where they were roughly 2 years ago when I stopped, with the added advantage that I’m getting to test a lot of this with the Vulkan beta to validate my suspicions from two years ago about what would and wouldn’t work. (Two years ago I could guess – today I can test)
This weekend saw the following major milestones met:
- The old WIP GUI work has been reintegrated and is working again.
- The ImgWindow binding has been updated with FontAtlas support which means less texture memory wasted on loading fonts multiple times, as well as making it easier to have a consistent set of fonts loaded for all windows.
- Some bug fixes have been integrated for erroneous behaviours observed and commented upon by other developers.
- These updates to ImgWindow are now in the xsb public source repository for all to use.
- The xplanemp2 (next-gen/legacy-free xplanemp) branch is finally working well enough for other people to start looking at it and has been published on GitHub
- xplanemp2 rips out all of the old CSL support (ACF and OBJ7/Legacy) that can’t work with Vulkan and focuses solely on Obj8 both in GL and in Vulkan/Metal.
- xplanemp2 has some map integration now (so you can see and identify multiplayer aircraft) which has also provided quite a lot of useful lessons about how to go about doing the controller representation on the map for upcoming work on XSB3.
- xplanemp2 is not a drop in replacement for the old libxplanemp, and it’s only compatible with XP11. XSB2.x will not be using it.
- The XSB3 text radio command parser has been finished and is ready for debugging – this came about to fix a pile of design problems in the original text radio system with how it handles commands and difficulties in extending it to handle new ones.
- Most importantly, XSB3 is finally back in a incrementally testable state – whilst it cannot be used on the network in a real capacity yet, it’s working well enough for me to verify feature work and check progress on major components as I go forward, rather than having to take big strides and hope it all works at the end.
There’s still a lot of work to be done over the upcoming weeks:
- A lot of the UI still needs to be rewritten into the new framework, and performance checked as we go.
- Flight Plan, Audio Setup and Connect dialogues have yet to be started.
- The console needs to be rewritten to make it faster and better suited for our needs – the one that’s currently in there is only good for testing in its current state.
- A new general status window needs to be added to show oustanding message state, Rx & Tx states, and to provide control overrides when the model doesn’t have them set up properly. A significant number of user borne problems in 2.x could be addressed by having this sort of information available readily from the client’s perspective.
- Controller map is still to be done.
- VR Testing hasn’t even started yet and is a major part of this cycle.
- Weather System Overhaul
- Whilst I’m loathed to pull the integrated weather out completely since it’s better than nothing, it needs updating to use the metar.rwx mechanism so you can get smooth weather transitions.
- The new plugin/integration API needs to be designed