Zelda Classic 2.53.0 ( Beta 23 )

[ZoriaRPG]

Bit late here, sorry. Haven't really been keeping up.

std_functions.zh has a commented-out version of NumTriforcePieces that should be removed.
I'd suggest that NumberEnemies should be named NumEnemies for consistency.
EnemiesAlive is misspelled. And it might as well return immediately on finding a living enemy.

And you're still including a bunch of random scripts and test quests, as well as config files that the programs would generate automatically. I assume that's intentional, since you keep doing it? You should at least update ghost.zh and tango.zh to the newest versions if you're going to include them.

Sure, I'll update them. I wasn't aware that they fell out of sync.

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.

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.

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.
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.)

[Saffith]

Writing the size to a register, and reading it back is absolutely more efficient than checking it repeatedly.

Sure, but unless you've made bigger changes to the compiler than I'm aware of, that's not what it does. I can't check the newest versions at the moment, but in the ones I've got, the variable goes into the stack and has to be retrieved again every time through the loop.

I notice that you didn't comment on any of the other efficiency changes, at all.

Because I don't dispute them. The other changes definitely have some effect.

Although looking again now, I noticed something else: several of those new functions use strlen(str-1) instead of strlen(str)-1.

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.

No, I mean that's not what an API is. It's not just a general term for technical specifications; it specifically means the set of functions, classes, variables, and so on provided by a library, operating system, etc. ZC's API specification is in zscript.txt.

Just nitpicking, anyway. It's not a big deal or anything.