So what's the licensing status of the quakec source code? I was planning on releasing the rubicon 2 source, but not sure what license i can put on it (e.g. GPL)

I know that the original source release was sort of an informal "you can make quake mods with it" type license, but not sure if there was a more recent GPL release of the same code. And whether it applies to hipnotic code as well (since i'm using the hipnotic rotating code.) 

It turns out that the builtins floor, ceil and rint are not as efficient as abusing the bitwise functions.

So if you're optimising a tight loop with a call to floor(x) you can instead substitute:(x | x) which does the same thing. Similarly ceil(x) can be replaced by ((x | x) + 1). rint(x) is a little more complicated to replace, it takes two statements:

x = x + 0.5;
(x | x);//is now the same as rint(x) before the first line

Note that you can't make a helper function like

float(float x) rint2 =
{
�x = x + 0.5;
�return x | x;
}

- because the efficiency saving arises from avoiding the function call overhead, and you waste that by making it a function instead. Also, reducing the number of instructions is only really worthwhile in a tight loop that might trip the runaway-loop counter. Hence this being the useless qc observation of the day... 

((x | x) + 1) is incorrect for ceil() as if x==floor(x) then you get a number that's 1 higher. 

 

i didn't understand any of that. :(

what is |? i only know it's the bitwise add operator. never heard of using it with normal numbers. 

However, since it can only work with integers, it floors each number before doing the OR. 

Yeah, I completely fluffed that one. I guess you'd need to do something along the lines of

temp = (x|x)
(temp != x) + temp;//this ACTUALLY evaluates to ceil x

Some lovely abuse of the boolean to float conversion there. I'm not sure if that's still fewer instructions than the call to ceil though... 

The "better" version of ceil still doesn't work for negative numbers, and you might not get the same results as you expect for negative numbers using the rint substitute either. So they're both limited in scope. The floor one works well though, since it does the least work... 

That crap like that matters? :s 

it's not about speed at all. preach already explained that it's main usefulness comes from reducing the number of operations done, thereby increasing the amount of things you can do in a while loop before the engine complains about it. 

Someone should make the engine not complain about how many instructions are being done. That seems.like a better fix than pretty much inlining every function call. 

That would mean that if you ever code an infinite loop in qc then the engine would hang rather than just drop the server with a runaway loop error message. 

Maybe then how many instructions are needed for a runaway error to be trigger should be increased? It would seem so if the kind of optimizations that were listed earlier are needed to stop runaway. Or maybe I'm crazy. 

but how many loops would trip the runaway loop counter? 

100000 instructions between QC programs - a program being a succession of QC functions called without control returning to the engine. In general this is a sensible limit. An example where it might be a problem is if you need to run a looping on each of a set of entities, 20 entities would leave you only 5000 instructions for each one, disregarding overhead. Whatever you set the loop limit to, you could always push the boundaries, until the computation speed becomes more of a factor.

Of course by then you have a new excuse to optimise. The profile command suggests that once upon a time qc performance was an issue, and if quake were to be popularised in mobile or flash form, it might yet matter. 

Lower it for developer 1? Or have a runtime 'reader' to let you know exactly what's going on?

Like an ingame debugger. 

Have it print to console every 10k, noting the current stack and position. Or maybe even 5k... 

Advanced logging. 

Having extra qc developing tools in engines would be a blessing, but they wouldn't help with this problem because they won't ever be universally adopted - making a mod than only works in engines that have a raised instruction limit would not be wise. By that point you might as well customise the engine to do the intensive calculation for you and add it as a qc extension. It's not the kind of thing that can be set to "progressive enhancement" either - you can't change the logic of your code to suit the capacity of the engine that is running it.

At some point I want to write down my thoughts of "progressive enhancement" - usually a web design term - and how it relates to Quake. It can explain why features like fog and skyboxes were embraced, but things like qc extensions on the whole were not. 

The question is, how can QSB be made. 

i've never really had any problems with the 100k instruction limit and i've done all kinds of weirdo shit in while loops.

the point where you start to hit the limit, you're better off thinking about deferring operations to the next frame or something. 

While I've never had anything proper reach the loop limit yet, I know that it was a problem in Prydon Gate, so I guess it depends how different your mod is. The further you go from the original game, the harder you have to work in qc I guess... 

If I started hitting the 100k limit in QuakeC I'd probably be at the point where I need to be doing an engine mod, not a QC mod. 

speaking of instructions...

i've been trying to figure out a way to be able to have two huge groups of monsters fight each other without slowing down.
i'm talking like 2 or 3k monster teams here.

been experimenting with sort of deferring all ai functions to a 'group leader' but it's sort of hit and miss. you either have like a static group and when you have intermittent LOS, then some of the group can't hit their target, or you have a dynamic group and the code to figure out what group you're in eats up even more time than just running ai on all monsters like normal. :\ 

Oh wait...