Oh my FUCKING god, I don't need to write any NBC anymore. Ya know what? I already mentioned, NXC has some functions which won't work/can't be found by the compiler. And the right and even WORSE opposite of it that the only way to read the ultrasonic sensor is to use a special function that's simply not documented. I simply HATE such moments of tremendously HORRIBLE documentation! Really, what the fuck did this guy think, er? If he can't make one function out of them, I really doubt something I don't know at the moment. Hmpf, that's pissing me off again. However, I finally got it to read and can start developing my little synthesizer I wanted to make. Finally! And it only took one fucking week...
NBC has a horrible documentation if it comes to actual how-to-use details. Fortunately, there are enough example programs I can abuse to my liking. The syntax itself is very easy and once you found your way through the JustTooRawAndUseless(TM)-alike documentation, you can actually get stuff to work without much problems. But I really don't want to make real code using it. I'm much more of a C/C++-oriented guy, so I guess I either need to fight my through it (I don't like to fight) or create a language that's much comftable and translates to NBC code. That shouldn't be hard, since it already give you essential things like structures, subroutines and threads. Besides a static amount of memory for global variables, you also also get a limited support for dynamic memory allocation in form of arrays. So somehow there seems to be enough functionality in the firmware to make some limited, procedural programming languages possible using NBC. Only drawback I don't like that you can't really abuse them as adresses or pointers. So there won't be any "dynamic" content structure, you can only use pre-defined and you can only use these. I read an informative paper a Logo implementation using NBC. As far as I can remember, they just wrote that they used NBC for making it, so it's either a bytecode interpreter occupying the whole 32k memory to garbagecollect it, or they actually wrote a converter. But I guess they wrote an interpreter (I'm not in the mood to further dig into it), cause it'd be hard to integrate certain features with standard NBC.

After some more tests I'll guess I'll design a language I can easily parse, manage and code. I don't to have something too fancy with too strict rules, just some basic elements covering NBCs feature list (and firmware system calls, of course, too). So I can rely on NBC doing it's work as long as I capture all syntax and logic mistakes BEFORE it get's compiled via NBC.


I tried to let the NXC compile my program using a function SetSensorUltrasonic() I took from the documentation, but for some reason it does just not compile.  He always complains about it beeing non-existent. Versions match, function name ist the same - even codes from the internet including this function don't work. This made me look a bit more deep inside the NXC/NBC connection: Why do I get errors with exactly the same content multiple times? Why do some functiona generate weird error when writting multiple command in one line? These were really strange things to me - a compiler written for a specific language does usually cover every wrong syntax with a specific message in a more or less readable but often unique format. Not so with NBC, I had soooo weird errors with this compiler. I did something wrong, intentionially or not, I wasn't always able to get the real message he was telling me.

Some webpages later I discovered that the creator used macros instead of functions! Yes, macros - macros ONLY. And thus some of these weird messages come from the fact that he had to code a mechanic to trace error back to the original NBC code, resulting in multiple errors (for one line) with exactly the same content cause wrong parameters get inserted into multiple lines of NBC assembler code it does translate to during compilation. So what do we have in the end? A compiler that's rather a blind translator and not the original language. Fortunately, there's a (so far) rather understandable documentation of NBC and all of it's functionalities. To avoid further annoying suprises I'm currently learning how to in NBC and thus in some kind of Assembler-like language (which can only be useful in my later life). It's a simple syntax and also offers a macro system with some kind of strange features which could ultimately lead to some interesting code generation macros and some other things interesting for personal development.

I'm at the very low end of NXT programming. If something WON'T work this way, I'll probably get VERY VERY ANGRY in the end. I don't want delays anymore, I want TO FUCKING CODE MY IDEAS. Also, I designed an interesting little system for making the NXT a digital synthesizer. Cause most functions will be done by the firmware, I can use functions to generate tone a specific frequence and amplitude. My idea is to create a little synthesizer with a system or digital LFOs and ADSR generators and allterate the played amplitude and frequency of the playing sound. The concept is ready and the real work lies in learning NBC and create a keyboard for it. However, all things are ready to go, I'll only have to realize in NBC. And I'm sure it won't be as nice to code as with standard C... Atleast, it's the lowest possible level with standard firmware, providing all functions out of the box and with no further developer-accessible layers. I just CAN'T do anything non-working with it. It has to work!


Nope it didn't work

Yes, I tried it, but no, it didn't work. I just can't do anything with Java. I'm not used to it and I'm not interested in it. Instead, I reflashed my brick once again and let NXC/NBC do the rest. I just can't work with Java, it's so littered and so over-the-top conceptual - where does all this shit come from? As much as I love the idea of having a single bytecode interpreter as a base, I always forget how immensely stupid everything else about Java is. Java is for web applications, enough said. Also, I'm not a fan of too OOP-e-fied OOP. It should still resemble the natural structure of code, not stupid analogies and abstract concepts. These guys really know how to wreck newbie programmers. It seems so hard for Java programmers to code something actually clean in C/C++. But maybe I just don't know the right people... However, this will it be, for the last time. No more firmware flashs! I'm curious how I can squeeze the last drop of functionality out of it. In my freetime, I'll not only work on code and Lego machines, I also want to find a nice way to give C some nicer OOP and Template features. I know the only way to do this is to use macros - they are ok, if they're the languages natural way of enhancement (sounds like a spam mail, doesn't it?). So fuck yes, let's start with this and break the laws of limitations. And I'm tempted to abuse it's almost non-existing dynamic memory allocation. I have so many ideas I can do with it, cause the NXT is so limited. Let's see what I can do and what not. I'm intrigued! And as it's using Lego's NXT firmware, I know all sensors will work. In LeJOS I could just not get color sensors to work. Must be the firmware or the horrible API... However, I'm glad I do have a proper C-style syntax and functional API now... Home sweet home.



Well, as it seems to work with Java, I tried to use some more advanced, rather Java-like concepts for sensor access (like listeners for button events and so on), but I failed so hard. The documentation is very much work-in-progress and doesn't cover all included functions. However, there's a tutorial and there are sensors you can access any time you want. That's good by default, so I guess I should write my own functions for timing and ignore the more Java-ish parts of LeJOS. But there are still things annoying me. I don't know if it's just me of Java, but it's random number generator seems no to work for me (always the same numbers even after initialization etc). I guess I forgot something important or use a wrong calculation. I really don't know. However, this means some heavy learning.... That's annoying me. Seriously.

So in my anger about it I tried to setup nxtOSEK to immediately start with my own C++ code, but after almost an hour of compilation and file management it told that it could find compile the sample codes due to one single missing file. Great. This way it won't work, for sure. Ok, stay with Java... Don't care about javaish Classes... Stay the C++ way... Just ignore it...

Fuck NBC, LeJOS is the new shit

I should have done this before. It was so much easier than finding this silly command line option for NBC. However, I flashed the standard firmware with LeJOs and now I can code within an almost full Java environment! Isn't that great or what? It's awesome to see how well everything went and how you it simply uses javac to create standard Java bytecode. Simply genius! My apologies, Java - today is the day I learned love you! Seriously, there's nothing more awesome than needing only you're already installed Java compiler and a quickly installed program to upload it. And as I also learned a lot more about the inner depths of OOP programming/garbage collectors etc from the implementor's point of view, I begin to understand Java's design decisions. Another cool thing is, that you can read a lot about Java's technology on Wikipedia and learn why it went like that.

All in all I'm much more lucky now. love this shit.
If this works that simple by default. I should be able to flash my firmware and try some other, better-suited compilers for it. I hope they all also provide a way to upload it. Otherwise I could also imagine writing only one program at a time, always overwriting the default NXT firmware. But well, also only if there are libraries to make use of it. I don't exactly. However, I can, in all cases, use NBC/NXC for programming with the default firmware bytecode. I'd still like to get a GCC toolchain working for it.


Finally! After so many tries and even more failures, it's finally working. And ya know what? I didn't need ANY other programs than a rather uptodate beta version of the NBC compiler itself. And (that's the part that's pretty stupid), you need to specifiy your NXT version via command line, means when compiling you'll need the "-v=128" option (the number varies depending on your firmware version). So yes, that's it. Also, it requires you to execute it with root rights (that's rather a minor issue I think). And for the first time I heard this annoying little system beep for having the upload complete. Nice! So let's see what I can do with it. I already tried myself  making some more complex in LEGO's default software, but it crashed my file in the middle and I lost interest in doing experiments with it. But this nice little thing should keep my going. Expect it be awesome!


I give up

I didn't found any way to send my programs to the NXT. It's just too difficult to setup for me. I can create all kinds of programs for you, but if it comes to the old-fashioned design of operating system, I fail. I really don't know what to say. Why isn't it easy? Why so difficult? Why don't developers think about others that don't have the knowledge they have? I don't know, I just don't know. Atleast I am trying to make my programs or dreations are simple as possible to use. I decided to continue NXT development on my desktop PC, using WinXP instead of Win7. It simply worked after installing the drivers. Why not always so easy? I just don't know... At first I'll continue tinkering with Lego's official software and use BricxCC later. It's the only software I could remember that seemed to work as simple as possible. Using it is something different. If I get in a better mood, I can test all other editors/compilers with Wine or a virtual box. It could work this way, maybe not. I don't know. Life's hard. Linux is Evil. I don't like Windows.
What a fucking shit, I could cry. There are numerous ways to compile and upload NXT programs, but most of them require older firmware and compilers to work or some other voodoo magic like perl scripts which's functionality I can't get rolling cause the only file I need isn't supported by unpacker I've yet used. AAAHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH This shit is driving me crazy. Compiling an NCX or NBC is the easiest part of it. Then you need to upload it. Problem is, NBC actually COULD upload it, if it would work. It does NOTHING except for compiling it somewhere. But uploading? I guess it doesn't even recognize the NXT. So there are programs like Talk2NXT (T2N) and LinXT. T2N does work for certain NXT firmware versions. Problem is that NBC creates programs for firmware version 1.128 and T2N works only with 1.124 below. So in order to get it right, I'd probably downgrade everything. I already did that for the brick, but I don't feel that I want to do it often as it is NOT the way I want to destroy it's flash memory. So I found some universities covering the setup process on some operating systems and found LinXT, which requires a lot of extra installations for which the last did just not work and I don't know how to open this fucked up archive type. I really don't know why GNOME's packager doesn't do anything there, but I can't change it.

So the last chance I give non-virtualboxey installations is to manually set the USB port NBC should use. I hope this will work... Otherwise I'd need to setup some very, very ugly things to get it work. I just don't know why devs do so fucking stupid things instead of developing a simple automagically working system. It isn't so hard, they just need to FUCKING DO SOMETHING FOR MONEY. What, Money? Oh right, I forgot. We live in A FREE COUNTRY, RIGHT.

This is pissing me sooooo off. More than anthing else at the moment. And no, I'm not interested in coding Haskell or something weird like that. It's already a shame that there's no working GCC toolchain that comes with a sane usage.

The hard way

Lego time! I got my NXT to work properly on Windows. Problem is, that I simply dislike the NXT variant of Labview. The idea of having everything graphically isn't the problem, rather it's execution. It's fucking slow and bad to control. It needs smaller graphics, more functions and a proper context menu and so on and so on... I know it has to work for complete newbs and children, so I can't blame Lego for it. What I need is some kind of simple toolchain (command line or IDE doesn't matter) for a programming I know. As I said before, there are some firmware updates (which I do badly need, I guess) to make it more suitable for realtime applications. I tried Bricx Command Center, but it simply doesn't detect my NXT. So as everything else is just CLI, I better switch to Linux and try sending it using Bluetooth. So yes, it's the hard way. I found a guide and I hope everything will work then. Good thing is, that I can always restore the original firmware using LEGO's official software. So nothing is lost when I start experimenting around.

However, I hope this will work somehow. I really want to explore the stuff I can make with it. I have so many ideas including concepts where you use the NXT as controller only, doing all calculations on another bluetooth client. There's much stuff floating around in my head and I begin to LOVE the idea of making all the things I found too trivial before for the NXT. It's just more interesting to create digitally controlled mechanical processes that'd be boring for a normal programmer. It's like having the real world as physics co-processor! No, not really.



Harhar, I converted my previously annoying and limited RTTI system in a way that you create typeIDs for EVERY class out there. Only thing bothering me is that it requires to overwrite every function named typeID, but I think that's something I won't be able to remove with out making in annoying to use... However, it really works for every possible class (including template and so on), as it create purely declarative class names with the purpose to create a special class ID. So you don't have to worry about inheritances, multiple base classes, etc. It works great! I'm so lucky it finally worked in a way that you simply write RTTI objectname; and everything can be done the normale. You take it's class* pointer, copy however you want and anything else. I wonder why they didn't create such a systems for C++ by default - it'd much more effective and took me, the unexperience small student of nowever, only some days to finalize it. Oh nose...


The only drawback of template wrapping classes for more convenient memory management is that you can't use other constructor than the ones without parameters. I tried to atleast add a possibility for "copy constructing" an object from another using the assignment operator, but that does just not work. It ends up in an endless recursion over two copy contructors calling their opponent cause they won't call themself to copy again. It's a problem I never encountered in everyday programming, so it's kind of special. I don't know how to solve it, so I'll just leave there as it is. That's the main drawback of trying to create a complex wrapper system: some things just won't work, logically. And there is no way to this problem I'm aware of. Maybe I should just let it be and don't think about impossible logical constructs that would only work in very few special cases. And as I want to keep my constructs almost absolutely safe, I need to overwrite the copy constructor for all of my classes and thus making it impossible to call the ones from base classes. Even if it would be possible, it would result in logical mistakes inside the language, so I also nothing can be done except for writing a new language. Maybe that's a good starting point. Writing a language that can be translated to standard C++. I think that's the best you can do if you got a safe system and don't want to remake all the stuff other people already archieve. In all cases, I can still make a bytecode for faster execution and translate to C++ later. But well! I'm thinking way to far at the moment...

RTTI revamped

I think I can rework my RTTI system in a way, so that you'll never need to specifiy which class is a possible RTTI class or not. As my experiments on garbage collection continue, I found a nice way of simply wrapping elements with a template wrapper instead of deriving their functionalities. That's quite a nice way for that, plus you can really give EVERY class a typeID. Only drawback is that you won't be able to add typeIDs with specifying that Object XY should have one. But well - having one wrapper for EVERYTHING makes it a better deal by default. I still wonder if I should create wrapper classes for normale datatype. You can't just take an int as a baseclass - you'll need a wrapper for that. Well, it's just an annoying amount of type work, so I think I'll leave it to what I originally planned - RTTI only for special objects like in GUI systems.

So far, this stuff is getting really cool and slick now. More like C++'s own class system, like a nice library extension you could need in a lot of cases. I'm also quite happy with the concept of my garbage collector, which I'll better call memory manager, as it doesn't collect the program's garbage, rather the garbage you left and created via a memory manager instance. I'm also thinking about an efficient way to make some kind of second version memory manager that simply acts like memory allocation like in C++. So you can use the garbage collector for important and buggy parts in the code and replacing it with a non-overhead, slimmed-down version. So you can get debugging functionality while running the program at full speed in release mode. I've so far NEVER used a debugger for C/C++ programs, I always created logs and nullpointer checks to be 100% sure where what fails. A debugger is great for really complex problems, but if you manage to find a way for a program to debug itself, it can be a great source information, as it gives the possibility to have one of the most clean views on a running program structure. This stuff will be useful in the future. And instead of tinkering around with slow bytecode languages like Java, I can rely on my own system and still get full speed later. Rejoice!



Oh, how exciting all this is! My wishes for designing a scanner with bricks and NXT grow and grow. I got so many ideas how to extend, for example, the color sensor with some physical build-arounds to provide RGB support etc. From what I know is that you can only check whether the light it got has a red, green oder blue part. I need to test this as soon as possible! Too bad I don't have the time to just start building and forgetting everything else. But there atleast time during the term break, so I can step by step build a nice workspace for developing during my free time. And then I'll be able to start making some actual constructions, programs etc. I also found out nxtOSEK for C/C++ programming and, as it seems, even file support and so on. Some really goes are out there, I just need to flash the brick somehow. At the moment I'm so excited and flashed by ideas bouncing through my head, I can barely just pick some programs and test if they work. This needs some more determination.

However, I'll continue with my garbage collector. Once this is done, I will have to work on other, more work related things.


Beside the garbage collector/memory manger I', currently designing for C++, I also started finding a better firmware for the Lego NXT brick I got as a christmas present. I started playing with the original firmware, but I'm not really fan of it, especially cause there are some really useless features for more advanced brick programming. However, one interesting thing I discovered is that some guys actually wrote a firmware featuring a tiny Java VM for the RCX and NXT! And holy shit, that's really awesome to know. I know there are also firmwares for coding C programs, but a fully-blow, object-oriented programming language? Fuck yes, I need to get that. Using libnxt I can flash the original firmware and put some interesting versions on it. And coding my control software with Java also teaches me some lessons about programming Java in general. I WILL need to code Java this semester end, so it's nothing bad to test some things out before going dirty with it.

So yeah, I'm still browsing Wikipedia to see what else interesting is there. I'll get a Lisp book in a month or so, so maybe I can eventually write my own firmware with a Lisp machine on it. I know that'd be a lot of work, but I otherwise I wouldn't evolve much. I don't want to get stuck with only hardware-independent experience. I look forward, seeking hardware abstraction on a deeper level. And even if it's just the very basic concept, List will probably the core syntax to what I will create one day. Nothing is more cool than syntax made for extremely fast parsing while offering full programming potational, if not more.


Garbage Collection

I not a fan of garbage collection for systems designed to reach high performance, but in certain moments it's quite useful. During my intense experiences with linked lists, I created a concept for lists that base on a specific kind of client/server system for pointer/object relations. It enables the programme to create server objects that automatically set all of their associated pointers to zero when it gets deleted. In the way it manages it's associated pointers, it can also detect when there are no more objects pointing at it. And that's the point where I thought that it'd make an interesting system for a more clean garbage collection. Some thoughts later I ended up with an interesting concept integratable into standard C++. That's cool, cause I make it as flexible as my RTTI system: You decide when to collect and when not. You could even create multiple garbage collectors and they won't do something until you say them. The cool thing is that this system is self-managed and on-demand: it doesn't break interrupt the program looking for deletable references. Instead, it always knows what to delete due to the object's self-managed garbage marking. It has it's memory overhead, though. Especially for the pointers used for such a collector: they would be three times as big as a normal one. But well, if you have always local pointer variables, this shouldn't be a problem. It's rather costly when assigning new objects, but efficient when deleting them. As every other management system, is has special balance of performance, overhead and feature set. This will also be an integral part of ITK. It's cool that you can use C++ to extend it's own possibilities, almost totally independent from the underlying system. As long as you don't use "evil" C casts. and other things breaking the newly subsystem.

So yeah, this would increase my GC tolerance a bit more, since it' has a rather nice performance equal to a double-linked list. I like linked lists. They do so well on modern systems. And they make fine structures for dynamic, unpredictable data (my specialization).

Pethatic humans

I give a FUCKING FUCK on family and their stupid, ever repeating stupid memes about stereotypes while giving a, for them, perfect example right on the next chair. Fuck christmas I say you. And fuck this FUCKING FAMILY away to eternity.

It's just ONE day in the whole year, ONE DAY and they manage to completely screw up everything by violating all politeness they'd normaly have if there weren't this fucking rest of the family. God, I hate this shit to NO END. Will this ever get normal? No, probably not. I know why I'm sitting infront of my computer typing rants and coding. Cause there is nothing to get close to this family. I'm glad I'm say, so they will all die one day and I won't have to worry about them or even their offsprings.

All this makes me hate social interaction. Pethatic humans. Why can't there be anything more rational in their minds instead of dumping stupid shit out of there head.

Quick thought

After a quick thought about my RTTI code, I created a second version of RTTI where Object and Class merge into one class, ultimately making it possible to declare classes without any additional object wrapping. I still think it's better to give the coder working with RTTI a chance to decide if he want objects from an RTTI class with or without type ID. So I'm trying to combine both systems in a way that you can choose between two base classes, one for manual and one for automatic RTTI adding, but with compatibility between them. This isn't a problem, as you can use inheritance to let both variants have the same base class. In the I would have two types of RTTI classes - one class for manual typeID support in objects and another one for automatic typeID support. I'm not sure how to combine them with sense, I'd rather want one class for both variants but the same object instantiation for both. I know, that's logically impossible, but I hope I found a way to combine them anyway. If both are possible and just sums of there base components, there must be a way to get a proper usage.



As I said to my self before, during christmas I don't do anything that's not personal motivation. And well - waiting for presents and preparing all the glitterglammer-bimbam-jam stuff revitalized me a bit and I got into a healthy think mood that was the usual state for me before I got into this horribly work-loaded semester. And yes, I thought about extending the currently rather lousy feature set of ITK with some elements I was always interested in, but never used it due to too heavy, general overhead: Runtime Type Information (RTTI). C++ has, by default a rather annoying implementation. But to be fair, most RTTI implementation are lousy cause they span across the whole environment. Out of can interesting circumstance, I discovered that, surprisingly, wxWidgets has it's own RTTI implementation besides the C++ standard. I read a bit more about it and learned that their RTTI implementation is older than the one integrated in C++ nowadays. Some compilers still have no RTTI support, so it is quite a cool thing they did their. Only problem: it uses macros. Well, that's just bad for a toolkit like ITK which I want to code as macro-less as possible. So this fascinated me and I thought a bit here and a bit there  and it made BAM late in the night. So my own, early version of primitive RTTI was born. No, it wasn't really RTTI, but I managed to assign every class derived from a special RTTI class a unique ID with the help templates and static variables. Today I extend it far enough to support RTTI classes, objects with RTTI IDs and a cast function to cast from bases to their derivatives and derivated to their bases. There is also another cast method to cast stuff only when the object's ID matches the destination class' ID. So yes, it's effectively a fully functional RTTI implementation that doesn't require every variable to have an ID. Another cool feature, though due to the way I had to implented, is that you can add type IDs to classes but still have objects with and without RTTI ID simultaneously! I used a special wrapper class to create RTTI class objects with their IDs and a special cast function to make them compatible with each other (as long as they share the same base/inheritance branch etc). It basically maps down the C++'s internal cast verification. Quite cool that I got it done without doing so many actually ugly macro usages. In the current implementation, it's quite nice to work with I think. As I noticed that multiple inheritance doesn't work, I got a quick idea how it could work and it did. But it took me some time to realize why, tuning my brain for not less than 15 minutes to understand what weird templaty compile steps it went through. So multiple inheritance does also work, through with a different syntax than you're used for normal, non-RTTI classe. Here's how it looks it usage:

using namespace ITK::RTTI;

struct A: Class {
  void Aprint() {printf("A\n");}

struct B: Class {
  void Bprint() {printf("B\n");}

struct X: Class {
  void Xprint() {printf("X\n");}

struct C: Class {
  void Cprint() {printf("C\n");}

struct D: Class > > {
  void Dprint() {printf("D\n");}

int main() {
  Object a; printf("A a: %d\n",a.typeID());
  Object b; printf("B b: %d\n",b.typeID());
  Object c; printf("C c: %d\n",c.typeID());
  Object d; printf("D c: %d\n",d.typeID());
  Object* q = d.cast();
  if(q->typeID()==D::staticID()) printf("q points to an object of type D\n");
  if(a.typeID()==b.typeID()) printf("types A and B are equal, holy crap!\n");
  return 0;

Another surprising detail is that you can just create Object<> objects (these are objects with an RTTI ID) with non-RTTI classes. The system does completely base on templates, static members and class inheritance. So it's just a header you need to include and you can select where and on which objects you want to use and where not. And as you can see in class D, that's the way you can create multiple inheritance, but simply nesting a special, empty template class. The solution is so simple in execution but rather complex to explain in theory, I'm afraid to write the documentation for it. Well, atleast it's easy to explain how to use it. I'm happy it works. Maybe I can take now a look at more intelligent pointer structures, automatic memory address resetting etc. Some things floating in my head and popular among garbage-collected languages. One of my goals is have useful features, but only selective and not destroying the performance for code that doesn't need it. A blend of features from bytecode languages and strongly OOP-e-fied systems.

Oh, and you can of course cast down the RTTI object to it's original RTTI class while not caring about it's object ID. So as far as I can image, you can get the right objects you want in any case. Of course, handling RTTI objects and non-RTTI objects requires you differentiate their usage if you still want to access the type ID. But there's no way around it (not even in concept), they are simply two different classes, one with and one without type ID. But still, the compiler supports me to suppress backdoors he also suppresses for it's own system. Hooray for templates and inheritance!


A useful manual

I decided to take my christmas time easy and play around with things I usually can't when there's other to do. One of these things is to configure console applications I'll really use intensively. I like fiddling and testing them and I always forget to make backups of my rc files for. And well. I haven't configure nano on my current system! A shame, especially cause I always forget how well it is works like a normal GUI editor (excluding some minor things of course). And I'm still learning new things about it. It even has a file browser - did you knew that? The first source for finding out new features is of course it's manual. I should study it further while listening to good music.

GUI Libraries

As my student project continues, I see other team members having their problems with their tasks. Most notable the guy responsible for merging all components inside the GUI. He wanted to Qt, cause a lecturer mentioned it has the best documentation. It was a nice idea in the beginning, but he didn't quite understood what it means to use such a bloate libraries. The problem is that it's not only a simple GUI library, but also a strange framework for all kinds stuff, reinventing the wheel for everything. I don't say this a bad thing, as you can define everything fine within your framework. It's maybe a cool thing if you plan to develop an application in Qt only. However, Qt is bloaty and totally useless for newbie coders looking for something to develop with. I didn't watch his decisions so wisely - I payed a price, but one that's still ok to pay. At the moment, I guess I know more about Qt than he, cause I had to solve some of his code problems. I must admit, I don't like it. It reminds me of Java's concept-heavy reinvention of everything and constant tries to make some kind of "architecture" for everything. I fucking hate this term, I still see programs as a logical construction of other programs, not just concepts and design patterns, etc. So as my fellow student began to annoy me with his problems so late, I said I'm not in the mood for that shit, took a lengthy pause and started looking for a GUI library I'd like to use myself. And again, Wikipedia is a very useful ressource for more or less mature GUI libraries. I found something I already before, but never took a look at it. I'm talking about wxWidgets, as the other student also talked about it a while ago. He didn't like it, cause he "would need more code for hello world" when using it. Well, I begin to think it was a bad decision of him. I haven't yet used it, but looking at the documentation, I kind of like it's clean and direct design. Even if a couple of people say, Qt has a good documentation, I don't like it that much. I rather prefer a direct list of all classes, a simple but effective libary design with much talking about their design concepts. All necessary design ideas should be explainable in a few sentences at the beginning of a class documentation, that's it. And well, wxWidgets seems to do this quite nicely as I see. It reminds of my first tries to get a window working using Window's own API. It had a bad documentation, no classes (I didn't use any OOP back there) and weird behaviours. Then there was Purebasic limited approach and gave a simple but usable interface with relatively useful documentation. Now as I see wxWidgets, it seems to have all the nice GUI-related functions I missed from Purebasic. I guess I would've chosen wxWidgets for my fellow student's task. But well, he seems to like bloaty and talking frameworks. I rather prefer a silent agent delivering me only the necessary notes but still delivering my all essential elements for easy handling.

However, it looks good and it's documentation says everything I would've asked for. Isn't this a good sign? I rarely see something like that, so I don't see a reason to not keep it in mind. It's also interesting to know that  wxWidgets has some useful other classes, too. Multithreading, XML parsing, etc. All the other frameworks like Qt or GTK have additional stuff, too, but I don't like their Interfaces. Neither GTK's nor Qt's. But I'm still looking for a standalone multithreading library for advancing ITK during the next term break. I know I need some kind of cross platform library supporting threads in order to get my rendering concept done. I could either create a wrapper class that can be derived into a real thread management class and use it as an independent interface for my thread components. That would need some more thinkage and work. I'm not sure about it. I guess it's the best to create as many independent classes as possible and implement specialized version of them - as it's one of my design principles. 



After recovering a bit from an instant illness attack and beeing unable to produce any code, I did some tests with Oblivion's character model and it's weird how useless some things are. First of all, armor. Yes, it seems to be useless to me in this game. That's especially due to the fact that even the smallest wizard with aleast 25 points in alteration can it's personal 15% shield spell which grants a wopping 15 defense points to his already worn armor. So I can have more defense than a knight at the same level while being faster and will gain additional magical effects by my randomly chosen magical clothes. Even more, you can also wear items that also provide a shield effect, adding all shield percentages to a quite awesome resistance to almost anything that could encounter you physically. In the end I threw away all heavy armor parts (and it was already light armor) to wear robes and rings/amulets to get their much better shield bonus. And I didn't even enchant helms or so. There is just no point to wear armor in this. It costs weight points, doesn't make you better after all and you'll have to repair it. Normal clothes don't even have a condition rating, so it makes all your items indestructible. I guess you can even enchant the handcuffs from the the beginning, so you'll only need to find a weightless helm to get a perfect set of armor against every physical damage awaiting you. Furthermore, you also get massive amounts of shield potions relative early in the game - is there still ANY reason to use normale armor parts? Also, I found my self blocking more often than getting damage by direct hits. So well - my light armor was the lowest of all, cause they never really hit me.

I'm not sure what the game designers thought there, but it's definitely not as well-balanced as other, less polished games. And if you don't use a fighter race in the beginning, you can also leave swords and clubs aside - poisons do fine unless you like to face undeads more often than other enemy types. And even this can be solved by simply using enchanted weapons and a manual soul trap spell or a soul trap enchantment on the weapon. At a specific point in the game you can get a real tank this way. Almost indestructable and with so heavy damage than no enemy will be able to kill you. It makes me a bit sad that I'm realizing this after I played an archer/thief/mage combination with lots of points put into light armor and sword skills. It was totally useless in the end, It would've been better without those wasted points, you will just no them.

However, I'm tired. Let's finish for now.

Sick of games, especially first person ones

Seriously, I begin to dislike them more and more. Especially cause I'm not at the highest possible health level and get headaches when playing and/or looking at them. All these 1:1 camera motions get on my nerves rapidly. Maybe that's also due to the fact that I finally finished Oblivions' main story line which I actually never really touched before. It's a pretty bad story full of boring shit and constantly stupid monster slaying. Oblivion would be a better game without it's hilarious storyline and level progression system. In fact, I believe it's better to remove all character-related status variables and turn it into to a completely item-based advancing system. Means that you don't need to choose some stupid skills in the beginning and no level progression during acitivity execution. I think it's much much much better to make a big and freely accessible game by giving only items and skills to improve your character's possibilities. Oblivion does a lot of nice things, but also a lot of bad ones including it's main quest. In the end I simply skipped all enemies and just ran through to the end cause it doesn't make any difference to fight or not - the player/monster level adjustment does only make some damage type difference, the general fighting is always the same shit. And well, the main quest almost only consists of fighting in the end. It's ok for game as long as it doesn't offers anything else that is better. But as fighting is the most annoying part in Oblivion (I rather prefer jumping and running), I results in a rather dull experience. But it's good that I played it, so I can finally put it aside and distill the parts I like about it in a whole. I'm also wondering what the developers thought when the player will end/start the main quest. Of course, it starts with the very first moment you begin the game, I rather think about the first time you can decide to follow it or not. After I bought the game some years ago, I closed my first Oblivion with level 16 - a level that was already too high to enjoy my character. A definite problem I'm having with I'm having with Oblivion is that automatically levels you up depending on the skills you set to make you level up. I made some kind of thief mysticism hand-to-hand brawler and totally failed when facing a too fat Deadroth inside the Kvatch castle. I created several characters to test everything out, but all the skills I liked (jumping, running, mysticism, alchemy etc - all the rather "useless" skills) where just not made for fighting. So I hated the game for beeing only nice to tanks and fans or pure blends. This didn't changed so much on my second try. But still, if you don't choose skills made for fighting, you simply can't progress any further. So many quests simply consist of fighting, most not suitable for skills beyong skull mashing. Not sure whether I'm simply the wrong person for such games, but I rather like action-adventure-like progression (rather getting better items than leveling up) or a good blend between experience points and ways to through the game with all possible skills.

So yeah, this game sucks for everything story-related. I'm currently reading through some Oblivion wikis to find out what I else missed, but guess there isn't much. I knew most sidequests from my previous playthrough, so it wasn't that interesting to play this time. Typically for me, I began to use skills I didn't plan before, so this shitty level up didn't to anything for me. I think it'd be better to either give it a xp points-based system or a completely stats-independent character evolution. Maybe skill points, too. Who knows. But I'm sure they'd waste even this opportunity. I'm glad I finished this game - this gives it a "rest in peace" status while remembering the stuff liked, or better, the ideas that deviated from it.

Oh and I hate that they placed dozens of Oblivion gates but with only 7 variations in level design. That's just annoying - you closed one gate and then you need to close another that looks exactly like the one you already closed! I can understand that they used components to created their dungeons, yes, but not that they they simply copied while areas. I feel betrayed by last-minute design.


If that's not hot

I found a great way to eliminate all makefiles for rather simple C++ project structures: Simply compile it via command line using 'g++ *.cpp'. This takes all files in the current folder and compiles them. That's damn useful! I actually store all my current project files in one folder, so this elimites the usually necessary typing of filenames. Of course, it's always a full compilation. So it might be not so good for big projects. Well, atleast you can also use in makefiles as well, having more compile time than specifying it by hand of course. And you can't just make a simple backup files without giving it another extension. But well, I like simple project management and most of the time I'm, getting tired of adding new files to your project by hand. I structure everything in folders, so there doesn't seem to be any need for real project management. One problem is still persistent: having rather deep folder structures. Well, you could probably also solve this by executing 'g++ *.cpp */*.cpp' and so on. But if you really need a dozen of folders to get a clean file overview, it might be better to make a makefile instead for overall better performance...

But the wildcard solution it atm good enough for me. It's that I sometimes want a fully blown IDE but rethink it a few days later. Call it a short wave of virtual-virtual desire. The more I get typical IDE features, the sooner I don't want them anymore. It's just not as cool, you know. Plus, your CPU does stay cool without all this ressource-comsuming auto completition shit from seldomly effective alghorithms used to implement that kind of development feature. What I'd like is a mix of both features, but staying low in requirements and loose enough to take folder structures as input. So you only have a single project file where you can specify the folders it should take for compilation and it generates a makefile for all depencies on it's own. Additionally, it could also preparse the files and offer a auto completition when using gedit. So you'll have a sidepane for makefile generation and symbol browsing. To work automagically for EVERY file you've opened (and thus switching projects as you switch files), it would scan the folder of the opened file, taking the existing project file(s) there loading all preparsed symbol data. So in the end it's basically as system offering the possibility to refresh the current makefile based on the folders you gave it and a subsystem to switch auto completition depending on the currently opened file. Of course, if you want to share the same file over multiple projects, you'd need a) need to copy them here and there (ineffective) or add a possibility to choose completition based on the currently selected project. Well, maybe it's easier to make a selection of projects in a selected folder, so can have multiple projects/build variants simultaneously. And depending on the selected project, the auto completition and build would execute the associated makefile. I kind of like this idea. It's not an idea, but it's also no pure commandline compilation and no annoying makefile syntax. It's a tool to speed up the basic process you'd normally do by hand... I like it. It would give me the freedom to keep several componentcheck projects inside the same folder but still having a bigger project around sharing same files at once. That's exactly what I need for my ITK library. I have a lot of components to check, I don't want to have a single-click-to-compile-everything system cause some components maybe faulty or so. And if I don't want to develop anymore but write something else instead (like a concept for example), I can simply make a new file and the project manager simply doesn't do any auto completition since the file isn't a part of any projects.

Let's if I can actually code a gedit plugin, I'm not sure. It probably means some GTK and API work... Something I can't do at the moment. And a single command line tool? Oh come on - where'S the use if it doesn't integrate into my editor. This way I could also compile it all by hand.
I might switch between gedit and Code::Blocks depending on my mood. If I need to make bigger changes it's better to use an IDE, but as my little laptop is telling me that it tends to hard for him to keep his CPU fan down, I guess there's nothing bad about using gedit for normal code work you don't need a frigging overview machine for. It's really weird how Code::Blocks' performance behaves. I mean it can't even stop consuming too much CPU time during during idle mode. Of course, disabling some code completition features helps, but what's the point then? Where's my makefile...



there's a new design.


What a luck that I found a repository offering the newer 10.x version of Code::Blocks (Ubuntu repos only offer the simply too old 8.02 version) and all the that didn't work before does work now. That's great, plus I can FINALLY enjoy a decent development environment with all features I missed in gedit and without all the drawbacks of other IDEs. Hooray for software! No, that was weird. Ok, well. In the past I never didn't realised how lovely it is to have auto completition, especially cause I always had all the time of the world to find out function names. But since this is a highly specialized project, it's a breeze to have one. I can ctrlspace everywhere and it shows me all the stuff I'd need to know. Lovely! Always good to appreciate existing features. Well, gedit told me to work minimally, now it's time to speed this up.

Too many files

*sigh* Stuff's getting annyoing.I have so many files with even more lines that I'll need to compile my student project another way. And well, makefiles - let's say I haven't written any universal version I can use to my liking. I see were this is going. IDEs. Again. Well, atleast I found some I can use. In the end, Code::Blocks can still do the magic for me. I wasn't happy about some weird behaviours, but it's still the only IDE I used a longer time without so many complaints. So well, I need to decide. I badly need something for huge projects to keep work easier. And with work I don't mean the project, but rather the navigation between source files and program output etc. gedit is great, but for example, it can't deliver a header/source swap, no project tree, no class view etc... And as I don't have the time to keep everything universal (I hate writing highly specialized code), I'm kind of pumping new stuff everyday and get lost in how many features I actually implement. I also need to split some rather weird class construction I quickly hacked in, so I don't get bad mark cause my design followed rather C than pure OOP. Well! I need to browse some package lists...


Drop it

Nah, my previous idea of a link for such a list structure I'm using brings the same problem as storing the original structure. Only thing I could do is to create another list structure based on a list with pointers and dynamically added content. But still, that would make it possible to add the same entry multiple times and they would get deleted then... So it doesn't make sense, but it was a great operator exercise. Now I have a structure with all kinds of necessary operators! That's good to have for later experiments.

Unfortunately I'll have to write the code that used it, so I wasted a whole day of development. Annoying.


C++ operator overloading

Wikipedia is a great source for C++ operator overloading. Well, that sounds strange, but in fact, this page lists exactly what I was looking for. I wasn't able to find any complete reference to what kind of returns etc you need to get a specific operator to work like usually.

Speaking of this, I found a strange problem I strife to solve interesting and resusable. As I like to generalize stuff, I created a nonredundante list for my project, which takes a class T as template parameter and creates a member of this type in each list item. Problem, it's not a pointer, it's directly inside the item class. So if you want to append an item, you'll need to pass a complete T variable (not a pointer) to fill the item's content. And since the class is non-redundant, it compares it's items' data with the == operator. So here's the first problem: You want to pass a structures that's also pointer-heavy inside, but you don't recreate it everytime when you need to copy to the list item. Of course, why don't use a pointer as template parameter? Well, the == operator compares the pointer adresse, not it's content. So there's a problem we can't solve without some rather hacky tricks or simply by copying the whole structure all the time. As I use the class for strings which would require around three times copying with rather expensive comparison, I got the idea of some kind of pointer that free's the data it is pointing at while defining operators to compare it's own content with other class of the same type the pointer is pointing at. So we can dynamically allocate our string class, put it's adresse into this special pointer and make a list of them. We don't need to copy the whole string, only the pointer object. Plus, we can also savely clear the list and free it's content with no previous, unnecessary copying. Nice idea, eh? That solves some problems with template classes and functions, as it's often necessary to store lists with larger objects that just simple integers. I found inspiration in some older memories about early linux classes and links to files that not only delete the link to the original file, but also the orignal file itself. Reflecting which operators are listed on Wikipedia, I think one could design some interesting concepts also incorporating functions and functions pointers. I'm not exactly sure what such a thing would look like but atleast I can make a generic physical link for normal classes and structures that that just link all possible operators to the original data object. Inserted inline, it's only a simple NULL check instead of an otherwise horribly slow copy operation.

However, this solves some design problems I also had to struggle with in the past. Hooray for operator overloading!

new design

I switched to another performing better with Epiphany and returned to a simple Courier font for everything visible here. Plus a bit of dark orange, a color persistently used by one of my very first games, this one stays nice without beeing too eye candy or modern. Not really accessible. I like it.

May get a bit more contrast and brightness later. Til that it'll stay as it is.


Qt Creator

I saw the windows version of it while I was working with student from my team and it somehow caught my interest. It has a cool interface, many files opened in seperate splits, etc. It's really cool and it is fun work with it. Only problem is that you can't add any makefile except via your file managers, it doesn't know of any relative paths from the current project file etc... I already experienced enough problems with fixed paths, so this is setting me of. However, I'll leave it on my harddrive and watch what the updates will bring to me. I don't use it for Qt, so I'm limited to it's ability to understand relative pathes and makefiles. There is just no macro except $BUILDDIR, which is also a fixed path... Yes, it needs a polish this time. But if you set your paths this way and like it, it's a fucking nice development environment with builtin hex viewer, multiple files view, etc... Awesome I'd love to see in other, relative-pathing IDEs! A shame they don't allow themselves to be inspired by others development environments.


One annoying thing less


I did it! Finally the mandatory assignment is done and I can ignore OpenGL for a longer while. I must admit, I got used to it, but I still have it's state machine design. So confusing what when happens. However, the final result is quite awesome full with nice eyecandy and over-the-top useless features for such few overall requirements. Well, that shouldn't be the problem! In the next assignment someone else had to do the 3D work, but somehow he completely vanished from surface, possible beeing unable to understand even one thing they're telling us there. So it's good to have a "handy" way of making simple models as I did in the picture above. I'll set up a little post with Linux/Windows executables later, at first I need to setup a working windows compilation for OpenGL and so on... damnit, why can't these lectures choose a RIGHT operation system that supports compilation as simple as Linux? Oh well, gotcha. How stupid of me. I'll simply leave it there as Linux for my blog and give him his win exec instead. Not a real solution, but I'm soooo lazy.