Transform Widget

I’ve been doing more work on the “3D Tool”, which I’m now calling the Transform Widget. I plugged in my picking ray code, and wrote some new code to do line segment\segment intersection testing. That allowed me to do mouse-over tests on the widget axes, and get it translating along its axes via mouse input.

I also added a 2nd dialog box that will be used for selected object properties.

I haven’t posted screens in a while because this stuff isn’t very interesting to see, but I figured I’d post one anyway. Here I have the Transform Widget, but I’m hiding the circles that represent rotation manipulators since they don’t function yet.

So like I said a few posts ago, my first goal with the editor is to get the player-start entity to be editable, and I’m making progress toward that. Once I can do that I think progress should pick up a little bit. All of this back-end work to get one object editable will carry over to most object types.

I’ve spent some time using the editor camera navigation and I’m pretty happy with it. I had made some small tweaks here and there, and I like the way it’s settled out.

What’s next is to draw bounding boxes of editable objects – namely the player start. Then create a selected object, and allow the bbox to be selected, and render it white while selected. Then do a slight refactor of the transform widget so that it can be attached to the selected object. It can already modify any “body”, so once it’s attached to the selected object, the editor is basically functioning since save-load is already up and running.

At some point I’ll also have to add orientation control to the transform widget but I can easily put that off for a while until some other things are out of the way.

I added a couple of more links to other indie projects that I’ve been following: Eldgame, and Paper Sorcerer. Check them out.

I may make another post tonight, if I can get the bbox rendering going. I have to decide if I want the game to register editable objects with a manager – much like how collision detection works – or if all engine objects automatically have editor data attached to them…

Camera Views and 3D Tool

Earlier in the week I picked up a copy of Metal Gear Solid HD for PS Vita. I ended up playing the included Metal Gear (1) more than the HD remakes. After a bit I decided that if I was going to play a retro game I might as well continue my play-through of Dragon Quest 3 that I started about a year ago. That in turn started to inspire me to work on an RPG concept that I was tossing around the last time I was playing DQ. And that, finally, led me to launch my compiler again tonight and get to work on my integrated editor.

I started thinking that I should be able to make the editor support 2D and 3D editing without specializing it, or having to maintain two separate editors. I may need to include 2D areas in a 3D game, and vice versa. I ended up hooking the up, down, and right keyboard keys to switch the camera between top, front and side view perspectives. A 2nd press in the current mode toggles back to free camera. I also lock the rotation and change the mouse manipulation along various axes appropriate to each view.

I refactored my grid rendering into a “3D Tool”. I see this as a sort of 3D multi-tool \ cursor thing. For placing certain types of objects in the world, like 2D quads I may use the tool to create a sort of virtual canvas at a particular depth.

Level Manager

I’ve been spending a lot of my free time over the last week studying Japanese. I took a break from that today to focus on some engine code.

I added a World module to the engine and added level manager and level classes to it – mostly just stubbing things out. Next, I made an XML level file with nothing but a playerStart entity. I got it to load and save, and am pulling the player position out and applying it in game. Now I can concentrate on implementing some tools in the Editor to manipulate the playerStart position.

I moved my grid rendering code over from the game to the editor and need to make some tweaks to that. Next I’m thinking I’ll write some code to render a playerStart widget, along with a generic transform widget that can be used to manipulate different types of objects in 3D space.


One of the main purposes of this dev log is to function as a personal journal of my engine development and whatever my next indie project ends up being. That’s one reason I want to post screens during these early stages – so I can look back at where I started.

For my previous two games I kept .txt worklogs that were just massive task lists that I would plan out and then add completion dates when finished. I find those pretty interesting to read now, but wish they had more detail such as screenshots and more notes. That’s the kind of detail this dev log is intended to fill in. Making it available to anyone that might find the process interesting is a nice motivating factor to keep up with it.

That being said, there’s nothing too interesting about camera navigation, so I haven’t had any screens to post in the last couple of weeks. So, I thought I’d post a shot of one of my work areas.

Here’s a shot of the rolltop desk in my dining room from a couple of Saturdays ago. This is when I was implementing my first vertex and pixel shaders.

For the last few years I’ve done all of my personal projects on a laptop. I like being able to work at different stations around the house to keep things interesting, or go off to the coffee shop downtown for a couple of hours. The impetus for this was that the development time for Wave 49 and Blastorama was about 10 months each. I developed them both on a desktop PC in the same location. I got a bit sick of being tide down and would find myself wishing i could just move to the sofa once in a while :)

Now I actually keep a backpack that I call my “Portable Game Development Studio” with everything I need – laptop, clipboard w/ paper, pencil and eraser, 360 controller, mouse, mouse pad, and a reference book that I rotate in and out of my bookshelf.

In other “news”, I changed the color scheme of the site to low contrast, and added a blogroll \ link section. I’ve been following the Wolfire Overgrowth project a lot lately and find it pretty fascinating. I purchased their games Lugaru, and the Overgrowth Alpha earlier this week. I also added a link to Positech. I’ve been following this indie dev for around 10 years, and would compare notes from time to time.

Oh yeah, was my favorite stomping grounds several years ago. It was basically a forum where a lot of people discussed 3D graphics and games programming, and would post useful info from around the web. The site shut down in 2005. I went by there earlier this week and found out that it’s been brought back to life! If you’re in to this sort of thing it’s definitely worth keeping an eye on and seeing if traffic picks up once again.

IE Camera Navigation

I think my ~2 week gaming binge is about wrapped up. I played through Dark Souls 1.5 times, then went back to Skyrim and finished the main quest line.

So back to business. Over that course of time I did get ~some~ programming in, just not enough to result in meaningful change - until today.

I finished getting the game to Integrated Editor transform syncing working properly. It wasn’t quite right before as it wasn’t extracting heading and pitch properly from the view transform. Fixed.

After that I focused on mouse and keyboard navigation. I had issues with mouse focus and it turned out to just be that my input system update call was trapped behind the paused game simulation.

Now the user presses Tilde to suspend the game and activate the IE. The IE control bar pops up. The user presses Shift to toggle camera navigation. This hides the cursor and moves the camera around the environment with WASD and mouse – standard FPS controls but without physics\collision. Scroll wheel changes elevation. Holding Middle Mouse switches movement control to the mouse for finer control than WASD allows.

When positioned in the world, the user then presses Shift again to restore the cursor, which will be used to make selections, place objects, etc.

I may try to make a video of this soon because screenshots and descriptions don’t do it much justice.

Next I’m probably going to have to cast a ray from the cursor into the 3D scene, which means adding a raycast collector to the collision system. Then I’ll use that data to create and position a Player Start object. I already have collision mesh data, and screen space to world space mapping code, but no raycast collector.

Lately at work I’ve been doing a lot of undo\redo stuff in our animation editor, and it’s really tempting to just avoid that overhead in my IE… I bet I can stub it out for now and build around it, then plug it in later if necessary.

IE Camera Syncing

For future reference I will be using IE as an abbreviation for Integrated Editor, not Internet Explorer.

I just finished getting the camera syncing to work properly when switching from the game camera to the editor camera. I had two bugs in my matrix code which were screwing up the syncing code. To sync, I pull the view transform directly from the rendering system, as I’m trying to avoid having the editor poke game data directly – at least until I get in to actual editing.

Previously I had written all of the game camera transformations in view space, and I just finished switching it to world space. This is easier for me to visualize, and I can calculate the inverse right before passing it off to the renderer.

In the graphics system I have a ”visualizer” subsystem, which manages temporary debug rendering. For example if I want draw a character’s forward vector, I would calculate a line segment and pass it in to the visualizer. I can specify a duration too, which makes neat effects of the vector ghosting out over time.

I added a transformation matrix visualizer so now I can easily pass in world space transformations to be rendered. This helped a great deal in finding the two matrix bugs. I could see that when applying an x axis rotation the y axis x component was skewing wildly. That turned out to be a small error in the matrix multiplication where w was being referenced inplace of z.

Oh yeah, I also had to write a second shader, or rather resurrect the 2nd test shader I wrote last weekend. This handles rendering the visualizer output since that system supplies vertex color. The normal world shader was processing lighting and ignoring the color data. I don’t want to have to manage materials for the visualizer primitives – they’re intended to be quick and easy to invoke.

Now I can finally get on to figuring out a good camera navigation scheme. I was going to jump right in to that, but the syncing bug was nawing at my brain.

Integrated Editor

During the week I purchased a copy of MSVC 2012 Pro, but I got sidetracked by Dark Souls PC. Yesterday I got 2012 installed, and I spent today continuing my work on an integrated editor.

I decided to try a modeless dialog box for the editor’s primary UI. I envision it working sort of like a floating ribbon control - with tabs so that plenty of tools can be hidden in a relatively small space. I got the dialog to reveal and hide itself upon pressing of the tilde key. The game simulation pauses, and the editor camera syncs the camera transform from the engine. I have quick and dirty screen-space panning working, but I’d like to do it in world space based on the depth of the object below the cursor. When the user presses tilde again the game activates again and things continue like normal. We’ll see how well that actually works once I’m modifying data.

So now that editor activation \ deactivation is working I will be concentrating on getting editor style camera navigation up and running (whatever that means), and probably light placement will be next.