I couldn't watch all of e3m1rq - there was a disconnect cable error about halfway through and it locked up.

Nice e3m2rq demo - you figured out how the blaster worked and even seemed to be having fun, in a pants wetting terror sort of way :)

A hint about the secrets - in e3m2rq at least they're usually where they were before, although with a slightly different access method. 

I didnt mean features like random spawning or roaming but meant core mechanics (that I've read about) like Shamblers teleporting or ogres with different attacks etc.

I'm not sure how you would introduce the vhanges personally but is the plan that players will just work it out? 

If an Oger fires a rocket at you then its pretty obvious what is going on - same for one with double chainsaws or whatever.

Shamblers only dimension door when at a higher skill level and specifically flagged to do so by the mapper. And they're Shamblers - one of the high-tier enemies and as such players who see this happen are already going to have a good enough understanding of the world in order to understand what's going on.

Basically, yes, the idea is for the player to figure it out on their own.

As you'll remember the original monster descriptions were very rudimentary:

http://quakeone.com/q1files/documents/q1manual.pdf

Probably an added explanation there of the the Shamblers being able to telport in special circumstances on high skills would be a single sentence. 

http://www.quaketastic.com/upload/files/demos/e3m3rq_ankh.7z

e3m3rq demo. It stops somewhere in the middle of the map after I died from squishing (twice).
The map is very quake'y. Too long though.
What is it with the 4th button that can't be pressed?
The fog-poison area wasn't a nice experience/ 

Just yet - technical issues.

I've rethought this map quite a bit, the next version will be shorter and more objective driven.

4th button - I assume you mean one that has a 'rusted' message. The idea is to weigh it down to depress it. 

Is a bug... I'm assuming the shutters that raise there in the middle gibbed you - maybe they're off-axis or something.

The second one is intentional, just unfortunate the NPC placement - he's supposed to show you the danger by getting squished. 

... But I can't seem to quickload (or even load). Engine says "Hunk_Alloc: failed on 4194336 bytes". What's up with this? Any workarounds? I restarted the freakin' thing like 15 times...

Yesterday e2m1rq worked just fine... 

That's most likely one of the 1024x1024 textures. If you can get to the point where you can at least see the console and menus I know that it's not the post-processing textures (which would only be loaded at this size if you were running a video mode of something like 1024x768).

That leaves the replacement textures supplied with the pack. You could try either deleting or renaming your "textures" directory and see if it will load then; that would confirm that it's one of those.

RMQ allocates a 128mb heap by default, so options for you if that succeeds would include specifying a larger -heapsize (try 256mb).

Also, if you're using any other replacement content (e.g. in ID1) kill that to see if it fixes it.

Finally, if you're running Quoth with RMQ (unlikely but I have to check) then don't. Quoth isn't compatible with everything out there, and has been observed to break other mods (ARWOP is one I can remember from recent-ish).

And don't rule out something else on your PC as a possible trouble-maker. If nothing in RMQ content or it's engine has changed, and if it worked yesterday, then it's always possible. 

Let's see... A bit more info:

my command line is as follows, "C:\QUAKE\RMQEngine-Win32.exe -heapsize 56000 -game rmqwinter11 -sndspeed 44100 +map e3m1rq", I'm playing on a 3,1 Ghz Intel Core Imac with 8 gb ram on Parallels (I just played Serious Sam 3BFE on medium/high settings pretty well, and Wolfenstein 2009 works like a charm). I'm emulating a win2k machine that was my former pc and managed without a hitch the previous RMQ demos.

If I start the level from scratch, the loading goes just fine, trouble starts when I F6 and then F9.
There, it crashes.

I played up to the button that opens the first two doors, after having found the gunsmith secret...

I'm going to bed now, tomorrow I'll try something you suggested... Thx a bunch! 

Why don't you try the Mac Port of RMQEngine I posted above? I would be interested in your feedback. I am running it on a very similar system and it works like a charm. 

A very small heapsize - try 256000 or 512000.

I suspect this is the sounds in that map bombing things again. 

Is nowhere near adequate. e3m1rq actually needs only 16mb heap to run, but it will need a LOT more during loading as temp storage is heavily used.

A 1024x1024 skybox, for example, will need about 45mb of temp storage to just load. It's all discarded immediately after (as soon as the textures are created) but the texture data has to come from system memory in the first place (that 45mb includes files as they are opened and read, then converted to BGRA (cos it loads faster than RGBA)).

All maps will load and play fine using the default heapsize in the engine, so either drop it from your command-line or use a higher value (with 8gb of RAM you really have no need to be using just 56mb). 

Try the Mac port! :) 

...What happened is that my heapsize was inherited from who know when via multiple copy+paste. I was not aware it was set SO low. Sorry to have even asked. I should have thought this by myself. Maybe too tired to think, tonight I'm gonna set things right.

And ehi, sure Sleepwalker, glad to give you feedback on this!!! Thanks for taking the time to make the port, in the first place!!! 

there is also an OS X port of QuakeSpasm 

"then converted to BGRA (cos it loads faster than RGBA)"

Seriously? Are we talking something measurable or milliseconds here? 

I really must put that test program up on the RMQ SVN....

I've done a lot of measuring and benchmarking of formats and layouts here. Bottom line is that on all hardware (except ATI/AMD for some odd reason, where it's the same no matter) BGRA is between 6 and 30 times faster than RGBA.

For load times this may or may not be important.

If you're loading native 64x64 8-bit Quake textures, then it's likely you won't even notice.

If you're loading 512x512 TGAs it may be the difference between the player waiting 1 minute vs waiting 5 minutes for the map to load.

If you're updating lightmap textures at runtime, it may be the difference between running at 10fps and running at 250fps. That's where milliseconds are actually measurably important - 4 milliseconds will get you 250fps. 20 milliseconds will get you 50fps. If you're also running a server, running QC, drawing stuff, updating anuimations, playing sound, etc, then every single millisecond is precious. Every millisecond you save in this kind of this is a millisecond extra headroom for something else. 

OK, the test program is now on the RMQ public SVN: svn://svn.icculus.org/remakequake/engine/Experimental/TexSubImageTest

The code is mostly portable, but at present relies on some Windows-only libs for timing - you could replace this with the SDL timer stuff if you wanted (portability is not a huge concern for test programs). 

Well, some proper feedback on the sounds then (not giving a flying fuck about the bitrate because it is very irrelevant):


Nailgun and Super Nailgun sound like silenced weapons.
Sound player makes when coming out of the water sounds weak and squeamish.
Lightning gun sounds weak and silent.

All weapon sounds seem to have no bass and sound hissy. 

"BGRA is between 6 and 30 times faster than RGBA"

That makes zero sense to me but if you've measured it then I'll defer to that. 

All weapon sounds seem to have no bass and sound hissy.

This. What makes this extra strange is that the sound of soft gibs hitting the floor is the most bassy sound in the game!

All in all I have to say this is a huge improvement over the last demo. There are some great bits of atmosphere, especially thanks to some of the ambient music. As far as sounds go that's as possitive as I can be as the Enforcers (and now the ogres too) still sound as if someone's pulling a string on their back and if you get a whole load of grunts running around overhead it sounds like there are a bunch of coked up tap dancers roaming the slipgates.

For the most part the build quality of the maps is top notch, though I feel some of the "new areas" are often pretty unnecessary and just end up diluting the original level. The bit on the floating ship in Ep 3 has the most infuriating ladders I've come across in any game ever -- please put a clip brush in so it's not possible to just walk through them? A couple of times I got nearly to the top and then just shot straight through it and suffered falling damage. The third time I got to the top and an ogre raped my face. What's the fish about?

The laser rifle is way overpowered -- Fiends and Shamblers just arent scary when you can tear them apart in a matter of seconds. 

If you aren't planning on updating the animation of the Super shotgun (or are but haven't by your next release ;) ) you should add a simple 'click' noise at the end of the SSG reload imo, as the weapon sits inert but is unable to fire, so a little cue that it's ready would be helpful for learning it's firing timing since you've changed it. 

The OpenGL "common mistakes" page is quite awesome for this kind of thing; this link is relevant: http://www.opengl.org/wiki/Common_Mistakes#Texture_upload_and_pixel_reads.

Summary.

Most GPUs will internally store all textures in BGRA layout, irrespective of what you specify when creating the texture.

What should be obvious from this is (and this applies to the format param of glTexImage and glTexSubImage calls):

Using GL_RGB for starters is just plain nuts. You're not saving video RAM and when loading the texture your driver must expand it to 4 components and swap R and B.

Using G_BGR avoids the swap but means it must still be expanded.

Using GL_RGBA avoids the expansion but means it must still be swapped.

Using GL_BGRA avoids both the swap and expansion - transferring the data from system memory to GPU memory is just the equivalent of a straight memcpy which can be optimized (the most simple optimization being transferring 32 bits of source data at a time instead of 8 bits). No CPU work required before transferring, data is already in the format the GPU will use internally, result is a much faster transfer.

Of course, once the transfer has completed and the texture is in GPU memory none of this has any impact on performance. But if further transfers must happen during runtime (like e.g. Quake dynamic lightmap updating), then it most certainly does. 

The laser rifle is way overpowered -- Fiends and Shamblers just arent scary when you can tear them apart in a matter of seconds.

I think it should be toned down quite a bit as well because of this.