Maes
I like big butts!
Posts: 8664
Registered: 07-06 |
Graf Zahl said:
You are making the same old mistake to treat fps as a linear unit of measurement.
Funny, and you are making the mistake of treating time as an absolute measure of performance which has a "good enough" threshold that never needs to be improved upon, once reached.
So if we agree that e.g. taking 1/300 = 3.33 ms to render a frame is already "OK", then yeah, taking 1/400 = 2.5 ms instead doesn't sound that impressive...or does it? It's still a 33% improvement, no matter what.
If I render 300 of those 2.5 ms "faster frames", that means I have 250 whole ms left to do other processing (or, on a multitasking OS, to let other programs do their stuff), period. I never heard of a computer scientist or computer company saying "Yeah, that's fast/big enough, so let's cap improvements of this particular concern at this point, and focus on other things instead". Well, there's that infamous quote about 640 KB of RAM, and we all knew how well that turned out ;-)
OK, there ARE some real-life engineering scenarios where at a certain point it pays to call it "quits" on improving a certain aspect.
Why? Because the rig DOES get the job done or meets a certain quota as it is. In the CS domain, in those applications where you have to deal with fixed hardware, single-tasking OSes, fixed-function software and/or very precisely delimited expectations of performance, then yeah, once you reach a certain critical spot of "awesomeness" you can sort of call it a day and let the marketing team take over. This philosophy works great for e.g. dedicated hardware arcade games, game consoles, embedded systems, etc. and any fixed-hardware platform and single-purpose, single-task software in general.
Now, a program that has to perform in a multi-tasked environment and be extended to do arbitrary stuff....that's another story. Simply put, there's no "good enough" theoretical absolute excellence limit where you can simply call it a day and rest on your laurels forever (well..unless you can design a CPU specially optimized to run Doom and map 1 game operation to 1 opcode running in 1 CPU cycle ;-)
And it's one thing having no known way to improve performance of a particular aspect, and another knowing of a way but not applying it or dismissing it as unneecessary (ok, in the particular case of ZDoom it's actually a more complex situation, I understand that, and sometimes there are other compromises to take into account too, e.g. memory-CPU tradeoffs).
About the REJECT table's size:
Graph theory is relentless in this case. The REJECT table is simply a special type of adjacency matrix, the simplest form of checking whether two nodes of a graph are connected (in Doom terms, that would mean that there's mutual or partial LOS visibility between them), and also the fastest method (checking is an O(1) operation). However space is O(n^2), and that doesn't scale well no matter what.
There are more space-efficient ways such as adjacency lists, which however trade off space with search speed (still, they would probably be faster than a brute force unconditional LOS check most of the time, depending on how many sectors would be visible from a particular sector).
Maybe an interesting variation would be to cache LOS checks in a real-time generated REJECT structure, so that checks would be done with the engine's LOS check method (and that's fool-proof, right?) but would not need to be performed again and again. This would, eventually, lead to almost perfect in-memory REJECT structures (and an adjacency list approach would also make more sense).
Last edited by Maes on 07-30-11 at 18:00
|
07-29-11 09:16 
