News | Forum | People | FAQ | Links | Search | Register | Log in
Q1 Tools Update
at http://user.tninet.se/~xir870k . All engines are updated with many features/fixes, e.g. speed optimized builds, enhanced QC (progs) validation and support for 1k sounds.

GL-engines have now also external bsp texture support, smooth model interpolation and improved model lighting. GL/WinQuake have now rudimentary Nehahra support and can have 64k globals in progs.

NehQuake has now also support for 1k models, >32k clipnodes and improved standard engine conformance. Light and ConvDem have some minor fixes. Please see readmes for details.

Any comments are welcome.
I Love You 
Renderer Differences 
What is causing BengtQuake and FitzQuake to render things so differently?

STARTMAP in BengtQuake: http://www.saunalahti.fi/dnaumov/qecomp/start-bengt.png
STARTMAP in FitzQuake: http://www.saunalahti.fi/dnaumov/qecomp/start-fitz.png

DM6 in BengtQuake: http://www.saunalahti.fi/dnaumov/qecomp/dm6-bengt.png
DM& in FitzQuake: http://www.saunalahti.fi/dnaumov/qecomp/dm6-fitz.png

The screenshots were taken with exact same video settings and config, a lossless image format was used to avoid compression artefacts. 
Also Way Slower 
timedemo demo1 results

bengtquake: 127fps
fitzquake: 196fps

"-width 800 -height 600 -bpp 32 -heapsize 64000" used with both, same video settings/config. 
 
I vote for the fitzquake look and fps.

Aguirre can't you combine efforts with metlslime to produce some ultra FitzaguQuake or something? 
Hmm. I Love You But... 
I agree. Fitzquake has the nicest renderer around. Of course, your engine handles big stuff nicely (I'm guessing that's part of the reason for better FPS in Fitzquake), which is about the only reason I use it at all - It's good for testing broken maps.

I agree, maybe you engine coders (you, Tyrann and Metl - the ones concerned with useability and not implementing fancy effects*) and produce an uberengine?

By the way, is it possible to support two protocols in the same engine? For example, when loading a map start with the regular protocol, then if the map seems to be too big, cancel and reload using the more hardcore protocol. This would benefit from a widemap console command to load a map straight into the hardcore protocol. Sorry if I keep saying "hardcore", I can't think of a better word right now.

I dunno if you or metl already have this in your engines, but how about a console command to execute triggers? "trigger targetname" and "killtarget targetname". If it's an easy thing to add, it would be quite handy on occasion.

*note: I am not against Darkplaces etc. There are people that want to use them, but I'm not one of them. 
Jago: 
First, fitzquake has 2x overbright lighting on both lightmapped polys and .mdl models. You can see that my zombies are brighter, and you can see brighter highlights on the white pillars and on the wall above the spikes. The default glquake lighting flattens out those hotspots.

Second, you ran fitzquake in 16bpp mode, and the bengt shots are in 32bpp. The sky texture is a giveaway becuase it's got an alpha channel, so instead of being 5-6-5 bits per channel like the other textures, it's 4-4-4-4. You can also see that the fitzquake shots are dithered, which some cards do when rendering in 16bpp.

Third, fitzquake has fullbrights (check out the red crosses on the health packs.)

Fourth, fitzquake doesn't mipmap the water textures, so the teleporters looks sharper.

Fifth, fitzquake doesn't do anything to make torches look brighter, instead it just lets the texture's fullbrights do the job, so the torch models look a bit different as a result.

Finally, the colors look a little more saturated in the fitzquake shots, but i can't explain that. Unless the gamma correction was done differently. I don't think it can be explained by the different bit depth. 
I Prefer The Fitz Look Too 
especially the lighting.

BUT, aguirre's engine is actually closer to how standard, default gl quake looks. 
 
i use joequake... but is always god to see clients to be upgraded!

good work ;) and yes i already use bengtquake :) in tronyn map i use it! 
Nitin: 
well of course, but glquake is sort of an ugly approximation of winquake, which is the renderer i'm trying to emulate. 
I Too Would Like To See A Combination Of Fitz And Bengt 
Especially because my map only runs in bengtquake right now, but I'm sure it would look deliciouser in fitzquake. 
 
the maxed limits should be toggleable, though. 
Fullbrights 
Sorry to rant but:
I don't understand why anyone would specifically leave this feature out. It was planned in quake from the beginning, only id glquake and glqwcl until fuh-gl 2.2something didn't have it because of some old voodoo1 hw limitation / code oversight, and it was ugly as hell. Idbase lights in the dark were fucked, the red metal rune decors in dm2 were fucked, health boxes, whatever, you name it...

Plus nowadays it can be done with external textures too (lumas or something), and the external textures have been made accordingly. 
Thanks For The Comments 
Although I'd like this thread to be less about "My engine is better than your engine" or "Why FitzQuake/DarkPlaces/Telejano rulez" and more about the actual new features of my tools/engines, I'd like to address a few things. I will use the term other engines, which basically means any other Q1 engine.

1. Speed: You should find that in most real scenarios, my engines are often faster than other engines and this means loading, playing, demos, etc. If you use similar settings (although this is not always possible) or a clean start (no autoexec/config, only the same simple cmd line), my engines are often faster.

This applies to both small and huge maps with few enemies or hordes. When other engines actually are faster, it's usually in certain special cases (e.g. unvised huge maps with no monsters). I can't of course speak for any graphic card/driver combination, but on both my systems (ancient Voodoo2 and more recent GeForce3) this is true. Especially since many engines don't even run on older systems - mine do and run well.

2. Rendering: As this is usually extremely opinionated, I'll first state that I don't think software renderers (like pixellated DOS/WinQuake) are interesting to imitate in any way and this includes the ancient fullbright pixel handling. It was how Quake originally looked in the very beginning, when nothing else was possible. The palette and memory was limited, speed was at a premium (486 computers with only VGA) and players weren't really used to anything better.

id probably tried to spice it up as it otherwise would've been just different shades of green/brown as many critics also complained about. Today, I don't think it is relevant at all to compare with an engine that's seriously slow, pixellated and has horrible banding in any lit area. Also, having brightly lit (or even always fullbright) models may be useful in DM, but looks terrible in SP and other engines render models way too bright.

The fullbright pixel handling on models/textures can actually look nice (or at least interesting) sometimes, when it's used for making self-lit objects like flames/torches/plasma brighter, but it's awful when the overall result is garish day-glo. Especially in the Quake world, where except in the base style, most things are supposed to be old stuff and not self-illuminated wall panels that are taken from some Sci-Fi setting. Even in the base style, the plastic red/green/blue details look toy-like and out of place. Not to mention the awful fullbright spots on textures that haven't been "prepared" to work in engines with fullbright pixel amplification ...

3. Playability: This is maybe the most important aspect of engines; if you can't play the map, it really doesn't matter how it looks or how fast it crashes. Compatibility, capacity and robustness are the key words here and those are the exact goals for all my tools/engines. Any standard Q1 map should be loadable and playable and while I can't guarantee that for obvious reasons, I can safely say that all my engines are regularly verified to work with about 5000 Q1 maps; DM/SP/TF/CTF and singles as well as PC/TC paks. And even if I'm not a DM player, bot play has been extensively verified in high energy situations using most of the known bot paks.

Other engines just keep on crashing; if they can actually load a map, they'll usually fail later either by misbehaving (e.g. not displaying or even including! all entities) or die stuttering by choking when the heat turns up. Again, all my engines are verified to work in the most extreme nightmare scenarios, with huge maps and hordes of active monsters. Like everything else there are still limits, but they're all tuned to work together and with reasonable results on today's (and yesterday's) computers.

Since my engines are actually used for playing (as opposed to some technical ecstasy showcases), they have also encountered and been fixed for numerous gameplay issues that in other engines will just throw the player out of the game, disrupting the experience.

4. Reliability: This is of course closely related to playability, but this also applies to using the engines for developing and troubleshooting maps or QC. As most development is error-prone at one time or another, it's vital that you can rely on the engine to help you locate the cause of the problem and not just crash without any message. This has also been a major design goal in my engines and while I'm sure they still have many bugs, they're far more reliable than all other engines.

Hopefully, this explains some of my motivation and stance regarding the tools and engines. But again, I'd really like this thread to offer feedback or opinions on the actual new features of my tools/engines update, not just another pointless trench-trudging engine flame war. 
Well Then 
I'm surprised that you don't like fullbrights. I respect your opinion, but I think some of your reasons are not right.

It's not a trick. Their whole idea that the surface is emitting it's own light, hence it's always the same brightness regardless of the light falling on it. Besides being realistic, it often looks good to have these faintly glowing things in a dark setting. When I mentioned tech textures, I was mostly thinking about the yellowish-white light panels. And if a mapper thinks the fb looks bad, he can always use other textures which don't have fullbright places, or use more light in the area, which damps them.

I don't want to flame, but I wonder: if id / Carmack had bothered to put the correct fullbright feature into glquake, I believe we wouldn't be having this discussion...

I appreciate your efforts of doing a robust and solid client, I use it often too, especially when other clients fail. I'm not after modern eye candy addons etc.. 
 
i built a map... it had about 3.5k monsters in it with a special progs so that they would start fighting any monster not of the same class...

was quite fun watching that without stuttering or sound cut off. :P~~

maybe i'll record a .avi of it. ^_^; 
Necros 
which monsters would these be? Do we have another candidate for the assault on Olos Khommor? You know I like it when you do the avi thing :P

Actually, there's some other things I wanted to discuss; get on the hotdog if you have time. 
Yeah... 
i started playing WoW again. :(

that game never truly lets you go. :P 
Aguirre: 
I hope you didn't take my post as a criticism of your work; i was just trying answer the question of why the engines looked different in those screenshots. I do think your engine provides a valuable service for loading problem levels and mods. Keep up the good work. 
Woah There! 
I wasn't saying your engine was bad/worse than fitzquake either. I think you engine guys are doing great work. I'm just sad that I can't have the best of both worlds - the appearance of software quake at high resolution (seriously, what crack are you smoking when you think GLQuake looks better? Sorry, that is flamebait, ignore it :) and the behind the scenes power of your engine.

Just a quick pointer about GLQuake vs WinQuake. I am no coder, so I don't know if this is true, but I suspect that if adding overbrights and fullbrights was a trivial thing and didn't require a second pass and severe performance hit on the early 3d cards (i.e. Voodoo) then Carmack would have implemented those features. There are tons of other reasons that I and many others dislike the look of GLQuake (aside from the washed out lighting), such as sparklies (more or less fixable with some cvar changing I think),broken waterwarp, dodgy particle blending (from what I rememeber), slow ass sky rendering, messy fluid texture rendering... There were also useability problems that have all been eliminated with most of the custom engines.

Also, some maps look shit with fullbright because the textures were not converted correctly (i.e. they were converted for glquake, which didn't support fullbrights, so the fullbrights were used as standard colours). Most modern maps have non-fucked textures with either no fullbrights, or fullbrights in the proper places. The id maps obviously were designed with fullbrights in mind, and thus there are runes glowing in the shadows (dm2 is a good example of this) and it looks good.

Btw, model interpolation is cool, although it's something I am happy without in Fitz. I find it looks weird when everything moves smoothly after 10 years of 10frame per second anims :)

Couldn't post this in Opera :( I hope the recent func problems can be fixed easily - it's been a bit annoying lately. 
(So Going To Get Flamed.) 
I'm not going to argue Fitz vs Aguire - they're both excellent engines, but I do wish that they'd both get around to fixing the GLQuake 'console flickering' bug that makes GlQuake unplayable on my Intel GMA 900 integrated vid card.

(Well, almost unplayable, unless I use inferior engines like ToChris or Darkplaces that actually fix this bug.) 
Agree With Most Of What's Already Been Said... 
While I appreciate FitzQuake immensely and agree with most of metl's choices in terms of visuals, aguirRe's engines are an invaluable tool for anyone developing a large Q1SP map. He just keeps pushing the limits and from a mapper's perspective that's a beautiful thing. 
AguirRe Quake 
...is an absolute must have in my Quake folder since the increased limits make almost any bsp run. It also can dump out handy information that I can use to bring down limits in my maps such as clipnodes, bmodels, lightmaps, etc. It has great debugging features. I rely on it for my mapping project since I horribly abuse standard map limits but I am making sure all my projects run in FitzQuake before calling them done.

It is very stable and reliable and it replaces GLQuake for me. 
Yup 
fitz is my general engine of choice, whilst aguires engine is the one I go crying to if I have any serious problems :) 
Whoa Nessie 
The -nehahra support for the winquake.exe and glquake.exe is very interesting. That's the first time I've seen Nehahra in software in a very loooong time... it brought me back to some old very good days... early days... Of course, the stuff that is supposed to be transparent looks awful.. but a version that simply removes transparent brushes (and does a few other little things).. not to mention doesn't call a lot of cvars not present (which gives those UNKNOWN COMMANDS). Watching the demos in software... weird! I presume you could watch The Seal of Nehahra on the thing. To see that in software would be freaky for sure :)

I do enjoy software.. when I'm in the mood for software and some nostalgia...

However... heh... I don't dig GL engines that attempt to emulate software *much* (to offer the dissenting opinion which has just as much presence as the former but is too seldom voiced.. we're like the quiet Democrats while the Republicans run their mouths and sometimes even grab bullhorns).

A monkey that acts like a man may be impressive, but a man that acts like a monkey is a degenerate (not to mention embarassing).

I don't dig the lighting on models that makes them brighter than the surroundings, causing them to stand out more, whereas in Bengt engines it is smooth and visually correct.

I am of the same opinion as Bengt on Fullbrights and I needn't echo.

I'm likely inviting great harassment with what I'll next say, but overbrights fall under the trivial category as far as I'm concerned. I can take 'em or leave 'em. I've gone back and forth with RPG on the subject. He demonstrated with two screenshots showing the difference between overbrights and no overbrights. Yes, I did see the difference between the two, vaguely, more so when I looked at the two shots side by side, but I failed to see what was so earth-shattering. It is not as if while playing a map I would stop and say, "Wow, look at that overbright lighting." A mapper would do that. Mappers obsess about these things (often I believe *gulp* unnecessarily). A player who happens to be a mapper might. I cannot claim to think like a mapper. Though I've tried my hand at mapping on a number of occasion, I cannot call myself a mapper either. But I sometimes consider this an asset as it offers a degree of impartiality. I can look at things from different angles and compartmentalize each filter I run my perception through). I play like a player and think like a player. What do I not really notice or give much attention to as a player? Overbright lighting. Hence: I consider it trivial (though I prefer no overbrights and I admit that I shut them off in Fitz... because there's a thin line between emphasis in lighting and contrast which distracts from the game... which is what most players are there for... the game.. killing stuff...)

Big maps: yeah baby.

Speed: One of the most important ingredients. The Bengt engines, even the original nehahra engine and perhaps the dpnehahra.exe, practically laugh off high r_speeds and huge epoly counts. One significant factor in Nehahra not quite agreeing with a lot of other engines, ESPECIALLY now with the new monsters in, is the engines just can't handle it. It can't handle the high polys of some of the more detailed models.. at least.. when they're in bulk. Once those epolys fly up into the stratosphere and you've got heavy action going on, most engines bog down. Some die. Some crash hard (send some Get Well letters, boys and girls, but you'd best put a lot of postage on them, because it's a long journey down to Hell where those engines tend to land.)

Transparency: This is only implemented in Nehahra and DP as far as I know.. maybe someone else squeezed it in... But the potential for its use is fantastic. I am absolutely surprised that more people do not rally for it in engines. What excuse might one have not to?

Lastly.. model interpolation... what can I say on that other than it's impossible for me to step back. You become accustomed to everything so smooth. Loading up an engine without it where the models seem to blink in and out of existence with every move is very near to offensive. Unsightly to my eyes. In software, I expect it (and somehow doesn't bother me.. I expect because it isn't in anachronistic contrast to the GL environment around it as is the case with GL engines without interpolation, IMO).

Just an opinion. Grain of salt all around.

Keep up the good work, Bengt. 
Whoa Nessie 
The -nehahra support for the winquake.exe and glquake.exe is very interesting. That's the first time I've seen Nehahra in software in a very loooong time... it brought me back to some old very good days... early days... Of course, the stuff that is supposed to be transparent looks awful.. but a version that simply removes transparent brushes (and does a few other little things).. not to mention doesn't call a lot of cvars not present (which gives those UNKNOWN COMMANDS). Watching the demos in software... weird! I presume you could watch The Seal of Nehahra on the thing. To see that in software would be freaky for sure :)

I do enjoy software.. when I'm in the mood for software and some nostalgia...

However... heh... I don't dig GL engines that attempt to emulate software *much* (to offer the dissenting opinion which has just as much presence as the former but is too seldom voiced.. we're like the quiet Democrats while the Republicans run their mouths and sometimes even grab bullhorns).

A monkey that acts like a man may be impressive, but a man that acts like a monkey is a degenerate (not to mention embarassing).

I don't dig the lighting on models that makes them brighter than the surroundings, causing them to stand out more, whereas in Bengt engines it is smooth and visually correct.

I am of the same opinion as Bengt on Fullbrights and I needn't echo.

I'm likely inviting great harassment with what I'll next say, but overbrights fall under the trivial category as far as I'm concerned. I can take 'em or leave 'em. I've gone back and forth with RPG on the subject. He demonstrated with two screenshots showing the difference between overbrights and no overbrights. Yes, I did see the difference between the two, vaguely, more so when I looked at the two shots side by side, but I failed to see what was so earth-shattering. It is not as if while playing a map I would stop and say, "Wow, look at that overbright lighting." A mapper would do that. Mappers obsess about these things (often I believe *gulp* unnecessarily). A player who happens to be a mapper might. I cannot claim to think like a mapper. Though I've tried my hand at mapping on a number of occasion, I cannot call myself a mapper either. But I sometimes consider this an asset as it offers a degree of impartiality. I can look at things from different angles and compartmentalize each filter I run my perception through). I play like a player and think like a player. What do I not really notice or give much attention to as a player? Overbright lighting. Hence: I consider it trivial (though I prefer no overbrights and I admit that I shut them off in Fitz... because there's a thin line between emphasis in lighting and contrast which distracts from the game... which is what most players are there for... the game.. killing stuff...)

Big maps: yeah baby.

Speed: One of the most important ingredients. The Bengt engines, even the original nehahra engine and perhaps the dpnehahra.exe, practically laugh off high r_speeds and huge epoly counts. One significant factor in Nehahra not quite agreeing with a lot of other engines, ESPECIALLY now with the new monsters in, is the engines just can't handle it. It can't handle the high polys of some of the more detailed models.. at least.. when they're in bulk. Once those epolys fly up into the stratosphere and you've got heavy action going on, most engines bog down. Some die. Some crash hard (send some Get Well letters, boys and girls, but you'd best put a lot of postage on them, because it's a long journey down to Hell where those engines tend to land.)

Transparency: This is only implemented in Nehahra and DP as far as I know.. maybe someone else squeezed it in... But the potential for its use is fantastic. I am absolutely surprised that more people do not rally for it in engines. What excuse might one have not to?

Lastly.. model interpolation... what can I say on that other than it's impossible for me to step back. You become accustomed to everything so smooth. Loading up an engine without it where the models seem to blink in and out of existence with every move is very near to offensive. Unsightly to my eyes. In software, I expect it (and somehow doesn't bother me.. I expect because it isn't in anachronistic contrast to the GL environment around it as is the case with GL engines without interpolation, IMO).

Just an opinion. Grain of salt all around.

Keep up the good work, Bengt. 
Just Checked This Thread -> My 2 Pennyworth 
hm, seems like everyone�s arguing about how many angels can dance on the head of a pin.

True, some engines do other things better but at the moment the previous engine from Aguire is my engine of choice and the one I use most often. This is because I know maps will run on it, no matter how complex / spacious. My other favourite is darkplaces (the blood! and game speed - 1.25 my preference) but the sad fact is that some maps will not run or else experience problems.

As to the fullbrights - useful, yes, and it takes a mapper who wants to remove thier effect for whatever reason about two minutes (granted PS (or image editor of choice) is needed as well but it�s not difficult)to change it. I for one like fullbrights as certain effects are highlighted by them, though they do have thier (limited) place it�s true, 99% of the �normal� players out there will never notice the difference - only the people (such as myself) who take a game this old extremely seriously and still allow it to eat huge quantities of thier real life (tm) . . .

Now I tend to prefer building a level than playing it (ok, and playtesting it) and so whenever I try an engine I think ok, it does this (insert cool_feature); how can I use it?

Granted Aguire�s engine doesn�t have the bells and whistles of some of the others but it seems like "running reliably, any conceivable type of map" has been discounted by most as not a special feature. It�s a feature because most other engine�s can�t do it, just because you don�t notice it as a feature doesn�t make it less valuable.

>rant finished< 
Thanks For More Comments 
I'll try to address some of the issues you've mentioned.

than: It's possible to have more than one protocol in the engine; both DP and mine have several. The only big catch I know is something I discovered rather recently; progs can inject any arbitrary bytes right into the protocol stream via the server without any supervision (design: argh!).

This can cause major damage as the progs isn't aware of any protocol negotiations between the client and server, but fortunately most progs only use a pretty small subset of the services and they typically don't cause any problems.

In my engines, protocol handling is fixed from the server side, but the clients adapt to the current server. This means backwards compatibility, i.e. clients can connect to (or playback demos from) older servers. In the latest versions, this also means handling of the slightly extended Nehahra protocol (actually a "bastard" variant of std protocol 15, pretty common in custom engines), either by actually handling the extra info/services or just silently parse them and continue with the next.

DP has a user selectable protocol set controlled by a cvar and it has (like mine) several extended native protocols as well as the possibility to generate std Q1 protocol 15 (although it can actually produce too big messages in this mode - you can use my ConvDem to fix demos with this problem). DP might have more related features that I haven't delved into yet.

However, I can't see how the server can switch protocols midway, as the client will immediately abort if you're not imposing a new, incompatible soft protocol negotiation (which most likely will rule out any std client and which then basically nullifies the whole idea).

A console command for executing triggers (basically a use command I guess) has been suggested before by Kinn, I didn't do it then because I was unsure of implications. I haven't done anything yet about it. IIRC, Kinn solved it himself in the progs (which is maybe a better way to do it).

Engine sparklies (I assume tjunction effects) should either be already fixed by a better default setting for cvar gl_keeptjunctions or not easily fixable because the bsp is built without padded tjunctions (e.g. with TreeQBSP 1.63). Waterwarp can be disabled just like in WinQuake; r_waterwarp 0. Slow sky rendering is also fixed by a better default value of gl_subdivide_size (more sky distortion as usual though, but it doesn't bother me).

paneon: I'm unaware of the flickering console bug you mention, do you actually mean the flickering status bar when gl_clear is enabled? Have you tried different drivers/resolutions/colour depths, window/fullscreen operation or adding "-no8bit", "-nomtex" or other similar remedies? It sounds like a hardware/driver issue.

Mindcrime: Yes, you can watch the whole Nehahra movie (and all demos of course) in my latest GL/WinQuake. The only drawbacks are more or less limited visual features supported and that you'll have to restart the engine somewhere near the end of the four hour movie (i.e. you can't watch the whole movie in one engine session). The movie looks pretty good in WinQuake; you'll just have to enable your brain's "software filter" ...

As for Nehahra (or general) transparencies, JoeQuake also supports that AFAIK.

All my engines are of course also already prepared for the upcoming Nehahra Revamp material and if nothing major comes up along the way, I'll try to keep it that way. 
 
aguirRe client is like having a life colet is water... always in my Quake directory and is tools for mapping is a need :) they rockzzzz keep good work aguirRe ;) 
Trinca 
nice post :) 
Quake Console Flicker 
I get this in fitzquake whenever some other program pops up a dialogue that doesn't steal focus fully (and minimise fitz). For example, when I change the volume on my laptop, a little volume level meter appears on the screen. When it dissapears, the statusbar flashes. It stops when I toggle the console. It might also stop when the screen is affected by some kind of flash or effect, such as picking up an item or going underwater, though I'm not sure.

Anyway. this problem is not severe for me, and I haven't noticed it in any other engines. I didn't notice it in Aguire's engine whilst I was playing Masque, so presumably it is a different bug to the one that paneon is on about. Fitz defaults to 0 for gl_clear. 
Inertia 
qw engines have different physics and netcode, but i find ezquake to feel very nice for map development (sp and dm) 
Quick Question About The Engine 
Does it support the extension system ? 
Console Flicker Bug 
I can't show you a screenshot view of the console flicker bug - because all screenshots I make with any engine show perfect Quakey goodness. To see what my view of GLQuake looks like, type 'disconnect' into the console. See how the console then covers the whole screen? Imagine that Quake constantly flickers back and forward between this full-screen view of the console and the normal view of Quake at 85Hz while you're trying to play. That's the Intel integrated video 'console flicker bug.'

The console flicker bug is definitely a software error (my GMA900 card works fine on toChris and Darkplaces, not to mention all other ID games from Quake 2 to Doom 3) - but ATI and nVidia (and previously 3dfx) obviously have much greater corporate focus in developing decent graphic cards/drivers than Intel, so I guess their drivers must be written to preclude errors like this. 
No 
if you by that mean that you can call a builtin to see what's supported. 
Paneon 
Have you tried the suggestions I mentioned to see if they make any difference? 
Wannabe Modder's Perspective 
I've used all of the major engines and so far fitz was the only gl-engine one that could handle the requirements of Per-kr's models and still run on my system. but sounds would cut out and packets would overflow at a regular rate. Fitz also had good network playing-ability... until i downloaded aguirre-quake and had no packets overflowing (so far, not thoroughly tested) and no sounds cutting out. i haven't tested network stability however. the only other concern i have and this would just be icing on a rather tasty cake, is if BengtQuake supports file handling from qc. that would be sweet. 
No, There Are 
no extensions except the Nehahra ones yet. This is basically the few that seem originally intended for Q2 (e.g. tracetoss). 
AguirRe 
Yep - I've tried your suggestions, but no cigar.

(I think I'd better buy an OpenGL textbook, download the Quake source and VS Express 2005 and try and come up with a fix for this myself. I can't be the only odd person that doesn't believe that any good games have come out since 2000, and hence doesn't have any good reasons to upgrade from integrated video apart from this annoying Quake bug.) 
Try Setting 
gl_finish 1 and see if that helps. 
Sorry, But.... 
... gl_finish 1 doesn't help. Looks like I'll just have to play around with the code. 
If You Add 
option -condebug when running my GLQuake on the start map, you'll get a qconsole.log file. Zip it up and send it to me and I'll take a look at it. Please also include the full command line. 
Model Interpolation 
damn fine job on that aguire. So so smooth. 
Issue 
If I start the glquake.exe an error tells me:
(in german)
"Der Prozedureinsprungpunkt "_FMUSIC_loadSongmemory@8" wurde in DLL "fmod.dll" nicht gefunden"

I tried to get a new fmod.dll from fmod.org, but that didn't help. :( 
Duloque 
From the NehQuake readme:

If you get an error message regarding fmod.dll when starting, make sure to use the file from the Nehahra pack. Later versions are for unknown reasons not backwards compatible.

Please see if that helps. 
Duloque 
From the NehQuake readme:

If you get an error message regarding fmod.dll when starting, make sure to use the file from the Nehahra pack. Later versions are for unknown reasons not backwards compatible.

Please see if that helps. 
AguirRe 
Seems to work. Thanks! :) 
INTEL FLICKER BUG 
HAS ANYONE FOUND A WORK A ROUND FOR THE INTEL FLICKER BUG, ITS A RIGHT PAIN, ONE WAY AROUND THAT I DO IS TO HIT CTRL UP ARROW AND ESCAPE AS IF IM GOING TO SHUT IT DOWN, THEN HIT X AND GO BACK INTO THE GAME THAT WORKS FINE AND IT PLAYS FINE AS WELL, IF IT GOES BACK TO FLICKERING AFTER A MAP CHANGE DO IT AGAIN, IT USUALLY WILL SETTLE DOWN AFTER ABOUT TWO MAPS 
EGADS 
OBLIGATORY REPLY ABOUT CAPITAL LETTERS 
 
NO WONDER I HATE FUCKING GAMERS SO MUCH 
 
HAVE YOU EVER CONSIDERED THAT SOME OF US MIGHT NOT HAVE EYESIGHT AS GOOD AS EVERYONE ELSE AND TYPING IN CAPS ESNURES IT MAKES SENSE 
 
HAVE YOU EVER CONSIDERED THAT SOME OF US MIGHT NOT HAVE EYESIGHT AS GOOD AS EVERYONE ELSE AND TYPING IN CAPS ESNURES IT MAKES SENSE 
LOL, GOOD POINT. 
No 
i have, however, considered you're an idiot. 
 
TYPING IN CAPS ESNURES IT MAKES SENSE

Spelling might ensure it, too. 
What About 
typing in caps and spelling right - that makes double sense. The content is irrelevant.

Hint, if you use firefox, press ctrl-plus.

(this post is nonsensical, including this sentence.) 
ROFL 
LOLLERCAUST 
HEY MAN 
MAYBE IF YOU GET GLASSES THE SCREEN WONT APPEAR TO FLIKCER SO MUCH I HEAR THE LASIK IS RELALY GOOD TWO 
 
sorry not into acts of faith or modern mythos 
 
wow nonsensical, he'll be spouting prost next. at any rate no one has given an answer. what is the work a round for it? or do you know would be closer to the point. 
It's Proust, Silly. 
Obviously if someone knew, he would have answered you the first time you asked.
If you're so desperate try getting a new cheap gfx card. 
INtEl FLiCkEr BUg 
AlL I wAnT Is A rOoM sOmEwHeRe FaR aWaY fRoM tHe CoLd NiGhT aIr!

I aM cApS cHaLlEnGeD

(rAnD0M iDiOt pOsT) 
 
so then basically you lot know nothing and this entire forum board is meaningless as is your existence, the days of dada are still needed 
DEvO 
Come post here more often plz. From now on Im your loyal fan. 
Neo-dada 
it's back baby 
 
yes i do liven the place up dont i. what really ticks me off honestly is this. i now have doom, heretic and hexen looking better than quake which is bs if you ask me. ive tried everything from qw to fitzquake and ezquake and even in open gl they just dont look as good. i cant believe someone hasnt made a program like the doomsday machine for this game. 
SoRt It OuT 
I fOuNd Da iNtEl fIx hErE yOu sLaG:

http://www.fat-pie.com/chavs.htm 
 
i like that thx cept forget the cap and sportswear apparel way to fucking american for me, better yet lets do a family show with deathmetal, that is always comedy waiting to happen 
 
I think we already have established that it is your shitty intel card that is the porblem.

So please; Use winquake. 
Dada 
this board is more positive than others... sometimes. Like, nobody knows anything useful but at least we can have some fun. Alain Proust, the formula driver, what does he sprout? Sport a snout?

-La Chute

(Get a cheap nvidia card - they work.) 
 
either way moving on, i went out and bought a nvdia 7800 today which is a total piece of shit if there ever was one and guess what brain surgeons, it still fucking flickers, you incestuous lot are about on the level of fucking primates if that. 
Attn: DEvO 
A giant, black, throbbing cock slapping your drooling face forever. 
Feature Request! 
If Aguire is still reading.

Is it possible to add q2 style hint brush support to your compilers? I would so love that right now. 
If I Had A Penny... 
Is it possible to add q2 style hint brush support to your compilers?

...for every time someone asked aguirRe that, I might have enough to go buy a can of really, really cheap beer. 
Yeah... 
And add detail brushes while you're at it, kthxbye. =) 
Lol 
24 Oz can of US Steel -- 99 cents at the corner gas station. Be sure to get it really cold before it goes anywhere near your mouth. 
But... 
surely a hint brush is not a huge change to the code? all they do is suggest a good place to the compiler to create a new portal and don't require any fundamental changes to the code afaik. In Q2, all you needed was a texture named HINT.

Detail brushes are a bit different I think, but yeah, they would be nice too ;) 
Post A Reply:
Name:
Title:
Body:
message
question
exclamation
idea
flame
noflame
error
skull
beer
moon
pent
rocket
sheep
pacman
pig
cheese
worldcraft
gauntlet
crate
pitfall
pimp
smile
cool
sad
frown
oi
yay
tongue
evil
wink
neutral
q1
q2
q3
ut
hl
cs
doom
dkt
serious
cube
Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors.