I need animated fences!

About scrolling, remember those Q3A scrolling neon trims? 

Great you're upgrading the bsp compile code!
I've made a map with four turning skyboxes, in the way that it are large static entities. It perfomes some kind of changing period within one map.

Only min point is that I can't overcome the 240 frames on 0.1 sec so it still some kind of fast movement. If the frame limit of 256 could be passed it would look like the original Q2 standard. 

On an unrelated request, I really think you should reconsider colored lights. Warm hearted. 

MadFox: It's in-engine only, actually. But indeed, the BSP compiler would need some changes to include all extra frames without manually applying each frame in the map editor.

Adib: It's been a very long time since I've played Q3A. I gotta remember to take a look at it again.

I'm slowly thinking about colored lights, and should implement them after figuring out an optimal way. I already have a good idea that may work well, and will try it when possible. 

I think a func_wall with the .avelocity field set may work way better for what you're doing.

A proper solution would be a more flexible skybox system. Mine is full of bugs yet. 

That's what I also thought, but the func_wall acts rather bumpy compared to the static_entity. 

mankrip, that reminds me. an absolute must for all engines is full floating point for angles and not shorts! 

That doesn't look like shorts. This reminds me that the FitzQuake .85 protocol still uses single bytes for some kinds of angles, but I can't remember which. 

yeah sorry, they are unsigned bytes. either way, it ends up that there are actually less values (255) than angles which... ok, I know they were trying to pack in a lot of date into as small as they could, but it looks baaaad. :( 

The func_wall rotation goes with a info_not null avelocity "0 1 0", while the static_entity turns 240 frames self.nextthink = time + 0.1;.

I think the func_wall only counts degrees while the static entity rolls more smoothly. 

Shorts uses 16 bits, while bytes uses 8. 8 bytes contains 256 values, while shorts contains 65536.
360 / 65536 = 0.005493164
A short has roughly 5 milidegrees precision.

The 240 frames you speak of may be because the vanilla angle-to-byte algorithm floors the values twice � first before encoding, and then again during the integer division:
((int)f*256/360) & 255

A more accurate 8-bit encoding is:
(int) (f * 256.0f / 360.0f) & 255
This should give the full 256 values for angles.

Anyway, the immediate issue at hand is that the FQ 0.85 protocol still uses some 8-bit angles. 

is a trend, so people are calling "brutalism" any exposed concrete or anything that even just "feel brutal". 

Is what I did to your mom the other night. No lube, no mercy. HTH. 

Any concrete involved? 

He couldn't get hard without. 

A 'living' texture set (e.g. breathing walls, bleeding brick mortar, spiders escaping orifices), with a lovecraftian feel would be great. 

Contract Revoked 

Try the actual Matrix before the Animatrix. 

 

Yeah those breathing walls are classic! 

definition has nothing in common with being 'brutal' 

brutalism was a trend in the fecking 60s 

Yeah, it was a huge 60s trend and a huge facepalm at the same time ... luckily, people figured out it was fugly by the time the 70s hit. 

I noticed the trend in games, not real world architecture. Some recent indie games like Kairo are recurring to this aesthetic, there was that article on Gamasutra, some architecture related twitter accounts showing it, some level screenshots, etc.

I just made a random comment about people tagging "brutalism" on every exposed concrete around lately because "brutalism" is being hyped. 

This is all your fault you brutalist cubist!!1