Some updates

Haven't updated in a while, so I thought I might write a post to give a little update on what's happening with Tengoku.

- If you've taken a look at the repository you might have noticed that a lot of change happened in the organization of the files; I ditched the colorfully named sub-libraries and cleaned out a lot of junk, including most of the bad, inaccurate docs lying around, old tests etc.  The tests folder is very nice for doing experiments that double as tests.

- I finally settled on PascalCase for the entire thing and have been slowly updating the source code.  I know I had just wrote that I decided that allcaps was the ultimate but then I read some code written by Pablo Reda implementing an IMGUI and found it to be very nice to read code with a mix of case, even in Forth, so decided that it was worth it.  SwiftForth is case-insensitive so I haven't made the source perfectly consistent in regards to case but it definitely made it much more readable.  I used to do all lower case mostly out of laziness, and still do when the code is throwaway.  But hyphenation is an old Forth convention that I don't really like so I've started weeding that out - I still plan to use it though when I want to really distinguish the first word from the rest of the name of a function.

- New features are being added and changes are being made to the OOP framework all the time.  I recently added two new flavors of classes to complement the Module keyword: Structure and Topic.  These are cut-down versions of Module that don't support defining methods, to save memory, and to make intention clearer. Topic is meant to not have any properties or methods at all, only internal functions and static members.  It's basically a convenient way of defining and working with a private wordlist that works with the same semantics as other classes.

- You can now open any class's internal words with the words [Using and Using], but I decided that I hated typing that so then I added [u and u] which is easier to type and u: which lets you do just one word, and then I recently checked up on Retro and saw its version, so I decided to experiment with the syntax "With: ... Without" .  So there are three semantics for the same thing because I still haven't decided.  Probably [u ... u] / u: in compile mode and With: ... Without in interpret mode.

- Inspection has been beefed up a lot and you can peek into all sorts of objects and get useful info.  It's very nice to be able to quickly see what's going on in a group of variables - sort of a poor man's Visual Studio but nicer because you control exactly what the computer is showing you at any time.  It's not hard, just put an object on the stack and add M?.   They can be easily thrown into a dynamic textbox to have a live running update over-top the game.   .S was enhanced at some point to by some black magic know what items on the stack are modules.  Very nice and will be integrated into the HUD console I'm planning to add - that's a very old thing that I've had in every game engine experiment I've done since 2000 - but I found SwiftForth's sufficient up til this point.  It will be very very cool, I've got lots of great ideas for it, such as a Fixed-point stack view and more like live-updated Current and Context state.

- I plan to enhance .Fields to show you summaries of non-classed fields based on their size ( if more than 4, judge from there - 8 would mean a double, more would mean an array ... of course it won't show the entire contents of a huge field, maybe just a size and the first and last bytes).

- I'm going to add a new feature that will work very nicely in Forth and will make certain pieces of OO code look like normal procedural code.  It's called Property Sharing.  You'll be able to define certain properties (I call them fields, but whatever) in a module as being Shared , and then in another module you'll be able to say that you want to share the properties of another module using a connection that you give a name to.  Then you'll be able to invoke those fields without qualifying them at all, but they won't implicitly refer to This, instead they refer to the object that This (or the object on the stack, for external facing fields) is connected to.  If you do qualify them, they will point to the properties not necessarily of that object but the one it is connected to.  The connection is a plain old var that you must assign for the sharing to work.  Of course, objects with shared fields automatically define their own connection to themselves.  This will be used to streamline Entities and Components (currently the same thing is being accomplished with some ugly custom code), and make applications that utilize many interdependent objects.

- Now Tengoku has its own windowing and input code, called Iota.  SDL 1.3 was too buggy and it wasn't being regularly updated so I moved to a library I just found out about called SFML.  It's great, better than SDL, but it doesn't work on many computers with ATI cards.  So I ported a small subset to Tengoku.  Took me about 3 days, but, it works like a charm, and it can easily be swapped out for the real thing (when and if SFML matures to a level I feel that I could rely on), because I access it in the engine via a set of wrapper functions that match SFML.  It's even compatible with SFML 1.6's data structures and events.  Of course, the corresponding code was refactored heavily to make the task easier and came out to about ... 33% of the C++ code, I think.  Iota was developed in a private repository that sat nested within the Tengoku folder structure in an ignored folder, so it could include some selected files that it needed, then it was migrated into and debugged using the various test programs.

- The GUI framework, called Studio, is fleshing out nicely.  It is very easy to work with and you can do some fancy things like set up a game to support the mouse being able to pick up things and move them wherever you like.

I'm also doing some other things that I'm not sharing open-source.  I'm developing the game, of course, but I don't want to talk about it.  And I'm developing a set of tools built on the Studio (GUI) framework to work on graphics and maps.  There's a comment in Studio.f that I forgot to take out that mentions ideas for this.   

Guess that's about enough for today.  I'm just glad the system is stable and mature enough now that I feel I can do anything with it.