Sure, I'll update them. I wasn't aware that they fell out of sync.Originally Posted by Saffith
I'll check on the 2.53.0 std.zh stuff and fix it up, and get Beta 16 ready. I have one minor change to apply before I'm officially done with 2.53.0.
IDR why NumTriforcePieces() is disabled. It's still a beta phase package though. I'll rip out stuff that isn't used on release, but heck, the std.zh files have been packed full of half-finished shyte for years, and nobody cared enough to fix it. I'm spending my energy on 2.55. I should have just released 2.53 by now, bit I honestly wanted to solve this issue with input getting stuck, and fix the speed loss in colour conversion. Obviously, neither is getting done in a timely manner, so I may as well wrap up 2.53 soon. IDK when I can make a Mac build, and IDK if a Linux build will give me the same hassle as before.,
Honestly, I wanted to ensure that every gamma was available on all three platforms, but my sanity is limited.
Those are wholly new functions, that you're mentioning here, and not that many of them. Caching the array size is somewhat faster than checking it every iteration, in positive loops.
Often by storing the result of SizeOfArray() in a variable, I see. Is that based on testing or intuition? It could be more efficient, but since reading a variable means an indirect load from the stack, I would guess not.
Writing the size to a register, and reading it back is absolutely more efficient than checking it repeatedly.
That said, I have a newer version of string_functions.zh for 2.55, that I'll backport to 2.53.0. It should be more efficient, and I pushed it to the 2.55 branch. Instead of caching the array size, I check arr[q] != 0. That's technically slower than reading a cached SizeOfArray(), but because these are strings, it's theoretically faster to halt on a NULL terminator.
I notice that you didn't comment on any of the other efficiency changes, at all. Just on the new functions caching the array size. I went through and manually short-circuited returns, if-elseif-else blocks, and fine-tuned loop iterations in the extant functions. Some of that's probably a gigantic waste of my time, as I'll probably make string.zh internal in the future, but; oh well.
Simply changing N++ to ++N saves instructions. Given how slow ZS array access is, every little bit helps. Likewise, manually short-circuiting logical AND statements improves efficiency, as ZS doesn't bother to do that internally; and early returns do the same. In the 2.55 version, I change some of the functions from if-elseif-else chains to switch-case, which should help further.
Renaming NumberEnemies(), sure. That's a direct paste from one of my headers. It could also use some config settings in the future.
... API? I'm not sure what you're thinking there, but that's not what an API is.
I intended to make a comprehensive API doc for ZC/ZQ/ZScript out of it, and as an extension thereof, technical documentation on ZC?ZQ. It didn't shape up into that, and I have my hands full. System Documentation is probably a more apt title at this point, as a comprehensive API docs set is just a bloody nightmare, and no-one would ever care about it, or use it. I'll reword the title on the next draught.
I wanted to include block diagrams for the internal ZC/ZQ/parser logic at some point, too, but that stuff is in a perpetual state of flux now.
I'll get the fixes into 2.53.0 later this week, hopefully, before the holidays start. I need to add one rule to 2.53.0 (melee weapons use magic), and then it's done, unless I somehow manage to find out what causes the dir input getting stuck. (I cannot replicate that with any degree of reliability, in order to track it down.)
Reply With Quote