General Thread

by Aardappel on 01/05/2002 01:55, 15527 messages, last message: 03/01/2024 13:02, 12362116 views, last view: 10/08/2024 01:33

for questions, announcements etc.

   Board Index   

#9051: Re: Problem with shaders

by Xannin on 09/13/2007 21:45, refers to #9050

That's what it runs at when it's 1920 x 1200 resolution and 4x FSAA.
Also I did some checking around and read several places that there are problems with the drivers for all new IMacs.

reply to this message

#9052: ..

by Acord on 09/13/2007 23:16

Well, the resolution is VERY high. That and the 4xFSAA are going to take a major hit out of any card. The higher the res, the more of a hit it takes.

reply to this message

#9053: Problems connecting to master server

by dussander on 09/14/2007 08:47

i'm trying to request the in-game server list and i continue to get the "Master Server Not Replying" message. i'm not behind a router. i'm on wildblue satelite. any ideas?

btw, i'm running xp, firewall turned off

message me on AIM at HerrDussander if you have any ideas

reply to this message

#9054: Re: Problem with shaders

by Quin on 09/14/2007 18:41, refers to #9042

Well, firstly. Try the 'ati_*_bug' variables (ati_skybox_bug fixes the 'see through random parts of the level' for me on an R9550).

Next, try messing with your driver settings. Disable Catalyst AI if it is available, and try changing the OpenGL depth buffer (or perhaps even /zpass 0 from the Sauerbraten console).

Last but not least, you could try some of the suggestions on the wiki.

http://cube.wikispaces.com/
http://cube.wikispaces.com/FAQ

Hope this helps point you in the right direction, let us know how you go and if you have any success at all.

reply to this message

#9055: Re: Problem with shaders

by SanHolo on 09/14/2007 19:02, refers to #9050

I read about the "driver issues" for the new R600 Cards on OS X in the various benchmark reports. Some games (UT 2004, Doom III, Quake 4) perform worse on the new MBP with the GeForce 8600M than they do on the MBP with the Radeon X1600.

http://www.macworld.com/2007/06/firstlooks/mbpbench/index.php

reply to this message

#9056: Re: Problem with shaders

by SanHolo on 09/14/2007 19:02, refers to #9055

Not R600 of course, I mean the GeForce-8 series. Sorry. =)

reply to this message

#9057: Re: Problem with shaders

by demosthenes on 09/14/2007 20:42, refers to #9056

That's not a driver issue, except with ATI.

The X1600 I looked at just now had a 600MHz core clock and a 1GHz memory clock, compared to the 8600GT I looked at which had a 540MHz core clock and an 800MHz memory clock. Plus, the 8600s use GDDR2 while the X1600s use GDDR3.

The ATI should be performing better comparatively than it is, by a quick glance at those benchmarks.

reply to this message

#9058: Re: Problem with shaders

by Xannin on 09/14/2007 22:23, refers to #9054

Thanks Quin, /zpass 0 fixed the problem with seeing through the level.
I messed around with turning different shaders on and off,
thinking that one shader in particular might have been causing the problem with the models.
When I turned off dynamic shadows it seemed to help, and the models would sometimes be visible.
However, when they were visible the models were missing random faces and were all somewhat green.

reply to this message

#9059: Message censored by administrator

by oijrsqxatz on 09/15/2007 18:47

#9060: Re: Problem with shaders

by SanHolo on 09/15/2007 22:09, refers to #9057

You're referring to the Desktop-versions, I am talking about the mobile versions. The mobile X1600 has a 450/470 MHz clockrate, I don't know exactly about the 8600 Go, but clockrates are almost twice as high.

Plus it would make no sense to build a slower GPU into the next generation of a laptop.

reply to this message

#9061: Re: Problem with shaders

by yetanotherdemosthenescomputer on 09/15/2007 22:52, refers to #9060

To you, the end-user, no, it does not.

However, name-dropping can sell. And sell big! Saying that you've got a GeForce 8 card in a laptop makes more of an impression of the average user than saying you've got a x1600. So, regardless of the fact that the (desktop) 1600 is more powerful than the (desktop) 8600GT by clock speeds, at least, you can still sell more laptops with the "new" chipset than you might sell of identical laptops with the "old" chipset, even though they're practically identical.

That is, of course, before GPU architecture is brought into it, at which point, the lower clock rates of the one (desktop) card as opposed to the other may not actually reflect performance. Either way, the main point of the 8 series is DX10 cores (Note that an 8600 is fairly identical to a 7600, but for the DX version). Since Mac OS can't really use DX (it being Windows only), there's no real reason to include an 8 series card in there which is less powerful than a 7 series card might be for a similar price.

Eh, whatever.

reply to this message

#9062: ..

by Julius on 09/15/2007 23:00

AFAIK MacOSX and Linux can use the "dx10" features of the Geforce8 series by OpenGL extensions and OpenGL2.0.

reply to this message

#9063: Re: ..

by yetanotherdemosthenescomputer on 09/15/2007 23:05, refers to #9062

What?! Links, please. I have never heard of OGL and DX being able to be used in conjunction with each other. Would be interesting to read about if it's true.

reply to this message

#9064: Re: ..

by absinth on 09/15/2007 23:14, refers to #9063

http://developer.download.nvidia.com/opengl/specs/g80specs.pdf

"in conjunction with each other"
conjunction? nah, it is just that you can exploit the features of the hardware just as well with opengl (extensions) as with dx version xyz

reply to this message

#9065: Re: ..

by yetanotherdemosthenescomputer on 09/15/2007 23:36, refers to #9064

Okay, so there are OGL updates. That's not what was being said earlier. Yes, OGL and DX are updated and added to together (except where there isn't a new DX version, because OGL continues to be added to). And yes, the fact that there is new OGL stuff is nice. But that doesn't mean that DX10-specific logic pathways can be used for OGL.

I'm not sure if I'm getting my point across clearly. :(

Let's put it this way: If two GPUs were exactly identical in every way except their DX version, the DX10 card would not be able to render via OGL any quicker or better than the DX9 card (because the OGL versions between the two cards are identical in this hypothetical situation).

I thought that Julius was saying that the DX10 card in our hypothetical situation would render things via OGL quicker or better because it could utilize new DX10-specific things that a DX9 card couldn't.

Gah! Wasn't supposed to be this big of a deal. :P

reply to this message

#9066: ..

by Julius on 09/16/2007 00:51

huh? I don't get your example...

Just as a DX10 card wouldn't render a game with only dx9 features any faster than on a dx9 card, so would it be the case with the same openGL version.

But if you have a game with a special dx10 or opengl2.0 rendering path it would.

But you can't compare one program that is optimised with another that isn't, right?

The dx10 "specific" logic pathways can be used by openGL2.0 just as well AFAIK.

reply to this message

#9067: Re: ..

by yetanotherdemosthenescomputer on 09/16/2007 08:22, refers to #9066

>The dx10 "specific" logic pathways can be used by openGL2.0 just as well AFAIK.

OpenGL can't use DirectX specific things, just as DirectX can't use things specific to OpenGL. That's just part of the definition of the word specific. Last time I checked into the way GPUs worked, there were instruction sets for both OGL and DX. There were common pathways used by both, and some specific to one or the other. But the fact that there is a DX10 instruction set would not in any way make the OGL instruction set more capable.

My point is that OpenGL cannot make use of things which are unique to a DX instruction set, whether it is present or not. DX's presence is not linked to OpenGL functionality in any way, shape, or form.

reply to this message

#9068: ..

by Julius on 09/16/2007 13:58

Hmm you might be right since I am really no expert on that topic.

But I find it hard to believe that there are parts of the hardware that can only be accessed by either DX or OGL.

So far I always thought all GPU instruction sets can be accessed by both software libraries as long as there is support for them build into the driver and the software itself.

reply to this message

#9069: Message censored by administrator

by TestName on 09/16/2007 14:06

#9070: Crash on launch: Win32 summer edition + 9/4 patch

by ctate on 09/17/2007 00:39

I just installed Sauerbraten for the first time, Summer Edition 2007/08/29 + patch 2007/09/04, but alas it crashes immediately after the init phase. The crash is reported with an error dialog reading "Sauerbraten Win32 Exception: 0xc0000005 [0x8]". Have other people had this experience with the game as it installs out of the box? And does anyone know what to do about it?


Console output when run from cmd.exe:

C:\bin\Sauerbraten>bin\sauerbraten.exe -r
init: sdl
init: enet
init: video: mode
init: video: misc
init: gl
Renderer: Intel 965/963 Graphics Media Accelerator (Intel)
Driver: 1.5.0 - Build 7.14.10.1147
Rendering using the OpenGL 1.5 assembly shader path.
WARNING: No texture rectangle support. (no full screen shaders)
WARNING: No framebuffer object support. (reflective water may be slow)
WARNING: Non-power-of-two textures not supported!
init: console
init: world
init: sound
init: cfg
init: localconnect
init: mainloop
read map packages\base\metl4.ogz (0.1 seconds)
Mining Station by metlslime
game mode is ffa/default
Sauerbraten Win32 Exception: 0xc0000005 [0x8]

System configuration:

Dell Dimension E520
CPU: Intel Core 2 Duo
RAM: 2 GB
Video: Intel G965 Express Chipset onboard (X3000)
OS: Vista Home Basic

reply to this message

   Board Index