Alo Sarv
lead developer

Donate via
MoneyBookers

Latest Builds

version 0.3
tar.gz tar.bz2
Boost 1.33.1 Headers
MLDonkey Downloads Import Module Development
Payment completed
Development in progress.
Developer's Diary
irc.hydranode.com/#hydranode

Friday, January 07, 2005

Considering development directions

The reason why I haven't delved into full-speed coding yet after the vacation is that I'v been trying to figure out which development direction to take. There has been only trivial updates in CVS - x86-64 support (thanks to sca for testing), precompiled headers support on MSVC, and minor OSX improvements (no, it still crashes on startup), but nothing major.

The thing is, it feels the existing directions (e.g. develop the engine until it works, then attach UI) isn't really working anymore, since there is too much information needed to be monitored for simple trace output to work out. One idea to solve that was the Launcher application (that would need to be written sooner or later), however, that would solve only part of the problem. Yet another way of doing it would be to write the Launcher application in a very generic manner, so that it would be capable of displaying almost any kind of data (not just log output) - have it display lists, settings and so on for example. It's not very hard to design it in a generic manner, since wxWidgets allows very simple runtime UI generation (as opposed to many toolkits mainly relying on pre-built dialogs). But I'm still not 100% certain whether it's the right road to take or not.

What I'd like to avoid regarding the Launcher application is that it would be considered as full user interface - that's not the topic I want to go here. The idea of Launcher application is to provide a shell for the engine to be run in in release versions, and in development versions, also aid the engine developer. As such, it doesn't have to be very user-friendly, but instead must be a good developer aid, exposing the internals of the engine to the developer.

The good side of this approach is also the fact that the Launcher would interact with the engine using Core/GUI comm protocol, which gives us an early testing platform / overview of the protocol and the errors in the protocol design (which are much easier to fix in case only the Launcher depends on the protocol, but would be much more complex when we built a full UI on top of it).

Madcat, ZzZz

PS: If you have experience in OSX C/C++ plugin development, contact me - there are problems regarding module linkage resolving symbols in bundle_loader - Lazy Singleton pattern symbols somehow resolve to 0x0. Probably I'm exporting (or not exporting) the symbols from the bundle_loader properly ...



Comments: Post a Comment



<< Home

This page is powered by Blogger. Isn't yours?