News | Forum | People | FAQ | Links | Search | Register | Log in
RemakeQuake Winter Demo 2011
Here's the d/l link: download
The RemakeQuake blog with screenshots: blog
And our public forum for feedback: forum

The pack consists of four large levels by myself and Ricky along with a load of new Qc, sound and engine features. Shortly we'll be releasing the tools version as well, which features the BSP2 tools. A small detail was omitted from the readme, that being the correct command line of:

-game rmqwinter11 -sndspeed 44100

Let us know what you think, this has been a long time in the making, but we're pretty pleased with the results.
First | Previous | Next | Last
Darkness 
Is this only in my maps or in Ricky's as well? 
All Of Them, As Far As I Can Tell... 
...with obvious variation in places.

The Gunsmith secret area pops to mind... You can barely see the path to get to the goodies. 
I Remember Your Maps 
being darker, or at least having more pitch black corners. I'll replay and check. 
Doom 3 
The hardware requirements are similar in terms of the GL extensions I use.

The formats and underlying technology are completely different. Doom 3 stresses your hardware in much different ways than this stuff does, and depending on how your hardware responds to this stress you may have a very different experience on both.

DarkPlaces is not an option because a custom BSP format was needed during the course of last year. Q1 BSP imposes various 64k limits which were overflown - vertexes were an early one, which got worked around, clipnodes became a serious problem, and leafs is a fairly recent one.

Using a different BSP format was not an option for various reasons. Formats considered either did absolutely nothing to resolve the problem (Q2, HL), were missing important features (Q3A), were encumbered by licensing restrictions (HL) or required too much upsetting of codebases and changing of the toolchain (all of them). The eventual choice to extend Q1 BSP by using ints instead of shorts in key strategic places meant that mappers could continue using their preferred editors and that minimal changes were needed to both tools and engine code (and - importantly - the very same backend code could be used in the engine for both the new format and the original - there were some small changes in the loader but that was all).

If DarkPlaces implements support for this format then DarkPlaces will become a serious contender.

None of that makes Q1 BSP suitable for hardware rendering. It was designed around the requirements of a software renderer running on a p60 with 8mb of RAM, so it chops surfaces up far too much (and far too small) leading to poor batching and lots of tiny submissions of geometry to the GPU - all things which make hardware rendering suffer. This wasn't resolved in any ID engine until Q3A, which would be easily capable of running this content with much higher performance. 
Right 
I'd expect my maps to be darker since I work in bright places..

I think in future I'll light for minimum brightness settings on my machines, it's the only way to make it work properly for everyone.

Point of fact I played the brilliant Moonlight Assault the other day and couldn't believe how bright it was - thats not the level thats broken, but my set up.

BTW Text_fish, yes, what you're describing there is an idea for a trigger_status which would cause status changing effects and have methods for not affecting the player, like being in an envirosuit, partially or fully submerged (fire) and so on. In theory it could instead become an extension of the trigger_hurt's functionality, which would be neater.

What you see in e3m3rq is basically a maphack. 
Ok 
So then the logical step must be to reduce the map's complexity, use fewer textures, or optimize it in other ways to make it playable on a smooth framerate. As painful as it may be. 
Indeed, Replacement Textures Are The Culprit 
Just checked the texture folder. E2M1RQ has 183 files with a total of 100MB. E3M1RQ has 100 (!) files totalling to 220MB, lots of them being 3MB. Obviously, some optimization in this area is required. 
3 MB 
Sounds like a lot of 1024x1024 RGB textures.

Even pulling them down to 512x512 would help a lot to relieve the hurt. We probably need to talk more about this internally as there are tradeoffs to be made here (one of the options we've been looking at recently is using DXT compression, which would reduce that 220mb to 27.5 mb and also enable much faster texture sampling in the fragment shaders - there are patent issues surrounding that however, which would affect the ability to provide a reasonable fallback for those using free Linux drivers that can't support the required extension).

Lighting

I don't think that there's a perfect solution that will run well for everyone. Everybody's hardware is different, different monitors will have different gamma curves, etc.

The next release of the engine is going to have an r_lightscale cvar that you can use to bring up lighting levels (but without any clamping or washout) which may be all that is needed. 
Lighting 
Sure, but right now I'm lighting from a middle position, if instead I go from one extreme (full black / full bright) and work towards the opposite then it should result in a more balanced range overall.

Starting from black will leave the levels with max brightness being almost whiteout - at least that's the plan.

Maybe not explaining that very well: right now the brightness range is to small between black and white.

Textures; yeah, 1024 isn't actually visible on most monitors just down to pixel real-estate. Granted it might look good if you headbutt a wall - but thats not something you're going to be doing much, compared to say, fighting.

Map size is something we probably won't be decreasing, there's levels in the works that are a little bit bigger than those in this release. I suspect on textures alone we can save a massive amount of overhead. 
Map Size Is A Feature Of RMQ 
We're saying 'Make gigantic maps!' or 'make maps with a huge amount of detail'. The toolkit that we use is really amazing. Just the engine and tools alone open huge possibilities. 
I For One Get 790 Fps On E2m1rq 
 
Fucking Brutal 
Mh Hint Hint 
200 mb of textures for a map roughly sounds like the q1 mega texture space requirements. I'd definitely like that. 
Q1 Megatexture 
It's an interesting idea but not something I'd be keen to do in a production engine. Not with OpenGL anyway.

OpenGL is basically shit for updating dynamic resources. glTexSubImage is OK provided you invoke the correct eldritch incantations, but anything built on the GL_ARB_vertex_buffer_object and GL_ARB_pixel_buffer_object extensions is pure and total rubbish. Vague usage flags, mysterious crap happens behind the scenes, the driver does what it wants to anyway irrespective of what you do or don't specify, you get arbitrary fallbacks to software emulation and in the end it would have been faster if you'd just used system memory instead. (They're OK for purely static data though.)

Essential reading: http://www.stevestreeting.com/2007/03/16/glmapbuffer-how-i-mock-thee/ (one of the Unity people also has a "GL_ARB_vertedx_buffer_object is stupid" post but I can't access it from this PC at the moment - try Google). 
Vertedx -> Vertex Stupid Keyboard 
 
Perfect Solution That Will Run Well For Everyone 
is to actually lit the places where it matters - ie where player will have to go or will have to look at, instead of relying on a dim ambient that only works with high gamma settings.
Doesn't help that some of your textures are very dark, like peaking at 40 and cutting off at 70 (out 0-255 obviously) and you can only go down from those values since no overbrights.

Btw my monitor gamma is brighter than SRGB (I can distinguish the lowest grades, even 1-2-3 depending on the view angle http://www.lagom.nl/lcd-test/black.php) and I found some places too dark as well. 
Problem Is 
That this is just not gonna work. I run my own monitor fairly dark (and I smoke so it tends to pick up a lot of gunge over time) but I could still see everything OK.

Which means that one's own individual experience means absolute squat in terms of how the maps are lit.

And: "no overbrights"? I don't think so. In fact the engine enforces overbrighting always on. 
Dark Maps? 
I blame TFT screens! 
Turn Monitor Brightness Up XD 
I had Quake brightness slider half way up and it was WAAAYYY too bright on e2m1rq. Put it back to the default (lowest) setting and the map seemed OK to me.

The person who said the map was too dark:-

1 - what is your GPU? (U never know)

2 - what is the brightness/contrast setting on your monitor?

3 - what was your brightness setting in the engine? 
The Silent 
It was you! Sorry mate, I forgot who had made the post. 
No Prob, Rick... 
here goes:

1 - AMD Radeon HD 6970M - 1024 MB.

2 - Optimal, I'd say, even though the iMac screen is a bit too reflective for my taste...so I tend to keep it a lil' bit higher than I'd do on a normal monitor...

3 -Top. 
Does The Darkness Apply To E2m1rq? 
Nice rig btw :)

Is it a Mac though? I mean OS, engine etc... 
 
You don't understand, you need to properly light the map with contrast lights so it looks fine regardless of the gamma in the areas that are important for the progress (not secrets obviously) and use functional lighting to lead the player. (Unless you want to pull Doom3\Amnesia)

There are no overbrights on external textures, they always look darker http://i.imgur.com/722XZ.jpg 
That's Actually 
an interesting point. Er... MH? 
Lightmill 
What engine is that? 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.