Vista and OpenGL

Demirug said:
You should read all the public information again (hint: WinHEC) and then rewrite this blog entry.
Actually, I have done that ... anything striking wrong? I had a few developers review this and most agreed ... Just saying WinHEC doesn't help me much. Please PM me in case it's a lot ;)

Anyway, I'm quite sure that average people will be scared by software that turns off their fancy desktop (Oh my god! This software is buggy! It changed my desktop!) and that is probably the main problem. CAD people don't bother if their desktop runs with eye candy or not, but the average joe will. People will think there's something wrong if software uses OpenGL and stick to DirectX games, and in the long run, well, ...

Let's hope the best that M$ gets OpenGL running under Vista without turning Aero off and without falling back to stone-age OpenGL 1.4 without extensions.

Does anyone know whether ATI or nVidia have made some statements on Vista and OpenGL? Anyone here with Vista running who could tell us whether support is coming?
 
Anteru said:
Actually, I have done that ... anything striking wrong? I had a few developers review this and most agreed ... Just saying WinHEC doesn't help me much. Please PM me in case it's a lot ;)

Anyway, I'm quite sure that average people will be scared by software that turns off their fancy desktop (Oh my god! This software is buggy! It changed my desktop!) and that is probably the main problem. CAD people don't bother if their desktop runs with eye candy or not, but the average joe will. People will think there's something wrong if software uses OpenGL and stick to DirectX games, and in the long run, well, ...

Let's hope the best that M$ gets OpenGL running under Vista without turning Aero off and without falling back to stone-age OpenGL 1.4 without extensions.

Does anyone know whether ATI or nVidia have made some statements on Vista and OpenGL? Anyone here with Vista running who could tell us whether support is coming?

Average Joe's wouldn't be running anything Dx or Ogl in windows mode either ;)
 
*yawns*

This is really a non-issue. If you do some research and only take information from those who are in the know (i.e. cut out anyone who uses M$ and other 1337 terms) it doesn't seem to be a problem - or, what was a problem does in fact have a workable solution.

That and Vista is still in development - it's coming up on a feature-complete deadline from what I've read, but there's still a fair number of things we either don't know for certain and/or simply haven't been finalized yet. Talk about jumping the gun.

Jack
 
Anteru said:
Actually, I have done that ... anything striking wrong? I had a few developers review this and most agreed ... Just saying WinHEC doesn't help me much. Please PM me in case it's a lot ;)

I am sorry I was the incorrect opinion that everybody who is concerned about driver on Windows knows what WinHEC is.

http://www.microsoft.com/whdc/winhec/default.mspx

You can find some slides and other information’s about video drivers there.
 
Razor1 said:
Average Joe's wouldn't be running anything Dx or Ogl in windows mode either ;)

I would have agreed but now you have stuff like Google Earth (I used NASA worldwind but now am on 56K . ...can't use either), or 3D Mahjong Solitaire (an excellent shareware game I actually bought!) which my mother plays much.
 
Demirug said:
I am sorry I was the incorrect opinion that everybody who is concerned about driver on Windows knows what WinHEC is.

http://www.microsoft.com/whdc/winhec/default.mspx

You can find some slides and other information’s about video drivers there.

Ok, just in case you didn't see it I'm quoting the WinHec slides ... Never mind, gonna check everything twice.

Back on topic: It's the coupling of the GUI to the OS that scares me a bit. As I said previously, it would be great if someone from the IHVs could tell us how they see it, otherwise this will probably be yet another Vista! OpenGL! ?!? topic that does not bring any light on the situation.
 
Anteru said:
Back on topic: It's the coupling of the GUI to the OS that scares me a bit. As I said previously, it would be great if someone from the IHVs could tell us how they see it, otherwise this will probably be yet another Vista! OpenGL! ?!? topic that does not bring any light on the situation.

The current Windows GUI is coupled on the OS too. From the programmers view you will still use the good old WIN32 API even on Windows Vista. Sure you can use WPF but this is not a Vista only API too.
 
The GPU is a "shared resource" under Windows Vista. The GPU is no longer exclusively for the gaming side of things anymore.

I'm wondering if there'll be two upshots:

1. More GPU adoption. As I mentioned somewhere before, new computers will probably ship with SM2 hardware by default so that their new machines support AERO "out of the box"

2. Will the hardware have to be more robust and fault-tolerant if it's going to be used all the time instead of just during gaming sessions.

As far as it having a performance hit on the desktop - not important as I see it. It's fairly normal for my D3D applications to run much faster in fullscreen mode compared with windowed mode. Given the context switching, a fullscreen application should get all the power it needs (much like it would in current OS's).

The windowed-only programs I've written don't tend to need to use absolute maximum performance anyway - it's a whole different thing editing levels/models compared with actually playing the games.

hth
Jack
 
JHoxley said:
The windowed-only programs I've written don't tend to need to use absolute maximum performance anyway - it's a whole different thing editing levels/models compared with actually playing the games.

You haven't edited Doom 3 levels lately right? Practically the entire rendering pipeline of the game is available in the editor's 3D preview window which means you get as much performance in a 300x300 window as playing the game at 1024x768. I disagree with you when you say this is a non-issue. Having to disable AERO is not a solution, it's a workaround, a pretty sloppy one at that; especially for windowed apps where it will be very visible and probably annoying.

And other people argumenting that "smart people" would have that disabled anyway is acknowledging that Vista's Home Basic is better for "smart people" than Home Premium or Ultimate Editions since in the former you can't enable AERO in the first place. I turn off (and actually remove with nLite) a LOT of features from XP but I don't berate other people that choose to enable and use them.

OTOH I do think some people are overreacting about the performance implications and Microsoft's motives for doing this. IMO it is an issue but it's not the end of the world.
 
Mordenkainen said:
You haven't edited Doom 3 levels lately right? Practically the entire rendering pipeline of the game is available in the editor's 3D preview window
I've only played the demo of D3, so no - never done any level editing. However, I don't really see why it'd need to run at the same speed as the game.

Is the editor running it in full game mode? AI, physics, gameplay (is there any?) etc... Does it even need to update on a loop unless there are animations? I tend to make my windowed mode editors "paint on demand" or have a relatively slow (~25hz) refresh rate. I don't see much point in trying to benchmark my GPU whilst I'm just doing some GUI-based editing (etc..) :smile:

Mordenkainen said:
Having to disable AERO is not a solution, it's a workaround, a pretty sloppy one at that; especially for windowed apps where it will be very visible and probably annoying.
Yes, I will agree - it's definitely a work around and not a solution.

Either way, I stand by my previous comment about it still being work in progress. I'm content with seeing what the end result is rather than jumping the gun :smile:

Jack
 
JHoxley said:
I've only played the demo of D3, so no - never done any level editing. However, I don't really see why it'd need to run at the same speed as the game.

Is the editor running it in full game mode? AI, physics, gameplay (is there any?) etc... Does it even need to update on a loop unless there are animations? I tend to make my windowed mode editors "paint on demand" or have a relatively slow (~25hz) refresh rate. I don't see much point in trying to benchmark my GPU whilst I'm just doing some GUI-based editing (etc..) :smile:

Yes it has model animations which you can select on a per animation frame basis for each model you place on your map, and you fly the camera around the world selecting polys and texturing them, and you vertex edit bezier curves, and you see the per pixel light shaders as you select them for each light, and when you move an object you need to see exactly how the dynamic shadows move; you can see the fragment programs used by your materials and how they fit in, and it renders the fog, etc. In the Effects editor you see all the particle effects and how they animate and can hide/modify effect stages WYSIWYG. As I said, practically all the rendering pipeline is used by the editor so it ends up being a lot slower than while running the game. I don't know why you ask about AI, physics, etc. since they don't care about OGL/D3D.
 
Mordenkainen said:
Yes it has model animations which you can select on a per animation frame basis for each model you place on your map, and you fly the camera around the world selecting polys and texturing them, and you vertex edit bezier curves, and you see the per pixel light shaders as you select them for each light, and when you move an object you need to see exactly how the dynamic shadows move; you can see the fragment programs used by your materials and how they fit in, and it renders the fog, etc. In the Effects editor you see all the particle effects and how they animate and can hide/modify effect stages WYSIWYG. As I said, practically all the rendering pipeline is used by the editor so it ends up being a lot slower than while running the game.
Okay, so it's using all of the features. I expected as much. Point still stands - if it runs at ~130fps in the game[/i] environment that's great, you guys love that sort of thing ;) In an editor environment you've got different definitions - as long as it's responsive then that's all that matters. As long as you can get your "job" of editing/creating that level then that's fine - instantaneous 100hz reaction times aren't important until you're blasting away in some multiplayer match or actually playing the game.

My point being that if windowed D3D/OpenGL takes a hit due to the cutesy new AERO Glass stuff, it's not necessarily a big issue.

I don't know why you ask about AI, physics, etc. since they don't care about OGL/D3D.
I was getting at the fact that an editor shouldn't necessarily need the same raw power that the real game does.

One of the "golden rules" when developing Windows applications is that you should "play nice" with whatever else is running. It's quite rare that applications actually do this - but just dig around the various PDC/Meltdown/Developer slides and you'll see how many times Microsoft try and inject common-sense into programmers :D

Jack
 
JHoxley said:
Okay, so it's using all of the features. I expected as much. Point still stands - if it runs at ~130fps in the game[/i] environment that's great, you guys love that sort of thing ;) In an editor environment you've got different definitions - as long as it's responsive then that's all that matters. As long as you can get your "job" of editing/creating that level then that's fine - instantaneous 100hz reaction times aren't important until you're blasting away in some multiplayer match or actually playing the game.

Sure, but it can be nice to have immediate feedback if you accidentally add something to the level that tanks performance.
 
JHoxley said:
Okay, so it's using all of the features. I expected as much. Point still stands - if it runs at ~130fps in the game[/i] environment that's great, you guys love that sort of thing ;) In an editor environment you've got different definitions - as long as it's responsive then that's all that matters. As long as you can get your "job" of editing/creating that level then that's fine - instantaneous 100hz reaction times aren't important until you're blasting away in some multiplayer match or actually playing the game.


I think you're still underestimating the performance required by the editor. This should be obvious but: before saving it you are brute-force rendering every single polygon in the level regardless of distance. Not just the 3d preview but the texture browser and the 2D mapping windows use OGL acceleration, there's no texture/model management scheme so you're also loading every single model and texture used somewhere in the level at any given time. The overdraw is horrendous. Like I said, you get as much performance in a 300x300 window as you get playing the game fullscreen at 1024x768.

My point being that if windowed D3D/OpenGL takes a hit due to the cutesy new AERO Glass stuff, it's not necessarily a big issue.

I was actually talking about when you do turn off AERO. If you leave it on and have to use microsoft's software only OGL 1.4 no ext implementation then prepare for an even slower experience as D3's renderering pipeline uses a lot of extensions to improve speed. ATI drivers have a bug currently that whenever you are viewing fragment programs in the editor your performance tanks to about 1 or 2 fps. Let me just say I don't look forward to when I've finished basic geometry and want to prettify my level with these things. I wouldn't want to have that kind of performance as my average.

I was getting at the fact that an editor shouldn't necessarily need the same raw power that the real game does.

We are in agreement here. Editors don't need stupidly high framerates but don't think you can use the editor with the preview window running at 10fps. Editing D3 levels is a very visual affair that expects low latency and immediate feedback. When you're dragging vertices around in 3D space it pays off to get at least 30fps. If you written a light material that strobes RGB values with a cosin function at a 60Hz rate and you want to see it in the preview window then not just "responsiveness" is important but actual speed. The slower the editor is, the more frustrating will be your work experience.
 
Okay, I'll concede defeat on this one - well argued Mordenkainen :smile:

Although, I will still stick by my earlier point that until it's released/final then this type of thread isn't really anything more than speculation/rumour..

Thanks
Jack
 
surely WRT games + performance its a non-issue,
if the user is running in a window (not fullscreen) then the user obviously doesnt want full performance.
the same applys to d3d games running in a window they run slower than they do fullscreen.
 
Back
Top