Long Day Short Blog
Brain slowly turning to much with these long double days, but getting there at remarkable speed.
Signing Off
I said it would be short :) Join me next week when we crash dive into Reloaded and get real time lighting within the editor...fun stuff!
Thursday, 28 February 2013
Wednesday, 27 February 2013
Wednesday Overdrive
Plenty Of Wins
I can report the crunch week is going well, lots AND LOTS of bugs being knocked on the head and on schedule to be done for Friday. Had little bits of time between compiles, builds and uploads to answer some key emails.
I removed some code from FPSC V120 which caused a catastrophic crash on Windows 8, and will release next week to the community. Hopefully it does not substitute the fix with another issue :) We will see.
Signing Off
As will be the style this week, keeping my blog brief so you know I am using every minute I have in the day to crack on with my crunch work.
I can report the crunch week is going well, lots AND LOTS of bugs being knocked on the head and on schedule to be done for Friday. Had little bits of time between compiles, builds and uploads to answer some key emails.
I removed some code from FPSC V120 which caused a catastrophic crash on Windows 8, and will release next week to the community. Hopefully it does not substitute the fix with another issue :) We will see.
Signing Off
As will be the style this week, keeping my blog brief so you know I am using every minute I have in the day to crack on with my crunch work.
Tuesday, 26 February 2013
Tuesday Flash Update
Quick Blog
Possibly my shortest blog this year. AGK App crunch day went well, looking forward to another action packed day Wednesday.
Signing Off
Had a Google Hangout with some of the other Ultimate Coder Challengers today, so that should be hitting the net soon. The End.
Possibly my shortest blog this year. AGK App crunch day went well, looking forward to another action packed day Wednesday.
Signing Off
Had a Google Hangout with some of the other Ultimate Coder Challengers today, so that should be hitting the net soon. The End.
Monday, 25 February 2013
Monday Meeting
Monthly Meet-Up
Most of the time I work in my little Welsh cave coding, blogging and emailing my little fingers away, but today I trekked across hills and dales to meet up with real people for an actual meeting. Discussed lots of things and made some good progress on many battle fronts.
Whilst continuing our meeting over a pub lunch, we captured a photo of a mysterious stranger who sometimes passes through those parts. They simply call him 'The Bug Hunter' aka 'That Fat Git'.
Crunch Week
One of the decisions we came to is that there is not enough work being done on Reloaded, and although we are only about 10 days behind schedule it's a very slippery slope and we want to nip it in the bud now. To this end, starting Tuesday and for the next four days I am entering what is disdainfully known in the industry as crunch mode. Essentially forced labour of coders until the deed is done, which in my case is two apps that need finishing immediately.
I have the support of the whole team to help me in this, and together with help from the publisher involved, we should make lots of progress. I've just returned from a three hour drive and in the last three days have clocked only 16 hours sleep so I'm firing on all thrusters right now, but the PC is on and emails and tasks await, so thus begins Crunch Week.
Signing Off
My blogs this week will be a little thinner so I can put myself in full focus mode, and only pop in to provide any broad stroke news. My second Ultimate Coder Challenge blog was posted earlier on, so that should appear in the Intel website(s) soon. I have also made a duplicate of the blog on my side as well which acts as a good back-up and I personally prefer the editing features of the Google Blogger.
If the plans works, starting Monday next, I will be on 95% Reloaded with no AGK apps to distract. If anything else is required on those apps, the work will be delegated outward. As this is not ideal, the plan is to get it right first time and have two apps ready for submission on Friday. Time to start knocking tennis balls over the net :)
Most of the time I work in my little Welsh cave coding, blogging and emailing my little fingers away, but today I trekked across hills and dales to meet up with real people for an actual meeting. Discussed lots of things and made some good progress on many battle fronts.
Whilst continuing our meeting over a pub lunch, we captured a photo of a mysterious stranger who sometimes passes through those parts. They simply call him 'The Bug Hunter' aka 'That Fat Git'.
Crunch Week
One of the decisions we came to is that there is not enough work being done on Reloaded, and although we are only about 10 days behind schedule it's a very slippery slope and we want to nip it in the bud now. To this end, starting Tuesday and for the next four days I am entering what is disdainfully known in the industry as crunch mode. Essentially forced labour of coders until the deed is done, which in my case is two apps that need finishing immediately.
I have the support of the whole team to help me in this, and together with help from the publisher involved, we should make lots of progress. I've just returned from a three hour drive and in the last three days have clocked only 16 hours sleep so I'm firing on all thrusters right now, but the PC is on and emails and tasks await, so thus begins Crunch Week.
Signing Off
My blogs this week will be a little thinner so I can put myself in full focus mode, and only pop in to provide any broad stroke news. My second Ultimate Coder Challenge blog was posted earlier on, so that should appear in the Intel website(s) soon. I have also made a duplicate of the blog on my side as well which acts as a good back-up and I personally prefer the editing features of the Google Blogger.
If the plans works, starting Monday next, I will be on 95% Reloaded with no AGK apps to distract. If anything else is required on those apps, the work will be delegated outward. As this is not ideal, the plan is to get it right first time and have two apps ready for submission on Friday. Time to start knocking tennis balls over the net :)
Friday, 22 February 2013
Friday Frenzy
Where To Begin
I started the day with a simple mission. Get everything I needed done for the end of this day, as the weekend I am back on the road to Wigan. Technically I have Saturday morning too, but I can see that being spent snoring my head off until the last possible moment.
My missions where thus; to finish builds of my AGK apps, make Reloaded look functional and pretty for a meeting on Monday and get a little bit of Perceptual done in leu of a disrupted weekend. No pressure.
Where To End
You can also throw into this builds of other projects, quite a barrage of emails that seemed to have clogged up my inbox and prepare all the things I will need for when I leave the office. As my trip to Wigan passes Manchester, and I need to be in Manchester on Monday, I had the thought of sticking around in Wigan and just drive to Manchester from there on Monday morning. If that is the case I need EVERYTHING in a bag Saturday morning.
Mission A Complete
I can report that my two AGK missions are somewhat complete. I got a rush of new graphics in, and apart from four assets they are all now integrated, all be it a little disjointed. I gave this part to midnight, but it looked pretty ropey at that point so I have it another hour and it looks better now. Not perfect by any means with lots of little GUI tweaks, but definitely a model of the new graphics style and functionality.
I will need to build the iOS deployment packages for them, which will take another 30 minutes, but then I can move onto the second mission; Reloaded or Perceptual.
30 Minutes Later
Well maybe not thirty minutes. One of the gripes I have with AGK, and it is something I am hopeful to remedy during 2013 is the lag between the latest AGK Player source code (interpreter) and any older private projects you have created based on an earlier version of those files. You have to intrinsically know which files and project settings have been changed which is causing your project to suddenly fail. It is perhaps not too bad for AGK full version users with a solid release version, but when you are working on AGK as the sand shifts, it presents a whole bunch of challenges to work with. It is something you get used to. Getting very close now, I have my Windows builds, just making the iOS builds now and then a nice cup of tea and onwards to the next sortie.
01:33 Mission One Complete
Okay folks, those builds are uploading, completely untested you understand, but I think the universe wants me bashing out code not plodding through apps and making notes. More importantly, if I find bugs I might just step and fix them which means I will not get on. Time to get on.
I have decided my cup of tea will be accompanied with two hours of Perceptual work. That is, get the depth sample I modified last night and move it to a DBP module which will produce a 3D object from the data. Fortunately the Intel PerC SDK provided good core sample code which is all I need. I am going to leave the higher level stuff for others to enjoy, and maybe dip into it later, but I like to work with raw stuff. Raw stuff is usually the fastest, and just like clay, you can pretty much mould it into a unique shape no matter what you do. When you tap higher level stuff, your results are usually variations on a theme and share a striking resemblance to everybody else's efforts using the same high level accesses.
First job of course, make a cup of tea!
01:48 Dug Out A DBP Module and Cuppa
I have decided for the sake of expedience to 'graft' the PerC stuff onto the Basic3D module, the central 3D command set of DBP. I know it's hacky and not very responsible, but there is method to the madness. I have moved the latest code base over to a new project area and updated it to use VS2010. The legacy DBP is VS2009 and currently open sourced for modder access.
I will be able to publicly share my modifications through Google Code when I have finished my PerC stuff so other DBP users can benefit from it. It also means the contaminating code does not affect the new VS2010 build of the modules which I intend to overhaul before starting into the guts of DBP for Reloaded development.
Essentially, I can have my cake and eat it. A phrase I never understood until someone suggested the proper way to say it was 'eat my cake and have it', which for a coder makes much more sense.
02:44 Two New Commands and a Blob
I've created the first of what may be many DBP apps for this project, and added two new hacky commands called MAKE OBJECT PERCBLOB and UPDATE OBJECT PERCBLOB. I have added code into the module to create and modify the vertices of a basic sphere so I can see this on screen.
Now I know everything is running fine and I can see the 3D, and manipulate it, I just have to replace the mesh form with something that represents the depth data in some reasonable way. It means if anything goes wrong, it's nothing to do with my 3D, just the data and the code that finds the data. Clever huh!
02:58 Ambitious Way
I was just about to create a basic vertices only grid then realised later on I would have to change four vertices for every coordinate in the depth buffer that changed. It is times like this that you realise taking the slightly longer route during early development will save headaches later. Going to use an index buffer and keep it to one vertex per depth reading, which will make a smaller footprint for the 3D object and make changing it MUCH easier.
03:16 Who'd Be A Programmer
It turns out 320x240 grid and six indices per face works out at over 400K in size, and a 16-bit indices buffer has a maximum size of 65535. The current DBP uses WORD index values (designed many moons ago when WORDs where faster and more memory efficient than gorging on 32-bit index buffers). The natural step is to go back to vertex only where I can have a very large mesh. That said, I don't think I will need (or want) to use the entire 320x240 depth area for the final 3D object (unless the subject is extremely fat and wide). As I am both, if I can squeeze myself into a single indice buffer it should be good for most users. I can have 10,922 faces, which works out at roughly 45x40 capture area which is okay to start with. If I had more time, I would just bite the bullet and step up to DirectX 11 and get mucky with tessellation and geometry shading tricks but I don't have the luxury of time here. I will proceed with my little 45x40 grid and basically detect the best place to grab the depth data from as it's probably not far from the actual area I am interested in.
03:29 Smug Mode Times Two
I adjusted the size and my entire vertex+index construction code compiled and ran first time perfectly (almost). When I ran the app there was no 3D object. Thanks to the fact I added a CONTROL CAMERA WITH ARROWKEYS to my DBP program, I was able to go for a short walk to view the other side of my object. And presto, there it was. The face culling winding order was reversed, that's all. I could have been hammering at that for ages wondering where my 3D went, but after over ten years of messing with 3D graphics I know that old chestnut!
03:44 Make Short Video
I've just made a short video of the current state of the DBP app, with the wibbly wobbly 3D grid, ready to have depth data added onto it. This is a tense moment as I will be adding lots of new headers and dependencies from the SDK sample code, and many wonderfully bad things can happen. Fingers crossed, except mine as I need them for typing.
04:24 HOT TIP : Warning For PerC SDK C++ Users
Been banging my head against a wall wondering why my cut and paste code is not linking properly, and decided to trace the decorated name it was creating with that used by the Perc SDK Util Library. Turns out you cannot use a project that switches off wchar_t as a unique type as this confuses the linker. This option can be changed under "Project Properties>C/C++/Language/Treat WChar_t as Builtin type", it can also be changed via the "/Zc" option.
07:13 Way Too Much Fun
I just want to report that I became absorbed with the 3D version of myself. Once I got the basic representation of depth working in 3D, I just kept going. Adding normalisation, averaging vertices, tweaking depth scope and scale, all sorts of tweaks. Have to stop though as I need to produce a blog video and also my third mission. To accommodate I have decided not to sleep and catch a few hours just before setting off later on Saturday afternoon. My first DBP prototype for PerC is done, hurray, and you will learn all about it if you skip over to the Ultimate Coder Challenge II blog on Monday night. Here is the link: http://ultimatecoderchallenge.blogspot.co.uk/
Signing Off
Technically I am not signing off but carrying on, but this blog is already too long for one day and I will have nothing to write about in my other blog ( to be authored in about 30 minutes after a quick video. For a laugh, the video will show me somewhat sleep deprived so worth a watch for the dribble I am probably going to ramble about.
I started the day with a simple mission. Get everything I needed done for the end of this day, as the weekend I am back on the road to Wigan. Technically I have Saturday morning too, but I can see that being spent snoring my head off until the last possible moment.
My missions where thus; to finish builds of my AGK apps, make Reloaded look functional and pretty for a meeting on Monday and get a little bit of Perceptual done in leu of a disrupted weekend. No pressure.
Where To End
You can also throw into this builds of other projects, quite a barrage of emails that seemed to have clogged up my inbox and prepare all the things I will need for when I leave the office. As my trip to Wigan passes Manchester, and I need to be in Manchester on Monday, I had the thought of sticking around in Wigan and just drive to Manchester from there on Monday morning. If that is the case I need EVERYTHING in a bag Saturday morning.
Mission A Complete
I can report that my two AGK missions are somewhat complete. I got a rush of new graphics in, and apart from four assets they are all now integrated, all be it a little disjointed. I gave this part to midnight, but it looked pretty ropey at that point so I have it another hour and it looks better now. Not perfect by any means with lots of little GUI tweaks, but definitely a model of the new graphics style and functionality.
I will need to build the iOS deployment packages for them, which will take another 30 minutes, but then I can move onto the second mission; Reloaded or Perceptual.
30 Minutes Later
Well maybe not thirty minutes. One of the gripes I have with AGK, and it is something I am hopeful to remedy during 2013 is the lag between the latest AGK Player source code (interpreter) and any older private projects you have created based on an earlier version of those files. You have to intrinsically know which files and project settings have been changed which is causing your project to suddenly fail. It is perhaps not too bad for AGK full version users with a solid release version, but when you are working on AGK as the sand shifts, it presents a whole bunch of challenges to work with. It is something you get used to. Getting very close now, I have my Windows builds, just making the iOS builds now and then a nice cup of tea and onwards to the next sortie.
01:33 Mission One Complete
Okay folks, those builds are uploading, completely untested you understand, but I think the universe wants me bashing out code not plodding through apps and making notes. More importantly, if I find bugs I might just step and fix them which means I will not get on. Time to get on.
I have decided my cup of tea will be accompanied with two hours of Perceptual work. That is, get the depth sample I modified last night and move it to a DBP module which will produce a 3D object from the data. Fortunately the Intel PerC SDK provided good core sample code which is all I need. I am going to leave the higher level stuff for others to enjoy, and maybe dip into it later, but I like to work with raw stuff. Raw stuff is usually the fastest, and just like clay, you can pretty much mould it into a unique shape no matter what you do. When you tap higher level stuff, your results are usually variations on a theme and share a striking resemblance to everybody else's efforts using the same high level accesses.
First job of course, make a cup of tea!
01:48 Dug Out A DBP Module and Cuppa
I have decided for the sake of expedience to 'graft' the PerC stuff onto the Basic3D module, the central 3D command set of DBP. I know it's hacky and not very responsible, but there is method to the madness. I have moved the latest code base over to a new project area and updated it to use VS2010. The legacy DBP is VS2009 and currently open sourced for modder access.
I will be able to publicly share my modifications through Google Code when I have finished my PerC stuff so other DBP users can benefit from it. It also means the contaminating code does not affect the new VS2010 build of the modules which I intend to overhaul before starting into the guts of DBP for Reloaded development.
Essentially, I can have my cake and eat it. A phrase I never understood until someone suggested the proper way to say it was 'eat my cake and have it', which for a coder makes much more sense.
02:44 Two New Commands and a Blob
I've created the first of what may be many DBP apps for this project, and added two new hacky commands called MAKE OBJECT PERCBLOB and UPDATE OBJECT PERCBLOB. I have added code into the module to create and modify the vertices of a basic sphere so I can see this on screen.
Now I know everything is running fine and I can see the 3D, and manipulate it, I just have to replace the mesh form with something that represents the depth data in some reasonable way. It means if anything goes wrong, it's nothing to do with my 3D, just the data and the code that finds the data. Clever huh!
02:58 Ambitious Way
I was just about to create a basic vertices only grid then realised later on I would have to change four vertices for every coordinate in the depth buffer that changed. It is times like this that you realise taking the slightly longer route during early development will save headaches later. Going to use an index buffer and keep it to one vertex per depth reading, which will make a smaller footprint for the 3D object and make changing it MUCH easier.
03:16 Who'd Be A Programmer
It turns out 320x240 grid and six indices per face works out at over 400K in size, and a 16-bit indices buffer has a maximum size of 65535. The current DBP uses WORD index values (designed many moons ago when WORDs where faster and more memory efficient than gorging on 32-bit index buffers). The natural step is to go back to vertex only where I can have a very large mesh. That said, I don't think I will need (or want) to use the entire 320x240 depth area for the final 3D object (unless the subject is extremely fat and wide). As I am both, if I can squeeze myself into a single indice buffer it should be good for most users. I can have 10,922 faces, which works out at roughly 45x40 capture area which is okay to start with. If I had more time, I would just bite the bullet and step up to DirectX 11 and get mucky with tessellation and geometry shading tricks but I don't have the luxury of time here. I will proceed with my little 45x40 grid and basically detect the best place to grab the depth data from as it's probably not far from the actual area I am interested in.
03:29 Smug Mode Times Two
I adjusted the size and my entire vertex+index construction code compiled and ran first time perfectly (almost). When I ran the app there was no 3D object. Thanks to the fact I added a CONTROL CAMERA WITH ARROWKEYS to my DBP program, I was able to go for a short walk to view the other side of my object. And presto, there it was. The face culling winding order was reversed, that's all. I could have been hammering at that for ages wondering where my 3D went, but after over ten years of messing with 3D graphics I know that old chestnut!
03:44 Make Short Video
I've just made a short video of the current state of the DBP app, with the wibbly wobbly 3D grid, ready to have depth data added onto it. This is a tense moment as I will be adding lots of new headers and dependencies from the SDK sample code, and many wonderfully bad things can happen. Fingers crossed, except mine as I need them for typing.
04:24 HOT TIP : Warning For PerC SDK C++ Users
Been banging my head against a wall wondering why my cut and paste code is not linking properly, and decided to trace the decorated name it was creating with that used by the Perc SDK Util Library. Turns out you cannot use a project that switches off wchar_t as a unique type as this confuses the linker. This option can be changed under "Project Properties>C/C++/Language/Treat WChar_t as Builtin type", it can also be changed via the "/Zc" option.
07:13 Way Too Much Fun
I just want to report that I became absorbed with the 3D version of myself. Once I got the basic representation of depth working in 3D, I just kept going. Adding normalisation, averaging vertices, tweaking depth scope and scale, all sorts of tweaks. Have to stop though as I need to produce a blog video and also my third mission. To accommodate I have decided not to sleep and catch a few hours just before setting off later on Saturday afternoon. My first DBP prototype for PerC is done, hurray, and you will learn all about it if you skip over to the Ultimate Coder Challenge II blog on Monday night. Here is the link: http://ultimatecoderchallenge.blogspot.co.uk/
Signing Off
Technically I am not signing off but carrying on, but this blog is already too long for one day and I will have nothing to write about in my other blog ( to be authored in about 30 minutes after a quick video. For a laugh, the video will show me somewhat sleep deprived so worth a watch for the dribble I am probably going to ramble about.
Thursday, 21 February 2013
Thursday Thrust
On A Mission
Once I had the bits and bobs out my way, AGK project tweaks, builds, emails and other distractions, my aim was to get right back on the Reloaded saddle and continue riding. And that's what is happening now...
Reloaded Full Screen
I will continue the blog format of adding bits to it as I go this evening, as it worked quite well last night and I got a lot of details out the door. I left off looking at a working Test level button with input, but not in a full screen view. Today is about exploring BCG (an old version) and figuring out how to make my MDI child window take up the whole view. I don't need to separate it from the parent, I just want it to take over the title bar, windows task bar, everything basically. Ideally I don't want to hide and move almost ALL the visible sub-windows of the app to achieve this, I'd prefer to just move the child window to fill each corner of the desktop, but life is never that simple and to be fair, child windows where not designed for that.
I just tried an hour of hacking in all sorts of reasonably looking commands but they just resulted in strange window views or crashes. I will read through the BCG documentation and also trace through the app to see exactly how the GUI was assembled, then I will have a much better idea where to go in and what to change. If time, I also plan to add real time light mapping to the editor system and throw away the old object rendering system and use a whole new one which will support rendering the entire level in one go instead of a sectioned off view of the world which is what you get now. Watch this space.
01:02 Code and Comments
I found some documentation and started plodding through the GUI code, and there are as many sections of commented out code as there is code! All the programs are effectively double in size which means lots of scrolling ;) I am VERY tempted to go through and delete commented code and start re-formatting the source with my own alignment habits and comments, but I know it would take hours and for the whole code base, weeks. It is well worth doing in the long-term but there is no such thing as long-term with deadlines hitting you over the head like an impatient child. To compromise, once I find the area of code I am interested in, the window creation section, I will delete the dud code in that area and add my comments. This way I know where I have been and avoid messing up something inadvertently.
01:44 Well Behaved GUI
I rather suspect all the windows changes I am firing away at the GUI is all for naught, and that BCG is maintaining a 'friendly windows app' with an iron fist. Making the main window full screen maximized does nothing, when it should override the task bar and produce a full screen window. Ah well, going to see what BCG documentation has to say on the subject. Five minutes later; zip. It says precisely zip about full screen, or anything with the word full or screen in the title (except for the main intro page finding 'full customisation' and 'screen commands'). Oh hum. Once more unto the breach dear friends. I wonder if I can hack the very style of the window itself to do my bidding.
02:04 Cue Evil Laugh
Successipoos!! I used the SetWindowLong command to change the main window to WS_POPUP and bingo, the title bar disappeared and so did the taskbar. This just leaves the sub-windows, which I am now going to hide using the BCG calls. In theory, I should have my full screen view in 10 minutes or less!
03:13 There And Back Again With Bamber Baggins
Okay so not quite ten minutes. Maybe multiply my estimates by 6 from now on. I had lots of success, but had one huge fight with some strange edge artefacts and lost. I can now click Test Level button and it goes full screen, and I click out of the test mode and the windows are restored and it looks just the same as when I left. Hurray. I can also bounce and forth as many times as I want almost instantly. It used to do it once then tried to reload the mapeditor executable, but now that bug has gone away and it works nicely now.
Here is a shot of the artefact I am seeing. This is my BCG application hacked using SetWindowLong to make it a POPUP and then I resize it to the desktop resolution.
It SHOULD fill the entire area with my window, but for some reason as you can see the window stops short by a few pixels on the horizontal and 22 pixels short of the vertical. I set the window to a larger size than needed, but something seems to resize the window back to this strange sized result.
I am going to let the universe brew over that one as I am sure it is something very very silly. I want to jump straight into getting some real time light mapping into the scene before the weekend and now is as good a time.
03:29 Then Again
I dropped into the P001 prototype and realised it was implemented with double buffer object system, that is, I am using twice as many objects to create a perfect transition in the scene. This would DOUBLE the amount of memory used when editing/testing which is not what we want. This transition will be handled smartly inside DarkLIGHTS eventually but it's not a system I want to put in DBP code now.
Further, it looks like I will need to create a whole new object placement system for the map editor so it works with the 'infinite level' idea I am after, and it makes sense to get these objects in there before I start light mapping anything. All this needs many hours of clear thought, and I only have an hour or so left in the tank, so the best thing I can do is stop right now.
Signing Off
I am going to spend this last hour leaping over to Perceptual Computing world and seeing what I can knock up with the depth stuff. It's not much, but it's all I have got. For more interesting developments in this area, look no further than our own AGK community, and a member who is already knee deep in Perceptual Computing. We here at TGC think it's awesome and wish the author the best of luck finishing the app: http://www.youtube.com/watch?v=XUqhcI_4nWo&feature=youtu.be
Once I had the bits and bobs out my way, AGK project tweaks, builds, emails and other distractions, my aim was to get right back on the Reloaded saddle and continue riding. And that's what is happening now...
Reloaded Full Screen
I will continue the blog format of adding bits to it as I go this evening, as it worked quite well last night and I got a lot of details out the door. I left off looking at a working Test level button with input, but not in a full screen view. Today is about exploring BCG (an old version) and figuring out how to make my MDI child window take up the whole view. I don't need to separate it from the parent, I just want it to take over the title bar, windows task bar, everything basically. Ideally I don't want to hide and move almost ALL the visible sub-windows of the app to achieve this, I'd prefer to just move the child window to fill each corner of the desktop, but life is never that simple and to be fair, child windows where not designed for that.
I just tried an hour of hacking in all sorts of reasonably looking commands but they just resulted in strange window views or crashes. I will read through the BCG documentation and also trace through the app to see exactly how the GUI was assembled, then I will have a much better idea where to go in and what to change. If time, I also plan to add real time light mapping to the editor system and throw away the old object rendering system and use a whole new one which will support rendering the entire level in one go instead of a sectioned off view of the world which is what you get now. Watch this space.
01:02 Code and Comments
I found some documentation and started plodding through the GUI code, and there are as many sections of commented out code as there is code! All the programs are effectively double in size which means lots of scrolling ;) I am VERY tempted to go through and delete commented code and start re-formatting the source with my own alignment habits and comments, but I know it would take hours and for the whole code base, weeks. It is well worth doing in the long-term but there is no such thing as long-term with deadlines hitting you over the head like an impatient child. To compromise, once I find the area of code I am interested in, the window creation section, I will delete the dud code in that area and add my comments. This way I know where I have been and avoid messing up something inadvertently.
01:44 Well Behaved GUI
I rather suspect all the windows changes I am firing away at the GUI is all for naught, and that BCG is maintaining a 'friendly windows app' with an iron fist. Making the main window full screen maximized does nothing, when it should override the task bar and produce a full screen window. Ah well, going to see what BCG documentation has to say on the subject. Five minutes later; zip. It says precisely zip about full screen, or anything with the word full or screen in the title (except for the main intro page finding 'full customisation' and 'screen commands'). Oh hum. Once more unto the breach dear friends. I wonder if I can hack the very style of the window itself to do my bidding.
02:04 Cue Evil Laugh
Successipoos!! I used the SetWindowLong command to change the main window to WS_POPUP and bingo, the title bar disappeared and so did the taskbar. This just leaves the sub-windows, which I am now going to hide using the BCG calls. In theory, I should have my full screen view in 10 minutes or less!
03:13 There And Back Again With Bamber Baggins
Okay so not quite ten minutes. Maybe multiply my estimates by 6 from now on. I had lots of success, but had one huge fight with some strange edge artefacts and lost. I can now click Test Level button and it goes full screen, and I click out of the test mode and the windows are restored and it looks just the same as when I left. Hurray. I can also bounce and forth as many times as I want almost instantly. It used to do it once then tried to reload the mapeditor executable, but now that bug has gone away and it works nicely now.
Here is a shot of the artefact I am seeing. This is my BCG application hacked using SetWindowLong to make it a POPUP and then I resize it to the desktop resolution.
It SHOULD fill the entire area with my window, but for some reason as you can see the window stops short by a few pixels on the horizontal and 22 pixels short of the vertical. I set the window to a larger size than needed, but something seems to resize the window back to this strange sized result.
I am going to let the universe brew over that one as I am sure it is something very very silly. I want to jump straight into getting some real time light mapping into the scene before the weekend and now is as good a time.
03:29 Then Again
I dropped into the P001 prototype and realised it was implemented with double buffer object system, that is, I am using twice as many objects to create a perfect transition in the scene. This would DOUBLE the amount of memory used when editing/testing which is not what we want. This transition will be handled smartly inside DarkLIGHTS eventually but it's not a system I want to put in DBP code now.
Further, it looks like I will need to create a whole new object placement system for the map editor so it works with the 'infinite level' idea I am after, and it makes sense to get these objects in there before I start light mapping anything. All this needs many hours of clear thought, and I only have an hour or so left in the tank, so the best thing I can do is stop right now.
Signing Off
I am going to spend this last hour leaping over to Perceptual Computing world and seeing what I can knock up with the depth stuff. It's not much, but it's all I have got. For more interesting developments in this area, look no further than our own AGK community, and a member who is already knee deep in Perceptual Computing. We here at TGC think it's awesome and wish the author the best of luck finishing the app: http://www.youtube.com/watch?v=XUqhcI_4nWo&feature=youtu.be
Wednesday, 20 February 2013
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!
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!
Tuesday, 19 February 2013
Tuesday Enlightenment
Helped By An Angel
I got an email almost immediately after posting yesterdays blog from the fine fellow who wrote the FPS Creator classic GUI, with a good clue as to where I should look to find out where the map editor exe connects it's window as a child to the parent GUI application.
As I suspected, it was not in the GUI code at all, but a special feature of the DBP engine controlled by external files! Arg! DBPro has so many features now I forgot it had them (and I wrote some of them too).
The Real Hunt Begins
Today has been a long one, and grilled my brain good (the world is swimming right now), but I managed to get a lot of tasks fired off. On Wednesday I will be making an appointment with the core of DBP itself to find out where this new 'child window feature' sits and make it work for me instead of against me. With that one conquered I will be able to toggle the map editor between GUI friendly child window and completely separate standalone full screen window.
From there, I can get the controls up to speed and start thinking about real time light mapping in the editor. I will start with using the code from my P001 prototype, and then if need be, enter the DarkLights module source code and add a little more treat magic.
Signing Off
I am keeping this blog short as I want to click 'Publish' before I fall off my chair. Maybe a relatively early night will help for the rest of the week. One bit of interesting news is that I might (just might) be doing a quick presentation at the GDC Expo. Exciting times! I will also be bringing with me some GDC discounts crammed into my satchel as I walk around so if you catch me, you will get a very generous discount if you want to try out AGK during the event. There is also a good chance I will be in the Develop magazine which features a line up of game development tools, of which AGK may feature.
While at the event I hope to make a few contacts to help push Reloaded into the market further as well, maybe meet up with some GPU guys, some Publisher and Distributors and hopefully some TGC community members who are there as well. It is always great to have a chin wag with community goers.
I got an email almost immediately after posting yesterdays blog from the fine fellow who wrote the FPS Creator classic GUI, with a good clue as to where I should look to find out where the map editor exe connects it's window as a child to the parent GUI application.
As I suspected, it was not in the GUI code at all, but a special feature of the DBP engine controlled by external files! Arg! DBPro has so many features now I forgot it had them (and I wrote some of them too).
The Real Hunt Begins
Today has been a long one, and grilled my brain good (the world is swimming right now), but I managed to get a lot of tasks fired off. On Wednesday I will be making an appointment with the core of DBP itself to find out where this new 'child window feature' sits and make it work for me instead of against me. With that one conquered I will be able to toggle the map editor between GUI friendly child window and completely separate standalone full screen window.
From there, I can get the controls up to speed and start thinking about real time light mapping in the editor. I will start with using the code from my P001 prototype, and then if need be, enter the DarkLights module source code and add a little more treat magic.
Signing Off
I am keeping this blog short as I want to click 'Publish' before I fall off my chair. Maybe a relatively early night will help for the rest of the week. One bit of interesting news is that I might (just might) be doing a quick presentation at the GDC Expo. Exciting times! I will also be bringing with me some GDC discounts crammed into my satchel as I walk around so if you catch me, you will get a very generous discount if you want to try out AGK during the event. There is also a good chance I will be in the Develop magazine which features a line up of game development tools, of which AGK may feature.
While at the event I hope to make a few contacts to help push Reloaded into the market further as well, maybe meet up with some GPU guys, some Publisher and Distributors and hopefully some TGC community members who are there as well. It is always great to have a chin wag with community goers.
Monday, 18 February 2013
Monday Blog Burst
An Action Packed Weekend
I left you Friday with the prospect of jumping into some Reloaded work that evening, and you have had the weekend to wonder whether I did. Well I am back to report that I most certainly did.
I ate some food then powered up the monster PC for some more Reloaded fun, and my mission was to throw away the FPSC-Game.exe dependence. I promptly deleted it - dependence broken. And so was the map editor, which would now crash when I clicked the Test Level button. My task for the evening was thus, to replace this functionality.
Test Level Button
I dropped into the source code and located the command which launches the separate game builder, and replaced it with the old legacy code which prepares the level for 'preview mode'.
Preview Mode was a feature in the original FPSC but was dropped due to lack of power. I resurrected this and instantly saw why I had removed it in the first place. The mouselook control was poor, the player movement was worse and there was some very strange collision events occurring!
It needed a MAJOR overhaul, and possibly a rewrite. I stripped out the input system which was taking it's cues from the parent Window GUI and restored original DirectX input methods. Ran the software and nothing, no input whatsoever. Turns out the Window GUI was disabling the native DBP app from using it's own input data. I switched the child window of the map editor off in the top this would decouple from the main GUI but this just crashed it.
Legacy Adventures
As it happens, I did not write the original FPSC Window GUI, and for some universal reason I always get away with not writing IDE's, and this one was no exception. The downside struck when I tried to figure out how the main GUI attached the DBP client app as a child window. I traced the code down to the machine code, I changed executable names around and tried to trick the software to not attach the DBP app (thus restoring my input controls). The only success I had was to rename another DBP app (the cleaner.exe) to the filename FPSC-MapEditor.exe. This added the DBP app as a child window, just like the real editor suggesting that it was the filename itself that was the key. I changed the code to attach a DBP app with a different name, and behold, the window did not attach and was free-floating.
It seemed as though some part of the system detects the filename of the window and if it is 'FPSC-MapEditor.exe' it will attach it as a child to the main GUI. I have scanned and scoured the code of the GUI and to some degree the modified BCG library being used for the gadget controls, but no luck.
Six hours later, my brain was waving the white flag and insisting I take a break while it worked it out for me. I would have to resume my epic search on Monday when I would have more hours to spend.
Other Blogging News
This weekend was the first of seven weekends where I would post my new Ultimate Coder Challenge II blogs to the world. They are hosted on IDZ (Intel Developer Zone) and are set to be approved on Monday 5PM PST. The blogs will feature my attempt to create a brand new piece of software which takes advantage of the new Gesture Camera devices. These new cameras have a built-in depth radar which can determine how far each pixel of the video footage is from the camera.
My goal will be to turn this into a 3D mesh and transmit it to a client app which can reconstruct it within a virtual 3D world. In order to preserve the integrity of the Reloaded project, I am confining this work to weekends and holidays. I figured that as the competition was called a 'challenge' I would turn it up to eleven and make it REALLY challenging :)
The good news is that this app will be written in DBP, the same language used to create Reloaded, so this technology will filter through to the Reloaded universe at some point in the future. Early ideas include detecting if you dodge left or right and control the FPS camera to peek round corners or avoid rockets that are fired in your direction. Voice control so you can change and fire weapons/spells/abilities with a word. Facial tracking so the camera will focus in on the object you are looking at on screen (i.e. if you look to the top left corner of the screen, the camera zooms in slightly and blurs out the rest). We could even experiment with hands-free gaming, where you don't even need a mouse or keyboard (but that might be a stretch for high-speed combat).
To keep up with this development, check out the soon to be released blog at the soon to be made live site at: ultimatecoderchallenge.blogspot.co.uk
Signing Off
I also found time to install and play the intro of the Borderlands 2 FPS game which I have been meaning to do for some time now. Did not have any time to play it and my internal sense of right and wrong tells me that I should catch up with my Reloaded timetable before playing any more games :) Good advice from the inner-Lee I think.
The plan this week is to crack on and the AGK apps sorted, keep the email plates spinning and grab a few hours each night to progress the map editor to allow a build-less test level experience. Although culling is critical for the performance of large levels, I think my priority will be to get the Test Level button working nicely with full smooth controls for the player and the real time light mapping going on in the background. Although not everything I wanted for the end of February, I think it would be a good goal.
I left you Friday with the prospect of jumping into some Reloaded work that evening, and you have had the weekend to wonder whether I did. Well I am back to report that I most certainly did.
I ate some food then powered up the monster PC for some more Reloaded fun, and my mission was to throw away the FPSC-Game.exe dependence. I promptly deleted it - dependence broken. And so was the map editor, which would now crash when I clicked the Test Level button. My task for the evening was thus, to replace this functionality.
Test Level Button
I dropped into the source code and located the command which launches the separate game builder, and replaced it with the old legacy code which prepares the level for 'preview mode'.
Preview Mode was a feature in the original FPSC but was dropped due to lack of power. I resurrected this and instantly saw why I had removed it in the first place. The mouselook control was poor, the player movement was worse and there was some very strange collision events occurring!
It needed a MAJOR overhaul, and possibly a rewrite. I stripped out the input system which was taking it's cues from the parent Window GUI and restored original DirectX input methods. Ran the software and nothing, no input whatsoever. Turns out the Window GUI was disabling the native DBP app from using it's own input data. I switched the child window of the map editor off in the top this would decouple from the main GUI but this just crashed it.
Legacy Adventures
As it happens, I did not write the original FPSC Window GUI, and for some universal reason I always get away with not writing IDE's, and this one was no exception. The downside struck when I tried to figure out how the main GUI attached the DBP client app as a child window. I traced the code down to the machine code, I changed executable names around and tried to trick the software to not attach the DBP app (thus restoring my input controls). The only success I had was to rename another DBP app (the cleaner.exe) to the filename FPSC-MapEditor.exe. This added the DBP app as a child window, just like the real editor suggesting that it was the filename itself that was the key. I changed the code to attach a DBP app with a different name, and behold, the window did not attach and was free-floating.
It seemed as though some part of the system detects the filename of the window and if it is 'FPSC-MapEditor.exe' it will attach it as a child to the main GUI. I have scanned and scoured the code of the GUI and to some degree the modified BCG library being used for the gadget controls, but no luck.
Six hours later, my brain was waving the white flag and insisting I take a break while it worked it out for me. I would have to resume my epic search on Monday when I would have more hours to spend.
Other Blogging News
This weekend was the first of seven weekends where I would post my new Ultimate Coder Challenge II blogs to the world. They are hosted on IDZ (Intel Developer Zone) and are set to be approved on Monday 5PM PST. The blogs will feature my attempt to create a brand new piece of software which takes advantage of the new Gesture Camera devices. These new cameras have a built-in depth radar which can determine how far each pixel of the video footage is from the camera.
My goal will be to turn this into a 3D mesh and transmit it to a client app which can reconstruct it within a virtual 3D world. In order to preserve the integrity of the Reloaded project, I am confining this work to weekends and holidays. I figured that as the competition was called a 'challenge' I would turn it up to eleven and make it REALLY challenging :)
The good news is that this app will be written in DBP, the same language used to create Reloaded, so this technology will filter through to the Reloaded universe at some point in the future. Early ideas include detecting if you dodge left or right and control the FPS camera to peek round corners or avoid rockets that are fired in your direction. Voice control so you can change and fire weapons/spells/abilities with a word. Facial tracking so the camera will focus in on the object you are looking at on screen (i.e. if you look to the top left corner of the screen, the camera zooms in slightly and blurs out the rest). We could even experiment with hands-free gaming, where you don't even need a mouse or keyboard (but that might be a stretch for high-speed combat).
To keep up with this development, check out the soon to be released blog at the soon to be made live site at: ultimatecoderchallenge.blogspot.co.uk
Signing Off
I also found time to install and play the intro of the Borderlands 2 FPS game which I have been meaning to do for some time now. Did not have any time to play it and my internal sense of right and wrong tells me that I should catch up with my Reloaded timetable before playing any more games :) Good advice from the inner-Lee I think.
The plan this week is to crack on and the AGK apps sorted, keep the email plates spinning and grab a few hours each night to progress the map editor to allow a build-less test level experience. Although culling is critical for the performance of large levels, I think my priority will be to get the Test Level button working nicely with full smooth controls for the player and the real time light mapping going on in the background. Although not everything I wanted for the end of February, I think it would be a good goal.
Friday, 15 February 2013
Friday Locked
And Loaded
As you may recall from yesterday's blog, my mission was to return to the PC after tea and work on Reloaded, which is precisely what I done. I downloaded the source to the Intel Software Occluder, found it was VS2010 project so installed Visual Studio. It also needed DirectX 11 SDK so I installed that too. Compiled and ran in debug and half the 3D world was missing. Compiled and ran in release and it worked fine.
The Intel Software Occluder was something written back in 2011 which uses a system memory depth buffer and CPU rasterisation techniques to figure out which objects are entirely occluded by the scene. The source code looks straight forward but it is quite involved and will take a lot of reading and picking out techniques to understand the whole thing, but it's a great technique, especially for PC's that have multiple cores.
One drawback I identified early on is that it used DirectX 11 (not surprisingly) and my engine is based on older DirectX 9 commands. My fear is that the technique uses some new fangled depth buffer commands only found in DX11 which means I cannot use it with DX9. A lesser fear is that the technique is still possible, but I would have to convert the DX11 method to a DX9 method, which will take time and would no longer be a drag and drop operation.
And There's More
While I was in the neighbourhood I also decided to set up the new source code folders for the Reloaded project, dropping in the latest version of FPSC V120 and the latest Dark Basic Pro build which can compile the source.
I upgraded my DBP DLL builds to use VS2010 so I don't have to have three different versions of Visual Studio floating about, and did a test compile to make sure I can still build Basic3D.DLL for FPSC. All good.
It looks like I will have another evening free to work on Reloaded tonight, and rather that dip dive into the complex world of CPU depth buffers and DX11 to DX9 conversions, I am taking the easier route of dismantling the build system from the current FPSC source and getting the Test Level button to do something different.
Test Level With A Difference
It won't be an ambitious change as I will only have a few hours, but my goal for the evening is that when you press the green Test Level button, instead of the map editor being terminated and the new game executable launching into build mode. I will simply switch the map editor into a new 'live play' mode which re-uses all the existing assets present in the map editor at that point.
With this in place, theoretically, you should be able to press the button and instantly transport to the start marker in first person view, right inside your map editor world. I used to have such a feature in FPSC way back when called Preview but it was trapped between two worlds and did not really delivery on it's promise. You could say I am going back to Preview and finishing the job.
I will probably use the built-in collision system of DBP to allow level navigation to begin with, just so I can get a feel for the new feature. The ultimate aim is to implement a whole new 'unified' physics system to take care of everything from player movement and collision to exploding walls. That will probably be the world of another day and worth saving!
In terms of internal schedules and deadline, I had planned to have the build system decoupled last Friday and I am already one week behind. By the end of today, I should be back on track (technically), but of course my aim for THIS Friday in the original schedule was to have real-time light mapping going on in the background of the editor. My guess is that it will take a few days to get that into the system, and if I keep plugging away I'll be able to catch up.
Signing Off
Currently being plagued with power cuts and intermittent internet at the moment which is no fun if you are making lots of large uploads and keeping in touch with the world wide web. Hopefully the powers that be will fix it long enough for me to get on with things.
As you may recall from yesterday's blog, my mission was to return to the PC after tea and work on Reloaded, which is precisely what I done. I downloaded the source to the Intel Software Occluder, found it was VS2010 project so installed Visual Studio. It also needed DirectX 11 SDK so I installed that too. Compiled and ran in debug and half the 3D world was missing. Compiled and ran in release and it worked fine.
The Intel Software Occluder was something written back in 2011 which uses a system memory depth buffer and CPU rasterisation techniques to figure out which objects are entirely occluded by the scene. The source code looks straight forward but it is quite involved and will take a lot of reading and picking out techniques to understand the whole thing, but it's a great technique, especially for PC's that have multiple cores.
One drawback I identified early on is that it used DirectX 11 (not surprisingly) and my engine is based on older DirectX 9 commands. My fear is that the technique uses some new fangled depth buffer commands only found in DX11 which means I cannot use it with DX9. A lesser fear is that the technique is still possible, but I would have to convert the DX11 method to a DX9 method, which will take time and would no longer be a drag and drop operation.
And There's More
While I was in the neighbourhood I also decided to set up the new source code folders for the Reloaded project, dropping in the latest version of FPSC V120 and the latest Dark Basic Pro build which can compile the source.
I upgraded my DBP DLL builds to use VS2010 so I don't have to have three different versions of Visual Studio floating about, and did a test compile to make sure I can still build Basic3D.DLL for FPSC. All good.
It looks like I will have another evening free to work on Reloaded tonight, and rather that dip dive into the complex world of CPU depth buffers and DX11 to DX9 conversions, I am taking the easier route of dismantling the build system from the current FPSC source and getting the Test Level button to do something different.
Test Level With A Difference
It won't be an ambitious change as I will only have a few hours, but my goal for the evening is that when you press the green Test Level button, instead of the map editor being terminated and the new game executable launching into build mode. I will simply switch the map editor into a new 'live play' mode which re-uses all the existing assets present in the map editor at that point.
With this in place, theoretically, you should be able to press the button and instantly transport to the start marker in first person view, right inside your map editor world. I used to have such a feature in FPSC way back when called Preview but it was trapped between two worlds and did not really delivery on it's promise. You could say I am going back to Preview and finishing the job.
I will probably use the built-in collision system of DBP to allow level navigation to begin with, just so I can get a feel for the new feature. The ultimate aim is to implement a whole new 'unified' physics system to take care of everything from player movement and collision to exploding walls. That will probably be the world of another day and worth saving!
In terms of internal schedules and deadline, I had planned to have the build system decoupled last Friday and I am already one week behind. By the end of today, I should be back on track (technically), but of course my aim for THIS Friday in the original schedule was to have real-time light mapping going on in the background of the editor. My guess is that it will take a few days to get that into the system, and if I keep plugging away I'll be able to catch up.
Signing Off
Currently being plagued with power cuts and intermittent internet at the moment which is no fun if you are making lots of large uploads and keeping in touch with the world wide web. Hopefully the powers that be will fix it long enough for me to get on with things.
Thursday, 14 February 2013
Thursday Grind
Plate Spinning
You will hear the term plate spinning, which is the activity of keeping as many plates continually rotating on a long thin pole for as long as possible before one of them crashes to the floor due to lack of momentum.
When I start forgetting tasks that I had planned to keep spinning, that is when I know I have too many plates on the go, and the next sound you will hear is the crash of pottery! Not to name names, but I have totally forgotten two tasks in as many days and it's not something I like to do as a rule.
I have since corrected the omission and all is well with the world but I do feel I am at the threshold of what I can comfortably spin. This means any new projects or jobs coming along will have very little resource placed on it for the time being.
DarkGDK Now Open Source
Meet the new boss, same as the old boss. Although many of you will know that DarkGDK has been open source and free for years, we still get the occasional email coming through support mail asking for, er, support. It is tasks like these that find themselves with precious little resource with other more demanding projects on the go.
To head off any disappointment in the DarkGDK camp, I have decided to announce today that it is now officially open source, and that no further intervention from TGC will be made on the currently open source code. It will remain free to use, and the source code from Google Code will allow you to amend, fix and upgrade as you see fit. The forum is still a lively place so it should continue rolling for many years to come, all be it without a steering wheel.
Fortunately this allows me to bring the source code back in-house so I can start ripping it apart from the impending FPSC Reloaded work. Part of the project will involve improving some aspects of DBP (of which DarkGDK is the underlying engine) and having it closed source will help me focus on it without having to consider how it might break other coders projects.
FPSC Fun
It became apparent to me today that my first month of Reloaded work is not been too spectacular on the progress front. In blasting the other projects to get them out the way it has been sacrificed and I am about a week behind my internal schedule.
To combat this, irrespective of the demands of the hour, when I return in the evening I am going to switch to FPSC work for the rest of Thursday. That way I can put another stake in the ground along the way to completion. I am going to leave the 'what' for later, but switching on the new machine and working for a few hours on Reloaded will give me a nice warm feeling.
Signing Off
The work will continue into the night, but I will sign off now so you can look forward to Friday's blog and find out what and how much I did on Reloaded. I must also note that internet drop-outs are a royal pain. I have been uploading the same test flight binary for over 24 hours now and it's driving me nuts! Even my blog is showing 'an error occurred' every now and again, and last night the whole power grid went off at 3AM. Sometimes living in a small town in Wales has it's downsides!
You will hear the term plate spinning, which is the activity of keeping as many plates continually rotating on a long thin pole for as long as possible before one of them crashes to the floor due to lack of momentum.
When I start forgetting tasks that I had planned to keep spinning, that is when I know I have too many plates on the go, and the next sound you will hear is the crash of pottery! Not to name names, but I have totally forgotten two tasks in as many days and it's not something I like to do as a rule.
I have since corrected the omission and all is well with the world but I do feel I am at the threshold of what I can comfortably spin. This means any new projects or jobs coming along will have very little resource placed on it for the time being.
DarkGDK Now Open Source
Meet the new boss, same as the old boss. Although many of you will know that DarkGDK has been open source and free for years, we still get the occasional email coming through support mail asking for, er, support. It is tasks like these that find themselves with precious little resource with other more demanding projects on the go.
To head off any disappointment in the DarkGDK camp, I have decided to announce today that it is now officially open source, and that no further intervention from TGC will be made on the currently open source code. It will remain free to use, and the source code from Google Code will allow you to amend, fix and upgrade as you see fit. The forum is still a lively place so it should continue rolling for many years to come, all be it without a steering wheel.
Fortunately this allows me to bring the source code back in-house so I can start ripping it apart from the impending FPSC Reloaded work. Part of the project will involve improving some aspects of DBP (of which DarkGDK is the underlying engine) and having it closed source will help me focus on it without having to consider how it might break other coders projects.
FPSC Fun
It became apparent to me today that my first month of Reloaded work is not been too spectacular on the progress front. In blasting the other projects to get them out the way it has been sacrificed and I am about a week behind my internal schedule.
To combat this, irrespective of the demands of the hour, when I return in the evening I am going to switch to FPSC work for the rest of Thursday. That way I can put another stake in the ground along the way to completion. I am going to leave the 'what' for later, but switching on the new machine and working for a few hours on Reloaded will give me a nice warm feeling.
Signing Off
The work will continue into the night, but I will sign off now so you can look forward to Friday's blog and find out what and how much I did on Reloaded. I must also note that internet drop-outs are a royal pain. I have been uploading the same test flight binary for over 24 hours now and it's driving me nuts! Even my blog is showing 'an error occurred' every now and again, and last night the whole power grid went off at 3AM. Sometimes living in a small town in Wales has it's downsides!
Wednesday, 13 February 2013
Wednesday News
Lee Goes To GDC
That's right! I will be flying out on the 24th March to attend the biggest developer conference on the planet, and dragging a bunch of AGK discount vouchers and other goodies with me for a few lucky visitors. I will also be on the Expo floor for a few hours, and probably a few GDC parties if they let me in. And it gets better...
Ultimate Coder Challenge II
As part of my blogging activities for the competition, I'm bringing my Perceptual inventions with me, and hopefully I will be able to demonstrate them during the EXPO for those attending.
I have not started my prototype for this competition, nor have I even opened the Ultrabook that will be hosting my Perceptual app. I am saving it all up for my first Ultimate Coder blog which is due in less than a week. My first blog will include a full unwrapping of the Gesture Camera and the Ultrabook so stay tuned for that one.
Regular Works
My regular day job continues a pace with more improvements to the AGK app I am beavering away to complete. It is coming along nicely and quickly, and this iterative process should result in a great app for the various app stores out there. The app is also tied to a very strong brand and a constant stream of new customers every year so it should make for a great show piece for AGK and what it can do.
Signing Off
This week is ebbing away quite quickly so far, and I have yet to break open the FPSC source code which I had planned for the end of this week. My hope is that I can capture a lull between AGK versions and rush in to chop up some code before my brain realises what is happening. I find once I am ten minutes into something, I can pretty much stay there until good things happen. The trick is to stop before bad things start to happen!
That's right! I will be flying out on the 24th March to attend the biggest developer conference on the planet, and dragging a bunch of AGK discount vouchers and other goodies with me for a few lucky visitors. I will also be on the Expo floor for a few hours, and probably a few GDC parties if they let me in. And it gets better...
Ultimate Coder Challenge II
As part of my blogging activities for the competition, I'm bringing my Perceptual inventions with me, and hopefully I will be able to demonstrate them during the EXPO for those attending.
I have not started my prototype for this competition, nor have I even opened the Ultrabook that will be hosting my Perceptual app. I am saving it all up for my first Ultimate Coder blog which is due in less than a week. My first blog will include a full unwrapping of the Gesture Camera and the Ultrabook so stay tuned for that one.
Regular Works
My regular day job continues a pace with more improvements to the AGK app I am beavering away to complete. It is coming along nicely and quickly, and this iterative process should result in a great app for the various app stores out there. The app is also tied to a very strong brand and a constant stream of new customers every year so it should make for a great show piece for AGK and what it can do.
Signing Off
This week is ebbing away quite quickly so far, and I have yet to break open the FPSC source code which I had planned for the end of this week. My hope is that I can capture a lull between AGK versions and rush in to chop up some code before my brain realises what is happening. I find once I am ten minutes into something, I can pretty much stay there until good things happen. The trick is to stop before bad things start to happen!
Tuesday, 12 February 2013
Tuesday With AGK
Lots of AGK
Not only my usual run of AGK project work, but a long conference call with the core AGK engine team to plot out a roadmap for the rest of 2013. It was a good call with lots of cool ideas, and we eventually arrived at some good solid decisions. If this was the forum, I would probably not mention them as I will be beaten over the head with my words 12 months from now. This is my blog however so I feel like I have enough freedom to reveal some hints.
AGK Roadmap Hints
Our top priority is the conclusion of the V108 update which is 'almost' done. We keep adding a command every now and again which resets the whole testing and build work, plus there are numerous little 'niggles' which we want to eradicate before making the update official. There are also a few Game Centre commands going in too.
When we make an update official, we have to upload all the AGK Players out there, and so we want to make sure the version everyone permanently updates to is rock solid.
Once V108 is out the door, we will either sit on the command set and go for more testing, or what is looking more likely, adding a few much needed 3D Animation commands and then testing for stability and consistency across platforms. When we stood back from our current 3D command set, we realised that there was some holes in what you could do, and having a 3D game with no animating models was a little cruel. These are going in, along with some extra file format work so you can import your creations into AGK more easily. Beyond that, many things, but I will touch on those when we get closer to them. In the meantime, watch the AGK forum for news on new betas.
FPSC Beta 15
Also got a report that the latest FPSC beta is going down well, with just a single issue relating to the spawning of characters not finding the floor quickly. It's not a show stopper, so will leave the beta for a while longer in case anything else crops up.
Signing Off
I still have three hours on the clock, and I suspect most of them will be eaten up with AGK project work, but if I escape the tractor beam my plan is to break out FPSC Source Code and have a quick hour chopping away at it, to see if I can trigger the build game from within the map editor executable. This will be the first step to eliminating the build step altogether as the ultimate aim is always to have a single executable running, instead of spawning off a new one each time you click Test Level.
Not only my usual run of AGK project work, but a long conference call with the core AGK engine team to plot out a roadmap for the rest of 2013. It was a good call with lots of cool ideas, and we eventually arrived at some good solid decisions. If this was the forum, I would probably not mention them as I will be beaten over the head with my words 12 months from now. This is my blog however so I feel like I have enough freedom to reveal some hints.
AGK Roadmap Hints
Our top priority is the conclusion of the V108 update which is 'almost' done. We keep adding a command every now and again which resets the whole testing and build work, plus there are numerous little 'niggles' which we want to eradicate before making the update official. There are also a few Game Centre commands going in too.
When we make an update official, we have to upload all the AGK Players out there, and so we want to make sure the version everyone permanently updates to is rock solid.
Once V108 is out the door, we will either sit on the command set and go for more testing, or what is looking more likely, adding a few much needed 3D Animation commands and then testing for stability and consistency across platforms. When we stood back from our current 3D command set, we realised that there was some holes in what you could do, and having a 3D game with no animating models was a little cruel. These are going in, along with some extra file format work so you can import your creations into AGK more easily. Beyond that, many things, but I will touch on those when we get closer to them. In the meantime, watch the AGK forum for news on new betas.
FPSC Beta 15
Also got a report that the latest FPSC beta is going down well, with just a single issue relating to the spawning of characters not finding the floor quickly. It's not a show stopper, so will leave the beta for a while longer in case anything else crops up.
Signing Off
I still have three hours on the clock, and I suspect most of them will be eaten up with AGK project work, but if I escape the tractor beam my plan is to break out FPSC Source Code and have a quick hour chopping away at it, to see if I can trigger the build game from within the map editor executable. This will be the first step to eliminating the build step altogether as the ultimate aim is always to have a single executable running, instead of spawning off a new one each time you click Test Level.
Monday, 11 February 2013
Monday Catch-Up
Final Weekend Away
It is likely the weekend just gone will be my final jaunt down to Wigan for a few weeks as my work down there has been completed for the time being. From next weekend onwards, I will be parked at the PC doing PC 'things'. One of those things will be playing FPS games and making FPSC game makers.
Today's Tasks
Apart from the usual backlog of email, I have cracked on and got more of my AGK projects moving forward, always trying to keep the tennis balls out of my side of the court. It's a good feeling having lots of tennis balls to blast into the stratosphere but too many of them bouncing around is confusing and a little bit demoralising. I like to knock them back over the fence as soon as they come hurtling towards me where and whenever possible.
Today I had a lot of graphics waiting for me which is always fun, and my app transformed in front of me. Just spending another 40 minutes moving art around the screen and then calling it a [long] day. The driving and Wigan-side manual labour really takes it out of me, so hopefully a good night's rest will screw my head back on straight.
Keyboard Trouble
For some reason my keyboard seems to go to sleep if I don't type for more than 30 seconds, and it takes numerous jabbing at a key to make it come back to me. I can live with it, and loathe buying a new one [happened just now], so we'll see how long it takes before I go from Defcon 4 (mildly aware) to Defcon 1 (ready to smash the keyboard into little pieces).
Something along the lines of Angry German Kid 4 minutes in: http://www.youtube.com/watch?v=PbcctWbC8Q0
Signing Off
One of the duties I will have to perform in the coming weeks is to produce some video blogs, so I am re-arranging my office to remove all the old empty boxes that used to line my back wall. I thought it looked suitably geeky and interesting, but apparently it looks like I am living in a junk shop. I have also been advised to add some promotional posters on the wall befitting a computer type person but the only one I have is from FPS Creator X10 featuring a salivating monster with an uber-rifle jammed up his nose. Not the impression I want to create! I'd like to use the TGC logo, but I could not find one ten feet high. I might just jump onto eBay and see what kind of posters passes for modern-geek these days.
It is likely the weekend just gone will be my final jaunt down to Wigan for a few weeks as my work down there has been completed for the time being. From next weekend onwards, I will be parked at the PC doing PC 'things'. One of those things will be playing FPS games and making FPSC game makers.
Today's Tasks
Apart from the usual backlog of email, I have cracked on and got more of my AGK projects moving forward, always trying to keep the tennis balls out of my side of the court. It's a good feeling having lots of tennis balls to blast into the stratosphere but too many of them bouncing around is confusing and a little bit demoralising. I like to knock them back over the fence as soon as they come hurtling towards me where and whenever possible.
Today I had a lot of graphics waiting for me which is always fun, and my app transformed in front of me. Just spending another 40 minutes moving art around the screen and then calling it a [long] day. The driving and Wigan-side manual labour really takes it out of me, so hopefully a good night's rest will screw my head back on straight.
Keyboard Trouble
For some reason my keyboard seems to go to sleep if I don't type for more than 30 seconds, and it takes numerous jabbing at a key to make it come back to me. I can live with it, and loathe buying a new one [happened just now], so we'll see how long it takes before I go from Defcon 4 (mildly aware) to Defcon 1 (ready to smash the keyboard into little pieces).
Something along the lines of Angry German Kid 4 minutes in: http://www.youtube.com/watch?v=PbcctWbC8Q0
Signing Off
One of the duties I will have to perform in the coming weeks is to produce some video blogs, so I am re-arranging my office to remove all the old empty boxes that used to line my back wall. I thought it looked suitably geeky and interesting, but apparently it looks like I am living in a junk shop. I have also been advised to add some promotional posters on the wall befitting a computer type person but the only one I have is from FPS Creator X10 featuring a salivating monster with an uber-rifle jammed up his nose. Not the impression I want to create! I'd like to use the TGC logo, but I could not find one ten feet high. I might just jump onto eBay and see what kind of posters passes for modern-geek these days.
Friday, 8 February 2013
Friday Flee
AGK Project Overdrive
I had though I could split the day squarely between Reloaded proto work and the AGK projects I am working on, but the thing about commercial software is that they require a lot of fine tuning and are often set-up as an iterative process. I should pretty much give up trying to estimate how long product completion will take when there is more than one person involved in the process.
The inaccuracy of one's estimate is compounded not only by waiting for material and works to arrive on your desk, but the micro-changes requested/demanded from others during the process. The only estimates that come close to reality are the supremely exaggerated ones, as all sensible predictions don't even come close.
Early Knock
Back off to Wigan in a few hours so my day is cut short. I started the day at a reasonable time but when you have two or three large plates spinning those hours fly by very quickly. The good news is that some of my ships are coming in and by Monday I will have plenty of meat to grind. Hopefully these distractions won't hound me too much longer and I can get stuck into my Reloaded project.
Signing Off
Not much blog today as all my progress info is secret :) I can reveal that adding Facebook support to AGK apps is EXTREMELY simple thanks to the team. Just add an app from Facebook, get an App ID, then insert that into your set-up command and away you go. From afar, it all seemed like voodoo, but today I had to integrate me some Facebook and I found the whole experience alarmingly straight forward! If all API's where this simple. I might add for readers who do not know AGK, I integrated Facebook in three commands, and in under five minutes. I am pretty sure there are very few competitors to AGK who could claim those stats ;)
I had though I could split the day squarely between Reloaded proto work and the AGK projects I am working on, but the thing about commercial software is that they require a lot of fine tuning and are often set-up as an iterative process. I should pretty much give up trying to estimate how long product completion will take when there is more than one person involved in the process.
The inaccuracy of one's estimate is compounded not only by waiting for material and works to arrive on your desk, but the micro-changes requested/demanded from others during the process. The only estimates that come close to reality are the supremely exaggerated ones, as all sensible predictions don't even come close.
Early Knock
Back off to Wigan in a few hours so my day is cut short. I started the day at a reasonable time but when you have two or three large plates spinning those hours fly by very quickly. The good news is that some of my ships are coming in and by Monday I will have plenty of meat to grind. Hopefully these distractions won't hound me too much longer and I can get stuck into my Reloaded project.
Signing Off
Not much blog today as all my progress info is secret :) I can reveal that adding Facebook support to AGK apps is EXTREMELY simple thanks to the team. Just add an app from Facebook, get an App ID, then insert that into your set-up command and away you go. From afar, it all seemed like voodoo, but today I had to integrate me some Facebook and I found the whole experience alarmingly straight forward! If all API's where this simple. I might add for readers who do not know AGK, I integrated Facebook in three commands, and in under five minutes. I am pretty sure there are very few competitors to AGK who could claim those stats ;)
Thursday, 7 February 2013
Thursday Focus
What A Busy Boy
Yesterday was crammed with my AGK project, which seemed to stretch off in every increasing distances for each door I opened. I am pleased to say I solved almost all the issues on my plate but it certainly gobbled up a lot of hours. Looks like Thursday is shaping up to be the same kind of deal, with plenty of spreadsheets lining up my coding tasks like toasted soldiers about to be eaten.
On the Reloaded P002 front, while I was deliberating writing a view space culling approach, Rick sent me a very interesting article from Intel which covered the very issue of geometry culling. The article describes a more advanced technique which uses a system memory depth buffer and multi-core operations to break down the task of figuring out what to draw. It still uses occlusion volumes and AABB bound boxes, but is written in C++ and optimised by brainiac Intel engineers. When I read the article and ran the provided code sample I made the decision to abandon my little P002 experiment and use this new technique instead.
A New Occlusion
We can argue that the purpose of the P002 prototype was to highlight the challenges to me, and give me a better grounding on the problems my occlusion system needs to solve. It took me HOURS to figure out the dynamics of a single plane culling system, and even that small piece of code I had to fudge before it worked. Can you imagine what an entire scene management system would look like with that approach, and the performance hit such a system might incur.
The benefit of using the Intel sample is that the code is already written and tested. I just need to cut and paste the pertinent parts into a new Dark Basic Pro module and link it with object visibility. Another extreme benefit is that our occlusion system performance jumps up when it gets a whiff of any multi-core processors in the room. The metrics quotes in the article suggest a sizeable increase in frame rate when all techniques discussed are implemented.
What I like about the system is that the scene appears to be a collection of independent objects, and the occlusion system can figure out within a few milliseconds which ones should be rendered, and all done in real-time. I am sometimes asked to run my apps through a concurrency checker to see how many of the cores are being utilized and in the case of FPSC Classic it would only melt the cores during the light mapping stage. During the game only a single core would be taxed. In theory, this new system will be running the occlusion stuff all the time, which means all the cores will be working all the time, improving my concurrency markedly.
This means the next time Intel ask me how well my app is threaded, I can wear my cheesy smug grin.
Signing Off
No new games have been installed since finishing Dishonoured, mainly due to the onset of additional work. Hopefully I can break free of these micro-tasks and in the next few weeks complete my research into the remaining FPS games I have here. Borderlands 2 is burning a hole in my shelf!!
Yesterday was crammed with my AGK project, which seemed to stretch off in every increasing distances for each door I opened. I am pleased to say I solved almost all the issues on my plate but it certainly gobbled up a lot of hours. Looks like Thursday is shaping up to be the same kind of deal, with plenty of spreadsheets lining up my coding tasks like toasted soldiers about to be eaten.
On the Reloaded P002 front, while I was deliberating writing a view space culling approach, Rick sent me a very interesting article from Intel which covered the very issue of geometry culling. The article describes a more advanced technique which uses a system memory depth buffer and multi-core operations to break down the task of figuring out what to draw. It still uses occlusion volumes and AABB bound boxes, but is written in C++ and optimised by brainiac Intel engineers. When I read the article and ran the provided code sample I made the decision to abandon my little P002 experiment and use this new technique instead.
A New Occlusion
We can argue that the purpose of the P002 prototype was to highlight the challenges to me, and give me a better grounding on the problems my occlusion system needs to solve. It took me HOURS to figure out the dynamics of a single plane culling system, and even that small piece of code I had to fudge before it worked. Can you imagine what an entire scene management system would look like with that approach, and the performance hit such a system might incur.
The benefit of using the Intel sample is that the code is already written and tested. I just need to cut and paste the pertinent parts into a new Dark Basic Pro module and link it with object visibility. Another extreme benefit is that our occlusion system performance jumps up when it gets a whiff of any multi-core processors in the room. The metrics quotes in the article suggest a sizeable increase in frame rate when all techniques discussed are implemented.
What I like about the system is that the scene appears to be a collection of independent objects, and the occlusion system can figure out within a few milliseconds which ones should be rendered, and all done in real-time. I am sometimes asked to run my apps through a concurrency checker to see how many of the cores are being utilized and in the case of FPSC Classic it would only melt the cores during the light mapping stage. During the game only a single core would be taxed. In theory, this new system will be running the occlusion stuff all the time, which means all the cores will be working all the time, improving my concurrency markedly.
This means the next time Intel ask me how well my app is threaded, I can wear my cheesy smug grin.
Signing Off
No new games have been installed since finishing Dishonoured, mainly due to the onset of additional work. Hopefully I can break free of these micro-tasks and in the next few weeks complete my research into the remaining FPS games I have here. Borderlands 2 is burning a hole in my shelf!!
Wednesday, 6 February 2013
Wednesday Crammed
Plenty of Day
For some reason my body clock has been screwy this last week or so. I can't seem to oversleep?! No matter how late I go to bed, I am waking before 8AM and on my feet around 9AM. Very unusual for me. It might be those three sets of days I glued together last week! We will see if this disturbing trend continues this week.
Two Job Lee
My mind says I have two jobs to today. My AGK project and the Reloaded P002 prototype (and my blog). Okay, so three jobs. Four if you count emails. Four jobs today. Firstly a report.
Reloaded Report
After my blog post last night I broke out the Reloaded prototype source and attempted to solve the issue causing some objects to remain visible even though there where clearly occluded. Turns out my top and bottom planes caused by the top and bottom edges of the bound box occluder where reversing the Z values, meaning the further back I went the more likely the reversed plane would slice right through the object being occluded and make it visible. Easy to write down but took three hours to disassemble my plane creation and detection code to find it.
I have reduced my prototype to create a single face from an arbitrarily created bound box and that works great, occluding everything behind it with alarming accuracy. The downside is that the occlusion fails if my occluder has a negative Z position and the other faces of the bound box did not occlude at all. I am also concerned that my fudge to fix the top and bottom plane detectors is indicative of faulty plane creation/usage code.
I suspect the issue relates to my confused sense of world space versus view space and trying to get the two to co-operate. I have decided that instead of trying to fudge the other faces to get it all working around the bound box and in plus Z situations, I am going to re-write the occluder using all view space coordinates. This should mean that it will not matter if it's up, down, left, right, high, low or any other combination. A plane is a plane and anything trapped within the volume that employs it will be culled from view.
AGK Fun
Before that however, I have some small tweaks and integrations to make on the other project I am finishing off. I don't anticipate this will take too long and I have already fixed the remaining issue from last night over my morning coffee so hopefully I can be out of AGK land and in Reloaded land before dinner time.
Sneak Peek Sniper Rifle
Rick kindly made a video of the new sniper rifle so you can see those lovely weapon shaders employing cube mapping and metallic reflection tricks.
Don't worry about the old classic zoom mechanism, we're going to upgrade this, along with new HUD art, extra motion options when you move and further down the road, customisable weapon attachments ;) Exciting times ahead!
Signing Off
I have no doubt emails will arrive to attempt to distract me, but time is a wasting and I only have two and a bit days to get the main FPSC source code and strip it down to eliminate the build step. I did not anticipate the occluder prototype would take LONGER than the real-time light mapping prototype, but that's development right there!
For some reason my body clock has been screwy this last week or so. I can't seem to oversleep?! No matter how late I go to bed, I am waking before 8AM and on my feet around 9AM. Very unusual for me. It might be those three sets of days I glued together last week! We will see if this disturbing trend continues this week.
Two Job Lee
My mind says I have two jobs to today. My AGK project and the Reloaded P002 prototype (and my blog). Okay, so three jobs. Four if you count emails. Four jobs today. Firstly a report.
Reloaded Report
After my blog post last night I broke out the Reloaded prototype source and attempted to solve the issue causing some objects to remain visible even though there where clearly occluded. Turns out my top and bottom planes caused by the top and bottom edges of the bound box occluder where reversing the Z values, meaning the further back I went the more likely the reversed plane would slice right through the object being occluded and make it visible. Easy to write down but took three hours to disassemble my plane creation and detection code to find it.
I have reduced my prototype to create a single face from an arbitrarily created bound box and that works great, occluding everything behind it with alarming accuracy. The downside is that the occlusion fails if my occluder has a negative Z position and the other faces of the bound box did not occlude at all. I am also concerned that my fudge to fix the top and bottom plane detectors is indicative of faulty plane creation/usage code.
I suspect the issue relates to my confused sense of world space versus view space and trying to get the two to co-operate. I have decided that instead of trying to fudge the other faces to get it all working around the bound box and in plus Z situations, I am going to re-write the occluder using all view space coordinates. This should mean that it will not matter if it's up, down, left, right, high, low or any other combination. A plane is a plane and anything trapped within the volume that employs it will be culled from view.
AGK Fun
Before that however, I have some small tweaks and integrations to make on the other project I am finishing off. I don't anticipate this will take too long and I have already fixed the remaining issue from last night over my morning coffee so hopefully I can be out of AGK land and in Reloaded land before dinner time.
Sneak Peek Sniper Rifle
Rick kindly made a video of the new sniper rifle so you can see those lovely weapon shaders employing cube mapping and metallic reflection tricks.
http://www.youtube.com/watch?v=umWMgSfrFNg&feature=share&list=UUiqOU8lHcr0LM90ecc84XbQ
Don't worry about the old classic zoom mechanism, we're going to upgrade this, along with new HUD art, extra motion options when you move and further down the road, customisable weapon attachments ;) Exciting times ahead!
Signing Off
I have no doubt emails will arrive to attempt to distract me, but time is a wasting and I only have two and a bit days to get the main FPSC source code and strip it down to eliminate the build step. I did not anticipate the occluder prototype would take LONGER than the real-time light mapping prototype, but that's development right there!
Tuesday, 5 February 2013
Tuesday Catch-Up
Backlog World
Amazing how many emails and accumulate over a three day period! Took several hours to work through and answer them all but finally got to the last one and back onto my daily task list.
Secret AGK Project
My AGK project obligations moved to the final stage with receipt of new graphics to integrate, with more on the way so hopefully I can be signing them off later this month. Once they have been officially green lit, I will reveal exactly what these apps are and provide links to them. I think you will approve as they are set to become 'very' popular and provide a great showcase for what AGK can do and encourage new developers to try our development solution.
Reloaded Next Stage
I have an internal goal to eliminate the build step in FPSC by Friday, so that the map editor supports the test level functionality. I am sure there are a whole mountain of horrors I have not anticipated, but I wanted to get the occlusion stuff sorted before diving into the original source code.
The P002 prototype now generates larger bound boxes where smaller bound boxes can be glued together easily, but there is a small bug which allows objects that should be occluded to remain visible, so I will be checking that later today.
The latest FPSC beta was released which should solve the Windows 8 false-positive issue and also solve the floating character issue and with a little luck will be the Release Candidate for V120. I will be keeping the source code access open for mods, but this will be the last version of the source code in it's current form, and the next official code base will be V1 of the Reloaded source.
P002 Prototype
Once I have solved the strange visibility issue in the current prototype I will post a small video so you can see what it's all about. I am sorry if some of my ramblings are a little technical, but I find it quicker to dump what my mind is chewing over directly to the blog than try and edit it too much. Here is one such brain dump, my 'in-progress' sketches for the P002 prototype:
Reloaded Art News
I also received word that a new weapon has come off the production line in the form of a sniper rifle of the highest calibre (ah em). The still shot does not do it justice as the use of advanced shading makes this gun come alive when you run around the scene with it.
We have quite a collection now, all ready for the Reloaded Asset Library, but we will be returning to each one and refining their in-game behaviour to rival the features you expect from an FPS game in 2013/2014. The art is top draw, we just need to make them as game savvy and mechanically slick as they are stunning visually.
Signing Off
I will see if I can get you a video of the above artwork in Wednesday's blog, so you can see what I see. Ignore the scene graphics in the background as they are from the old FPSC Classic. A typical Reloaded scene will be much more 'atmospheric' and high-definition (at least that's the plan).
Amazing how many emails and accumulate over a three day period! Took several hours to work through and answer them all but finally got to the last one and back onto my daily task list.
Secret AGK Project
My AGK project obligations moved to the final stage with receipt of new graphics to integrate, with more on the way so hopefully I can be signing them off later this month. Once they have been officially green lit, I will reveal exactly what these apps are and provide links to them. I think you will approve as they are set to become 'very' popular and provide a great showcase for what AGK can do and encourage new developers to try our development solution.
Reloaded Next Stage
I have an internal goal to eliminate the build step in FPSC by Friday, so that the map editor supports the test level functionality. I am sure there are a whole mountain of horrors I have not anticipated, but I wanted to get the occlusion stuff sorted before diving into the original source code.
The P002 prototype now generates larger bound boxes where smaller bound boxes can be glued together easily, but there is a small bug which allows objects that should be occluded to remain visible, so I will be checking that later today.
The latest FPSC beta was released which should solve the Windows 8 false-positive issue and also solve the floating character issue and with a little luck will be the Release Candidate for V120. I will be keeping the source code access open for mods, but this will be the last version of the source code in it's current form, and the next official code base will be V1 of the Reloaded source.
P002 Prototype
Once I have solved the strange visibility issue in the current prototype I will post a small video so you can see what it's all about. I am sorry if some of my ramblings are a little technical, but I find it quicker to dump what my mind is chewing over directly to the blog than try and edit it too much. Here is one such brain dump, my 'in-progress' sketches for the P002 prototype:
Reloaded Art News
I also received word that a new weapon has come off the production line in the form of a sniper rifle of the highest calibre (ah em). The still shot does not do it justice as the use of advanced shading makes this gun come alive when you run around the scene with it.
We have quite a collection now, all ready for the Reloaded Asset Library, but we will be returning to each one and refining their in-game behaviour to rival the features you expect from an FPS game in 2013/2014. The art is top draw, we just need to make them as game savvy and mechanically slick as they are stunning visually.
Signing Off
I will see if I can get you a video of the above artwork in Wednesday's blog, so you can see what I see. Ignore the scene graphics in the background as they are from the old FPSC Classic. A typical Reloaded scene will be much more 'atmospheric' and high-definition (at least that's the plan).
Monday Absence
Day Off
My apologises for my lack of blog from Monday. I was in another country filling a corgi sized skip with non combustible items and creating a large bonfire for the rest. Me and my hobbies...
Signing Off
Normal service will resume Tuesday when I am back in front of the keyboard.
My apologises for my lack of blog from Monday. I was in another country filling a corgi sized skip with non combustible items and creating a large bonfire for the rest. Me and my hobbies...
Signing Off
Normal service will resume Tuesday when I am back in front of the keyboard.
Friday, 1 February 2013
Friday Officially Reloaded
Up With The Larks
Morning broke at 5:30AM today and got emails done in just 30 minutes, so had time to finish lots of little tasks scattered around my machine. New FPSC beta uploaded and further work to migrate my work files to the new machine. The big task of the day of course is some lovely Reloaded work
P002 Continued
As you recall, last time we got a single bound box casting an occlusion shadow over the scene which hid anything within it. The current issue is that anything that is partially occluded is left visible, even if a second occluder hides the parts remaining visible.
The task to day is to write something that will mark which objects are partially occluded, and record which occluder(s) are partially hiding it. I can then reference the first occluder when a second also partially hides it, and then in theory merge the two (or more) volumes to see if their combined efforts completely hide the object. I can slam in some code but my mind wants a fast efficient way to do it, as this will be running 60 times a second and I want the code to be practically invisible from the performance metrics.
Reloaded Day One
Today officially marks the first day of the Reloaded project! Up until now the prototypes where created ahead of schedule as I was itching to start coding. Today however is when the egg timer turns and all eyes are on me to complete this little project in time for Christmas.
I have mapped out my duties over the next eight months very roughly, and mapped out my duties over the next three weeks specifically. All things being equal, next week will see the elimination of the 'build phase' and separate FPSC-Game.exe executable so you can click a button in the editor and instantly play the game. The following week will see real time light-mapping of the scene as you are editing it (segments and entities) and the third week will see the introduction of entities that have a built-in dynamic light that can cast a single shadow map into the scene. Putting all that together, you will be able to drop in area lights for effective static light-mapping and spaced our dynamic lights to cast lovely real-time shadows from any dynamic objects in the scene. I will wrap the whole thing up with some cool scene graphics provided by Mark and should have a playable alpha of this part of the product by the 25th February.
Over the years, I have learned the best way to get a product finished is to finish it quickly. Spend too much time planning, drawing little sketches, tinkering with funny little modules or mulling over the enormity of the project and chances are you will never finish it. I have a heap of stuff to do, and only a few short months of fevered activity to do it in, so the sooner I can get the general shape of the new product carved out the better.
The following month (providing I hit my target) will be a coin toss between the new physics system or the new terrain system. Both equally relevant and connect directly to the work done in February. I think terrain has the edge given this geometry also needs to be light mapped and incorporated into the editing experience.
In doing some advance research into physics, I have found Bullet Physics to be a good contender for selection over PhysX. Bullet is completely free (PhysX has priced licensing), Bullet is GPU accelerated on AMD cards, it's open source which means I can fix anything that goes strange and the online demos are very cool indeed. I will return to this comparison of features closer the time but I find my mind getting excited to think that after we finish Reloaded, the very next thing I will want to do is add vehicles with trailing cloth banners, riding on it's soft body tyres across a dynamic rope bridge at break neck speed before crashing through a destructible wall into someone's living room.
Early Knock
We have a saying here in England (and Wales I think) called 'Early Knock' which means if you get all your work done quickly you can go home. I plan to have an early knock today and be finished for 5PM as I am driving to Wigan this weekend to fill a skip with lots of yucky things.
This means I will not have the weekend to tinker with prototypes or play more games, but I am pretty sure next weekend is completely free so something to look forward to there.
Signing Off
With the FPS game Dishonoured complete and back on my shelf, I will probably be picking up a new FPS game to install, perhaps Borderlands 2 which has come highly recommended. The game is not directly related to the work that needs to be done in February, but the knowledge will sit in my head and mature like a fine wine :)
Morning broke at 5:30AM today and got emails done in just 30 minutes, so had time to finish lots of little tasks scattered around my machine. New FPSC beta uploaded and further work to migrate my work files to the new machine. The big task of the day of course is some lovely Reloaded work
P002 Continued
As you recall, last time we got a single bound box casting an occlusion shadow over the scene which hid anything within it. The current issue is that anything that is partially occluded is left visible, even if a second occluder hides the parts remaining visible.
The task to day is to write something that will mark which objects are partially occluded, and record which occluder(s) are partially hiding it. I can then reference the first occluder when a second also partially hides it, and then in theory merge the two (or more) volumes to see if their combined efforts completely hide the object. I can slam in some code but my mind wants a fast efficient way to do it, as this will be running 60 times a second and I want the code to be practically invisible from the performance metrics.
Reloaded Day One
Today officially marks the first day of the Reloaded project! Up until now the prototypes where created ahead of schedule as I was itching to start coding. Today however is when the egg timer turns and all eyes are on me to complete this little project in time for Christmas.
I have mapped out my duties over the next eight months very roughly, and mapped out my duties over the next three weeks specifically. All things being equal, next week will see the elimination of the 'build phase' and separate FPSC-Game.exe executable so you can click a button in the editor and instantly play the game. The following week will see real time light-mapping of the scene as you are editing it (segments and entities) and the third week will see the introduction of entities that have a built-in dynamic light that can cast a single shadow map into the scene. Putting all that together, you will be able to drop in area lights for effective static light-mapping and spaced our dynamic lights to cast lovely real-time shadows from any dynamic objects in the scene. I will wrap the whole thing up with some cool scene graphics provided by Mark and should have a playable alpha of this part of the product by the 25th February.
Over the years, I have learned the best way to get a product finished is to finish it quickly. Spend too much time planning, drawing little sketches, tinkering with funny little modules or mulling over the enormity of the project and chances are you will never finish it. I have a heap of stuff to do, and only a few short months of fevered activity to do it in, so the sooner I can get the general shape of the new product carved out the better.
The following month (providing I hit my target) will be a coin toss between the new physics system or the new terrain system. Both equally relevant and connect directly to the work done in February. I think terrain has the edge given this geometry also needs to be light mapped and incorporated into the editing experience.
In doing some advance research into physics, I have found Bullet Physics to be a good contender for selection over PhysX. Bullet is completely free (PhysX has priced licensing), Bullet is GPU accelerated on AMD cards, it's open source which means I can fix anything that goes strange and the online demos are very cool indeed. I will return to this comparison of features closer the time but I find my mind getting excited to think that after we finish Reloaded, the very next thing I will want to do is add vehicles with trailing cloth banners, riding on it's soft body tyres across a dynamic rope bridge at break neck speed before crashing through a destructible wall into someone's living room.
Early Knock
We have a saying here in England (and Wales I think) called 'Early Knock' which means if you get all your work done quickly you can go home. I plan to have an early knock today and be finished for 5PM as I am driving to Wigan this weekend to fill a skip with lots of yucky things.
This means I will not have the weekend to tinker with prototypes or play more games, but I am pretty sure next weekend is completely free so something to look forward to there.
Signing Off
With the FPS game Dishonoured complete and back on my shelf, I will probably be picking up a new FPS game to install, perhaps Borderlands 2 which has come highly recommended. The game is not directly related to the work that needs to be done in February, but the knowledge will sit in my head and mature like a fine wine :)
Subscribe to:
Posts (Atom)