Wednesday Wins

Cracked FPSC Classic

Finally solved the riddle of the mysterious attaching window. The code was indeed in the DBP engine, with a special INI file that accompanies the mapeditor.exe which tells it to assume the role of child window to any window called Editor. It's a little crude given that other software could be running with such a common name, but nothing was reported along these lines for seven years so I think we are safe.

Next Reloaded Steps

Now I have the window detached when I click Test Level, the fun has only just started. For one, the window re-creates the DirectX interfaces which means all video memory is wiped (so the new window is white) and for some reason the GUI still seems to be able to capture the rendering even though a new window has appeared, and further it seems that the input is now being taken from the new detached window but channelled into the GUI child render. Very odd.


Just Captured Keyboard

Using SetFocus(hwnd) on the newly created separate window, I have captured the key strokes from the window and they are being detected in the app (being rendered in the child view still) but they are not being translated into any sort of movement. Grr. I will leave that to one side as I still need to get the basics up and running which is (a) click to full view (b) rotate and move (c) escape back into map editor mode.

Ongoing Development

It is now 11:30PM and I did decide to spend more time on Reloaded today and the night is relatively young. I have lots of tea bag and coffee, not too tired and not too many distractions from the ether, so will continue. If I can get the above (a,b,c) done this night, all will be well in the world of Reloaded.


23:40 Moved The Render Target

By calling SetDisplayMode just after decoupling the window, I was able to move the rendering to the new window. I suspect DirectX was still funnelling the 3D rendering to the last known window handle (the GUI child area). Sure, the render is now just a blue backdrop with some yellow debug text, but after recreating all DirectX devices that is exactly what I expected to see. I can also confirm all inputs are intact too. Further, the GUI hums along happily in the background with no sign of crashing, even after I stole it's child window. Next will be to load in the assets that where lost in the device recreation. One initial concern is with the entire asset set being wiped from video memory, would this mean I have to reload everything again? Right now certainly, but if this remains unchanged I will be back where I started, having to load everything in again.  The solution might be to avoid calling SetDisplayMode and just use those bits of code that where responsible for re-purposing the DirectX render output to the new window.  We will see. 


00:55 Can bounce back and forth (once)

I have improved the code so that instead of wiping everything out, I just recreate the DirectX device only. This means most of the assets are retained in theory (all objects, loaded images, e.t.c.). Sure, the screen is completely black and it only works with a level than consists of floor, but I can click Test Level and come back into the GUI without crashing. A good start. The next challenge is to get something other than a black screen, which I suspect is because the video memory was wiped out but the rest of the engine was not informed.  I might even do some Googling to see if I can just update the HWND elements rather than recreate the whole device which seems a little extreme. The less impact I can achieve when entering test mode will mean less to do on the way back out, and of course it makes the transition between the two much quicker which is what we all want.

00:59 Quick News Flash

The judges for the Ultimate Coder Challenge have weighed in with their judgements for week one. Admittedly I have not given them a target to throw tomatoes at yet, but plenty of time for that. Right now here is the link: http://software.intel.com/en-us/ultimatecoder2#meetthej


01:22 Brain Toggle

I was just blasting through how to change the HWND used to create the DirectX device, which I am pretty sure now looking at the commands and doing some Google research that such a thing is not possible. It then occurred that all the work done so far might not have been necessary. The goal is to get the input from DirectX to the window and to make it full screen. Perhaps instead of using a new window and swapping back and forward, what if I use the existing window which is already set up with rendering and just add code to send the input to the window, and I can solve the full screen later by moving the GUI areas around.  It means avoiding the messy DirectX switch, and the memory recreation and the headache of another window to deal with later on, and who knows what else.  I have restored the source code to regular operations and will not proceed on the lane of getting the full keyboard and mouse movement directly into the app.  Before we used file maps to communicate the data from the GUI to the window, but I need full direct high speed access to the actual data via the app, so I will proceed on those lines of enquiry.


02:24 Breakthrough

Yes indeed, I am glad I switched tracks. It was the right decision. I found out that I can change the DirectInput Co-Operative level to BACKGROUND which means it will take the input no matter what window is in focus. As I will be making the view full screen it does not matter too much in this case, so I have added two internal commands to the DBP command set which will make this state change and allow my keyboard and mouse data to enter the window. Sure, even though my keys are being detected the player is not actually trudging through my level yet, but that's by the by right now. I have my direct input data. I think I will forgo the need to make it full screen just yet as that is the messy and muddy world of BCG GUI and I am not brave enough to go there this evening.  Instead I am going to get my player running and jumping around the editor level, just for kicks!


03:11 Done The Bis

You better believe it. My player now runs around, all be it with no jump and no collision, but I can jump in and out of my amazing floor scene as many times as I like. No crashing, no silly flickering, perfectly fast input system (too fast at the moment in fact).  I am going to quit while I am ahead. The next step will be to make it truly full screen by shifting the left panel, status bar and top bars out of the way to only show the child window view, which I think with a fresh start will be straight forward.  Once I have that, it will 'appear' like the Build Game is completely instantaneous. That is, until you start playing the level, though I am not concerned about that too much at this stage. Once we are full screen, I will make inroads on the real time light mapping which will mean opening up DarkLIGHTS source code and having a good old rummage!

Signing Off

Sorry for the long blog but I thought I would keep a running dialog to show the kind of process a developer might go through to achieve what on the face of it seems like a five minute job.  Now multiply that by fifty thousand and you have a rough idea what indie games development can be like. Until Thursday, when we do it all over again!