Increasing vertex limit in trek.exe

[thunderchero]

help thunder clean his chero from your marmelade mess!

hey I keep my chero clean

chero.jpg (241.46 KiB) Viewed 717 times

[Spocks-cuddly-tribble]

what would be the max vertex limit of your "SmartHeap global pool size" in patch?
if I calculate it right 50% of global pool /96 = 109,226 vertices?

In theory yes, but I'm not entirely sure how the SmartHeap sub-pool allocations (max sizes) work.

If you want to go big with 100k+ (albeit it's still recommended to keep model vertex count low in BotF?) I'd switch the patch to VirtualAlloc:

Code: Select all

NAME: GlobalVertex & GlobalCoordinates Buffers with 100,000 vertex limit using VirtualAlloc
DESC: Limit can be increased by editing 'Buffer sizes combined (0x60 * limit X)' and 'displacement (0x44 * limit X)'.
AUTHOR: Spocks-cuddly-tribble
URL: https://www.armadafleetcommand.com/onscreen/botf/viewtopic.php?p=59802#p59802

>> 0x00078bc9 89 e3 8d 54 24 04 b8 c4 ba 57 00 bf a8 58 5b 00 e8 22 ba 09
>> 0x00078bde 8b 0c 24 8b 74 24 04
>> 0x0015863e c7 85 ac 0b 00
>> 0x00158644 3c 2b 61 00 8b 40 10 89 c2 c1 e2 04 01 c2 b8 3c 2b 61 00 c1 e2 02 c7 85 b4 0b 00 00 5c 5b 66 00 01 d0
>> 0x0015867d b8 5c 5b 66 00
>> 0x00158f36 7e
>> 0x00158f8f 7e

<< 0x00078bc9 6a 04 68 00 30 00 00 68 00 7c 92 00 6a 00 2e ff 15 b0 45 57
<< 0x00078bde a3 a8 58 5b 00 eb 5c
<< 0x0015863e 8b 0d a8 58 5b
<< 0x00158644 8d b9 80 c2 67 00 89 8d ac 0b 00 00 8b 40 10 8b d0 c1 e0 04 03 c2 c1 e0 02 89 bd b4 0b 00 00 03 c1 90
<< 0x0015867d 8b c7 90 90 90
<< 0x00158f36 eb
<< 0x00158f8f eb


#004797C9     6A 04                PUSH 4  // flProtect
#004797CB     68 00300000          PUSH 3000  // flAllocationType
#004797D0     68 007C9200          PUSH 927C00  // GlobalVertex + GlobalCoordinates Buffer sizes combined (0x60 * limit X)
#004797D5     6A 00                PUSH 0  // lpAddress
#004797D7     2E:FF15 B0455700     CALL DWORD PTR CS:[<&KERNEL32.VirtualAlloc>]
#004797DE     A3 A8585B00          MOV DWORD PTR DS:[5B58A8],EAX  // use disabled combat.bin pointer
#004797E3     EB 5C                JMP SHORT 479841

#0055923E     8B0D A8585B00      MOV ECX,DWORD PTR DS:[5B58A8]
#00559244     8DB9 80C26700      LEA EDI,DWORD PTR DS:[ECX+67C280]  // displacement (0x44 * limit X)
#0055924A     898D AC0B0000      MOV DWORD PTR SS:[EBP+BAC],ECX
#00559250     8B40 10            MOV EAX,DWORD PTR DS:[EAX+10]
#00559253     8BD0               MOV EDX,EAX
#00559255     C1E0 04            SHL EAX,4
#00559258     03C2               ADD EAX,EDX
#0055925A     C1E0 02            SHL EAX,2
#0055925D     89BD B40B0000      MOV DWORD PTR SS:[EBP+BB4],EDI
#00559263     03C1               ADD EAX,ECX
#00559265     90                 NOP

#0055927D     8BC7               MOV EAX,EDI
#0055927F     909090             NOP


#00559B36     EB 24          JMP SHORT 559B5C

#00559B8F     EB 24          JMP SHORT 559BB5

hey I keep my chero clean

I told you not to clean with the angle grinder, look what happened to the door handles...

[thunderchero]

tested VirtualAlloc patch with no issues.

just curious would there be any chance it would help turn processing if all smartheap calls were moved to VirtualAlloc?

[Spocks-cuddly-tribble]

just curious would there be any chance it would help turn processing if all smartheap calls were moved to VirtualAlloc?

No, the (small effect size) contrary: viewtopic.php?p=54126#p54126

[Flocke]

just curious would there be any chance it would help turn processing if all smartheap calls were moved to VirtualAlloc?

That routine is only made for 64KB block allocation and you need to call unalloc to prevent memory leaks on temporary buffers. But what might help, is to increase buffer limits for some routines. That will however require extensive analysis.

P.S. I'm relieved your chero is in good condition and no tribbles at work. Who knows what thunder blasting rocket monster you'd get back after cleanup.
https://fuelcurve.com/bitchin-64-ranchero/
https://www.kindigit.com/gallery/64-ford-ranchero/
That car has a really nice classic design. No special extras needed!

[Spocks-cuddly-tribble]

The part 'SmartHeap Initializing Memory' should be removed from the patch to prevent conflicts with other patches.

Also I think this is just a check whether SmartHeap can grab this minimum of free RAM from the system = min SmartHeap pool size.

I updated above patch with the code line removed.


EDIT: From a tactical combat RAM usage bug we know sub_537C74 can grab 1GB RAM with no issues, so the effort with VirtualAlloc was pointless.