Jump to content

  • Log In with Google      Sign In   
  • Create Account

Not dead...

Slowly becoming more and more disappointed...

Posted by , 29 September 2012 - - - - - - · 3,400 views
windows 8, xna, metro, stupidness
I'm slowly... oh so slowly... starting to crack.

MS have some blame to take here because they are apprently not communicating well enough but at the same time the latest Windows release is starting to bring out the Silly Season in a manner not seen since Windows Vista... in fact it's worse because it would seem people are not using their brains and its got to the point where I'm facepalming as I read twitter/blogs and... well.. I'm writing this at half-midnight on a sunday morning.

The first 'gem' which started to push me over the edge was the recent thing I saw where someone tweeted that 'windows 8 was a closed system'.

So, yes, there is this windows store and yes it will be the only way for end users to get at Metro apps but metro apps are not the only apps. I dunno, maybe it's just me but if the option to control where, more than likely the vast majority of the apps I'm going to install, comes from exists and they don't have to be signed and delivered from a single source I'm pretty sure that's not a closed system.

So, my Windows 8 machine could still run/install unsigned apps just like my Windows 7 machine currently does.
No change there.

(Minor side note: latest OSX release turned on 'app store or signed' only running of apps. Fortunately you can turn this off in the control panel but switching it on, silently, by default for all apps is pretty sneaky imo. And Vista users thought UAC was bad.)

The thing which really got to me however is the continued wailing about XNA which is going on and a blog post which tipped me over the edge.

Now, to be fair I think part of this can be put down to an MS employee not understanding a question correctly and thus giving a poor answer but the basics of it boil down to a developer asking 'will XNA work on Windows 8?' and being told 'no, never.'

Now, while I've not tried personally, I've heard that XNA based games are indeed working just fine on the RC version of Windows 8; which isn't surprising really considering XNA is a .Net library which wrap DX9 and Windows 8 supports .Net and thus the XNA runtime and if Windows 8 didn't support DX9 it would die a death anyway as no one would buy it because they couldn't play Half-Life 2 (and lets face it, it would give Gabe more reasons to cry about Win8).

What I think happened was that the MS employee heard 'XNA' and 'Windows 8' and assumed the asker was asking 'Will XNA work via Metro/WinRT?' which, of course, the answer is 'no' (which isn't really unexpected).

The net result; yet another blog post of uninformed opinions with no real basis in fact (and I'd like to say well done to a few commenters for trying to correct the amount of 'wrong' in that post) but, more importantly, the developer in question has swapped to using Unity for their game. Now, unless Unity at some point has a WinRT wrapper (and I believe they are trying to sort something out in that regard?) then Unity is working at the same level as XNA would have with regards to the OS, APIs etc.

*face-fucking-palm*

Of course this was an interview where the developer had no real idea about what XNA was, even refering to it as a language multiple times, so ya know I'm not assuming large technical competance but it just seems like the kind of thing you could figure out with a bit of logic ya know?

Which is where this wandering post is going to; an increasingly sad state where people jump on bandwagons and panic without bothing to research things themselves.

I've got no inside line at MS; I don't know anyone personally and I work for a living so I can't dedicate all my time to following tech; yet somehow I can figure out all this stuff but others can't?

A few months back Gabe of Valve fame declared Windows 8 a 'disaster' for gaming in what can only be described as 'scare tactic of the fucking decade' by anyone who takes a few seconds to look at the claim. Does Windows 8 control what software you can install? No. Does Windows 8 'hide' non-MS software? No. Hell do you think they would turn down a Metro based version of the Steam UI if Valve wanted to provide one? No.

It's not like Steam is a weak name either; practically every PC gamer going to going to know about Steam, even my mum has an idea of what it is thanks to my dad using it for games - I'd even go as far as to say 'Steam' as a brand is stronger than 'Windows' when it comes to gaming and the core audience they supply software to.

(Of course this all fell into place when a day or two later Valve announced they would be selling non-game apps via Steam - at which point the light bulb in my head got so bright it burnt out.)

Of course the arguement could be made that the MS store in Windows gives them an unfair advantage but my problem with that is - sure, but they have to get software to sell first; if developers don't put it on there then what advantage? And if they do its because they like the terms or are getting better terms so.. ya know.. compete?

It seems that the software industry is slowly, or not so slowly I guess, becoming a mire of conjecture, lies, sensationalism and down right misinformation. From PR people I could at least understand it but some of this stuff is coming from people who should be looking at the facts and not going around throwing out terms without any checking.

In a way its starting to become like mainstream politics; facts are out of the window and its down to making your opponent look bad rather than making yourself look good and having answers.

It depresses me and makes me think about just saying 'fuck it..', packing up and going to live in a cave somewhere.

(Oh, and I don't vote either...)


Week off.

Posted by , 10 June 2012 - - - - - - · 1,022 views

I've had the last week off.

I had plans involving OpenCL.

Then Max Payne 3 happened.

Such a well executed game; the story was really good, the characters were realistic and engaging and there is nothing more satifying than doing a bullet time drive into a room and popping 3 guys in the head with 3 shots ;) The sound track rocks; it fits so well with the setting its crazy and the graphics on the PC version were pretty awesome.

The whole story mode is like playing a film in a way, the combination of game play, voice over, cut scenes and subtle interactive hints (such as Max saying "I knew I couldn't stay here long..." when the game thinks you should move forward) was really well done.

A few minor issues such as cut scenes jumping slightly from game play or the tendency for Max to sometimes forget the gun he was holding... that said it doesn't happen all the time so when he is done with a cut scene he'll pick up the submachine gun he put down on a shelf before walking off...

So far, game of the year for me, no contest.
(Sorry ME3)


Sounding off....

Posted by , 28 May 2012 - - - - - - · 829 views

There are two things I dislike about games and to an extent software development in general.

One of them are the gamers themselves; I could rant about this for ages but I'll refrain.

The other is the massive weight of resistance to anything new or not understood which seems intent on holding the whole state of the art back to What Is Known.

It annoys me because instead of trying to look for the good in new things people seem intent on trying to tear them down or pick holes in them without offering any constructive ways to improve; "waaaah it is different there fore it is bad and we like what we have!"

It's nothing new I admit; this refrain can be heard down the years probably echoing back to long before I was born a good 30 years ago.

Even professionally there is resistance; for a chunk of the last two months while I've enjoyed the freedom of working with C#, TPL and LINQ it has been against a back drop of resistance to things not understood; "what are these tasks things?" - "is this the best way of doing it" - "isn't this going to cause deadlocks?" and being told that by using LINQ I'm doing 'fancy stuff' when its a facility built into the language!

I appreciate that not eveyone has time to learn everything, that sometimes you have to look at a bit of technology and let it pass you by (I did myself with pretty much everything after .Net2.0 because I didn't have the time) but this doesn't account for the resistance - sometimes you just have to trust people who have had the time to look into something.

Maybe I'm just one of the few and the brave always willing to look forward to try the next thing to see if it will make life easier or not..

I'm not saying 'embrace everything as the answer to all our problems' but the constant resistance is nothing but a sad statement about what should be an industry where things are pushed foward - not sat in a corner playing with what is safe.

So I say this; pick a weekend, any weekend, but soon and try something new - a language. An IDE. A design method. An API. Anything...

Not every shiney new thing will be a diamond - but without searching we don't stand a chance of finding anything at all.


Slow progress...

Posted by , 09 May 2012 - - - - - - · 808 views
C#, Tasks, LINQ
Not a great deal to report from the front; having spent a few hours on trains over the weekend I've managed to chew into the DLR book I have a fair chunk. It is slow going but progress is being made in my head which is nice.

Most of my time at work has been spent working on our new data build pipeline (I am a rendering coder, honest!) which has let me do something I've been wanting to do for some time and really stretch my wings a bit with C# and .Net4.

Over the last few weeks I've come to love the whole Task system in .Net 4 so much so that, after some initial resistance from those who didn't know about them in general, I've managed to convince the other guys working on it that using Tasks as the basis of the build system is the way forward. It isn't a strict task system; asset processing rules themselves get launched as 'long running' tasks which means they get a new thread, as to tasks which kick off an exe to do some processing however the ability to just throw work around and know that it'll get done and back to you does make coding quite relaxing.

It isn't completed yet however it is already leaps and bounds better than our old python build system (a pox on the GIL!) and has afforded me a nice chance to learn somethings.

In fact today, while converting some build rules from Python to C# I took the time to dive into LINQ too, which I've always liked the look of but never had a chance to try. It has made parsing XML files and pulling out data MUCH saner so yeah, pretty much in love with that too... so much so I want to revisit some already converted rules armed with this new knowledge :)

So, if you haven't got around to it already I would urge you to have a play with the Task system in .Net and the LINQ stuff; an afternoon of learning and playing around adds a couple of extra useful tools to your skill set.


Learnings.

Posted by , 13 April 2012 - - - - - - · 853 views

So, my own rendering project at home has been stalled of late : between Mass Effect 3, F1 races, going back to my home town and being ill I've not had the time to work on it too much.

The weekend before last I wrote some code to setup a simple Win32 window so that I could crack on but beyond that things haven't progressed too far.

While I do intend to carry on with the project over time (because there are some things I want to try out) I've also shifted my attention to properly learning about the Dynamic Language Runtime (DLR) in .Net4.

My motivation behind this is down to a growing frustration at work with our material data system and the amount of work it takes to work with them.

Broadly speaking out materials are broken up into 3 parts;
  • templates
  • types
  • materials
Templates are the lowest level; they define all the input data and configuration options that can be applied to a shader.
Types are a set of configurations for a shader and are used to control shader compiling.
Finally the 'materials' themselves are an instance of a type/template which holds the parameter settings and what textures should be applied to them.

As a system it works very well however there are still some issues with it mostly to do with redeclarations of information.

You see there is a 4th, slightly hidden, component to the above; a python script.
This python script is used to help process the information in a material into a 'game ready' state.

The build system uses it on a per-material basis to work out what operations should be done to textures to make them 'game ready' as well as how parameters should be packed together so that the game team can control what entries go where in each float4 block.

This flexibilityis nice however it brought with it some problems, mostly with textures but also with parameters.

With textures there is no longer a 1:1 mapping between what the artist attaches and what the shader reads. The pipeline could, for example, take two textures and combine them to produce a 3rd which is used in the game. It could split a texture into two. The most extreme example we could think of was that a texture could be processed, it's average lum. value worked out and this feedback into the material as a parameter.

The first problem however was the lack of 1:1 mapping and this was 'solved' in the script by having it remap the inputs to the correct outputs when it was a pass thru operation. This was done, everyone was happy and on we went.

The parameters came next and they had the same problem; as we could pack parameters together now there 1:1 mapping was once again removed so once again the python script performed the remap and pack operation and all was good.

Then another problem appeared; live link.
Via a connection to the game it is possible to change material parameters on the fly however with the broken 1:1 mapping we now needed a way to tell the editor how to pack data together to send it over the wire and, more importantly, which artist inputs trigger updates on what parameters in the shader.

And thus was born a 'live link' map which could be used to figure out what inputs affected what outputs, would let you run a python script (via IronPython) to condition the data if required and all was good once more.

Until the max shaders needed to be dealt with, at which point the lack of 1:1 mapping for the textures once again appeared. As the max shader could be heavier than the final in-game shaders there was no requirement to build the data for visualisation however it still needed to know what inputs mapped to what shader inputs and thus the 'max map' was born.

So now a template is defining
  • config options
  • artist inputs
  • material outputs
  • 'live link' mappings for parameters
  • max mappings for parameter and textures
But at the same time the python was also defining the mapping between parameters and textures for input & outputs so already the information is duplicated and easy to get out of step.

Finally the system isnt as easy to use as I had hoped. Yes, I did the python work and in my head I saw the idea of having centralised 'packing' functions for the scripts however this hasn't happened; instead the game team have been duplicating functions and copying and pasting things around.

Between the duplication, the 'logic' in the XML, the scripting issues and the general slowing of the build pipeline I've finally snapped.

Which brings us to the DLR.

What I would like to produce, using the DLR, is a domain specific language which can replace all of the above.
Our build system, tools and max plugin are all based on .Net4.0 now so the DLR is a key part of that so being able to load and run a 'script' which defines a template seems like a good fit.

My hope is that, given some time, a language can be designed which allows you to declare the various inputs, outputs & transformations and that, by using a plugable backend, the same script can be used by the tools and build system to a different end.

For example if you were to write:

declare parameter "foo" float

then the tools would know to create an input in the UI for a single float with the label/name foo while the build system would know to look for an input named 'foo' in the material file it was passing.

Now, that syntax is by no means final but a more declarative syntax would be a better fit I feel and with some decent library support for data packing/transform built in (and expandable via .Net dlls) could make a viable replacement.

Now, I only had the idea around 48 hours ago and I've only recently started working on learning the DLR however as projects go I think this would be worthwhile.






Recent Entries

Recent Comments