Repository navigation
Conversation
| 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?
There was a problem hiding this comment.
I agree with you.
Custom ASM aside, the code seems very much compiled with /O2. so I guess questioning this should come very late.
| 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?
There was a problem hiding this comment.
Could be a good idea. Assuming we do not forget it and create multiple... although, even then.
Once we are done and start consolidating them.
Maybe, in an ideal world, we might up only having to change small things to adjust this later.
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.