тьфу... опять все запутанно. я так понимаю логика должна быть такая:
1. вносить в массив метки из bmenuunits_ico в файле include.asm - там они идут по порядку, соответствующему порядку юнитов.
2. во второй массив вносить метки из файла юнита и последующем чтении sprites_ptrs.asm.
3. если метки не совпадают - делать вывод, что иконок для такого юнита по сути две штуки.
по второму случаю палитра видимо указана - GPAL3
dc.l icons_devastat ; $57
dc.l icon_spr_cfg|GPAL3
а по первому случаю палитру брать из ico_fact_pal.asm?
тут неканоничное решение бы применить - отказаться от домовых палитр. типа чтоб девастатор был не красным - а нейтральным желтым как осадный танк какойнить. так-же и прочие иконки специальных домовых юнитов - девиаторов и так далее. тогда выверты с палитрой были бы не нужны.
Добавлено позже:другой момент для воссоздания конфигов там, где их пока нет - например червяк где жрет. файлы этой анимации находятся выше первоначального содержимого файла, то есть выше метки
; vram block D800-DD20
misc_spr1:
начиная с этой метки идет расчет номера тайла как:
rep_tile equ (repair_spr-misc_spr1)/32+base2
само base2 это equ $D800/32
мне получается нужно запилить метку misc_spr0 в самом начале файла, перед началом перечисления путей файлов (начиная от thopters_tiles: и до house_spheres:), но для расчета номера тайла так-же нужно будет некое значение base0. чтобы формула для той же топтерной анимации расчитывалась что-то типа:
thopters_tiles1 equ (thopters_tiles-misc_spr0)/32+base0
вот где взять это значение base0?
Добавлено позже:да и это четкое указание меток base - меня тоже смущает:
base2 equ $D800/32
base3 equ $F980/32
base4 equ $BD20/32
base equ $7340/32
ведь проблема то в чем - если пользователь решит поменять тому-же кваду размер 2х2 тайла на 3х3 скажем, увеличив размер юнита - то эти метки base - получается собьются и все поплывет.
