Normal Service Resuming… slowly…

Hi all 🙂

Without belabouring the point – although far from ‘back to normal’ my back is improving – I can at last carry my laptop with me on my commute, so work is resuming!

So – it’s been a while since the last update I made to whine about my back…

In the meantime, I’ve been pursuing Intel and Apple about a graphics driver bug that exists with the Intel HD 5000 Windows 7 drivers, which means doing any serious graphics work on my Mac Air is utterly impossible. As it’s an Intel driver, running Intel hardware under Windows (my Mac Air is bootcamped), I approached Intel first.

They said it’s an Apple Support issue. This is going to be a rant btw, so feel free to skip on a bit 🙂 I challenged them – wanting to know why Apple should support Intel software and hardware. I also supplied source code for a tutorial available on the web that demonstrated the issue, and pointed out it only fails using the Windows 7 drivers from Intel, the tutorial worked fine under OSX. They went quiet. For months.

Meantime, I then bit the bullet, raised a Radar issue with Apple, and explained I was being fobbed off by Intel. Over a month elapsed, and Apple responded with a very detailed analysis of the tutorial code I’d sourced – with fixes. I am impressed.

To be fair to Intel, they have also now come back with the same fixes for the tutorial code.

Sadly they don’t address or resolve the problem I’m having – which is this…

To get normal mapped ships, I use glew to add extensions to allow vertex tangents to be provided to the rendering shaders. This works dandy on ATI and nVidia GPU’s. Only on Intel HD5000 under Windows 7 – it goes pants up. All I get is a sphere of the model geometry, with a unit radius of 1.0

(BTW – the pink stuff is actually the ‘Default’ texture used by 666 if none is supplied. This model is skinned by selecting one in-game within Dom itself.)

Now, if I just turn off sending the vertex tangent array to the HD5000, it renders the correct geometry…

… except of course, now Normal Mapping is impossible – and we lose all the luvverly goodness it offers.

Thus – to me – there’s a problem with the HD5000 Windows 7 driver handling glew extensions for vertex arrays. The latest response from Intel, having sent the above proof – again – is – again –  ‘Contact Apple’.

Nice, real nice support. Cheers. I’m left with a Mac Air I cannot use for serious development of Dom under Windows 7 – which is precisely the reason I purchased the Mac Air in the first place. Dual OS development, lightweight, fast. But now useless.

So… the long of this is – I’ve now updated the Mac OSX build of 666, so I can get Dom up and running on the Mac Air and do some graphics development instead of using Windows 7. It’s compiling and linking, but there are some kinks in the rendering pipeline somewhere as everything is rendering in Salmon Pink 🙂 Sadly, fixing this means using XCode – which is an IDE I’d rather not use for serious development. I know this, as I use it every single day to do my full time RL job of iOS development. As a case in point – it won’t debug into a static C/C++ library, so I can’t find out what the rendering issue is. According to Apple, this is a known bug with XCode. Odd then that it’s been there for 3 major versions of the IDE…

Speaking of iOS development – I’ve also updated the iOS build of 666 to run on device. Getting Dom onto it is not so easy though, as I’ll have to start dumbing down the game, model LOD’s and shaders to fit into OpenGLES2.0 – that’s work I’ve got slated for much later after Dom is something tangible.

What else… ah yes, TimelineFX. I had high hopes for this awesome particle effects system. Although there is no C/C++ SDK for it, it’s written in Monkey, which can generate a C/C++ application with source that can render and animate the effects. As TimelineFX comes with a whole raft of awesome particle effects for free which would look ace in Dom, I set about creating a C/C++ library from that generated source that could be used by anyone to import and render its effects, which I intended to then give back to TimelineFX for them to do as they will.

Sadly, it’s not to be. Yet. The generated code is – frankly – horrific, as generated code has a tendency to be. I’ve fought through it and got it to a linkable state, but to integrate it into my engine requires fundamental changes to load up textures and render the images. I can plough through this and re-engineer it, but it’s going to take a lot of time and effort, and I’d have to do it all again if TimelineFX gets updated. Lack of joy 🙁

Also, it’s a natively 2D particle engine… I have cunning plans to ‘3D’ it – but as there’s no guarantee that would work it’s now ‘parked’ – for now. I may revisit it again later though, because the effects would be worth the effort I think…

And finally, I am polishing the final draft of Insurmountable Odds – Book 1 of When Stars Fall… (the Dominium Trilogy I’m writing), with a view to self-publishing it on iBooks, Google Play, and Kindle. Perhaps it can earn a few pence to go towards Dom Development 🙂 Who knows!

Given the lack of progress this year so far, I’ll keep the next Newsletter for the end of March in the hope that I can push a few more weekly updates into it to make it worth reading 😉