Posts Tagged‘framework’

Dual Shock 4

Next Gen Consoles Will Peak Early, Peak Hard.

The current norms for games consoles are going to be flipped on their head when the next generation comes online. There are some things we could argue that are expected, like the lack of backwards compatibility, but the amount of change coming our way really doesn’t have any comparison in previous console generations. In nearly all respects I believe this is a good thing as many of the decisions made seemed to be born out of a mindset that worked 2 decades ago but was becoming rapidly outdated in today’s market. However one significant change could have a detrimental impact on consoles at large and could open up an opportunity for the PC (and by extension the SteamBox) to make a comeback.

Dual Shock 4The next generation of games consoles are shaping up to be some of the most developer friendly platforms ever created. Not only are they x86 under the hood, allowing many frameworks developers for regular PC games to be ported across with relative ease, many of the features that they have are a direct response to the requests from developers. This means that developers will be able to make use of the full power of these consoles from much earlier on and whilst this will make for some great launch titles that will be leaps and bounds above their previous generation predecessors it does mean that they’ll reach their peak early, and that might not be a good thing.

It was always expected that the best games of a console generation would come out towards the end of its lifecycle. This was due to games developers becoming far more familiar with the platform and the tools reaching a maturity level that made creating those games possible. The current generation, with its record breaking longevity, is a great example of this with the demos of current and next gen titles running on both platforms being very comparable. With the next generation being so developer friendly however I can’t imagine it taking long for them to be able to exploit the system to its fullest extent within a short time frame. Couple this with the next gen expected to have a similar life to the current gen and you’ve got a recipe for console games being stagnant (from a technology point of view) for a very long time.

Granted there will always be improvements that can be made and I’d still expect the best titles to come towards the end of its lifecycle. However the difference between first year and last year titles will be a lot smaller and in the case of the end user I doubt many will notice the difference. With the shared x86 base however there’s a big potential here for the PC versions of the games to start out pacing their console counterparts much earlier on as some of the optimizations will translate readily across, something which just wasn’t possible with previous platforms.

Indeed due to the current gen limitations we’ve already begun to see something of a resurgence in PC gaming. Now its likely that this could be dampened when the next gen of consoles get released however due the reasons I’ve outlined I’d expect to see the cycle begin again not too long afterwards. I do doubt that this will see PCs return to the glory days of being the king of gaming but there’s a definite opportunity for them to grab some significant market share, possibly enough to be elevated past their current also-ran status.

Of course this is wild speculation on my part but I do believe that the next generation of consoles will peak much earlier in its lifecycle which, as history has shown us, will usher people back towards the PC as a platform. With the SteamBox readying itself for release around the same time there’s ample opportunity for current gen console customers to be swayed over to the PC platform, even if it’s camouflaged itself as one of the enemy. In the end though the next gen consoles will still represent good value for money for several years to come, even if they’re quickly outpaced.

 

 

Windows 8 RT Running x86 Programs

Windows RT Running on ARM Has Full Win32 Compatibility.

As far back as I can remember the differences between the full version of Windows 8 and the tablet version, now dubbed Windows RT, were made pretty clear. Whilst the Modern UI section of them was going to be essentially identical the full version of Windows wasn’t going to run on anything that wasn’t x86 compatible and RT would be the version that could run on low power systems like ARM. This, logically, came with some draw backs the largest of which is the omission of the desktop environment on Windows RT devices. In all honesty this didn’t bother me as Microsoft is making a version of their Surface tablet (and I’m sure others will as well) that would run the full desktop anyway.

The delineation also made a lot of sense due to the different markets that both versions were targeting. The full version is squarely aimed at the desktop/laptop space whilst the RT version is strictly for mobile computing. In terms of functionality there’s a lot of crossover between these two spaces but the separation essentially meant that you had your desktop with its oodles of backwards compatibility that Microsoft is known for whilst also getting that nice, highly focused tablet environment should you want it.

However as it turns out Windows RT is far more full featured that I first thought and is capable of running Win32 applications:

Windows 8 RT Running x86 Programs

Thanks one intrepid user, Clrokr, over at XDA Developers it has been found out that Microsoft actually included full Win32 compatibility in Windows RT devices that run on the ARM architecture. Whilst this doesn’t mean you can straight up run those executables on said platform it does mean that any Windows application that you have the source of can be recompiled to run, without issue, on Windows RT devices. The above screenshot is from another user, peterdn, who has recompiled PuTTy to run on ARM and it appears to be functioning quite fine. Other applications have also been tested as well and shown to work as you’d expect.

Thinking about it more clearly this shouldn’t have come as a surprise as the architecture diagram for Windows 8 clearly shows that C/C++/C# are fully supported on both platforms and the inclusion of the desktop on Windows RT devices (again something I wasn’t aware of) would have you thinking everything was there to support this. As it turns out the only thing that was stopping this from working in the first place was runtime authentication level that was hard coded to only allow Microsoft signed applications to run in such an environment. The jailbreak that Clrokr details in this post is simply an in memory overwrite of this value which will allow any application to run. From there you just need to recompile your application and you’re golden.

The reasons for the lock out make sense from a business point of view: Microsoft was trying to create a pristine tablet environment that was tightly controlled in order to create a better experience. However at the same time porting all of the underlying architecture to ARM would have required quite a bit of effort and locking this functionality away from people seems like a strange idea. Whilst I’m not going to say they should unlock it for everyone having it as a configurable option would have meant that most users wouldn’t know about it but power users, like the ones who discovered this, could take advantage of it. I haven’t seen if Microsoft has made an official response to this yet or not but I’m sure they’d win more than a couple fans if they did this and it doesn’t look like it would be that hard to implement.

I was genuinely surprised by this as I hadn’t caught on pretty much all of Windows, including everything that makes it tick under the hood, had been ported across to the ARM architecture. I had believed that it was just a port of the core functionality required to support the WinRT framework but as the above screenshots prove Windows RT devices are pretty much fully fledged copies of Windows, they just need their applications recompiled in order to work. Of course questions of how those applications fair vs their modernized counterparts in a tablet environment remains to be seen but it’s interesting that the option is there and that Microsoft has gone to such lengths to keep people from fiddling with it.

 

WinRT

Windows 8 and WinRT: On the Cusp of Platform Unification.

Last week saw the much talked about Microsoft BUILD conference take place, the one for which all us developers tentatively held our breath wondering what the future of the Microsoft platform would be. Since then there’s been a veritable war chest of information that’s come from the conference and I unfortunately didn’t get the time to cover it last week (thanks mostly to my jet setting ways). Still not writing about it right away has given me some time to digest the flood of information and speculation that this conference has brought us and I personally believe that Windows 8 is nothing but good news for developers, even those who thought it would lead to the death of their ecosystem.

For starters the project codenamed Jupiter has an official name of Windows Run Time (WinRT) and looks to be an outright replacement for the Win32 API that’s been around since 1993. The big shift here is that whilst Win32 was designed for a world of C programmers WinRT will instead be far more object-oriented, aimed more directly at the C++ world. WinRT applications will also use the XAML framework for their user interfaces and will compile to native x86 code rather than to .NET bytecode like they currently do. WinRT applications also do away with the idea of dialog boxes, removing the notion of modal applications completely (at least, in the native API). This coupled with the fact that any API that takes longer than 50ms to respond being asynchronous means that Metro apps are inherently more responsive, something that current x86 desktop apps can’t guarantee. Additionally should an app be designed for the Metro styled interface it must only use the WinRT libraries for the interface, you can’t have mixed Metro/Classic applications.

If you’re after an in-depth breakdown of what WinRT means for developers Miguel de Icaza (of Mono fame) has a great breakdown here.

WinRT will also not be a universal platform on which will provide backwards compatibility for all current Windows applications. It’s long been known that Windows 8 will be able to run on ARM processors but what wasn’t clear was whether or not current applications would be compatible with the flavour of Windows running on said architecture. As it turns out x86 applications won’t work on the ARM version of Windows however applications written on the WinRT framework will run on every platform with only minor code changes (we’re talking single digit lines here). Those legacy applications will still run perfectly well in the Desktop mode that Windows 8 offers and they’ll be far from second class citizens as Microsoft recognizes how things like their Office suite don’t translate well to the tablet environment.

At the same time Microsoft has also announced that the web browser in the Metro UI will not support any kind of plug-ins including their very own Silverlight. Of course you’re always welcome to switch into desktop mode should you visit a website that requires a plug-in but Microsoft said the aim is for everyone to transition away from plug-ins and onto the HTML5/JavaScript stack. On the surface this seems to verify the notion that Silverlight developers are screwed as all their apps are second class citizens in the new Metro world. However since WinRT apps are developed in a very similar way to that of Silverlight apps the transition to the Metro platform will probably be nothing more than changing namespaces and tidying up the UI so it fits in with the new design. Distribution of said apps will then come via the Microsoft app store, rather than a company’s web server. Sure it’s a paradigm shift away from what they’re currently used to, but Silverlight developers will find themselves right at home with WinRT.

Taking this all into consideration it seems like there will be a line in the sand between what I’ll call “Full” Windows 8 users and “Metro” based users. Whilst initially I thought that Jupiter would mean any application (not just those developed on WinRT) would be able to run anywhere it seems that only WinRT apps have that benefit, with current x86 apps relegated to desktop mode. That leads me to the conclusion that the full Windows 8 experience, including the Desktop app, won’t be available to all users. In fact those running on ARM architecture more than likely won’t have access to the desktop at all instead being relegated to just the Metro UI. This isn’t a bad thing at all since tablets, phones et. al. have very different use cases than those of the desktop but, on the surface at least, it would appear to be a step away from their Three Screens vision.

From what I can tell though Microsoft believes the future is Metro styled apps for both desktop and tablet users a like. John Gruber said it best when he said “it’s going to be as if Mac OS X could run iPad apps, but iPads could still only run iPad apps. Metro everywhere, not Windows everywhere.” which I believe is an apt analogy. I believe Microsoft will push WinRT/Metro as the API to rule them all and with them demoing Xbox Live on Windows 8 it would seem that at least on some level WinRT will be making it’s way to the Xbox, thereby realizing Microsoft’s Three Screens idea. Whether the integration between those 3 platforms works as well as advertised remains to be seen but the demo’s shown at BUILD are definitely promising.

Windows 8 Able to Play Xbox Games? The Three Screens Unification Continues…

I’m not usually one to comment on rumours since most of the time they get us no where and have great potential to disappoint, something I like to avoid. Still if there’s a plausible root to a rumour that warrants investigation I’m more than happy to have a go at it since the sceptic in me loves debunking stuff and the geek revels in future possibilities that have their base in reality. Today such a rumour fell right into my lap with the usual lack of any official confirmation (or denial) and just a few tenuous clues as to how this reality could come to be.

That rumour was that Microsoft’s next iteration of Windows would be able to play Xbox games.

Of course the first part of any rumour is to try and track down the original sources to see if there’s any more information you can glean from them. After starting at Destructoid and working my way down the rabbit hole of back links I eventually came to these two sites who don’t even classify this idea as a rumour but give little else on the details. It’s long been known that Xbox Live would be coming to Windows 8 (much like it has come to the Windows Phone 7 platform)  but the idea that you’d be able to load up your Xbox games on your PC or tablet device was a new and novel idea that no one had really considered before. Since this information is coming to us via reports of finding Xbox360 code references in the leaked Windows 8 builds it would be easy to write it off as pure rumour milling, but I think there’s a bit more to it than that.

I’ve long talked about Microsoft’s Three Screens vision for the future world of computing, an idea where no matter what your viewing device (being either that of your PC, portable device or TV) the experience remains the same. Windows 8 was the first step towards this with the Metro inspired UI that will be available across both PC and tablet devices alike. One piece of the puzzle was missing however, the TV, and if I’m honest I wasn’t sure what strategy Microsoft was going to go for in order to bridge the gap. The answer, I believe, lies within Xbox Live as with its debut on the PC it will become the very first Three Screens enabled application, being available on all of them with a comparable experience on each. Once the path is paved by Xbox live it should be a lot easier to bring further applications into the Three Screens world, especially if they’re able to bring the .NET platform to those same platforms.

One of the big questions that looms over this rumour is how a PC will be capable of playing Xbox games, especially some of the more recent titles. Many of the games on the Xbox and Xbox360 make heavy use of the specific architecture of the platform in order to gain significant performance benefits. Whilst you could emulate the entire system in software it’s more than likely that any recent title would run quite poorly, to the point of not being playable. Taking this into consideration I believe it’s more likely then that, at least initially, the only games that will be available will be those developed on Microsoft’s XNA framework. It can be argued that most of the games built on this framework are more than likely already available on the PC (indeed this is the main reason many choose XNA in the first place) but since there’s no market currently the visibility of such games is a lot lower than it could be. Thus the introduction of Xbox Live (along with its Arcade section) coupled with the availability of XNA titles is a very real possibility for Windows 8, but how Microsoft will go about this remains to be seen.

It will be interesting to see how Microsoft reacts to this rumour as whilst they’re not usually into playing the rumour game they’re definitely more loose lipped than say, their Cupertino counterparts. Personally I’m more excited about the possibility that Microsoft is pursuing their Three Screens vision with the beach front into this world being one of my passions. Whether this rumour has any shred of truth to it though remains to be seen and we could be waiting up until the betas before we know any more about it. Still with the amount of interest this has generated in such a short time it would be interesting if Microsoft didn’t pursue this at least in some fashion since it would be a massive step towards their platform unification strategy.

Still In The Grok Stage.

After reaching 1.0 of Lobaco I’ve taken a breather from developing it, mostly so I could catch up on my backlog of games and give my brain a well deserved break from working on that problem space. It’s not that I’m tired of the idea, I still think it has merit, but the last 6 months of little free time on the nights and weekends were starting to catch up with me and a break is always a good way to kick start my motivation. It didn’t take long for numerous new ideas to start popping into my head afterwards and instead of jumping back into Lobaco development I thought I’d cut my teeth on another, simple project that would give me the experience I needed to migrate Lobaco into the cloud.

The weekend before last I started experimenting with ASP.NET MVC, Microsoft’s web framework that based on the model-view-controller pattern that I had become familiar with after deep diving into Objective-C. I could have easily done this project in Silverlight but I thought that I’d have to man up sooner or later and learn a proper web language otherwise I’d be stuck in my desktop developer paradigm for good. The results weren’t spectacular and I could only bring myself to spend about half the time I usually do coding on the new site, but there was progress made there none the less.

Last weekend was more productive with me managing to make the site look something like the vision I had in my head. Satisfied that I could design a decent looking website I decided to start hacking away at the core fundamentals of the application. This is where I rubbed up against the limitations of the framework that I had chosen for this particular project, not knowing that whilst ASP.NET MVC might share most of its name with its ASP.NET cousins it is in fact a world away from it. Sure it’s still extremely capable but it’s nothing like the drag and drop framework that I had been used to with other Microsoft products, leaving me to research pure HTML and Javascript solutions, something which I had avoided like the plague in the past. This meant that progress was pretty slow and the temptation to play Starcraft 2 with a bunch of my good mates was too strong and I left it there for the weekend.

The slow progress really frustrated me. After finally gaining competence with Objective-C I felt like learning yet another new framework would be easy, even if it meant learning another language. Somehow I managed to forget that frustrating first month where progress was almost nil and I convinced myself I wasn’t procrastinating when looking for other solutions to my problems. Eventually I came to the realization that I was still grokking the new framework I had chosen for my application and that I shouldn’t be expecting myself to be blazing trails when I was still establishing my base of fundamental knowledge.

I see lots of people go through the same struggle when trying out new things and can see how easy it is to give up when you’re not making the kinds of progress other people are. Believe me its even worse in the tech/start-up area where every other day I’m reading about someone who hacked together a fully usable service in a weekend whilst I struggle to get my page to look like it wasn’t written in notepad. The realization that you’re still in the grok stage of learning something new I find to be quite a powerful motivator as past experience has shown that it’s only a matter of time and persistence between floundering around and becoming quite capable.

I’m usually the first one to tell people to stick with what they know as re-skilling is extremely expensive time wise (and can be $$$ wise too, Objective-C set me back a few large) but the pay-offs of diversifying you skills can be quite large. Whilst I’ve yet to make any semblance of a dollar from all my adventures in iPhone development I still count it as a valuable experience, if for the mere fact it’s given me a lot of perspective and oodles of delicious blog fodder. Time will tell if this current foray into yet another web framework will be worth my time but I wouldn’t be doing it if I thought there was no chance of it ever paying off.

Procrastination Takes Many Forms.

I really can be my own worst enemy sometimes. It’s been almost a month since I got back from the USA and despite the best of intentions I haven’t really done that much work on Lobaco apart from a little work on the API and web UI. Whilst I was pretty sure I wasn’t going to hit the code hard immediately after touching back down in Australia I still thought that after maybe a week or two of lazing about the coding bug which had firmly bitten me before I left would take a hold once again, pushing me to build on the momentum I had set up. Sadly it wasn’t to be and instead I just resided myself to feeling guilty about what I should’ve been doing and pulling the meter tall weeds that had grown in our front yard.

Partly to blame is that sense of perspective I get whenever I take time away from a project to work on something else or to just have a break. Usually the first thing that pops into my head is “why the hell should I bother” and I’ll spend a good chunk of time focusing on the negative aspects of whatever I’m doing. After a while though I’ll just try to do a feel small things, a few quick wins to get me back into the mindset of getting things done. After that it’s usually pretty easy going (this usually takes about 2 weeks) until I hit a wall again or I feel like getting my weekends back for a while so I can relax and get my head back together. The last few iterations of this cycle are what lead to the 3 major revisions of what is now Lobaco.

This time however was different. After being back for 2 weeks and being firmly thrust back into the world that had barely changed since I had left (even though I expected it to be wildly different,  for some reason) I still really couldn’t get into coding without feeling like I should be doing something else. My usual routine of getting a couple quick wins with the API and web UI didn’t translate into jumping back onto my MacBook and smashing out some iPhone code. Instead I started wondering whether or not a native client was the way to go and the possibility of doing a web based client for the phone itself. I had been down this road before and ultimately found that whilst iPhone programming was a world away from I’d done before the progress I had made with only a couple weeks of effort was far more encouraging than the same amount of time spent trying to wrangle HTML5 and Javascript into something workable.

Then along came Sencha.

I was going through my 700+ post backlog of Techcrunch articles when I came across this one about Sencha, a web startup that just released their Touch framework which provides the basis for building native looking applications in HTML5 and Javascript. Thinking this might be my salvation to writing native clients for all handsets I quickly downloaded the framework and started hacking around to get something workable. I was able to get the example running in one weekend and made a few modifications but I didn’t get into the real meat of it until last Friday night. After managing to replicate the UI I had built in objective-c within the Sencha framework I uploaded it to my web server to see what it would look like on the iPhone and instantly I realised what was wrong.

This client was just an elaborate way of procrastinating.

Now whilst the client looked decent and didn’t take too much to set up it didn’t look anywhere near as good as my native app nor could it hold a candle to its performance. Sure my hack job probably ensured that the performance wasn’t as good as it could be but in comparison to the native client hack job I did it was pretty stunning. After coming to that realisation I booted up my MacBook to start getting acquainted with Xcode again and spent last weekend coding up some performance improvements¹ for it which I had put off before I left for the USA. I’m sure this won’t stop me from looking at going down that path in the future but I can at least rest easier now that I’m feeling the urge to program once again.

It’s been a weird learning experience for me since I’m usually pretty good at knowing when I’m procrastinating. Usually I have a good reason for it (like having 1 bit of work to do and not doing it since it’s not due for months) but this is the first time I caught myself doing something I thought was useful when really I was just making excuses for doing the work I knew needed to be done. With a good week of holidays coming up over the Christmas/New Year period this realisation couldn’t have come at a better time and I’m looking forward to making the most of my time off with the hope that the momentum will carry me on into the new year.

¹I’m going to do a big post about this hopefully tomorrow. I hit some really, really esoteric problems getting everything to work but I have and the results are, to put it bluntly, bloody amazing.