Jump to content

Dreamora

Members
  • Content Count

    3
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Dreamora

  • Rank
    Newbie

Profile Information

  • Gender
    Male
  • Location
    Switzerland
  1. I think the real and fair solution here is simple and easy: 1. Base price that stays roughtly the same at least unless new features balloon and add to all platforms (currently it seems somewhat a tick tock, half the platforms are ignored for the other half of the platforms and alike) 2. Stop the upgrade price policy and sell support contracts which can be paused at max 1 year. That way people know that they pay for 12 months, not 'perhaps 12, but could just as well be 8 or 16 months' That way we all know what we are up to and leadwerks can push things more continously instead of starting to freeze releasing stuff to the licensees just cause its required as selling point at 'last release + 10m' (compare it to Adobes development cycles during standalone CS versions version cloud now) To me this is what its hurting most, that there is a very high likelyhood that stuff gets pushed back or scheduled in stupid / counter intuitive / developer hurting way when it does not need to be like that and should not be like it. I got 3.0 with mobile addons, cost me a good $500 and I can't say that I'm satisfyed with how the mobile engine works etc even remotely right now. ITs the least capable, performant and productive engine I've at hand to use (compared to Shiva, UDK, Unity) and a year later its already 'dead' again as its now all about eye candy and linux due to the 'year cycle selling point focus'?? I kinda doubt that there will be going any more cash from my end to leadwerks until the development phylosophy itself gets fixed to a more 'the engine as a complete, real crossplatform product' approach without exclusive yearly focus
  2. Dreamora

    Post-GDC Wrapup

    This is pretty cool Looking forward to pain my iOS and Android devices a bit with this But actually I think the conclussion is not complete. PowerVR and Mali end up like that because they have tile based multi gpus. The 3 GPUs of the iPad4 for example render tile by tile independently (grid of Y x Y tiles that make up the screen), so if 2/3 of the screen actually does not require power (as in the deferred rendering movie), they can focus all their power on the remaining 1/3. With deferred this can be great as it can achieve a lot of quality with a design focused to make use of it (Real Racing 3 is a prime example), yet on the other hand it can also be absolutely devastating if too much work ends in a single tile as all other gpus will simply run out of work and enter idle, tiles can not be subdivided to share the workload etc. Mali and PowerVR also have unified shader units which help them a lot. Also their early z-out pipeline is much stronger, doing z discards before processing shaders for a pixel at all (thats the reason why alpha mask is much more expensive than alpha blend on them vs desktop where its the other way round) But thats also what makes this technology troublesome potentially at least for Android devs due to Tegra. Neither is Tegra tile based, nor does Tegra even offer unified shader units (Tegra4 changes the later, but only partially. And it will still not be tile based) Tegra 2 / 3 basically uses a desktop gpu back from GF6-7 days neutred enough to run on the mobile energy constraints, while avoiding to use all those expected and smart optimizations to make it use less power or offer more graphical fidelity at the same power draw.
×
×
  • Create New...