Goodbye Forever, WinQuake?

[Lerster]

Looks like r_draworder 1 to me.

Don't state shit that doesn't exist, you lame pucker with no delight, or flare.

I'll have to ask R00k, sometime, i'd love to use prowinquake again, if it didn't run so fucking slow on the newage cards.

I really miss it, it has such better texturizated details in the dithering of each texture.

Like i said before, quake = living artwork.

It is truely beautiful.

[Megazoid]

I don't want to ever stop using winquake. I love pixels!

Yeah, I can't run my hacked maps without... erm, I mean, yeah those groovy pixels.

/Just kidding btw.

[ORL]

Don't state shit that doesn't exist, you lame pucker with no delight, or flare.

Why don't you try typing it in the console and see for yourself?

[Baker]

Why don't you try typing it in the console and see for yourself?

Might work in WinQuake, doesn't seem to work in d3dpro370.exe

d3dpro370 is basically GL ProQuake except that it doesn't use OpenGL for rendering and instead uses Direct3D/DirectX, I think r_draworder 1 is a winquake option and not a glquake one.

r_draworder

Game: WinQuake

Type: Toggle

Default: 0

Description: Toggle the correct order of rendering walls.

Note: This toggle will change the order which is used to properly render the visible walls on a map. The default rendering order first renders the walls which are far away and then renders the walls which are close to the player thus the walls that are closer to the player will cover up the far away walls. When this toggle is enabled the rendering order will be reversed, so that the player will be able to see right through the walls which are close to him creating a x-ray type effect. This toggle allows map makers to see how much of the map is actually rendered and which parts of the map are rendered but would not be seen by players. This allows map authors to optimize the maps by limiting limiting the number of far away walls which are rendered. This command does not work during multiplayer games.

[ORL]

Might work in WinQuake, doesn't seem to work in d3dpro370.exe

d3dpro370 is basically GL ProQuake except that it doesn't use OpenGL for rendering and instead uses Direct3D/DirectX, I think r_draworder 1 is a winquake option and not a glquake one.

Okay, that makes sense. From the look of those screens, it just looked like r_draworder 1 with no vis calculations. That's all.

[Stung]

I thought I left feedback to this. Guess not.
Baker - nicely done.
Only places that could use improvement: the shadowing in the new GLpro is a bit much. If manipulated to replicate the original GLquake(or make colors yellow blue red more distinct, as in winquake, IF possible), this would be neat! (I saw you replied to PapaSmurf already)

And the alt-tab owns my pc. Minor concern.

Indirect concern would be getting crmod to accept the client if possible, or to have an updated server side CR.

Otherwise, awesome job.

[Baker]

Only places that could use improvement: the shadowing in the new GLpro is a bit much. If manipulated to replicate the original GLquake(or make colors yellow blue red more distinct, as in winquake, IF possible), this would be neat!

No worries, it'll look exactly like GLQuake/GL ProQuake when I get a chance to revisit the lighting code

And the alt-tab owns my pc. Minor concern.

That's a shame. Are you getting an "off-centered" screen or a "all messed up" screen when ALT-Tabbing or something else?

Indirect concern would be getting crmod to accept the client if possible, or to have an updated server side CR.

Otherwise, awesome job.

Thanks!

After I get the features into this I want it to have I'll start looking into options more to see if it can be made to connect to cheat-free.

[PapaSmurf]

Two bugs i found in D3Dpro:

1. cl_bobcycle is broken. I have this set to 0.6 (default), and my screen was actually bobbing and 0.6 Hz just standing still. Usually bobcycle will only have an effect if cl_bob is 1. Setting cl_bobcycle to 0 fixes it, but it's still not workign correctly. Incidentally, the reason I have cl_bobcycle as a nonzero value goes back to winquake.exe. In winquake, setting bobcycle to 0 actually displaced your point of view to be lower on your body. This can be tested easily by going to e2m2 and running around the knee deep water, with bobcycle 0, your view is now underwater!

2. When ever i pick up an item, the screen flash effect persists until i fire.

[Stung]

Two bugs i found in D3Dpro:

1. cl_bobcycle is broken. I have this set to 0.6 (default), and my screen was actually bobbing and 0.6 Hz just standing still. Usually bobcycle will only have an effect if cl_bob is 1. Setting cl_bobcycle to 0 fixes it, but it's still not workign correctly. Incidentally, the reason I have cl_bobcycle as a nonzero value goes back to winquake.exe. In winquake, setting bobcycle to 0 actually displaced your point of view to be lower on your body. This can be tested easily by going to e2m2 and running around the knee deep water, with bobcycle 0, your view is now underwater!

2. When ever i pick up an item, the screen flash effect persists until i fire.

cl_bobcycle 0 rocks. just thought i'd mention that.

[Stung]

That's a shame. Are you getting an "off-centered" screen or a "all messed up" screen when ALT-Tabbing or something else?

I'm going to assume it's Windows Vista that's the problem -- it entirely crashes the program.

[PapaSmurf]

cl_bobcycle 0 rocks. just thought i'd mention that.

in glquake and winquake, it kinda sucks. For some reason, setting cl_bobcycle to 0 fixes your viewpoint at the low point of the bob, rather than the midpoint. So on some levels where the water is waist deep, your viewpoint will be underwater rather than out of the water.

setting cl_bob 0 and cl_bobup 0, will get rid of the bobbing motion, regardless of what cl_bobcycle is set as (except in d3dpro370.exe).

[Baker]

setting cl_bob 0 and cl_bobup 0, will get rid of the bobbing mothing, regardless of what cl_bobcycle is set as (except in d3dpro370.exe).

If only d3dpro370 is doing this wrong, it may be resolved in the next release.

The D3DQuake guy, who wrote the code that was assimilated into this, used a compiler option that affected rounding (in a way that affects a lot of the code in a very unintended way).