News | Forum | People | FAQ | Links | Search | Register | Log in
Quakespasm Engine
This engine needs its own thread.

Feedback: I like the OS X version, but I have to start it from the terminal for it to work and can't just double-click it like a traditional OS X app. I'm sure you guys already know this, either way great engine.
First | Previous | Next | Last
Bbox Rotation 
What are people's thoughts on rotating bmodel bounding boxes when the "angles" field is set, as described in Baker's tutorial here:

This lets you do "real" rotating doors without setting up func_movewalls.
I had a request to add this feature to QS. As far as I know the only quake singleplayer map to need it is e3m3rq.bsp, from the rmqwinter11 demo.

Here are some pros/cons I thought of:

- strictly speaking, this is a breaking change. for example, in those maps that have a func_train with 'angles' set, (recall the offset elevators in add.bsp or apsp1.bsp), with fitz 0.85, only the visual part of the model is rotated, the bounding box is left in the original place the mapper put it. If you add bbox rotation to the engine, the bounding box is lined up with the visible part of the model. Both maps still seem playable with bbox rotation, but it's possible other content is broken.

- better for mappers than hipnotic rotation, no need for func_movewall
- possible to make rotating fans, etc, with no qc
- already implemented in many engines: mark V (only if you use sv_protocol 668), fte, darkplaces, quakeforge, qbism.
- IMO the chance of breaking existing content is small; because you could consider the fact that bboxes don't rotate in vanilla quake a bug, and it's unlikely that somone would deliberately have the physics bbox in one place and the visual part of a model rotated away from that.

Question for Baker, was there any compatibility reaason you left this disabled in protocol 666 in MarkV? 
Remember the apsp1 issue with an entity being rotated a little? With a rotation of -1 or something? It had something to do with that, but I can't remember off hand --- it might have been of the "an entity has a strange rotation, do we honor it or ignore?" So I chose to disable rotation until the feature gains some usage. But I haven't thought about this in a while, so my memory could be wrong but I wanted to err on the side of compatibility.

The reason for protocol 668 was for smooth rotation. Something like FitzQuake interpolations positions nice and smooth, but not angles.

But yes, I'd love to see rotation go into mainstream usage. 
Rotation -1 
This was an angle key of -1 on the entity signifying something meaningful to mappers; probably the direction in which a moving brush model should move, I can't recall exactly what, but it was valid usage in Quake.

This wasn't a problem in the original Quake because angle-to-byte quantization with truncation meant that the value was transmitted as 0.

In FitzQuake it became an issue because it used a Q_rint call for better rounding, and so the -1 value suddenly became visible on the client.

It was only ever an issue on the client; -1 was insignificant enough that on the server things were just off by a little.

It seems that it should be possible to detect these entities at load time and flag them for special handling in the edict_t struct.

Another, possibly bigger, thing to watch out for with rotated bboxes is that some of the maps have an angles key set; e3m3 is one example from ID1. Things go quite insane if you don't exclude the world from bbox rotation. 
I believe the cause of the -1 angles in those maps is a door that was converted to a plat or train, without deleting the angle key. For doors the -1 is meaningful and i think the quakec even zeroes it out after doing its special thing. For plats and trains the angle isn't used, which means the unnecessary key is left alone to cause this bug.

Otherwise you'd see weird angled stuff in every level in fitzquake because almost ever level has a vertical-moving door (angle -1 or -2) 
It'd Be Nice 
To have true rotation instead of the hacky method.

Maybe enable it as a default on variable so if some map or mod does rely on weird qc usage it can be turned off. 
The Problem With Cvar Controlled Stuff... that you're pushing the solution on to the player. 99% of the time the player won't take up the solution and then it's going to be your fault anyway. Deervedly so, because you didn't fix it proper nor proive a sensible default to begin with. 
But you choose the default that works with most old cases, and place the onus on new modders to choose the one that they want in their rc or whatever. 
Here is a zip

Do -game rotate, map rotate or map rotate2

There is an old Mark V in there "fitzquake_mark_4.exe" which has rotation working and under both 666 and 668.

Rotate2.bsp only works right under DarkPlaces, I'm not sure why and I swear that ages ago I had that working in engine tests. I don't think even the RMQ engine does that map right. Try DarkPlaces and you will be standing on rotating platform to see the correct behavior.

Try Rotate.bsp with the provided fitz under 666 and 668. Pay particular attention to shooting the "drawbridge" and standing on it when it raises and lowers with 666 and 668 and try DarkPlaces too doing the same. 
The Problem With Cvar Controlled Stuff... that you're pushing the solution on to the player. 99% of the time the player won't take up the solution and then it's going to be your fault anyway. Deervedly so, because you didn't fix it proper nor proive a sensible default to begin with

Haha :) Fix it proper for 1000 Q1 maps/mods ?
Sensible defaults vary according who to joe dick and harry are. Roughly - QS tries to provide sensible defaults and interface for the Average Joe, and *document* cvars, workarounds, etc, for more technical users/features. 
gb made a bbox rotation demo map back in 2010 that has a bit more stuff to play with:

It works well in the engine baker attached in #1508, or here is a test build of QS with rotation:

(sorry about the url..) 
Works great!

And in Quakespasm if I noclip onto the top of the rotate continuous it works fine with the rmq_rotate/rotatetest.bsp (and it works in the old Mark V I provided, so I'm not losing my mind that standing on top of a rotator works fine in a correctly compiled decent .bsp)

[Perhaps my rotate2.bsp in is "wrong" or the map compiler used (unknown what it was) did a poor job.

I've not thought much about rotation in quite some time ...] 
Quakespasm 0.90.1 Released 
Thanks Oz and Eric 
Thank You Again 
Thank you guys for all your hard work on this. It really is appreciated by those of us who enjoy playing Quake. The new games have _nothing_ on the classics. 
First | Previous | Next | Last
Post A Reply:
Website copyright © 2002-2018 John Fitzgibbons. All posts are copyright their respective authors.