Flocke wrote: ↑Fri Sep 08, 2023 2:06 amWhat about the other 414 bytes of each palette entry?
I kept analysing the palette entries.
They are rather stupid as usual...
In sub_1001BC70 all the 128 palette entries of 418 bytes each are getting zero initialized by rep stosd.
That command repeats to write the 4 byte eax value 8300h times, so 418h/4 = 106h * 80h entries = 8300h.
- init_palettes.jpg (57.08 KiB) Viewed 691 times
The very first palette entry starts at asm_10084214 and seems to be skipped.
It is preceded by the gen.mpr library handle, stored by asm_10016367.
For the next 127 entries, they usually begin with a data pointer to the palette data, as already reported. In some cases yet to be analysed it however is set to zero, like below. If set to zero, the entries by themselves contain the palette data, making it such huge! Otherwise they instead are mostly blank.
Palette entry structure (
UPDATED):
0x000-0x003: the allocated palette data pointer or zero
the buffer allocation routine sub_100185FB searches for the first unused entry by checking whether the palette data pointer is set or not
this is both the case for combat and tech info screen
0x004-0x007: always set to 0x7FFFFFFFh, max signed integer
0x008-0x00B: always the base pointer to asm_100841E0, which contains the palette list
0x00C-0x00F: some usage counter I guess
palette defaults 0x004-0x00F are initialized at:
Code: Select all
.text:10018636 mov [edi+8], ebx ( =100841E0h )
.text:10018639 mov dword ptr [edi+0Ch], 0
.text:10018640 mov dword ptr [edi+4], 7FFFFFFFh
the counter gets incremented at:
Code: Select all
.text:10018C4A mov ecx, [eax+40h]
.text:10018C4D inc ecx
.text:10018C4E and ecx, 7FFFFFFFh
.text:10018C54 mov [eax+40h], ecx
0x010-0x013: by some models set to the model render number, e.g. 78h or EFh, else 0
the value is getting read at asm_10015297 to check whether it is already set:
Code: Select all
.text:10015291 mov ecx, ds:dword_1003D6C0
.text:10015297 mov edx, [eax]
.text:10015299 and edi, 0F8F8F8F8h
.text:1001529F cmp edx, ecx
- palette_convert.jpg (93.5 KiB) Viewed 661 times
if not already set, the optional data array gets copied over at asm_100152E0 (see optional palette data)
and afterwards at asm_100152F1 the palette index gets stored:
Code: Select all
.text:100152EB mov edx, ds:dword_1003D6C0
.text:100152F1 mov [ecx], edx
0x014-0x017: converted 16bit palette data pointer, usually zero
sub_10015270 first stores away the current palette index pointer
Code: Select all
.text:100152A1 mov off_10298154, eax
then it checks whether the converted 16bit palette pointer is zero
next it keeps searching esi+4 for first zero pointer or end mark "F8F8F8F8" (edi) like it was a queue
Code: Select all
.text:100152AF cmp [esi], edi
.text:100152B1 jz short loc_100152BC
.text:100152B3 mov esi, [esi+4]
.text:100152B6 test esi, esi
.text:100152B8 jnz short loc_100152AF
if marked "F8F8F8F8" processing is aborted
the "F8F8F8F8" value is set short thereafter at
afterwards loc_59C52F3 calls sub_100153D0, which updates the data pointer at asm_10015427
Code: Select all
.text:100152F3 call sub_100153D0
.text:100153D0 mov ecx, off_10298150
.text:10015427 mov [ecx+4], eax
short thereafter with the loop of loc_1001535D the optional palette data is converted from 32bit ARGB to 16bit RGB and written to the 16bit palette data with an offset of 18h
it is returned to the callee, but in another iteration of sub_10015270 the processing is skipped but it is read back from the pointer at
so sub_10015270 does the 16bit conversion, caches the converted data and sets both the converted data pointer and the entry number
sub_10015270 is called from
Code: Select all
.text:1001852A jmp sub_10015270
.text:10016FBF call sub_10018500
.text:10002E43 call dword ptr [edx+38h]
.text:100156E5 call sub_10001C50
.text:10001522 call sub_10015630
.text:1001A271 call [esp+2Ch+var_8]
.text:10015EAD call dword ptr [eax+edx*4] (engMessage case eax=7)
also called from
Code: Select all
.text:1001852A jmp sub_10015270
.text:10005BF2 call sub_10018500
.text:10002E43 call dword ptr [edx+38h]
.text:100156E5 call sub_10001C50
.text:100016D7 call sub_10015630
.text:1001A29D call [esp+24h+var_4]
.text:10015EAD call dword ptr [eax+edx*4] (engMessage case eax=7)
both called from
Code: Select all
mpr97.dll:1000290C call dword ptr [eax+18h] (MPRMessage case 2)
trek.exe:0053AE8B call MPRMessage
trek.exe:0053AE0E call MPRMessage_context_buffer
trek.exe:00511758 call call_MPRMessage_context_buffer
trek.exe:00402484 call cc_MPRMessage_context_buffer
trek.exe:0040233C call c_call_Time_render_object
sub_10018500 is a massive data processing routine and by the call stack above looks to be part of the rendering process
engMessage case 7 keeps processing some message array, always substracting the message size till all are processed
0x018-0x418: optional palette data
the optionla palette data is written by the data copy routine sub_10014C70 at:
called from
which only happens for some of the ships, see
viewtopic.php?p=59974#p59974
furthermore it only is written once when a new model is rendered, afterwards it is reused
- palette_entry.jpg (26.83 KiB) Viewed 691 times
asm_1003D6C0 is some model render counter it seems. It isn't reset but continues to increment with:
Code: Select all
.text:10015206 inc ds:dword_1003D6C0
more analysis to follow
thunderchero wrote: ↑Fri Sep 08, 2023 7:35 am
input overload... brain exploded (add video of your choice)
almost as insane like this I guess:
https://www.youtube.com/watch?v=ctUDMAcKqrE