the green screen problem -1 reply

Please wait...

Von II

aka noobst3R

50 XP

16th June 2008

0 Uploads

4,339 Posts

0 Threads

#1 10 years ago

hi, i'm having this weird problem on one of our PC's running quake4. It's a pentium 4 with 1.5 GB RAM, i know it isn't the best pc for quake4 and i do have other pc's where it just runs fine but i wanna now why i'm having this problem. The pc has an ATI radeon 7xxx (don't remember the other numbs :p) Here it is: It started from the first level where you go speak with the guy hided behind some wall. the ground looks orange and green (just like it's grass) and when i enter the ruined spaceship or w/e it may be the light is green. I can see things in a normal color, but some things like my gun are green. It isn't total green but the light that falls on it is green. i don't have any problems with the framerate or the game speed, it's just running fine. I would have made a srnshot, but my DVD-rom of Q4 is at my uncle so... no screenshot.... Thanks anyway. (as soon i get the disk back i am going to make a screenshot)




LDAsh

a person

50 XP

15th March 2004

0 Uploads

38 Posts

0 Threads

#2 10 years ago

I don't know what it is about Quake 4 but it responds worse when running under the recommended specs, when compared with Doom3 and Prey, and even ET:QW, which can all be tweaked down and still run okay on older systems. But Quake 4 is strange, on my laptop I get lights going all rainbowy multicolors and bad seams on models, and some surfaces suddenly turning fullbright on and off. It _could_ run fine on my laptop (fps), but these problems make it unplayable.




Von II

aka noobst3R

50 XP

16th June 2008

0 Uploads

4,339 Posts

0 Threads

#3 10 years ago

yeah, i can run fine FPs but the colors are all messed up :p But it isn't a real problem cos i can run it on another pc..




youkaizero

I don't spend enough time here

50 XP

20th April 2005

0 Uploads

23 Posts

0 Threads

#4 9 years ago

This is actually a very common thing to happen in Quake 4. And actually, out of the games that are based on the doom 3 engine, Prey handles unsupported hardware the best, then quake 4, then doom 3, then quake wars. But, you're getting green colors in quake 4 because any radeon lower than the 9600 lacks ps2.0. Which, ID did not take out ps 1.0, and 1.4 renders out of quake 4(probably more lazy than anything else). Which by default, the render is set to the r200 render, you can change it by accessing your console, and putting in either r_renderer arb2, or r_renderer arb. Now, with both of these you sacrafice a lot of detail. And other things as well, like specular shaders you lose completely. However, this can also be fixed by updating quake 4 to its latest version. For only supporting ps2.0 and higher, quake 4 does a bad job at that, seeing that you can easily use cards with only 1.4, or 1.0. I recommend using tailored quake 4 configs(UpsetChaps Quake4 Guide - Tailored Configs (Framerate and Visual Tweaks)), or my old Radeon 9xxx,8xxx,7xxx config file and quick guide.(Quake 4 on Radeon 9000 PRO - Guru3D.com Forums)

Hope this helps out. :D




Von II

aka noobst3R

50 XP

16th June 2008

0 Uploads

4,339 Posts

0 Threads

#5 9 years ago

Thanks for the help, but i bought a new graphicscard for this pc (was about time:))




Dafama2k7

I follow teh Moo!

50 XP

29th September 2006

0 Uploads

622 Posts

0 Threads

#6 9 years ago

The ATI Radeon 9200 and lower can be user without the green effect opening the console and trying different settings for r_renderer command like...:

r_renderer r200

or...

r_renderer arb

or...

r_renderer BEST

and more...




Dafama2k7

I follow teh Moo!

50 XP

29th September 2006

0 Uploads

622 Posts

0 Threads

#7 9 years ago

The ATI Radeon 92x0 and lower green effect BUG can be easily fixed opening the in-game console and trying different settings for r_renderer command like...: r_renderer r200 or... r_renderer arb But of course, the best visuals would be seen by using... r_renderer BEST This latest command will select the glprogs/interaction.vfp shader file that contains the in theory the BEST shader file that Q4 can use, well, also the test.vfp is the same as the interaction.vfp file, but may be even better and in my mods i use it to contain an specific NVidia custom glprogs shader, that is faster and better and requires an NVidia gfx card with support for ARB2 or better and that test.vfp shader file may be selected from in-game console typing set r_testARBProgram 1 and to return to normal type set r_testARBProgram 0 that agin it will useinteraction.vfp generic shader file.

But with an ATI Radeon 92x0 gfx card you are forced to use the glprogs/r200_interaction.vp shader file that is automatically selected with the r_renderer r200 command.

The bigger problem is that in Quake 4 retail game, there was a bug in the glprogs/r200_interaction.vp shader file contained in some .pk4 official file also official q4base folder into the Quake root directory, well, to fix this i recommend to update Q4 to latest patch available that actually is v1.4.2 or at least to v1.04beta that is the most stable and compatible one if you don't use Q4 for multiplayer, and done, this patches comes with the new fixed special ATI r200_interaction.vp custom shader file.

Also this glprogs shader file can be fixed with many of my latest shaders packs for Q4 that already contains the latest enhanced and fixed r200_interaction.vp ATI specific shader file that does NOT contain the GREEN R200 BUG ! :)




Dafama2k7

I follow teh Moo!

50 XP

29th September 2006

0 Uploads

622 Posts

0 Threads

#8 9 years ago

This is the r200_interaction.vfp with fixed green screen bug, to use it you can copy from the !!ARB to the END and paste it on new text file named r200_interaction.vfp, save it with that name and then copy that file to for example in "Quake 4/q4base" directory into a newly created by you glprogs folder, then start Q4 game and enter the in-game console and type r_renderer r200, the green screen bug will be gone forever ! :D

!!ARBvp1.0 OPTION ARB_position_invariant ;

# this is slightly simpler than the ARB interaction, # because the R200 can only emit six texture coordinates, # so we assume that the diffuse and specular matrixes are # the same, with higher level code splitting it into two # passes if it isn't # # I am using texcoords instead of attribs, because a separate # extension is required to use attribs with vertex array objects. # # input: # # TEX0 texture coordinates # TEX1 tangent[0] # TEX2 tangent[1] # TEX3 normal # COL vertex color # # c[4] localLightOrigin # c[5] localViewOrigin # c[6] lightProjection S # c[7] lightProjection T # c[8] lightProjection Q # c[9] lightFalloff S # c[10] bumpMatrix S # c[11] bumpMatrix T # c[12] diffuseMatrix S # c[13] diffuseMatrix T # c[14] specularMatrix S # c[15] specularMatrix T # # output: # # texcoord 0 = light projection texGen # texcoord 1 = light falloff texGen # texcoord 2 = bumpmap texCoords # texcoord 3 = specular / diffuse texCoords # texcoord 4 = normalized halfangle vector in tangent space # texcoord 5 = unnormalized vector to light in tangent space

TEMP R0, R1, R2, lightDir;

PARAM defaultTexCoord = { 0, 0.5, 0, 1 };

# texture 0 has three texgens DP4 result.texcoord[0].x, vertex.position, program.env[6]; DP4 result.texcoord[0].y, vertex.position, program.env[7]; DP4 result.texcoord[0].w, vertex.position, program.env[8];

# texture 1 has one texgen MOV result.texcoord[1].xy, defaultTexCoord; DP4 result.texcoord[1].x, vertex.position, program.env[9];

# textures 2 takes the base coordinates by the texture matrix MOV result.texcoord[2].xy, defaultTexCoord; DP4 result.texcoord[2].x, vertex.texcoord[0], program.env[10]; DP4 result.texcoord[2].y, vertex.texcoord[0], program.env[11];

# textures 3 takes the base coordinates by the texture matrix MOV result.texcoord[3].xy, defaultTexCoord; DP4 result.texcoord[3].x, vertex.texcoord[0], program.env[12]; DP4 result.texcoord[3].y, vertex.texcoord[0], program.env[13];

# texture 4's texcoords will be the halfangle in tangent space

# calculate normalized vector to light in R0 SUB lightDir.xyz, program.env[4], vertex.position;

DP3 R1, lightDir, lightDir; RSQ R1, R1.x; MUL R0, lightDir, R1.x;

# calculate normalized vector to viewer in R1 SUB R1.xyz, program.env[5], vertex.position;

DP3 R2, R1, R1; RSQ R2, R2.x; MAD R0, R1, R2.x, R0; #MUL R1, R1, R2.x; # add together to become the half angle vector in object space (non-normalized) #ADD R0, R0, R1;

# put into texture space DP3 result.texcoord[4].x, vertex.texcoord[1], R0; DP3 result.texcoord[4].y, vertex.texcoord[2], R0; DP3 result.texcoord[4].z, vertex.texcoord[3], R0;

# texture 5's texcoords will be the unnormalized lightDir in tangent space DP3 result.texcoord[5].x, vertex.texcoord[1], lightDir; DP3 result.texcoord[5].y, vertex.texcoord[2], lightDir; DP3 result.texcoord[5].z, vertex.texcoord[3], lightDir;

# generate the vertex color, which can be 1.0, color, or 1.0 - color # for 1.0 : env[16] = 0, env[17] = 1 # for color : env[16] = 1, env[17] = 0 # for 1.0-color : env[16] = -1, env[17] = 1 #MAD result.color.xyz, vertex.color, program.env[16].x, program.env[17].y; #MAD result.color.xyz, vertex.color, program.env[17].x, program.env[17].y;

#MAD result.color.xyz, vertex.color, program.env[17].x, program.env[16].y; MAD result.color.xyz, vertex.color, program.env[16].x, program.env[16].y;

END