как работает ZVS Palette Traslation v.2.0 ?
У меня она мгновенно появляется и исчезает. Так и должно быть? :\

Автор чаще всего тот, кто выкладывает. Пиши, по каким авторы не известны - восстановим.
ZVS Palette Traslation - это которая готовит кадры для дефов? Если да, то она консольная, так и должно быть. Вообще, лучше использовать DefTool и не мучаться.

Это самая первая страница темки программ.
Там вроде написано что изменяет палитру...
Ладно, удалю её+)

DEF Edit v.2.0
DEF Maker v.8.5

Авторы этих двух программ мне неизвестны.
Иногда кстати пишут в самой программе, в справке, а тут нет
выложил их Генадий http://forum.df2.ru/index.php?showtopic=93...indpost&p=28726

Открываешь свойства файла DEFmaker.exe и на закладке "Версия" просматриваешь пункты "Дополнительные сведения". В пункте "Комментарий" значится "Created by A_K_ZyZop". DEF Edit под руку не попался, но тот же принцип поиска данных, я думаю, будет полезен.

оба от Александра Карпеко (Z_K_ZyZop)

DefMaker 8.5 - по-моему, не последний.
Посмотрел прогу ZVS - то, о чем я думал.

Гм, я не понял, зачем вам программа для упаковки звуков в snd архив? Звуки прекрасно работают, если их просто в папку Data скинуть...

А вот чтобы не захламляли место в Data. Berserker уже сделал пилотный вариант проги.

Qwertyus, спасиба)
Но я там уже смотрел и в комментарии у меня пусто и везде...
А вообще я не понимаю авторов которые не пишут в своей программе кто автор

sergroj, спасиба) скоро будет ещё)

Heroes PCX Converter v.1.02 (там же где и предыдущие)

В графе автор стоит Heores III эт что значит?

Ну подписали так.
Вопрос разработчикам КореВог:
нет ли возможности чтобы файлы из лодов просто находились в распакованном виде в разных каталогах? Например
Heroes3\Data\Units
Heroes3\Data\Buildings

Это было бы удобно для содержания многих модов в одной папке и для тестирования.

Кнопка Info -> внизу надпись Eugene. Или опять нет такой кнопки в программе?

Скорость работы падает катастрофически, когда в папке больше 1000-и файлов. Всё потому, что винда писалась на СИ с его нуль-терминированными строками и идиотской системой вычисления размера строки, проходясь по ней.

бред. нуль-терминированные строки и винда тут не причем.

Полная статья: http://russian.joelonsoftware.com/Articles/BacktoBasics.html
Человек - атворитет в мире ПО, могу поискать глубже. Не спешите бросаться словами.

Добавлено ([mergetime]1250199126[/mergetime]):

А теперь скажите, проще найти строку, сравнивая её с десятком или 10000 файлов? Не забывайте, что имена не сортированы и чтение идёт с hdd. В таких каталогах даже удаление файла (просто стирание информации в загоовках его кластеров) занимает значительное время.

Вы скажите, что всё это имеет такое отношение и не к нуль-терминированным именам файлам. Затрудняюсь ответить, почему Джоэл утверждает обратное, но в паскаль-строках (старых) первый байт содержит размер строки и поэтому значительную часть файлов можно смело пропускать при несовпадении длины имени, а проверять только нужные.

Проще найти строку сравнивая хэши. Да и зачем в риалтайме постоянно считывать и сравнивать 10К строк? Загрузка происходит один раз при старте программы. И не корретно сравнивать чтение с записью, запись всегда была медленнее.

Да и пример Спольски с корзиной, мимо кассы. Если там и используется функция подсчета длины строки, то время выполнянения оной для всех файлов врядли составит больше 1-2% от общего времени выполнения открытия корзины. Тут большую часть времени сожрет аллокации памяти, загрузка иконок для файлов, а также получение доп. информации.

И опять же, касаясь вопроса Гиппо. Что вы собрались постоянно сравнивать/читать/что-то еще, что боитесь за производительность? ИМХО упаковка в архивы оправданна 2 случаями: 1) скрыть ресурсы от неискушенного взгляда, хотя кому надо тот и формат расковыряет, 2) уменьшить потери на кластерах, да и фрагментация одного файла может быть ниже, чем кучи мелких.

Вообщем не вижу никаких проблем, для добавления нужного функционала

P.S. ОС кэширует чтение списка файлов. Второй раз это чтение будет почти мгновенным.
P.P.S. Никто не запрещает написать свой враппер над строкой, хранящий длину отдельно, или воспользоватся готовым решением (напримре, std::string).
Сравнение таких строк, будет такое же быстрое как и для pascal-строк.

Не знаю насчёт проводника, но Total Commander подгружает иконки файлов динамически, и первоначально видно около 20-и в списке, что не мешает ему тормозить, а при попытке подсчитать кол-во занимаемого файлами места, вообще вводит в долгую кому. Интересно другое. При удалении 100000 файлов из папки, скорость падает до нескольких десятков файлов в секунду с уменьшением до 1-2х. Может быть это проблема Тотала. У проводника спишем ещё на что-нибудь, но может где-то есть именно проблема реализации ФС на уровне ядра. Чтобы реально о чём-то судить, нужны тесты и код ОС.


СИ++ - это уже не СИ.

P.S А за примерами программ далеко ходить не нужно. Сперва считывают список имён файлов в объект вроде TList, а потом пофайлово обрабатывают. При каждом обращении к CreateFileW с очередным именем файла ОС нужно пройтись по 10к имён, сравнивая строки.
Насчёт кэша утверждать не буду, но что в реале тормоза появляются 100%-но, это факт. И разработчики хранят ресурсы в архивах, имхо, не только из-за экономии места.

Во-первых, я написал "например". Во-вторых, кто мешает на С враппер написать?

Все таки прошу ответить на мой вопрос. Почему то, о чем просил Гиппо, должно дико тормозить?

В синтетическом тесте при создании 100000 строк в памяти размером 1-100 со случайным набором символов и далее поиску среди них СИ-методом (lstrcmp?) и паскалевским, выбирая только с нужным размером через сравнение одного байта, думаю результаты будут отличаться в разы.
Сомневаюсь, что в Windows используются хэши строк, но утверждать не буду. Хотя почему тогда не ввели хэши строк в таблице импорта? GetProcAddress работал бы значительно быстрее, например.

По поводу вопроса. Распакованный архив Героев тормозит. Если очень принципиален результат, я напишу тулзу для теста скорости доступа к файлам из такой папки. Как вы понимаете, никакими иконками (подгрузкой оных) здесь уже не оправдаться.

Добавлено ([mergetime]1250207705[/mergetime]):
Я уже опускаю потери в месте и огромную дефрагментацию при работе с такой папкой. Вполне логично, что отдельным куском (архивом) хранить данные гораздо целесообразнее.

Вы собрались открывать и читать 10К файлов каждый кадр игры? Инициализация и загрузка происходит один раз. И потерпеть пару лишних секунд, за счет подросшего кол-ва вызовов функций октрытия/закрытия файлов.

Возьмем игрушку Battle for Wesnoth. Там как раз 10К файлов не упакованных. Тормозов - нет

В Героях 3 ресурсы загружаются по мере надобности. Входите вы в экран города и 50 дефов достаются из архива. Хорошо, что в архиве имена сортированы и это один файл, а если винт будет шуршать постоянно, кому это понравится?

Добавлено ([mergetime]1250208087[/mergetime]):
Герои 3 шли у меня на Пентиуме 133, видеокарте в 8 МБ и если я не ошибаюсь, 32 МБ памяти. Даже при текущей кофигурации окно города грузится с заметным черновым эффектом (когда экран чёрный и ресурсы загружаются), впрочем, как и окно битвы. И несколько секунд здесь крайне неприятны.

И? 50 != 10К. И если будет в одном файле, то шуршать не будет чтоли?


И непонятно как распакованный архив может тормозить...



Сильно это будет отличаться от сравнения Pascal строк?

Речь шла о pchar-ах, а не более высокоуровневых объектах. Тем не менее, спорим мы зря. Если у вас хард не трещит по швам при работе с папками, где множество файлов, это отлично.

Конечно зря Ваш первый аргумент был - тормоза при нуль-терминированных, что на самом деле капля в море

И таки да, не разрывается

Я, конечно, не программист, но не пойму, почему речь идёт о тысяче файлов в ОДНОЙ папке. Гиппокамус как раз и предложил рассортировать файлы в отдельные папки, что более чем удобно и логично, в зависимости от их функционала. А если речь идёт о переделке геройского движка, то я уже излагал своё мнение по этому поводу в теме "Ремейк" - вообще отказаться от всех старых геройских форматов и перейти к более удобным, что так же не исключает принципа, предлагаемого Гиппокамусом - чтобы всё было логично рассортировано (и упаковано, если надо).

Меня радовал движок Fallout tactics: BoS. Все ресурсы хранятся в зип-архиве, при этом работает даже и с распакованными архивами, даже быстрее получалось.

Если не ошибаюсь, подобное было и в Battlefield 2 - работа из zip.

И в KB.

А с Карзиной дело темное. Сравнение файлов для сортировки там требует раз в 100 больше времени, чем простое сравнение строк.

А что они на карте делают? Ну, подбегает к ним герой - и что? Забирает любого приглянувшегося?))

Командиры, если их не включить - обычные монстры. Кто-то играет и так.

RAD Video Tools (Bink and Smacker)
Что-то не пойму,как это работает.

По-моему, там интуитивно всё понятно. И хэлп инетный есть.

Какой файл-то надо выбирать? Может я не понял смысл программы. С её помощью можно смотреть видео из Георев?

Есть тема "Обсуждение программ" для вопросов о них. А видео, прежде чем смотреть, надо извлечь из файла Video.vid (папка Data на CD или в каталоге Героев). Программа открывает *.smk-файлы.

Я понял одну великую вещь в DefTool: чтобы деф интерфейса собрался без косяков и тому подобных зелёных пятен, даже при различной индексации кадров - нужно выставить ему тип "Заклинание".
Ни разу не подвело.

Уже писал. Повторю ещё.
Def Tool. Версия 3,2. Не работает опция создания .msk и .msg файлов. Пишет, что ошибка строки ********* в GUI32.dll. Необходимо срочно исправить!

Кинь мне DefList и ErrorLog.txt.

Вот:
http://slil.ru/27921838

а, все, у меня тоже Def List с такой ошибкой есть, просто еще не смотрел

Ошибку исправил. Теперь еще кое-что полезное сделаю и выложу.


пришли мне дефлист вместе с кадрами, который генерится неверно.

Вообще, этот деф-лист - h3l, а не hdl, ибо, как я некогда упоминал, ДефТул (любая версия) у меня запоминает ограниченную последовательность кадров. ~ 150. Тогда в случае длинных дефов я сохраняю лучше лист для дефмейкера (h3l), ибо он ограничений не имеет, и ДефТул его открывает полностью.
А проблемы с зелёными пятнами постоянны, когда собираешь деф интерфейса из кадров разной (и даже одинаковой) индексации с использованием h3l. Тогда меняю тип дефа на "Заклинание" - и всё становится ОК.

Итого: не знаю, что именно нужно, и посылаю в личку и здоровый h3l, и "больной" hdl, который вообще перестал открываться, несмотря на наличие кадров.

Добавлено ([mergetime]1251282812[/mergetime]):
А, кадры не прислал. Ну да они - стандартные портреты монстров из TWCRPORT.def.

У меня нет зеленых пятен.

ХЗ. От системы зависеть не может? А через какой деф-лист собирался деф?
Меня больше интересует ограниченность цепочки кадров в hdl. Не знаю, что глючит - DefPreview или DefTool. Если бы я собирал деф на основе hdl, может, и не было бы пятен.

Небольшой вопрос специалистом по def-файлам: Как определить эээ... "нулевую точку" для юнита?

Я про координаты относительно левого верхнего угла той точки, что является базовой для постановки юнита на поле. Грубо говоря, о точке, в которой юнит ногами касается земли (у) и вокруг которой рисунок "флипается" при обработке поворота (х).

Вертикальную координату можно определить вручную по картинке поворота (может быть правильнее то картике "трупа"?), а горизонтальная всегда в районе: для однохексовых юнитов - 195, для двуххексовых - 220.

Но должна же быть где точная информация. Ведь в игре юниты позиционируются точно и красиво.

Ну, насчёт постоянной точности позиционирования - это ты преувеличиваешь. Некоторые юниты WoG не так уж идеально расположены. А в работа Ехх'а вообще сильные смещения бывают. Официальных координат, как таковых, нет, ведь и у отдельно взятого юнита центральная линия не всегда очевидна.

По горизонтали - 195 и 217 (см. Grid.pcx из DefTool). А по вертикали я взял за базу 260, но она может врьироваться.


От системы не должно зависить. Через оба пробовал. Глюк с .hdl я уже поправил - у Дельфи чтение строки из ini было ограничено 2048 символами.
Тогда отправь еще и сами кадры. И как выглядят эти пятна?

Спасибо. От этого и буду отталкиваться.

Теперь назрел вопрос по формату карты :о)

Фрагмент описания географии карты:
Вопрос: как сопоставить значение этого второго байта, описывающего тип рисунка, с именем файла соответствующей текстуры из .def для указанного в первом байте типа поверхности?

Вижу, например, группу: "03 16 00 00 00 00 43". Здесь:
03 - тип поверхности snow.
43 - два флипа по обеим осям
А вот 16 - это - ...? Рисунок в Snowtl.def называется tsns002.pcx

Эм, какие ж тут трудности?
Там же все написано

16 - это номер кадра в блоке.

Спасибо.
Когда проверял эту гипотезу - совсем забыл про "из хекса - в дец" :о)

4 sergroj

по справке к редактору карт (MapEditHelp):
читаю: "Урочная застава
.. чтобы прости .."