#1510 posted by ericw on 2015/05/02 10:03:00
gb made a bbox rotation demo map back in 2010 that has a bit more stuff to play with:
http://www.quaketastic.com/upload/files/misc/rmqrotate_patch3.zip
It works well in the engine baker attached in #1508, or here is a test build of QS with rotation:
http://quakespasm.ericwa.com/job/quakespasm-ericwa-sdl2/62/artifact/quakespasm/quakespasm-r4daaebe3ea8cf5a23dc5c3530a9abc3f59cbe564.zip
(sorry about the url..)
#1511 posted by Baker on 2015/05/02 10:53:43
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 rotate.zip 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
#1512 posted by szo on 2015/06/15 09:19:29
Thank You Again
#1514 posted by Tamarisk on 2015/06/17 15:13:55
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.
A Rendering Glitch?
#1515 posted by path0gen on 2015/06/24 19:16:50
hi all!
thanks for the new version of the engine!
found this visual glitch with the teleporter and the secret door on the start map of 'contract revoked' pack:
http://imgur.com/VdnkXE3
i was using 0.90.1 windows version, seems to happen on both x32 and x64 executables. doesn't happen with quakespasm 0.90.0. graphics card is nvidia gtx 550 ti with recent drivers.
Argh
#1516 posted by ericw on 2015/06/24 20:10:03
thanks for the report. Was trying to be clever and sort the bmodels by texture to gain a bit of performance, but it breaks that scene.
I guess the entities were ordered in the bsp file so that the teleporter entitiy would draw after the bookshelf.
Weird Fog Issue
#1517 posted by Breezeep_ on 2015/07/31 02:57:15
I've noticed some rendering issues with certain models and fog in the map:
http://i.imgur.com/BGel82p.png
#1518 posted by Spirit on 2015/08/08 13:01:51
Feature Request: Write stdout so that it is line-buffered or unbuffered or something. This would allow grepping the output and have the Quake Injector's engine output log update while playing.
Darkplaces does this well, no idea about other engines.
Animated Texture Question
#1519 posted by ptoing on 2015/08/16 03:16:59
In Jackhammer textures animate depending on which is their assigned frame. So you can do an animation that looks cascading inside of the JH viewport (for example with having a bunch of brushes with slip textures with increasing framenumbers.)
This looks pretty cool, but it seems this is not the way the engine handles things, since they all seem to start at +0. This is kinda lame (esp seeing as in Doom having them at different frame offsets is possible. Step back :|)
Would there be a way to implement this easily somehow? r_animtexoffset maybe?
Hack:
#1520 posted by ijed on 2015/08/17 14:34:09
Duplicate the textures and offset them by hand.
#1521 posted by ptoing on 2015/08/17 14:46:21
Well yeah, that is the obvious hack. Have the same textures a whole bunch of time with different offsets. Would be nice if it was possible in a non-stupid way :/
Stupid Is As Stupid Does
#1522 posted by ijed on 2015/08/17 15:25:25
Why not just offset the UVs on the brush?
#1523 posted by ptoing on 2015/08/17 15:27:44
How would that help with which animation frame is played?
It Wouldn't
#1524 posted by ijed on 2015/08/17 16:13:04
But it could help hide the fact they're all marching in unison, depending on how tall each brush is.
If you have large flat wall, it's always going to be visible. however, if you break the wall up into steps or multiple slopes and have the liquid flow over each one, this will also help hide the repetition.
Especially if you scale the textures as they 'flow' over the different angles to give them different flow speed. You will get some misalignment between brushes doing that.
If you do want them to move at different speeds (even though physics don't do that) you can just scale the textures on each of your flat brushes. A minor range of variation, say between 0.9-1.1 in Y.
#1525 posted by ptoing on 2015/08/17 16:36:43
I think you misunderstood me slightly. As in what I wanted to do.
Imagine a slipgate with that animated red grate texture, +0slip and following.
Imagine now you want to have 4 of these grates next to each other, but starting at different frames, +0slip, +1slip and so on. That would give a nice effect of the pulse going through the machine, not all as once, but flowing through it.
But the animation does always start on +0 no matter which frame you actually put on a brush.
So you would actually have to duplicate the brush and change the frames so that +1slip in the new animation becomes something like +0slip2. pita.
#1526 posted by mfx on 2015/08/18 03:29:03
#1527 posted by necros on 2015/08/18 04:02:01
clever!
#1528 posted by mh on 2015/08/18 11:09:00
I don't really see any reason why this wouldn't be possible in-engine, but I'm trying to think of how it could possibly break compatibility with other content. A cvar isn't the answer because that other content might be in the same map.
#1529 posted by ptoing on 2015/08/18 14:10:23
The simplest solution would be a variable which starts animations at the frames which is actually set on any given brushface. Of course this depends on how stuff is handled by the compiler? Does the compiler by any chance set all animation textures to +0?
But if that was possible something like r_textureanimframeoffset 1 or something would work well enough.
I think the way to do this right now is changing the texture names to suit your needs. There's no way of staggering the start points of the animation cycle.
#1531 posted by ptoing on 2015/08/18 15:45:20
Yeah, simple but kinda dumb way of doing it is duplicating the texture a bunch of times with different offsets. I really wonder why they did it like this in Quake when it works fine in Doom :/
#1532 posted by metlslime on 2015/08/18 18:18:13
have you tried it in software quake? It might actually work there and just be broken in all GL-based ports.
#1533 posted by ptoing on 2015/08/18 18:19:49
hmmmmmmmmmmmmmmmmmmmmmmmm. Trying now. will report back in a bit.
Nope
#1534 posted by ptoing on 2015/08/18 18:26:02
Tried in Winquake and original DOS Quake.exe 1.08. Same behaviour.
|