Repository navigation
Conversation
| this->calculations = this->calculations + 1; | ||
| int _index = 0; | ||
| this->searchQueue.readIndex = 0; | ||
| if (this->searchQueue.writeIndex != 0) { |
There was a problem hiding this comment.
Same thing: Can you try to clean the loop?
There was a problem hiding this comment.
Are you sure this can not be changed to a while-loop with this->searchQueue.readIndex as run value? It is set to 0 at the start, after all.
| handwritten assembly the frame pointer says nothing about the optimisation level: reimplement the handwritten part as | ||
| inline asm and leave the rest at `/O2`. Checking the prologue settles it - values kept in registers across the entry | ||
| tests mean `/O2`. Taking the `/Od` reading instead took `findLinkageBasedPathOrWalkRadius` from 5.1% to 2.8%, where | ||
| the same body without the pragma reaches 49.2%. When it really is `/Od`, add `#pragma optimize(, off)` |
There was a problem hiding this comment.
Did you had a case that needed \Od?
There was a problem hiding this comment.
/Od is tried every now and then but it usually ends up as an inbetween stage for progress, but never used in the final product. JUst like the pragma's.... I just don't see it being used in a logical way ever. Actually I think we should remove any mention of /Od or pragma's in these docs. Or say as little as possible about it. What do you think?
| return; | ||
| } | ||
| this->searchQueue.readIndex = this->searchQueue.readIndex + 1; | ||
| if (0x13a10 <= (int)this->searchQueue.readIndex) { |
There was a problem hiding this comment.
I see you changed it to the decimal number. My question would be: Is the number related to the PathLinkageLayer explicitly, or is this a map/tile size number?
There was a problem hiding this comment.
It is the map tile size number. Where should we handle this number? Should we make an enum and I make the code refer to it?
Bring the twelve PathFindingState .cpp files that already match the original binary to the style used on main, and verify every one of them still matches: - drop the decompiler's comment blocks (decompilerscript, WARNING: Enum) and the duplicate include of the file's own .func.hpp - clearActiveClimbDataOfType6And7: the two lockstep pointers over climbData become a counted for loop over named fields, the trailing return goes - clearPathFindingTileMaps: sizeof(layer) instead of 0x27420/0x13a10, and the layer passed straight through instead of (void*)((int)(...)) - computeAttackVectorsBasedOnXAndY: iVar1/_index named, += 1 instead of x = x + 1, 80400 instead of 0x13a10, de-yoda'd bound test - reflow the clearActiveClimbDataOfType6And7 doc comment reccmp before and after: all twelve at 100.0%, normalized 100.0%. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
| namespace Map { | ||
| namespace Navigation { | ||
|
|
||
| /* |
There was a problem hiding this comment.
Remove these comment lines
| int* piVar2; | ||
| int iVar1 = 1; | ||
| piVar2 = &this->climbData[1].type; | ||
| do { |
This branch has not been deployed
2 participants
100% matching but currently not always styled properly yet.