#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.
#1535 posted by metlslime on 2015/08/18 18:32:33
ah well. I think you should just duplicate the textures and be done with it.
#1536 posted by ptoing on 2015/08/18 18:48:24
Yeah, that's what I will do when I wanna do something like this, which I likely will at some point.
Weird Bug. Engine Or Map Related?
#1537 posted by ptoing on 2015/08/18 20:31:26
I just played a bit of A Desert Dusk in QS and at some point I got a weird bug. My axe was replaced with what looks like a scorpion stinger or something and all my other weapons could not be used until I found more ammo for them.
Link to demo, sadly not from start:
https://dl.dropboxusercontent.com/u/15588722/add_weirdness.zip
Little Idea, But Would Have To Be Coordinated With Other Engine Makers
#1538 posted by ptoing on 2015/08/19 12:26:36
func_water, func_lava and slime as well, so you can make something with a different texture have lava properties as well, without having to do hacky shit. But I reckon such a feature would lead to between-engine-headaches.
#1539 posted by mh on 2015/08/19 16:36:51
func_water, func_lava and slime as well, so you can make something with a different texture have lava properties as well, without having to do hacky shit. But I reckon such a feature would lead to between-engine-headaches.
This isn't determined by the engine, it's determined by the BSP compiler.
The only thing that the engine does is identify surfaces who's texture starts with "*" and draws them with the turbulent warp effect. But contents are already set during BSP compilation, so any changes would need to be made there.
#1540 posted by ptoing on 2015/08/19 17:57:30
Ah, that makes sense.
It Also Means...
#1541 posted by mh on 2015/08/20 00:14:05
...that if a BSP compiler was modified to support this, then all engines would automatically pick it up without any headache or grief.
Can't Suicide -- Allready Dead!
#1542 posted by Spirit on 2015/08/20 15:33:32
#1543 posted by necros on 2015/08/21 01:28:03
more important than moving lava imo
Seems To Have Been A Recurring Problem..
#1544 posted by ericw on 2015/08/21 06:54:12
Allrighty...
#1545 posted by ijed on 2015/08/21 16:22:17
Was Wondering...
#1546 posted by ptoing on 2015/08/23 01:20:18
The alpha variable is pretty cool, but alpha always has the sorting issue, as we all know.
It would be pretty cool if there were also vars for additive and subtractive blending. Of course they should be mutually exclusive, but I think some cool stuff could be done with those, and they do not suffer from any sorting problems, from what I know.
#1547 posted by - on 2015/08/23 04:29:48
If you want to go that far, tbh you should use something the supports Q3 maps, and just use shaders.
Darkplaces Is Also An Option For Q1 Bsp
#1548 posted by necros on 2015/08/23 05:53:44
There is a sort of simplified shader support in darkplaces. While it is not as powerful as doom3 or anything, it is close to q3 except for some limitations and you can still use q1 bsp format.
It's all done with text files just like q3 and is pretty easy to set up. You can get some pretty wild stuff with it too:
https://www.youtube.com/watch?v=bhwzAxTg99U
https://www.youtube.com/watch?v=_NrHNilIqLo
#1549 posted by ptoing on 2015/08/23 15:45:01
Scampie: how is a bit of additive blending going further than alpha, skyboxes or coloured light. It really is not. And it is one of those effects which could add to the atmosphere of a map but still feeling like Quake, which the stuff that necros linked, while looking neat, decidedly do not. That water does not mesh with Quake at all, imo.
|