Pseudo Random Journal Generator Predictable permutations on programming, technology, and more.

adam_26mar2007.plan

So lots of time passed and very little work got done.

As usual some odds and ends I thought of were tweaked and fixed as I was coding unrelated things. Then spring break came along and I didn't even see a computer for 7 days [ very nice 🙂 ] Then I came back and bought the first game I've paid for in 6 years, STALKER, which took up more time.

Anyway long story short ( too late ) I finally started coding again. Wrote the the first Input Widget implementation which is a simple button. Then went back and implemented input handling in the Windowing Service, and Window Managers which was quite a bit of work, but you can now switch which window is active and it all works nicely. I'm currently finishing hooking up the input to the actual buttons. Which will fire events to any subscribers when pressed. And that should be it for now for the Windowing sub system. It really is a truly robust system.

Later I plan on implementing a few new things:
1. Separate boarder quads to support separate boarder textures ( visual improvement )
2. Theme manager, to handle different window visuals easily.
3. Font manager, not strictly a Windowing component but closely related.
4. Resolution scaled windows and such.

But for now, once the buttons are finished, I'm going to get back to the new 3D camera system, finish that in 1 code session hopefully, then bug test and tweak for the v.6 release!

So stay tuned.

[edit]
I didn't think this warranted a whole nother .plan file so I'll just append it to this one. I finished hooking up the input to the Input Widgets, and have the first successful use of a button fireing an action, and a special action handler class responding accordingly. So it's all done! The window system is done for the moment. I kinda can't believe it. Maybe tomorrow I can get to the camera system!
[/edit]

- Adam

adam_04mar2007.plan

Well, did a bit more work over the past few days. A lot of it in planning and design, and more in C++ research.

Finalized the basic widget design and implemented a 'Label' widget which can be used to put text labels on a window. Next up is InputHandlingWidgets which are pretty much designed, just need to implement one to hash our the unforeseen nitty-gritties that always pop up. So I'm going to implement a simple button class which is actually the last GUI related class I will be implementing for this release. Also going to implement a bit of functionality in the 2D Display Graph nodes to mimic their 3D counter parts so that all nodes under a 2D translation node will share that 2D position shift. It will simplify widget management a bit.

Thats about it. I'm going to be frigging pumped when that is all done. All thats left after that is hooking up the input to the WindowManagerService which will manage active windows etc, writing the clean up code for unloading BSPs, and implementing the new Camera system.

And of course, there will be small tweaks and polishes to other things before the release. One thing for sure is I'm going to finish the stage 2 texture memory management as I have been calling it. This simply tracks how many things are using each texture, and when nothing is using a certain texture it will free the memory. The last improvement was to check if a texture had already been loaded and to not re-load it. So this is just really finishing that system.

Also been doing research concerning my performance issues and have almost certainly pegged the biggest culprit. But I have many other things to focus on at the moment so that will come after the v.6 release.

Any way I've been on a role lately getting at least something done every day, so lets hope it continues and I get a release out soon-ish!

adam_27feb2007.plan

Well this is less of a progress update on Black Engine and more of some mindless ramblings and thoughts.

Since I presented Black Engine at the end of my Independent Study it has grown by over 3,000 lines of code. So what is diffident you might ask? Nothing. At least thats what the casual observer would see. It still looks exactly the same.

Under the hood though there have been a TON of changes. From the asynchronous logger to the configuration class to the centralized texture manager. Even smaller things like a much tighter and cleaner build environment and finally a working Linux build target, the kinetic resource system was greatly improved in concept and design. More recently outward appearances have finally started to change with the GUI classes coming along. These are fairly close to completion too.

But I just read something I've been mulling over. "Perfect is the enemy of good". I've been wondering if I have been guilty of this. Obviously very little work has gotten done this month, but I have been researching the dark corners of C++ learning the language more and more intimately. And tonight when I began coding I started applying that knowledge. Going through the class hierarchy altering every class with explicit constructors and removing their default constructor I never wanted in the first place.

See, sure this is better, and in fact this is what I had wanted from the beginning but hadn't known about the explicit key word. And my code is now cleaner and tighter. But what if I had spent that time finishing the last of the GUI classes. What if all the time and love I've put into pre-existing code since the tech demo was spent on new code. Would I have my next public release done already? Probably, but who knows. Really at heart I am a perfectionist. And I try to practice a strongly iterative development approach so I actually get project finished. But I ALWAYS find my self going back and tweaking every little thing, these projects become my babies, my works of art. So maybe perfect is the enemy of good, maybe it does kill many promising projects. But I need to find a way to use my perfectionist tendencies to create exceptional projects that still actually get finished. Because, whether I like it or not. I am a perfectionist.

adam_08feb2007.plan

So. so. tired.

Trying to code but making just really stupid mistakes.

So I'm stopping for the night. But I did get quite a bit done.

The WindowManagerService used to just store and Manage Windows. Now, to provide more flexibility, The WindowManagerService is basically a wrapper that stored and manages WindowManagers. Then, WindowManagers store windows. So a lot of functionality was moved to the WindowManager and a lot was added to the WindowManagerService. The end result is very similar to what it was with a few small exceptions syntactically when creating windows. But what you get is more flexibility.

Windows and Window Managers can now be displayed and hidden which was the whole goal. Next up is layout managers, then buttons and labels.

So slowly getting there. Hopefully next time I will be a bit more with it.

Oh on a side note, I've been meaning to post about this for a while. I did my first big test of my new asynchronous logging class. Logging about 10 things per potential collier during a collision detection research test. Usually about 20 - 50 colliders per-frame, so thats between 200 and 500 write operations per-frame. The result! No noticeable frame drop! Ya, made me pretty happy 🙂 I'm beginning to use the new message levels too, but I think I'm going to make some minor modifications to that at some point.

- Adam

adam_02feb2007.plan

Ok! I have a real treat for you to night! I worked out the bugs in the code I did last nite and got my windowing API rendering!

Now keep in mind the window looks like crap because I didn't spend any time on the textures it uses, that's it. It could look like anything you want. So with out further adu, here it is.

It may not look like too much but I assure you it's a very robust API with a high level manager that makes window creation and management very easy 🙂

So whats next? I'm glad you asked!
1. Being able to hide windows
2. Multiple window managers
3. Window Themes
4. Window Layouts ( think Java style window layout managers, but simpler for now )
5. Window content ( Buttons, text labels for now )

And thats it for now for the API, once that is all done I will move on to implementing the new camera system, and then like I've said 100 times now, tweak a few things and get a release out!

Btw, totally off topic, just saw "Groundhog Day", What a freaking awesome movie!

That is all.

- Adam

adam_01feb2007.plan

Wow... that was not fun. at all.

I implemented the refactoring of the Resource base classes I talked about in the last .plan file.

It was a TOTAL bitch, affected many many files. But I took the opportunity to clean up some other code and add in Doxygen comments to most of the files I touched.

So there were a TON of tweaks along with the changes and additions I implemented. It all compiles and runs now. The scene graph is empty so it doesn't display anything, but thats intended.

I have to implement the new camera system before I can get the 3D components rendering again. That sounds like more then it is, it's really a pretty small change which will make a lot of things nicer.

I had about a month of changes that were not committed to the SVN which made me uncomfortable. So I committed all of the months changes even though it doesn't "run" persay.

Any way, with that huge task out of the way, I can get back to finishing the windowing API.

Once the windowing API is done, I have to tweak a few things and then I will do a public release!

- Adam

adam_28jan2007.plan

Uhg...

Spent many hours coding today. I began by creating what amounts to a basic Windowing API. This in it's self had a LOT to it.

But when it came time to implement it for the renderer my Scene Graph showed it's flaws.

After many hours it is clear what I have to do.

There are going to be 2 separate entities:
1) 3D Scene Graph
2) 2D Display Graph

Both with their own completely separate base classes for the nodes. This change is an important idealogical change though which will have far reaching ramifications in the rest of the framework. Right now the Resource base classes assumes the resource is a 3D concerned entity.

This will be changed. Now resource will be a more general base class, and 2 classes will derive from it, a Resource2D class and a Resource3D class. Then any entity that wants to be added to one of the graphs must derive from one of these two base classes. This will , after quite a few hours of work, simplify a lot of what is going on in the ResourceManagerService.

Lastly, A new system for cameras is going to be implemented which will resolve an long standing organization issue as well as provide for a flexible camera system.

Sigh... Wish the semester wasn't starting tomorrow. This is a very needed revamp to the Resource / Scene Graph system, but I had wanted to get something released before I got loaded down with work.

On a better note though, the WindowManagerService came out awesome! If I do say so my self, and I do 🙂 It combines several layers of complexity into simple high level functions. To create a window, all that is required is two function calls:
createWindow( window customization arguments );
displayWindow( windowId, true );

And thats it! I still have to build on top of this and add in buttons and such... But it's a great start.

So it looks like it's going to be a while till the next release, what with the semester starting and all... Oh well...

- Adam

adam_27jan2007.plan

Real quick one today, I finished the 2D base classes and got the Black Engine tag image displaying on the HUD again, with alpha blending.

Those base classes and the 2D Text base classes I did a long time ago are all that is required for my basic GUI. So now I am going to start work on the GUI service which I'm planning to have work quite a bit like a simple windowing API.

Meaning, you tell it the dimensions, location, and title of the window. Then using member functions of that base window class, you can add things to it like buttons. Really looking forward to this actually, should be fun 🙂 The other thing that will have to be accomplished along with this is having the Modes in the mode service take over control of setting the scene graph and such. This means, when you switch to the 2D GUI mode, that mode switch will automatically remove the 3D scene components from rendering, and when you push on a 3D mode it will push it's components into the scene graph. Much more dynamic way of handling things. Any way hopefully I can hammer most of this out to night and tomorrow!

- Adam