Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

Things that are wrong with GLQuake Goto page 1, 2 Next

| Inside3d Forums Forum Index -> Engine Programming

View previous topic :: View next topic
Author | Message
--- | ---
mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Sun Jun 27, 2010 4:17 pm Post subject: Things that are wrong with GLQuake |

Let's have a central clearing house for things that are wrong with GLQuake. By keeping all of this info in the one place we can get a good resource for anyone working on an engine project, and may even uncover a few things that are not common knowledge.
I don't mean the visual aesthetic part. We all know about fullbrights and overbrights, and Quaddicted has already covered those. It could even be argued that they're a matter of personal preference. Let's get a bit more under the bonnet here.
We shouldn't assume that "because Carmack did it, it must be Good and Right". It was his first commercial and publicly released OpenGL app after all, and he was still learning at the time.
I'll start. R_DrawSequentialPoly - it's evil. A bunch of state changes, texture changes and enabling/disabling TMUs for every surface that is drawn. Far better to make a multitextured equivalent of DrawTextureChains, or even to disable multitexturing.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Sun Jun 27, 2010 4:36 pm Post subject: |

modern gfx cards support npot textures properly. glquake naturally couldn't use it at the time, resulting in alwardly resampled images. another thing wrong with glquake - it uses too many globals. but then so does sw rendering. The meshing code sucks too.
Skingroups are foobared.
Lots of software code completely duplicated, even with no significant changes.
Not all sprite types are supported.
_________________
What's a signature?

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Sun Jun 27, 2010 5:19 pm Post subject: |

Flashblends defaulting on, but that's understandable at the time in mid-1997, texture upload performance sucked for everyone Console scroll speed when closing seems a lot slower than software Texture mismatch crashes going from maps with different textures on same names is fatal.
White skins when there's no skin found out of range of available skins is bad for heads
_________________

Back to top |

Ranger366 Joined: 18 Mar 2010 Posts: 72 Location: Berlin (Germany) |

Posted: Sun Jun 27, 2010 5:51 pm Post subject: |

leileilol wrote:
Flashblends defaulting on, but that's understandable at the time in mid-1997, texture upload performance sucked for everyone Console scroll speed when closing seems a lot slower than software Texture mismatch crashes going from maps with different textures on same names is fatal.
White skins when there's no skin found out of range of available skins is bad for heads

Yeah White skins are sucking.
_________________

Back to top |

Sajt Joined: 16 Oct 2004 Posts: 1026 |

Posted: Sun Jun 27, 2010 6:16 pm Post subject: |

This is something which affects software engines too. It resulted in very hard to debug glitches when I was playing with a mod that used a lot of lightning. The fix: http://svn.icculus.org/qshed/trunk/goldquake/cl_tent.c?limit_changes=100&r1=74&r2=76&pathrev=76
_________________
F. A. Špork, an enlightened nobleman and a great patron of art, had a stately Baroque spa complex built on the banks of the River Labe.

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Sun Jun 27, 2010 6:53 pm Post subject: |

Here my 0.02$ about this. Let's stop trying to fix Quake. It's a 14-year old dog. Instead, let's create a new engine from scratch. It's the next logical step to take now. We may support to read the older file formats and convert them, in memory, to more modern stuff. Or, better yet, we can write a bunch of tools that read a .pak file and convert its contents to more modern stuff, and forget forever about mdl or wad2.
With a new engine, we can learn from the mistakes in 3 engine generations and select the best solutions. No more global pointers, no more static arrays, highly modularized design with low coupling, etc.
With a new engine, we can finally consider possibilities like efficient outdoor rendering support, PHS, more than 32 players, Q3-style shaders, ability to switch between OpenGL and DirectX, etc.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Ranger366 Joined: 18 Mar 2010 Posts: 72 Location: Berlin (Germany) |

Posted: Sun Jun 27, 2010 7:32 pm Post subject: |

frag.machine wrote:
Here my 0.02$ about this. Let's stop trying to fix Quake. It's a 14-year old dog. Instead, let's create a new engine from scratch. It's the next logical step to take now..

Right. We have high quality coders here, but i think when we modify and make Quake better, even performance, wich is important for my idea, we haveto make it for something wich hasnt the best specs. We all know that mobile consoles or phones are the future, and why make Quake better for this? I mean, look on PSP, Quake is perfectly made for this, and one of the best Homebrews are on this engine.
We should fix Quake2, its an Engine with much, much potencial. look at darkPlaces, holy shit, Quake 2 could look like Prey and Doom 3 if Lord havoc would enhance this.
_________________

Back to top |

mh Joined: 12 Jan 2008 Posts: 910 |

Posted: Sun Jun 27, 2010 8:08 pm Post subject: |

There are a few reasons, but the biggie is that nobody is ever going to agree on a way forward with a clean sheet of paper design. We've seen this before every other time, and there's no cause to suspect that things would be any different now.
So why Quake? For some of us the engine is a means to an end rather than an end in itself, and Quake-The-Game is what matters. A good engine serves to help them achieve that end better. For others it's like that beat-up Oldsmobile that you love tinkering under the bonnet of. Let them soup it up, add new sparkplugs, etc. For the more reactionary retro-junkies all time and history stopped in 1996, and anything more recent gets a rather firm "la la la can't hear you" back at it.
TBH unless you fall into one of those 3 categories (or something similar) you may well ask valid questions, but I don't think you're in the intended audience of this thread.
Me, I love my 14-year old doggie.
_________________
DirectQ Engine - New release 1.8.666a, 9th August 2010
MHQuake Blog (General)
Direct3D 8 Quake Engines

Back to top |

frag.machine Joined: 25 Nov 2006 Posts: 728 |

Posted: Sun Jun 27, 2010 11:02 pm Post subject: |

mh wrote:
Me, I love my 14-year old doggie.

I agree about we never being able to gather all the community to create something starting with a blank sheet of paper. But I think is quite feasible to a small group - let's say, up to 5 people - to agree around the basics and start small: first, to define the new media formats to be adopted, then to create the tools to migrate the original artwork, then define the core render features and create a prototype/alpha version, etc. One step at time, I believe we can do that. Moreover, even if not everyone embraces the idea, many of the byproducts of the project can be reused in already existing engines.
But, let's not derail the thread with this discussion.
_________________
frag.machine - Q2K4 Project
http://fragmachine.quakedev.com/

Back to top |

Ranger366 Joined: 18 Mar 2010 Posts: 72 Location: Berlin (Germany) |

Posted: Mon Jun 28, 2010 3:14 pm Post subject: |

I just fixed the white texture bugs with making that no8bit is standardly ON, i dont care about 8bit thingies... tell me one important thing wich can be stocked in quake wich requires 8bit... idk right, i never saw a difference when i turned no8bit on...
_________________

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Mon Jun 28, 2010 3:41 pm Post subject: |

not all graphics cards support the default lighting mode that glquake uses, and the alternatives are broken anyway. GL_RGB (24bit packed) works on every card that I know of, assuming the engine is fixed to support it. _________________ What's a signature?

Back to top |

Ranger366 Joined: 18 Mar 2010 Posts: 72 Location: Berlin (Germany) |

Posted: Mon Jun 28, 2010 3:49 pm Post subject: |

Spike wrote:
not all graphics cards support the default lighting mode that glquake uses, and the alternatives are broken anyway. GL_RGB (24bit packed) works on every card that I know of, assuming the engine is fixed to support it.

Fixing this would be better for the GLQuake Engine.
I still have on my PC one modified version of GLQuake, wich simply fixes the Engine and makes Multiplayer sync a bit better...
Anyway, there should be one Engine wich fixes all things listed here, not like DarkPlaces wich implents alot-alot-alototot stuff more wich isnt needed for good old quake.
Off-T: Yeah, the Quake Lightning... is there one article or something for better light? I mean general resource, the spaces between darker/brighter steps are too long, must be sharper (lol? i hope i dont say crap)
(pop.lmp is a very interesting type of file.)
_________________

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Mon Jun 28, 2010 4:25 pm Post subject: |

QMB was meant to fix the various bugs in quake without adding anything particuarly new or too bloated. I remember them having a list of bugs and a patch/solution for each one. If you want a list of issues with the Quake engine in general then that would be a good site to browse.
(lightmap quality is locked to 1/16th of world texture resolution - that is, use texture scaling and you'll scale lightmaps too).
_________________
What's a signature?

Back to top |

Ranger366 Joined: 18 Mar 2010 Posts: 72 Location: Berlin (Germany) |

Posted: Mon Jun 28, 2010 4:45 pm Post subject: |

Spike wrote:
(lightmap quality is locked to 1/16th of world texture resolution - that is, use texture scaling and you'll scale lightmaps too).

Yeah, same in Half-Life i think, i amde one HL Map with some 512x512 texture with scaling on brush 0.25x0.25, this scaled down the flashlight too...
but this isnt the thing i mean, wait im looking in the code for this scene...
_________________

Back to top |

leileilol Joined: 15 Oct 2004 Posts: 1321 |

Posted: Mon Jun 28, 2010 8:15 pm Post subject: |

Ranger366 wrote:
i never saw a difference when i turned no8bit on...

because your card does not support paletted textures

Spike wrote:
not all graphics cards support the default lighting mode that glquake uses, and the alternatives are broken anyway. GL_RGB (24bit packed) works on every card that I know of, assuming the engine is fixed to support it.

*cough*PowerVR PCX-2*cough*

Ranger366 wrote:
Anyway, there should be one Engine wich fixes all things listed here, not like DarkPlaces wich implents alot-alot-alototot stuff more wich isnt needed for good old quake.

FitzQuake? There are plenty that already fix most

Ranger366 wrote:
(pop.lmp is a very interesting type of file.)

It's just the Quake Q and it acts as a form of copy protection.
_________________

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> Engine Programming | All times are GMT Goto page 1, 2 Next
Page 1 of 2

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group