Increasing the trek.exe Palette Limit project

[thunderchero]

I was looking at this again,

would it be possible to change location to VirtualAlloc?

I was able to get ship loaded in research screen in ida debug, but when ship was loaded it had no palette data at 5B58A8

the maximum numbers of palettes that trek.exe can use is 127. here's a small example how your ships look like when you use more than the maximum number of Palettes allowed:



In vanilla botf 122 palettes are already in use, so after adding 5 custom ships to the game you will run into this problem.

The trek.exe limit can be increased by increasing below code pointers by +2*(number of extra palettes), but requires also preparing a new dynamic area in trek.exe (initialized with zero bytes).

Code: Select all

AUTO:00539C05                 mov     esi, 59FF30 offset dynamic data field length 104h 260 -> new length +2* (number of extra palettes)
AUTO:00539C55                 mov     esi, 59FE30 offset dynamic data field length 100h 256 -> new length +2* (number of extra palettes)

sub_538450
AUTO:00538454                 sub     esp, 108h
AUTO:00538497                 mov     [esp+100h], ebp
AUTO:005384A0                 mov     [esp+104h], ebp
AUTO:005384AE                 lea     eax, [esp+100h]
AUTO:005384BE                 mov     ecx, [esp+100h]
AUTO:005384CE                 mov     esi, [esp+104h]
AUTO:005384DC                 add     esp, 108h
AUTO:005384EE                 mov     [esp+100h], ebp
AUTO:00538503                 mov     [esp+104h], edi
AUTO:0053850C                 lea     eax, [esp+100h]
AUTO:00538573                 lea     eax, [esp+100h]
AUTO:00538596                 lea     eax, [esp+100h]
AUTO:005385BB                 lea     eax, [esp+100h]
AUTO:005385C9                 mov     ecx, [esp+100h]
AUTO:005385E6                 mov     [esp+100h], ebx
AUTO:005385ED                 mov     esi, [esp+104h]
AUTO:00538609                 mov     [esp+104h], edi
AUTO:00538612                 add     esp, 108h
AUTO:0053861D                 lea     eax, [esp+100h]
AUTO:0053863E                 lea     eax, [esp+100h]
AUTO:00538652                 lea     eax, [esp+100h]
AUTO:005386BC                 lea     eax, [esp+100h]
AUTO:005386C8                 lea     eax, [esp+100h]
AUTO:0053870B                 lea     eax, [esp+100h]
AUTO:00538754                 lea     eax, [esp+100h]
AUTO:00538762                 mov     esi, [esp+100h]
AUTO:0053877C                 mov     [esp+100h], edi
AUTO:00538783                 mov     ebp, [esp+104h]
AUTO:0053879A                 mov     dword ptr [esp+104h], 0FFFFFFFFh
AUTO:005387A7                 add     esp, 108h
sub_538CA0
AUTO:00538CA4                 sub     esp, 110h
AUTO:00538CAA                 mov     [esp+10Ch], eax
AUTO:00538CB8                 mov     eax, 130h   -> ???
AUTO:00538CCD                 mov     eax, [esp+110h]
AUTO:00538CD4                 lea     edx, [esp+104h]
AUTO:00538D4E                 lea     eax, [esp+100h]
AUTO:00538D78                 lea     eax, [esp+100h]
AUTO:00538D96                 lea     eax, [esp+100h]
AUTO:00538DB4                 lea     eax, [esp+100h]
AUTO:00538DDF                 mov     eax, [esp+10Ch]
AUTO:00538E07                 add     esp, 110h
AUTO:00538E3F                 add     esp, 110h

But we can try to use the fixed asm-address of the loaded combat.bin file (unused feature):

1. Overwrite combat.bin (stbof.res) with zero bytes (62500)

2. Set AUTO:00539C05 mov esi, 59FF30 -> 5B58A8 (adr loaded combat.bin now initialized with zero bytes)

3. Ignore AUTO:00539C55 mov esi, 59FE30 (redirecting 59FF30 redoubles code space).

4. Increase all listed code pointer by 100h.

5. Test up to 255 palettes.

[Spocks-cuddly-tribble]

I was able to get ship loaded in research screen in ida debug, but when ship was loaded it had no palette data at 5B58A8

Note my GlobalVertex patches use the first four dynamic bytes at 5B58A8 (start of loaded combat.bin) and combat.bin isn't loaded in code anymore:
viewtopic.php?p=59775#p59775 or viewtopic.php?p=59802#p59802
Was this tested with a version of this patch installed? If so, uninstall for palette test project!

Pointer @ #2 for this project must be adjusted by +4 AND the dynamic area initialised with zero bytes!

would it be possible to change location to VirtualAlloc?

Unless you used above Vertex patch, dynamic memory should not be your issue, but rather many other code obstacles yet to find/fix...

And I think the used dynamic area for palette lists must be initialised with zero bytes (at least the default area is), so extra code must be written.

@ VirtualAlloc:

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.

[thunderchero]

Unless you used above Vertex patch

No test was on a fresh install of vanilla, it was just a thought

I am still getting ctd with event log of mpr565.dll at offset 10015E0E if viewed in ida

Code: Select all

call    ds:FreeLibrary

[Spocks-cuddly-tribble]

I am still getting ctd with event log of mpr565.dll

This code is not in my wheelhouse, Flocke might see more since the palette handle is close to the vertex code.

sub_538F70 mpr_import__TextureEAX_or_PaletteEBX

00538FA9           push  100h  ###
00538FAE           push  20h
00538FB0           push  esi
00538FB1           call  MPRNewTexturePalette

00538FC4           push  100h  ###
00538FC9           push  0
00538FCB           push  20h
00538FCD           push  80h   ###
00538FD2           push  edi
00538FD3           push  esi
00538FD4           call  MPRLoadTexturePalette

100h -> 256 /2 = 128 (limit+1)?

80h -> 128 (limit+1)?

Double some or all three of them?

[Flocke]

This code is not in my wheelhouse

sub_538F70 mpr_import__TextureEAX_or_PaletteEBX

00538FA9           push  100h <- num palette colors = 256
00538FAE           push  20h <- bitcount = 32
00538FB0           push  esi
00538FB1           call  MPRNewTexturePalette

00538FC4           push  100h <- num palette colors = 256
00538FC9           push  0
00538FCB           push  20h <- bitcount = 32
00538FCD           push  80h <- texture type 80h = PALETTE
00538FD2           push  edi
00538FD3           push  esi
00538FD4           call  MPRLoadTexturePalette

100h -> 256 /2 = 128 (limit+1)? no, the falcon code is full of references for a 256 palette color limit, but this is per palette, not the number of the palettes

80h -> just a flag for the texture type: 80h = PALETTE, 40h = ALPHA, 20h = CHROMAKEY, 1 = MIPMAP, 0 = DEFAULT

edit: As far I can find, there is no palette limit in MPR. For an engine even by that time, setting such a low limit also would be awkward. The error reported by thunder rather indicates that the library failed to unload (maybe after combat?). The most likely cause will be that you allocated additional palette entries from MPR but they are missed by some release routine. Then when the library unloads, there are some dangling references that raise this crash.
edit2: checking the mpr565 asm code, the unload routine is also called as a fail safe by sub_10017D10, which allocates buffers and I guess does some texture processing. It therefore more likely fails by some invalid data that's passed in, e.g. by invalid color table size, see below

[thunderchero]

This code is not in my wheelhouse

while in ida debug I found exactly where the palette info is loaded
I can see all the palette data loaded

.bss:00603EA4 dword_603EA4 dd 0C4D0020h ; DATA XREF: sub_538450+29w
.bss:00603EA4 ; sub_538450:loc_538701w ...

QD had it labeled as "GlobalPalette"

Note; 256 x 4 bytes = 1024 per palette x 128 limit = 131,072 x 2 (double limit) = 262,144 (combat.bin = 62,500)

[Spocks-cuddly-tribble]

603EA4 GlobalPalette

1024 per palette x 128 limit = 131,072 x 2 (double limit) = 262,144 (combat.bin = 62,500)

That's clear, but not your issue. Unlimited dynamic code allocated for the loaded palettes @ [603EA4].

Good one! @ combat.bin, default sizes of the two data fields for the known limit of palettes: 59FE30 100h_256dec & 59FF30 104h_260dec.

So not the loaded palettes themself, unless they use an outstanding data compression algorithm... (should be a list of loaded palette IDs)

However @ total memory:

indicates that the library failed to unload.
The most likely cause will be that you allocated additional palette entries from MPR but they are missed by some release routine.

Beginning with dword_58AB20 you see twelve times the value 20100h = 131,328 dec for array_store and delete_free memory.

This is suspicious close to the max palette limit 131,072 and used for our codes in question.

I'd try to increase all twelve values?

Screenshot (88).png (8.61 KiB) Viewed 1106 times

[thunderchero]

I'd try to increase all twelve values?

same crash in mpr565.dll

[Flocke]

I checked mpr565 again, the unload routine is also called as a fail safe by sub_10017D10, which allocates buffers and I guess does some texture processing.

The trek.exe limit can be increased by increasing below code pointers by +2*(number of extra palettes), but requires also preparing a new dynamic area in trek.exe (initialized with zero bytes).

Code: Select all

AUTO:00539C05                 mov     esi, 59FF30 offset dynamic data field length 104h 260 -> new length +2* (number of extra palettes)
AUTO:00539C55                 mov     esi, 59FE30 offset dynamic data field length 100h 256 -> new length +2* (number of extra palettes)

These are two separate lists. Likely the first code pointer 00539C05 is for palette handles and the second one 00539C55 for texture handles. By default one palette per texture is expected, therefore both lists should be of same size. 100h / 2byte handles (or ids) = 128 palettes & textures max.

sub_539C00 and sub_539C50 actually are zero-terminated copy routines, which copy 2-byte values into specified edx data pointer
given that it is zero terminated explains why the limit is -1

If I'm correctly reading the code, eax points to another list of handles, and both the global list and the eax handle list are written to the edx data.
For it at least the esp stack pointers of both subroutines need to be increased:
listed values of sub_538450 all must be increase to allow copy the palette handles to local stack buffer
listed values of sub_538CA0 all must be increase to allow copy the texture handles to local stack buffer

[thunderchero]

sub_539C00 and sub_539C50 actually are zero-terminated copy routines, which copy 2-byte values into specified edx data pointer
given that it is zero terminated explains why the limit is -1

If I'm correctly reading the code, eax points to another list of handles, and both the global list and the eax handle list are written to the edx data.
For it at least the esp stack pointers of both subroutines need to be increased:
listed values of sub_538450 all must be increase to allow copy the palette handles to local stack buffer
listed values of sub_538CA0 all must be increase to allow copy the texture handles to local stack buffer

palette handles and texture handles? would that be the texture.lst and palette.lst index? If so these should not need increasing just look at UDM and Galaxy mod. they both easily have double vanilla texture.lst and palette.lst index. only the palettes is limited

[Flocke]

palette handles and texture handles? would that be the texture.lst and palette.lst index? If so these should not need increasing just look at UDM and Galaxy mod. they both easily have double vanilla texture.lst and palette.lst index. only the palettes is limited

palette.lst is just some index mapping for textures to palettes, and texture.lst lists all the texture names
the two 127 limited lists above are for loaded MPR palette and texture handles from what I see

I guess not all the textures are being kept loaded to reduce memory usage, but possibly it again is some mapping table for textures to palettes

Thinking about, it makes sense that the list is zero ckecking. I think it is rather some kind of buffer for active handles and therefore searches the first free slot to add another handle. But just another guess.

Further, given that palettes use less space than the textures, maybe they are kept loaded.

[thunderchero]

look at UDM and Galaxy mod. they both easily have double vanilla texture.lst and palette.lst index. only the palettes is limited

just checked it is not double vanilla but still texture.lst and palette.lst index are well above 127 limit
vanilla 299
udm 311
galaxy 474

Edit; I am really starting to think the trek.exe will support unlimited palettes. But the mpr565.dll restricts to 127, just like the mpr565.dll limits textures to 512 x 512. (updated/hades mpr565.dll will limit to 256 x 256 texture).
trek.exe will allow 1024 x 1024 textures, but mpr565.dll does not read mapping correctly.

[Spocks-cuddly-tribble]

@ default trek.exe limit for palettes used -> Can you please clarify is this [dynamic] palette IDs 0-126 -> 127 max or 128 max with max ID/index 127

Code: Select all

AUTO:00539C05                 mov     esi, 59FF30 offset dynamic data field length 104h 260 -> new length +2* (number of extra palettes)
AUTO:00539C55                 mov     esi, 59FE30 offset dynamic data field length 100h 256 -> new length +2* (number of extra palettes)

These are two separate lists. Likely the first code pointer 00539C05 is for palette handles and the second one 00539C55 for texture handles. By default one palette per texture is expected, therefore both lists should be of same size. 100h / 2byte handles (or ids) = 128 palettes & textures max.

For it at least the esp stack pointers of both subroutines need to be increased:
listed values of sub_538450 all must be increase to allow copy the palette handles to local stack buffer
listed values of sub_538CA0 all must be increase to allow copy the texture handles to local stack buffer

Yes, that's the (still failing) approach of my initial patch suggestion. So there is still something missing or wrong with a specific value location.

Note: the zero initialized code space for the loaded palettes IDs list is four bytes longer by default than the corresponding texture list IDs array

EDIT: This might be the error/culprit:

2. Set AUTO:00539C05 mov esi, 59FF30 -> 5B58A8 (adr loaded combat.bin now initialized with zero bytes)

3. Ignore AUTO:00539C55 mov esi, 59FE30 (redirecting 59FF30 redoubles code space).

2. Set AUTO:00539C05 mov esi, 59FF30 -> 59FE30

3. Set AUTO:00539C55 mov esi, 59FE30 -> 5B58A8 (adr loaded combat.bin now initialized with zero bytes)

Thinking about, it makes sense that the list is zero ckecking. I think it is rather some kind of buffer for active handles and therefore searches the first free slot to add another handle. But just another guess.

Further, given that palettes use less space than the textures, maybe they are kept loaded.

Parts of the code give this impression, yes. Only the still missing ones get loaded and added to a new dynamic palette list until limit issue (index list handling, not memory for palettes ).

This is a crap approach by default, since the entire palette.lst from stbof is loaded into RAM anyway. Instead of this unneeded copy one should better read the palettes themselfes from there (but requires pointer calculation each time via reading texture.lst and palette.lst).

Default is just [new sorted palettes list copy] + 1024 * dynamic palette ID/index.

[thunderchero]

I went crazy....

I no-op the sub 00539C00 and all 3 3d screens loaded without issues (combat, screensaver, tech screen ships)

next I have a question vanilla palette has 129 palette entries, how does it load without crashing? I know it has duplicates but where do the duplicates get removed?

this sub is called twice 511630 both right after loading palette and texture and color.lst 495B2F and 502B88

are we looking at dead/not used code?

this brings up my second question what is color.lst for?

[Spocks-cuddly-tribble]

I no-op the sub 00539C00 and all 3 3d screens loaded without issues (combat, screensaver, tech screen ships)...

this sub is called twice 511630 both right after loading palette and texture and color.lst 495B2F and 502B88

are we looking at dead/not used code?

this brings up my second question what is color.lst for?

I'll have to come back to this later.

No idea about color.lst, I don't even see thhe point of palette.lst today (old time system limitations?).

next I have a question vanilla palette has 129 palette entries, how does it load without crashing? I know it has duplicates but where do the duplicates get removed?

Not all are moved, only the used ones read from texture.lst (there is unused palettes by default).

Limit is total number of different palettes used by all textures. his is my question

I.e. palette.lst can be extended as long as max X different palettes are used by the shipt textures (this is our dynamic lists).