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.
No comments:
Post a Comment