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

adam_28nov2006.plan

0500 or as I like to call it. O-Dark Thirty.

Couldn't sleep so, got some coffee and a sandwich at the mobile and headed over to the labs to get some work done.

Spent the time here reorganizing the source code into separate projects.

This has resulted in a significantly cleaner build environments that I'm quite pleased with. The new organization is a follows:

- Core: Contains the Core Framework code base, what was referred to before as the Framework and Framework Services. Also the base classes that everything must inherit from.

- Extension: Contains the blocks that use the Framework to create a Simulation Engine. So these files are more apt to change. The renderer is here, the BSPManagerService is here. These are not entirely game specific, though if a certain game required new abilities the engine did not currently provide this is where they would have to be added.

- Simulation: These are the game specific Entities and Services. A game developer should be able to work mostly in this project to develop their product.

- Main: This is the platform layer that maintains the main program loop, initializing, and tying everything together. A game developer should have to make minimal changes to this project, basically just instantiating some high level things maybe.

I have a bit more work to do adding some functions to the FrameworkContainer in the Core project to allow for a bit more access to parts of the Framework now that things must be handled in a more dynamic way. But over all the conversion has gone very smoothly and what has resulted is much cleaner. Was able to eliminate quite a few antiquated files and linkers too.

Any way after a bit more work I will move onto the tech demo stuff. Been doing a lot of thinking and research about the Scene Graph too. There will be some major changes coming to that soon.

- Adam

adam_26nov2006.plan

Aaaahhhhh…. BSP traversal solved. Great lesson on MACROs learned. Text alpha blending problem diagnosed and possible solutions in the works. Entity parsing and creation from BSP files implemented. Things are going well.

I can start the technical planning of the tech demo stuff I mentioned in the last .plan now while I figure out how to handle the alpha blending issue.

But I’ve had a long time to look back on different design decisions as well as look forward to future design decisions and I have distilled two imperatives that must be addressed.

The first, and I knew this one was coming and intentionally left it till now, is how I was doing to make the engine code independent from the game code so the engine code would need no knowledge of the game code at compile time. Since this is cross platform DLLs are out of the question. So I choose to split the code into two projects. The ‘Core’ project, which will be a static link library containing all of the Engine specific code, and the ‘External’ (probably will be renamed) project which will link to and use the Core project.

The second is a product of the lack of time I had while developing this and my desire to push towards something I could show. I’ve always felt my Scene Graph implementation was the weakest point of the project. And as I have worked with it I have identified areas for improvement. In fact, the alpha blending issue with the text is a problem with the scene graph. So I have been talking to a lot of people and analyzing previous decisions and thinking about how I could improve them and I am currently working on a new conceptual design for my Scene Graph implementation. It actually won’t require major code changes, but conceptually it will be pretty different.

The first of these issues I do hope to address before my dead line (which is in 3 weeks!) but the second will probably come after.

So what is next? I will probably hack in some sort of fix for the alpha blending problem in the scene graph for now since I am pressed for time and it will probably change anyway. And the next big thing is, as talked about before, a basic GUI class and re-loading of BSP files.

So before I go, here is a screen of my very simply level which I use for BSP leaf testing.
You can see the hideous Alpha Blending issue on the text, and the green block in the bottom left is a place holder for the Black Engine logo.

- Adam

adam_24nov2006.plan

So it's been a while since the last update. Work was a bit spotty for more then a week but some work was accomplished.

It's hard to remember all of the little things, tweaks, minor bug fixes, that get accomplished while working on larger systems but rest assured there has been quite a bit of work done.

I have put in two very long coding stints (12+ hours) in the last two days and plan on at least two more for the weekend. I finished adapting my old rendering and loading code into the framework and SDL. There is a small bug with the BSP tree traversal that seems to have to do with some sort of precession error but I don't think it will take long to squash. I also need to re-implement my Entity loading code which should only consist of uncommenting a few lines and changing 2 other lines.

Once I feel the code is bullet proof enough I am going to move onto creating the tech demo I will present in 3 weeks to the CS Dept.

For the tech demo, at a bare minimum I plan on having a basic GUI that loads when the engine loads. From here you can select a BSP file to load or to exit the program. When you select a BSP file, it will load with a loading screen, then obviously you will be able to move around in the 3D BSP world. You can hit ESC at any time and it will bring you back to the GUI and you can load a new BSP file or exit if you choose.

There are only two real tasks here. One is creating the simple GUI system which is certainly non-trivial if I plan on it being a solid base for future more robust GUI systems. And two, and this sounds like I'm a bad coder for not already having this, but make the BSPManagerService able to clean up after it's self, so when you load a new BSP file it unloads all the data from the current BSP file.

There are several other things I would have liked to implement, like gravity and collision detection, but gravity can't be implemented with out collision detection, and collision detection is just too much for the time I have left.

If I did get all that done for the tech demo and had time to spare I'd like to do something with interacting with some sort of object in the world. Maybe just pick up and dropping a box or something. Who knows, we'll see.

- Adam

adam_11nov2006.plan

The movement physics under went another rewrite a little while ago bringing them to what will be the final version functionality wise for the semester since there is much more to be done. That being said they improved a great deal in both concept and implementation and now, in my opinion work better then the movement in Half-Life.

I say this because the Half-Life engine suffers from the problem of compounding simultaneous multidimensional movement requests. Meaning, if your Resource has a movement speed defined as say 10 and you hold both the forward and side strafe keys at the same time to move at a 45 degree angle in Half-Life it would take the first input, and add 10 to the Y component of the movement vector. Then it would process the side strafe input and add 10 to the X component of the movement vector. The resulting vector would have a magnitude of ~14.142 units. Which in my mind, if you define 10 as the speed for something in your world then that should be the speed no if ands or buts. So in my code I accumulate all the input, then based on the input I modify the angle not the magnitude of the resulting vector so no matter how you move the magnitude of the vector will be 10. Actually saves some computation as well.

Additionally, I’ve spent time adapting my BSP loading and rendering code into the Framework these last couple days. This is going well and actually a bit faster then I expected. The BSPManagerServices now successfully loads in a v30 BSP file. There is quite a bit of a paradigm shift in how the data is rendered though which took some thinking through to come up with the new methods needed. The renderer is almost done ( Still writing functions to give it efficient access to the geometric data loaded from the BSP file ). Once I finish that I need to write some functions for the SimulationResourceManagerService which will locate each Resource it manages in a Leaf of the BSP tree when ever they move and dynamically attach them to the BSPLeafNodes as they move around. That should be it then. The new Framework should be caught up to where the old engine was before this semester started.

So exciting things to come as I move into some of the less essential things like config files (finally!) and collision detection!

- Adam

adam_02nov2006.plan

The movement system has undergone some more changes due to mouse look and my Trig knowledge has been put to the test working with the angles generated from mouse look. Mouse look, side strafing, friction, Velocity Read out, and World Coordinate tracking are all working.

The current movement code for the camera does not allow for side strafing and forward/back movement at the same time though which is pretty important. Also there is some mixing of what code should be in the Resource class and what should be in the User class. So those two things need to be sorted out.

But I think I am going to move onto geometry loading and get back to them since neither is essential at this point. In fact, though it would be crappy, I could leave the current movement code not allowing simultaneous movement in different dimensions as is. Of course when I turn this into a product that will have to change. But I really need to get moving along with this. So the geometry loading and rendering code must be adapted now.

- Adam

adam_31oct2006.plan

Well as is to be expected after developing a system as complex and important as the movement physics system I spent some time analyzing it and created a much more concise, efficient, system.

So the movement physics have already undergone a major revision which now easily incorporates friction. I have to implement a Velocity read out so I can ensure the friction is making the user maintain a constant speed. After then I will implement world coordinate tracking (not hard). And then Mouse Look. That should round out the beginnings of not only a solid base for the movement system but a solid beginning of an FPS style camera.

Then of course comes the adaptation of the Geometry loading and rendering code.

I also spent several hours today reading articles and forum posts on source code optimization and found many techniques I will need to learn more about and go through and refractor much of my code with after running gprof. I was starting to get very worried about performance, my frames had started to dip to the low 500s with the old movement system, but with the new revision we are back steadily above 600 while moving.

Very exciting to have that working 🙂

- Adam

adam_25oct2006.plan

Work progresses slowly when you are burnt out. But I struggled through my mental fog tonight and managed to work out some new concepts for how things should work as well as lay down a quite a few lines of code.

But with just over a month left before finals Im starting to wonder about what can realistically be accomplished before the deadline. So tonight Im going to review what has been done and what is left to be done.

So far the following has been accomplished:

• Platform layer implemented with SDL
• OpenGL integration
• Cross platform OpenGL text
• Majority of the Framework Services implemented
• AutonomousActionService
• ElementManagerService
• EventRelayService
• ModeService
• SimulationResourceManagerService
• TimeService
• Framework Base classes govern and simplify the interaction between everything inside the framework

Along with all of the Framework progress some progress has been made towards the Simulation implementation such as implementation specific Entities. As of right now it is possible to load the Engine, move around in the empty world ( The green grid is there ).

This doesn’t sound very grand but a good example of the hard work on the Framework paying off is the FPS counter. With all the base classes all that was necessary to implement this was to inherit from the Text2d Class and over ride the getString() method of the Text2d class with a function that would query the TimeService and use the information appropriately.

What is left to do? Well to night a lot of work was put into the movement physics portion ( Which has generated the first Element Service as opposed to a Framework Service, The KineticElementManagerService ) which required a new portion of the Framework to be created. The Autonomous Action Service which allows Elements to perform actions without any user input initiating those actions.

The movement physics will not require too much more work to finish, and this will easily allow for pseudo physics such as friction and gravity. In fact, it necessitates them.

Any way after that I will have to adapt my old geometry loading and rendering code into the framework. This. Will take. A lot. Of time. In the process of adapting the loading and rendering code I am going to finish implementing the light map loading and rendering code that is partially implemented in my old engine so it actually looks decent.

This whole process Im allotting a month for. So assuming I finish the movement physics this week, that will give me only about two weeks at the end of the semester to work on some sort of tech demo of the engine and it’s abilities.

Oh man…

- Adam

adam_19oct2006.plan

The last couple days of coding are very much a blur. Its hard to remember exactly what I touched. But after a ton of very hard work where very little visible progress was getting accomplished I have two major break throughs.

The first seems minor but was really a very VERY time consuming thing. I finally have cross platform text rending. The second is I now have user controlled movement of the camera.

The latter probably doesn’t even sound that trite but its even more complex then one might anticipate because while I had the timid beginnings of the event system in place already the entire concept and implementation of the system matured GREATLY over the past few days and there is now a solid base which will be built off of rather then the flimsy concepts from before that had to change as new things were needed.

The input controlled camera movement is in its very early stages and this part is going to require a lot of attention to get right since the systems that affect its movement are the systems that affect all movement in the 3D world.

Lastly I implemented the changes to my Logging that I mentioned in the last .plan. While its not a huge thing it is sssoooo nice for development let me tell you.

Any way this is going to be a short one for the same reason Im not posting another screen shot of the state of things. Because Im freaking exhausted. And I seem to be getting sicker and sicker no matter what I do. Aannnyyy ways... Several large strides forward but so many more to go...

- A very tired Adam