Wow ... this just keeps getting better and better. So far this sticks out as better than Warpspasm, Travail or Q2. The Warpspasm/Travail thing feels weird to say because I never really expected anything to pass Warpspasm or Travail.

The presentation is top notch, the fact it uses high resolution textures, ... sheesh. Probably 16 other things. The lighting.

Here is what bothers me ... and this isn't about RMQ:

1. RMQ has the word coop written all over it. However, being NetQuake that would realistically require a net code overhaul. I have spent a great deal of time thinking about how to pull that off or doing a DPP7 lite protocol. I feel that these kinds of things might happen this year (50/50 chance?).

2. The king-size maps almost require coop to correctly play. So many monsters and so much map size --- I mean seriously large maps -- would almost require a couple of players to find everything.

3. Might actually require coop for best experience. Watch other players do things from time to time instead of having to figure out everything yourself.

Plus this feels very replayable.

Please tell me this has been tested in coop and won't crash due to the camera action or what not ...

I have to admit when I heard about huge level sizes I wasn't so sure that was a good idea because generally I never thought map size was everything. But these maps have tons of detail and the colored lighting and high resolution textures make them look great.

Still, I think without people being able to coop the maps over the internet, the maximum potential of demo 3 won't be hit. 

Er - I tested the map on skill 3, and no-one has been man enough to feed me a nightmare demo. I think I would like to see your nightmare demo.

Known bugs:

1 - it is possible to break the end sequence by doing an Ankh near the start

2 - it is possible to re-fill the cavern once you have emptied it

3 - the killcount is wrong by one monster (I have figured out what causes this, it will be fixed)

4 - it is possible to to get stuck in the room with the ogres in two different ways

5 - if you fall off the platform at the end sequence, you have to travel quite a long distance to get back up again

6 - there is some zfighting at the tunnel entrance near the bridge in the large outside area

Luckily this stuff is W.I.P.

I had optimised the map to conform to the 657## verts limit, but since that was doubled a few months back thanks to the work of MH, I have since added a whole bunch of new 'stuff' to the map, and I am currently at the 74000ish mark, but I wont hit another limit until I reach about 130000 verts. So basically this map will be improved a shed-load before release. Stuff will be added, improved, bugs will be ironed out.

I appreciate your feedback genuinely, I was expecting a lot of comments about some of the known issues, and just generally because that is what happens when you release maps - but I have learned for a long time now that feedback is all good, if you take it the right way. It's all vaguely useful, even if it just re-iterates the point that "Item X, or SFX B seemed to go down like a lead balloon, maybe we should reconsider our options.

Believe you me, aside from the general musing, advocation and opinions being thrown around on this thread, our private forums have been BUZZING with creative activity on the back of this release, our intention is to get this project whipped right into some kind of real shape, we are listening to everyone.

Ultimately, we are going to do what WE want to do, but what that is changes, posts are moved, peoples opinions about ideas shift and change, and the evolution of the project has been quite profound up to this point alone, and I don't see it lessening any time soon. 

Do you guys have a public svn ? Or could you mail me the Intel tweaks. Cheers.

Public SVN here: svn://svn.icculus.org/remakequake/engine/Experimental

Be warned that the engine source code won't translate to any other Quake codebase without serious surgery.

OK, that out of the way.

Traditional Quake codebases do a LOT of work in software on the CPU. For the renderer much of this was transferred to the GPU instead - light animations, light updates in general, MDL animation and frame interpolation are all bottlenecks that were addressed. This allowed the data to be kept relatively static and in VBOs, which allowed for the renderer to avoid pipeline stalls associated with updating this type of data at runtime.

Much of this requires bumping the hardware requirements to a level that may be uncomfortable for some. That was a tradeoff that we discussed at length and are happy to accept. The current hardware requirements have settled around OpenGL 1.5 with the ARB program extensions and 5 or more texture units.

Even before this bump there were things done to improve on Intel but which are no longer in the code. These may be of more use to people, so I'll discuss them fairly generally.

A move from OpenGL immediate mode to vertex arrays was a very early change that saw useful gains in MDL rendering performance. Each MDL can be drawn with a single glDrawElements call. The vertex arrays needed for this can be built manually and at runtime if desirec, and it needs nothing beyond what's available in OpenGL 1.1. Moving that up to the next level involved putting everything for MDLs into static VBOs - no dynamic data is sent from CPU to GPU, the vertex pointers are set to offsets into the VBO for each frame (or pair of frames that must be lerped between) and blendweight and shadelight are sent as shader params. A switch from FFP arrays to vertex attrib arrays was an aesthethic choice moreso than a necessity, and was heavily influenced by a loathing of glClientActiveTexture (glMultiTexCoordPointer would have been a better API design choice).

In all cases, GL_UNSIGNED_SHORT indexes were preferred to GL_UNSIGNED_INT as the latter is not actually supported in hardware by many older parts, causing your vertex pipeline to drop to software emulation.

I believe that MDL handling can be gotten to somewhere around 75% of the full increased performance (drawing 400 knights went from 50fps to 300fps) just by making the vertex arrays and glDrawElements switch.

Something similar to this can be done for brush surfaces, but the gains are slightly more marginal owing to the need to dynamically build (and rebuild) a lot of data due to PVS and frustum switching.

This is getting long so I'll save the lighting changes for part 2. 

OK, this one no longer has a direct descendant in the current codebase, so I'm largely working from memory here.

I'd been aware for at least 10 years that dynamic light updates were a huge bottleneck in the Quake engine, and maybe 2 years ago I sat down and did a lot of work, testing and experimenting around what could be done about that.

Two main things came out of that.

First was a change of the glTexSubImage2D params from GL_RGB/GL_UNSIGNED_BYTE to GL_BGRA/GL_UNSIGNED_INT_8_8_8_8_REV. I have a test program (which I should probably put on the RMQ SVN) that tests various combinations of params for dynamic texture updates, and these two invariably came out fastest. The improvement on Intel was by a very wide margin - time to update 16 256x256 textures went from ~40ms to ~3ms. NVIDIA was 6x faster (18ms to 3ms), and - oddly enough - it seemed to make little or no difference to ATI/AMD, which locked at about 16/17/18ms irrespective of params. I haven't restested this on more modern AMD parts yet, but I have done some informal benching of D3D9 LockRect/UnlockRect performance which indicates that things are largely unchanged.

This fixed update times in glTexSubImage2D itself, but the pipeline was still stalling as GPU resources which were currently in use needed to be updated from the CPU, so a second change made was to bulk update all lightmaps that were changed during a frame at the start of the next frame. No glTexSubImage2D calls were used on-demand, but all light updates were deferred until after everything had been drawn, and this applied equally to the world and to brush models.

A tradeoff here was that light updates were out of step by 1 frame, but in practice it was not even noticeable.

The requirement here was for OpenGL 1.2 or the packed pixels and BGRA extensions.

Further experiments were around using GL_RGB10A2 formats to get more bits of precision and more dynamic range, as well as using the alpha channel of a GL_BGRA texture to store some HDR info, but they didn't go very far with RMQ because another problem had arose in the meantime.

However, these on their own will resolve 99% of the "dynamic light updates are slow and sometimes the engine runs faster if you switch off multitexture" problems that exist with current maps (and that I believe are a large part of the reason why community maps don't make much use of animating lightstyles).

The other problem that arose was in relation to a large (and as yet unreleased) map which made very heavy use of animating lightstyles - almost every surface had some kind of light animation on it. Some simple r_speeds tests revealed that most of the time we were getting 2-4 ms in the renderer, but 10 times per second that shot to 12-20 ms, and the criminal was light updates. Gameplay was very jerky and uneven; not enjoyable at all.

The eventual solution involved blending multiple textures (up to 3) on the GPU and completely ditching glTexSubImage2D light updates. Dynamic lights were done using additive vertex lighting (which was lower quality but we felt it to be acceptable as these lights are so short-lived; you can still see the lower quality in certin cases and if you switch r_lightmap 1 on though).

This moved frametimes from 2-4 ms to 3-5 ms in general cases, but it also meant that the engine was totally immune to the imapact of lightmap updates. Even though overall perf was lower, it was smooth and consistent and with no hitching or frametime spikes.

It also enabled the standard lightmap texture size to go to 512x512 which increased my ability to batch up brush surfaces - double win.

I've since written a more evolved version of this code (using D3D11/SM4) that handles dynamic lighting per-pixel, but it needs more shader instructions, dynamic branching, bitwise operators in shaders, increased constants register space and other higher hardware requirements that are not suitable for use with RMQ. It might be fun to make an "ultra" version of RMQ using a GLSL port of it sometime though, but other priorites must take precedence. 

I thought the "low" monster density in parts was good. It makes more sense, more atmospheric, in such a level. It would have been less so (plus probably frustrating) if every bit of space was jam-packed with enemies.

Some calmer moments improve or reinforce the setting. For example, I remember one situation, I think in the E2M1 part or shortly before, where I dropped down into some sort of basement area with no monsters or items but columns and beams. The area isn't particularly interesting, but it feels like it adds to the sense of place. Perhaps add a few low blueish lights (16x16) there. 

e2m1rq skill 3 when I shoot those 3 expl crates shortly after the start

same thing 2 times in a row 

 

The kids love them, the flashy stuff, the older ,audience dislikes them for the and disparities and nostalgic incongruence.

No. The average age in the RMQ team is surprisingly high, none of the people designing the game are noobs, and there are veterans of the community in the team as well, plus some of us have made landmark Quake maps or mods. This argument holds zero water, I'm sorry.

But I think we all agree on what the Lovecraft synonym stands for in this game,

Hah, an appeal to the audience. First time I hear it described as just a synonym, though. This, as well as the 3kHz audio frequency thing, is splitting hairs and grasping at straws. If Lovecraft isn't what you actually mean, then say what you mean instead. ;-)

otherworldliness, acrane magic, and strange eyeless monsters.

This could as well be a wishy-washy description of AD&D. None of it refutes my point that Quake is mainly a splatter-action game with quite some cheesy humour in it, even if some of the surroundings look like some sort of castle and there's an "evil altar" every once in a while. Much less does it refute the point that it's OK for the enforcer to say "suck it down" after the player died. It makes perfect sense.

As for the "Lovecraftian" in Quake, to be quite honest, there isn't much apart from a few names.

So we agree that there isn't actually that much Lovecraft in Quake, yes? Awesome, then we can let that rest. 

I think I got 4 random armors and sng this time http://www.quaketastic.com/upload/files/demos/m1-nm.7z 

You completely misinterpreted my post. It wasn't meant as criticism. 

Awesome. In that case, sorry for misinterpreting it. 

oh come on, I just wanted to make a snarky comment about mental age and stuff. 

 

It's not grasping out of ass, its science http://en.wikipedia.org/wiki/Sound_of_fingernails_scraping_chalkboard see: "The physical hypothesis".

There is no humor in a game acting like a brat from halo mp xboxlive and insulting the player if you didn't get the other post. Couldn't care less about Lovecraft in a q2-like base levels, but gamedev being an ass and insulting the player is never good. 

Thanks for that. It was great you play a lot like me. I should do a demo showing all of the secrets :) I think you missed 1 monster, the other two are because of the '1' monster I spoke of before being 2 on skills 2 and 3 :|

Well played! 

Part of ID's original design concept for Quake was to have the Ogre pissing on the player after killing him. I'd suggest that in the intervening years maybe some have evolved their own strange idea of "what Quake is" that's not necessarily correct. 

gb you make a good point about the fact that silly kill mesages were already in the game, so I have tried to think why that doesn't bother me... I think it is something about the breaking of illusion between the world of the game and the game itself, which does sound very fuzzy, but here is what I mean:

The messages that pop up to tell the player he 'got eviscerated by a fiend' is a message from the game itself along with 'you got some shells', the games master of our D&D campaign is giving us information, sometimes comically. But the Enforcer calling the player a 'noob' is a character within the game suddenly leaping out into the world of internet multiplayer and throwing a cliche at me. An enforcer is part of the world of the game, it is not a gamer in a multiplayer match, who I will spam :}}}}} at

I feel that this is probably why it rubs me personally, and it may totally be something no-one else has a problem with.

And yes, Romero did put his head in Doom 2, and his voice, but they weren't overt. It's a weird easter egg that is disguised in the normal game to not be noticed, like the Rot Fish. Daikatana takes Romero's cheesiness to the extreme and really does feel stupid when your high-pitched crap-japanese-accented sidekick says 'suck it down'. Again, it's a difference between the world the game gives us and the game itself.

I'm really not trying to be pointlessly negative or snarky, and your replies do force me to rationalise my thoughts on it. But they are genuine. 

Part of ID's original design concept for Quake was to have the Ogre pissing on the player after killing him.

Part of the original design was a third person action game where you were Thor. Sometimes stuff that is changed or missed out is a good thing. 

and I think he made a very good argument that the insult was dished out by the game rather than by the enemy. And even if the "original concept" for the ogre was to piss on the player - it's not in the game, so that doesn't count. I would really prefer it if the enemies don't talk (english, at least). They can eat my corpse or even piss on it, because that would fit with the idea I have of their characters. For me, Quake enemies don't talk to me. At least not in a way that I can understand. 

...in ID Quake talks in English. 

wow. 

but it's still almost unintelligible... and he doesn't taunt me, either. I think the only things he says is "stop" and "you there", is it? 

This is why I like working with smart people. 

Going completely off-topic, I reckon those voices are most likely Romero. He was heavily involved in the sound element of the game, and would be a prime candidate.