wow thanks for this!

Thought the game was Hor+ in the first place...

I've actually been playing around with Quake 3 lately too.

Though I'm going in the opposite direction by writing a totally new Q3 renderer in C++ (from scratch - no game libraries like unity/ogre) with GL3 + glsl.
I'm trying to implement everything in modern techniques, so I'm actually throwing out a lot of the baked in Q3 data:
-Global illumination instead of vertex illumination and lightmaps
-Occlusion culling instead of PVS
-GLSL instead of the q3 shader system

I'm also not using any code (or even referring to) from the Q3 source release. Already have the level itself rendering done in a pretty nice state in 56KB of code.

It's just a way to teach myself OpenGL though. I actually REALLY hated Quake3 for being multiplayer-only. As such no one will probably ever be interested in my releasing this since I won't be adding networking or even bots for local play (unless at some point I become interested in AI programming).

I will give this a try in the coming weeks 😀

"rename this file to the PK3 extension"
so
goodpalette.pk3.pk3 ?

Just chop off the .zip extension. .pk3 isn't allowed on Vogons 🙁

Jarvik7 wrote:

-GLSL instead of the q3 shader system

That would be fine if you parsed the old shaders just to layer textures or find tcGens and substitute other effects for it like cubemapping reflecting the current scene in GLSL. At least have two stages supported because of certain effects like the crossblended fires 😀

Also doing it from scratch reminds me of this old noble effort - which I wonder is portable enough to be a renderer module...

d1stortion wrote:

Thought the game was Hor+ in the first place...

Nope. Default behavior is Vert-, and often the "wide screen fix's" are just raising the cg_fov value to compensate, though this also introduces vertical distortion and the weapon being pushed down - and r_customPixelAspect doesn't seem to actually work as intended.

I pulled that from here, the screenshots look ok to me (aside from the obviously stretched hud, but it's an old game anyway). There is something going on with the crosshair though, but the circular objects in the background still appear circular in widescreen.

I've been wanting proper widescreen support for Quake III for such a long time. I hope this engine delivers. 😀

EDIT: Just played a few minutes of it with this engine, then with the original quake3.exe, the Hor+ support makes a whole world of difference. Hopefully this won't be considered cheating online. 🤣

Amazingly, Unreal Tournament and even Quake II had proper support for widescreen resolutions afaik, and both games used engines that predated Quake III. I don't know what method of widescreen correction they used, but whatever the case was, in Quake II selecting a widescreen resolution was as easy as choosing any other resolution, and for UT, all it took was one console command, and no meddling with configuration files or anything.

It shouldn't be cheating since even Quake Live has hor+, IIRC.

Q2 and UT were vert-.

leileilol wrote:

It shouldn't be cheating since even Quake Live has hor+, IIRC.

Q2 and UT were vert-.

So by playing Q2 and UT at my monitor's full resolution, I'm actually putting myself at a disadvantage? Dang. 😜

UT allows for a custom FOV to compensate...

Pleased to announce that this does indeed work on my Voodoo 3 3000 with 3Dfx's OpenGL ICD. It also does indeed give a slight performance boost 😀. Cool stuff leilei, keep it coming!

d1stortion wrote:

UT allows for a custom FOV to compensate...

I never actually knew that UT allowed you to set your FOV. What would be a good FOV for a 16:10 monitor?

The engine will instantly crash for me with a gray/white screen on a Pentium 3 with an Obsidian2 200sbi and win98se. I have already tried placing official 3dfx icds on rhe game's directory without results. Can this be because of using non-reference, custom drivers for the sli card?

subhuman@xgtx wrote:

The engine will instantly crash for me with a gray/white screen on a Pentium 3 with an Obsidian2 200sbi and win98se. I have already tried placing official 3dfx icds on rhe game's directory without results. Can this be because of using non-reference, custom drivers for the sli card?

Try switching from 3dfxvgl.dll to opengl32.dll and vice versa.

mr_bigmouth_502 wrote:

d1stortion wrote:

UT allows for a custom FOV to compensate...

I never actually knew that UT allowed you to set your FOV. What would be a good FOV for a 16:10 monitor?

100, presumably.

subhuman@xgtx wrote:

The engine will instantly crash for me with a gray/white screen on a Pentium 3 with an Obsidian2 200sbi and win98se. I have already tried placing official 3dfx icds on rhe game's directory without results. Can this be because of using non-reference, custom drivers for the sli card?

You must patch Q3A to version 1.32.
P.S. This renderer is slow... P4 3.2 GHz + Voodoo2 12 MB.

d1stortion wrote:

mr_bigmouth_502 wrote:

d1stortion wrote:

UT allows for a custom FOV to compensate...

I never actually knew that UT allowed you to set your FOV. What would be a good FOV for a 16:10 monitor?

100, presumably.

Cool. Would I be able to use this online, like on Quake III, or would it be considered a cheat?

It's not Punkbuster protected.

Gamecollector wrote:

P.S. This renderer is slow... P4 3.2 GHz + Voodoo2 12 MB.

And what ICD are you using? I'd imagine those "fast" Mesa3D-based ones might not implement paletted textures... remember to enable paletted, r_textureBits 8 and r_ext_paletted_texture 1. If paletted texture isn't natively supported, then you'll see smooth and clean mipmaps (since I didn't implement that function for true paletted), and the console should have a warning message about that extension.

I've only tested this in a January 2000 3dfx GL ICD and it's definitely faster on that.