Warning: Parameter 1 to NP_Poll::event_PreSkinParse() expected to be a reference, value given in /home/pokelege/public_html/nucleus/libs/MANAGER.php on line 370
The Project Gamma Development Progress Blog » Update
The Project Gamma Development Progress Blog

Update

Mar 02, 2011 by DX-MON
Since my last post, the following has happened, along with the completion of enough of my desktop's Cross-compiled Linux From Scratch builds to allow me to build 32- and 64- bit executables of the various components on it:

MapMaker: glGenericWindow-based code has been ported to Future Consciousness' glGenericWindow. This has actually fixed a load of bugs in MapMaker such as exit bugs caused by the old methods.

GTK++: The legacy Subclass/Unsubclass methods have been removed, which means the library is far less broken than it was. The OpenGL classes rewrite is also complete which provides a much nicer inheritance hierarchy and removes several more methods that were introduced to get around how the old hierarchy worked.

Future Consciousness: Having been highly unsuccessful with Python, and having mashed up some of the code by accident during the move from my laptop to my desktop, I have decided that it'll be easier to completely rewrite things like the layout engine for Future Consciousness, drop Python, and find another, different, scripting language to work with - maybe even make a byte-code language which allows programming the engine for certain handlers and associates a byte-code snippet with an action on a button, etc.. It certainly has the advantage of speed over what Python had/has. During moving the code to my desktop, though, I regrettably have to admit that certain non-Python components do not currently link due to some problems in the build system. I should be able to resolve this, though, through the removal of Python which will be the next thing I do. I can, however, say I know for certain why glMessageBox has a crash in it. (I won't say right here right now, but it has to do with two flags in glGenericWindow and a spurious GTK++ call in glMessageBox) The transparency for the connecting screen, as mentioned last post, will be served though adding one extra image and content descriptor member to the layout format. This image must be a grey-scale bitmap of some kind, stored where the Python table used to be (most likely), which can then be directly used with GTK+'s transparency systems, for which one of the functions should be one that takes a bitmap as a transparency map.

Signing off after what will likely be a slighly cryptic and a fairly hard-to-read post,
~DX-MON
PS: Sorry that it is cryptic in places and likely to be fairly hard-to-read, I try not doing posts like this one, but it's the only way I can document this progress this time.

Comments

No comments yet

Add Comment

This item is closed, it's not possible to add new comments to it or to vote on it