it seems like there's a bug in these gl engines... if the video resolution you choose is not 4:3 ratio, it still sets the vertical fov as if it was ... the result is that everyone looks short and fat when i play at 1680x1050.

I don't have glquake installed at the moment, but it seems like this was not a bug in the original glquake. But I could be wrong... 

ye than first level for me is a litle borring becouse gameplay is very slowed becouse of to much shambers in my opinion... but after that... are level for us not forget good quality and a size of maps real huge 

There's no explicit support for it in my engines, AFAIK there never was any such support. In GLQuake 0.97, it looks the same and you can't even change fov at all ...

I'd suggest using std 4:3 resolution. 

3 instant classics now, nightmare tangent is also fantastic. 

bit of a mixed bag for me. the maps are pretty nice for the most part, but 500+ monsters are just far too many to be enjoyable - it became boring, sometimes even annoying after a while (it's ok for one map, not for an entire episode). and it was very, i mean VERY hard on skill 2 - i was constantly low on health and sometimes even ran out of ammo. each map took me about an hour, maybe more, and LOTS of quickloading. switched to skill 1 after three maps and it became much better.

warpa could have been more detailed, still ok.
warpb conveyed a certain atmosphere i can't put my finger on. low lightlevel, fog, gritty textures and vast repetitive environment, the industrial juggernaut i would never want to end up in. by repetitive i mean there weren't many clearly distinct areas, or rather areas that really stood out - at least i had the impression. some bits were pretty bland.
warpc was cool (knave trims are a bitch to align properly). so were warpd and warpe, which had a very cool theme (also an insane amount of secrets, but i hardly found any).
the shortcut teleporters in all of the maps were very handy.

the sleeping player gibbing looked buggy: one could see the telefrag zombie.
what's up with the items' bounding boxes? they are like in qw or something - it's harder to pick them up, requires the player to really touch their center/origin.

quoth: being killed by polyp gibs prints a "fell to this death" message. i still don't like the plasmagun sound - and why did it emit a red light when hitting a wall? 

I think it's because ijed rotates the boxes slightly to make it look more realistic, I've seen that before in other maps. It's a nice touch, but annoying.

The polyp gib obituary seems like a QC bug. The red light from PG is just how NehQuake displays that type of effect.

As for boring/hard/easy gameplay, check out the extra coop modes ... 

i can't tell for sure, but there might be more to it. at least i've never experienced such a behavior with rotated items before. 

I noticed the items that were rotated were much harder to pick up. I think the problem is that the bounding boxes are the same as normal, but that ammo models are rotated about one corner rather than the centre. Quake bounded boxes don't change at all with the entity's rotation, so the boxes end up quite a long way out of place. From one direction the items are hard to pick up, from the other you pick them up before you appear to touch them. Trying to work out what's going on is made harder by the fact than ammo has the FL_ITEM flag, which makes the bounding box larger for players.

This same bug occurs in quake as well, it's just that lots of the ammo in these maps is rotated, so it's more noticable. I could probably write a new setsize function that would set a corrected bounding box. It would take into account the rotation of the entity and shift the position of the box accordingly(assuming of course that the given size is correct for a rotation of 0 degrees). The bounding boxes would still be parallel to the x and y axes, that's the only possibility in quake. But the boxes could be scaled to be a square that would exactly contain the hypothetical rotated bbox. Would this be a good fix? 

Warpspasm is the longest map pack I have ever played. With each level taking about an hour to complete (disregarding the first and the last), along with around 550 monsters, and VERY hard on skill 2, this pack is a blast. Highly recommended. Play it now! 

...can someone remind me what the final, fixed, release download is, cheers. 

the one linked in the news post. 

SDA is not supporting Quoth based maps.

I thought recording just for fun, personnaly I like watching runs on large maps, it�s like a movie :) 

There's no explicit support for it in my engines, AFAIK there never was any such support. In GLQuake 0.97, it looks the same and you can't even change fov at all ...

I'd suggest using std 4:3 resolution.

Yeah, I've been doing that. Just wish I could play in fullscreen on my wide-aspect LCD.

It's hard to remember now, but I thought that the code to correctly calculate vertical FOV was already in the source when I started making fitzquake. On the other hand, I did do some work on that part of the code, so maybe it never really worked before I touched it.

And, I recall the fixed FOV in glquake being not a missing feature, but an existing feature locked out by an id software programmer (not carmack) who thought high FOV was cheating and decided to disable it when working on the glquake port. 

A quakec patch to calculate better boxes would be worthwhile for a pack like this where all the items are rotated.

For mappers in general working with unpatched quakec, I would suggest never rotating an item box more than about 10-15 degrees.

Note that all items in quake have their bboxes expanded in code (by 16 units i think) to make them easier to touch, including items on shelves. This compensates for any small rotation because you still can't get too close before picking it up. But if it's been rotated like 135 degrees, the 16 units won't be enough obviously. 

I'd like to see a basic progs fix, for stuff like the fish couting twice (you'll notice there aren't any in Warp)and ammo bbox box.

Then we, as a community, agree that it's the basic version that everyone should use. I gauruntee there's lots more I don't know about that could be cleaner and more efficient. I'm not sure why this doesn't already exist, to be honest, it's a logical progression when the community of ten year old game keeps playing it.

Most mods have implemented the fixes that sneaked through the playtesting phase, but there's no basic 'use this' id1 progs.

I'm not a coder. 

on my Dell 24' with run command line:
...\glwarp.exe\ -quoth -game warp -heapsize 48000 -width 1920 -bpp 32 

with FOV either! (autoexec.cfg) 

Command line above should read:
...\glwarp.exe -quoth -game warp -heapsize 48000 -width 1920 -bpp 32 

chase_active 1 fov 110

appended to that - I put in a bind to 1 for autoswitch to the sword chase_active as an experiment, but it couldn't work with impuse 10 / 12 and I play with mousewheel for weapon switch.

It works good - first person close combat is shit. 

I want to see some demos on these lovely maps!

So I went ahead and recorded this as a starter; an easy run through warpe in 49 seconds. There "may" be more shortcuts than the single one I found...

http://mandelmassa.net/quake/div/warpe_049.dz 

ok, just tested it again and you are right.
i never experienced this before because i was always using only small angles. everthing <90 seems to work fine.

forgot to mention btw: i liked the music ;) 

Map the first (the snowy one).

Skill 2, GLWarp.exe, Quoth on, 85/87, 4/5, two deaths (one at first Smabler ambush as I was saving MHs and at 20-ish health when Smables appeared, one at end cos I was running around doing....something).

Cool map! I like it. Like the style, unusual feel. Some inside bits were quite plain. But overall the vibe was good. I like the fog and lava ball effects at the end, proper dramatic. Good secrets too. I really like the gameplay - the combination of easy Grunts, nice snipery Rocket Grunts, and mental Shamble ambushes was....quite refreshing really. It worked well and was well balanced too.

Music was okay, fitted well. The monster movement does me head in a bit although it's kinda cool on the Smablers. 

Nice demo, I also want to see clever runs on these unusual maps. Check out Sielwolf's demo3; maybe it can offer some hints on warpe. 

So <90 works well? I'll remember that.

Shambler: glad you like the maps - its a bit fanboy but I was reading the TEAMshambler archive repeatedly when putting these together. Also, Harsh Angled Edge and Final Drop are bookend maps, with the start map and Murder Mandala being secondary bookends (?). The real expansion is warpb-d.

Neg!ke: Something you liked! Heh, it's ok - I've never been a fan of speedmaps tbh, although the chain speedmaps are amongst my favourites. Like I said in another post, some people prefer hamburger to steak.

Mandel: Not bad, but do check out Sielwolf's demo3. You missed plasma jumping as well - its semi-pointless unless you have the quad, but Sielwolf's rocketpush to the crunch secret solves that. Also, these maps did have alot of clip brushes to break speedrunning, but they're all gone now. I guess warpd can be completed in less than a minute thanks to the bars helping the player to the exit via rocketjump.

Nice to hear comments, thanks. 

Here's a chunk of code that corrects the bounding boxes. It's not as optimal as it could be, lots of ugly if statements, but since it's not called often it doesn't really matter.


void setsizerotated (entity targ, vector b_min, vector b_max)

{
local vector y_ang, rotmin, rotmax, pt;

//only consider rotation in y axis
y_ang_y = targ.angles_y;
//get the unit vectors in local axes
makevectors(y_ang);

//correct for opposite orientation
v_right = v_right * -1;

//set initial min/max points to transformed bottom right coord
rotmin = rotmax = v_forward * b_min_x + v_right * b_min_y;


//point 2
pt = v_forward * b_min_x + v_right * b_max_y;
//compare to current min/max componentwise
if(pt_x < rotmin_x)
rotmin_x = pt_x;
if(pt_y < rotmin_y)
rotmin_y = pt_y;

if(pt_x > rotmax_x)
rotmax_x = pt_x;
if(pt_y > rotmax_y)
rotmax_y = pt_y;

//point 3
pt = v_forward * b_max_x + v_right * b_max_y;
//compare to current min/max componentwise
if(pt_x < rotmin_x)
rotmin_x = pt_x;
if(pt_y < rotmin_y)
rotmin_y = pt_y;

if(pt_x > rotmax_x)
rotmax_x = pt_x;
if(pt_y > rotmax_y)
rotmax_y = pt_y;

//point 4
pt = v_forward * b_max_x + v_right * b_min_y;
//compare to current min/max componentwise
if(pt_x < rotmin_x)
rotmin_x = pt_x;
if(pt_y < rotmin_y)
rotmin_y = pt_y;

if(pt_x > rotmax_x)
rotmax_x = pt_x;
if(pt_y > rotmax_y)
rotmax_y = pt_y;

//z unchanged, assuming rotation in y only
rotmin_z = b_min_z;
rotmax_z = b_max_z;

setsize (targ, rotmin, rotmax);

};


To use it, simply replace the call to setsize in the item's spawn function to call setsizerotated instead, the function takes the same parameters. Note that this function should not be used everywhere! Monsters for instance already have a bounding box large enough to accommodate their rotation, so you'll end up with monsters facing odd angles having larger bounding boxes if you use this. Similarly for weapons, although it's less important, it's not worth making a change for the worse. Just change it on ammo/health packs.

On a unified progs with fixes: I've thought about this before, but I don't know that it would work. There's a line to be drawn between what's a bug-fix and what's a feature, and it's not easy to do. If I wanted a bug-fixed source I'd start with aguirRe's source, which has some obvious ones like the fish count, and also some more subtle crashes/problems. But whether this rotation code counts as a bugfix is debatable to me, certainly none of the original quake maps rotate the items, so allowing rotation of items is kinda like a new feature.

We should probably start a different thread for discussion of this, or at least take it to mapping help. Stop derailing this thread, Preach!