If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

I'm somewhat curious about the Unity thing myself but I'm thinking they ran it in a window (since the resolution was 1280x1024) where maybe you wouldn't get the performance hit.

Running it in a window will also be slower, because compositions aren't suspended (afaik this isn't the case in OS X). However, there's a chance they fixed Unity and tested with suspend composition option turned on.

Comment

Again, I can make baseless statements too. Windows has come a long way since 3.1; even XP SP2 onward was very good on the stability front, and the 6.1 Kernel [Vista/7] even more so.

As far as security goes, the same above statement used to apply to some BSD OS that I refuse to name. You know, up until it got enough market share and started to attract too much attention...

I posted a lot about this. It come a long way, but still has dos vulnerabilities, dos (Abort, Retry, Ignore) problem, broken UAC and more. There's a difference between stability by design and ironing problems out that wouldn't occur in smartly designed systems. You don't have to have humongous market share to prove Linux' and OS X security is better (8% of market share is quite a lot). On Linux or OS X you don't have IE integrated with you system and you can't read whatever you want like in Windows with UAC.

Comment

i get most of it, some sort of optimized wrapper, sort of like wine
this will, in the long run, help with early development and cross platform support, with hardly to no performance decrease

linux is generally a step above enviroment, a step below performance, and a few steps behind in support compared to winblows
when you get better support, as with valve, you will get more percentage of linux users and this will drive performance up

it all is based on what cards are played now on how well it will do, but linux is certainly not dying right now

for the microsoft fans, you do not want linux to fade away, you already saw a preview with windows8, theres going to be even more mildly worked through money grubbing o.s. versions without competition, trust me on that

Comment

i get most of it, some sort of optimized wrapper, sort of like wine
this will, in the long run, help with early development and cross platform support, with hardly to no performance decrease

linux is generally a step above enviroment, a step below performance, and a few steps behind in support compared to winblows
when you get better support, as with valve, you will get more percentage of linux users and this will drive performance up

it all is based on what cards are played now on how well it will do, but linux is certainly not dying right now

for the microsoft fans, you do not want linux to fade away, you already saw a preview with windows8, theres going to be even more mildly worked through money grubbing o.s. versions without competition, trust me on that

Personally: I WANT Windows 8 to fall flat on its face. Hate the GUI. Loath the Windows Store.

Comment

Personally: I WANT Windows 8 to fall flat on its face. Hate the GUI. Loath the Windows Store.

You might get your wish. Spent some time this weekend doing initial Metro porting work and ran into some dumb-as-fucking-shit decisions the PMs made for the Metro mode apps. Namely, even Direct3D is hobbled, by the banning of D3DCompiler.dll. Which means that you must precompile your shaders with the HLSL compiler before shipping. This is perfectly fine for larger games, but then those aren't Metro games. The games that are most likely to be Metro games are going to be iOS/Android ports. Which means they're already written. In OpenGL ES. Which means the sanest means of porting them over is to use ANGLE. Which needs to retarget GLSL shaders to HLSL. Which requires either (a) generating the IR bytecode files or (b) using the compiler service. However, D3D Shader Model 4+ removed support for reading or writing the compiled bytecode directly (same as OpenGL has never allowed it by never offering it), which was tolerable so long as the compiler was available for source-to-source translations, but now in Metro it's not. This isn't a show stopper -- compiling the shaders ahead of time when building the Metro app bundle is totally doable. However, what it really fucks over are tools and graphics sandboxes, which is what I was working on. Hardly the death knell of Win8, but it does indicate in a strong way that the PMs there aren't actually thinking about the developer story for building Metro apps or building their ecosystem outside of the traditional desktop model that Windows has dominated, so the Metro/Win8 model could flop in a very big way. Granted, Win9 will just come out afterward and Win10 after that and so on... but Win8 may well be the next ME/Vista. Not because the UI is bad (it's actually easy to find just as many good reviews as bad ones; and yes, I'm in the "fuck Metro it's horrible" camp) but because Microsoft again is failing to understand how to move market forces the way Apple and Google have figured out to do.

Comment

You might get your wish. Spent some time this weekend doing initial Metro porting work and ran into some dumb-as-fucking-shit decisions the PMs made for the Metro mode apps. Namely, even Direct3D is hobbled, by the banning of D3DCompiler.dll. Which means that you must precompile your shaders with the HLSL compiler before shipping. This is perfectly fine for larger games, but then those aren't Metro games. The games that are most likely to be Metro games are going to be iOS/Android ports. Which means they're already written. In OpenGL ES. Which means the sanest means of porting them over is to use ANGLE. Which needs to retarget GLSL shaders to HLSL. Which requires either (a) generating the IR bytecode files or (b) using the compiler service. However, D3D Shader Model 4+ removed support for reading or writing the compiled bytecode directly (same as OpenGL has never allowed it by never offering it), which was tolerable so long as the compiler was available for source-to-source translations, but now in Metro it's not. This isn't a show stopper -- compiling the shaders ahead of time when building the Metro app bundle is totally doable. However, what it really fucks over are tools and graphics sandboxes, which is what I was working on. Hardly the death knell of Win8, but it does indicate in a strong way that the PMs there aren't actually thinking about the developer story for building Metro apps or building their ecosystem outside of the traditional desktop model that Windows has dominated, so the Metro/Win8 model could flop in a very big way. Granted, Win9 will just come out afterward and Win10 after that and so on... but Win8 may well be the next ME/Vista. Not because the UI is bad (it's actually easy to find just as many good reviews as bad ones; and yes, I'm in the "fuck Metro it's horrible" camp) but because Microsoft again is failing to understand how to move market forces the way Apple and Google have figured out to do.

Agree in principle; haven't played with Win8 yet, but assuming your correct, yeah, that would be a pain.

As a phone OS, Win8 actually looks decent. And because MS wants to unify its product line with a single OS, the Desktop is getting screwed. If there was a native way to get the classic shell, that would do a LOT for Win8 sales [really, I have no idea why this isn't an option...].

The store is less forgivable though, and MS is going to have a LOT of blowback over it from smaller devs.