|
23.07.2008
Баг ФриПаскаля №4605 (исключения в dll для Windows не ловятся) практически сводил на нет применимость самой архитектуры Chentrah, поскольку любое исключение в игровом модуле под Windows пробивало до модуля-матки, и программе оставалось только убиться об стенку: такие пряники, как, например, автосохранение при крахе рендера были просто невозможны.
Ждать исправления бага бессмысленно: он висит в багтрекере ещё с 2003 года. Обработка исключений в Виндовс не документирована, и всем производителям компиляторов (Борланду, например - точно) приходилось заниматься reverse engineering'ом чтобы обеспечить её поддержку.
Но я - что бы вы думали? - нашёл обходной путь, позволяющий снять основную тяжесть проблемы. Вместо бесполезного блока try...except используется процедура-враппер модуля-матки. Игровой модуль передаёт той свою процедуру, которую процедура - враппер вызывает, заворачивая в собственный блок try..except и ловя в ней исключения. Коряво? Да. Полный изврат? Да. Но работает.
10.05.2008
В последних версиях Wine пошли глюки с исчезновением мышьего курсора на моём окне. Плюнул, решил приделать-таки давно откладываемую поддержку курсора - в качестве которого загружалась бы произвольная картинка, хоть отрендерённая через тот же огл. Чтобы не заморачиваться с аппаратным, на который ушло бы слишком много сил - сделал через OpenGL.
Ага. А потом встал вопрос как *убрать* системный курсор. Трахался полдня, истощил свой словарный запас, в конце концов нашёл-таки решение (и, похоже, единственное): чтобы гарантированно убрать курсор нафиг, причём только для своего окна, надо создать и подключить полностью прозрачный курсор.
Трахался ещё полдня, сделал, отладил и для Win32 и для X. Оглянулся назад на пройденный путь. Подумал. Доделал оставшиеся 10%, получив ту самую поддержку аппаратного курсора, которой стремился избежать. Правда, он однобитный и смотрится не очень - Но! совместим с форточками вплоть до 95-х и иксами любой степени древности. А у меня девиз: совместимость - это наше всё, смерть зависимостям.
Потом стал чесать репу нафига мне два курсора. Привинтил так, что обычно используется цветной OpenGL'ёвый, а на аппаратный однобитный переключается если fps'ы падают ниже тридцати.
Ну вот скажите теперь, у кого, в какой вменяемой программе такая фича есть?..
19.03.2008
X сервер стал падать при переключении на терминал по Ctl+Alt+F1. Я, однако, не ныл, а тут же ухватился за возможность протестировать chentrah в подобных суровых условиях. И что бы вы думали? Сохраняет сессию как миленький. Вот попробуйте найти любой другой движок который сохрянял бы игру при крахе графической оболочки!
Надо посмотреть, возможно ли хоть какое-то подобие этого сделать для Виндовз.
29.01.2008
Я не дремал. Я совершил героический подвиг. Последовав по стопам Франкенштейна, я сшил своё детище из кусков неработавших модулей стандартной RTL - и вот она, долгожданная мечта человечества, самодебажащаяся программа. Умеет по адресу исключения вышаманивать позицию в исходниках и добавлять к сообщению об ошибке. Вроде бы, мелочь... Но такие мелочи двигают мир.
25.11.2007
Наконец-то, переделка модуля-матки закончена. Добавлен базовый гуй, так что теперь большинство сообщений об ошибках выводится в том же окне через OpenGL. Базовый гуй также умеет диалог выбора языка и выбора модуля. Дефолтная конфигурация, текстовые сообщения, битмапы шрифта и фона теперь вшиты в основной exe'шник, позволяет культурно сдохнуть даже если вообще не найдена папка с файлами.
18.11.2007
Две недели назад я думал, что наконец начну заниматься пиксельными шейдерами. Оглядываюсь назад - и что я вижу? Вылизанную поддержку текстового вывода и зачатки гуя. Не говоря уже об уйме черновой работы вроде вырезания нафиг всякого устаревшего мусора вроде поддержки переключения видеорежима.
20.10.2007
Взглянул внимательно на свой оконный менеджер - чуть не стошнило. Ни за что на свете я не выставлю на всеобщее обозрение эту кишащую багами помойку! Там говнокода накопилось несколько культурных слоёв, ещё с тех пор как я под Виндовс 98 алгоритмы методом тыка подгонял.
Остаётся одно: скальпель в руки - и вперёд... Когда ж я до пиксельных шейдеров то доеду, а?..
03.10.2007
Переделать менеджер ресурсов оказалось проще, чем я думал. В первую очередь, потому, что сам он стал проще на порядок при тех же выполняемых функциях. Надеюсь скоро смогу подготовить №13 к публичному показу
24.09.2007
По здравом размышлении, архитектура менеджера ресурсов никуда не годится, буду полностью переделывать. Заодно перенесу в модуль всю работу со шрифтами.
Заодно, достали глюки оконного менеджера для Линукс, созданного копированием куском чужого кода, без полного понимания оного, и подгонкой методом шаманского тыка. Скачал себе исходники Ogre, изучаю OgreGLXWindow.cpp. Уже открыл много интересного, включая существование такой вещи как Xrandr. Стал проверять - и правда, во ФриПаскале есть модуль xrandr. А у меня через Xxf86vm было сделано, причём хидеры сам конвертил, на коленке, и либу вручную подключал. Вот век живи - век учись.
24.06.2007
Битва была свирепой и нескончаемой, но баги, наконец, пали (как всегда, ошибки оказались совершенно идиотскими). Менеджер ресурсов, в минимальной пока комплектации, жив и работает, как часы. Можно, наконец, продолжиить работу над менеджером шрифтов, а там и до и GUI недалеко.
Кроме того, осуществлён переход на chepersy 0.8.1, полный переход на юникод (все исходники конвертированы в utf-8, IDE Лазаря перенастроен на GTK2), все внешние функции (функции ядра движка, вызываемые модулем) завёрнуты в специальные обёртки, так, что исключения *никогда* не пересекают границу между exe и dll. И куча всего ещё, включая изменение структуры папок под планирующийся установщик (с учётом особеннойстей Линукса и Висты).
09.05.2007
Затравил, наконец, долго не дававшийся баг с некорректной передачей русских букв в сообщениях об ошибках из модуля в основную программу. Причина оказалась абсолютно идиотской: среди дюжины перегруженных версий процедуры Die() не оказалось такой, что жрала бы голую Wide-строку. И молча вызывалась Ansi-версия, втихую перегонявшая мою юникодную строку во что-то согласно системной локали. А потом полученное безобразие обрабатывала моя собственная процедура перегонки из Windows-1251 в юникод. Понятно, что это работало только в настоящей Маздаине с русской локалью.
З.Ы. Скриншот сделан под Линуксом. Просто у меня стоит тема "Redmond 2000"...
С обями "Bliss"...
Кто первый назовёт меня извращенцем - получит в бубен.
24.04.2007
Zaderzhki iz za pereezda s ASPLinux 11.2 na Fedora Core 6... Vsyo horosho, prekrasnaya markiza, za isklyuchen'em pustyaka: podderzhka russkogo yazyka na urovne plintusa. Ni odnogo shrifta v kodirowke Windows, vse w koi-8, zarazy!
13.03.2007
Я завершил переход с библиотеки libPng на Vampyre Imaging. Она на Паскале, компилируется в движок прямо из исходников, поддерживает неизмеримо больше форматов, содержит функции обработки (вроде масштабирования или копирования прямоугольных областей) - а общий объём бинарных файлов практически тот же. cge.exe распух до 320 килобайт (линуксовая версия - до мегабайта), но зато не надо тащить с собой здоровые dll'ы.
04.02.2007
Оконный менеджер приведён к виду, в ктором пребудет ещё долгое, долгое время. Из линукс-версии вырезана поддержка полноэкранного режима. В виндовс-версии при переключении из полноэкранного режима в оконный выполняется перезапуск программы: исследования показали, чо надёжного способа вернуть окну цивильный вид не существует, легче прибить его (со всеми текстурами, увы) и создать заново.
На скриншоте: win32- и linux-версии CGE мирно уживаются на десктопе gnome. Что забавно, обе крутятся параллельно, с полным аппаратным ускорением.
29.01.2007
Связанная с полным переездом на Линукс задержка подходит к концу. Как ни странно, для получения рабочей нативной версии мне пришлось подправить лиш пару строчек кода. Глючит лишь переключение между полноэкранными режимами: чего-то я, всё-таки, не учёл. Надо было делать на FreeGlut а не свой оконный менеджер писать. Но это всё цветочки. Оказалось, основной исполняемый файл под Линуксом получается в 600 килобайт размером, и - главная подлость - UPX'ом его обрабатывать нельзя, начинает глючит процедура распознания собственных имени и пути. Кроме того, динамические библиотеки модулей, за каким-то бесом, выходят в полтора мегабайта размером (и это после strip!)
Короче, основной курс теперь - кросскомпиляция и запуск из-под wine. Тем более, что под wine CGE идёт, как по маслу (а что что переключение из полноэкранного в оконный режим глючит - так оно и под Виндовсом глючило, что-то там в параметрах окна не то задаётся).
03.10.2006
Тест №13 пока не готов, но я обновил Тест №12 на странице скачки, исправив серьёзный баг, из-за которого программа, скорее всего, молча падала с большинством видеодрайверов. Кроме того, структура исходников приведена в соответствие новой структуре движка.
20.09.2006
Нееееет! Фри Паскаль на целых четыре процента медленнее!
15.09.2006
Ну, понеслась...
15.08.2006
Исправил совершенно идиотские ошибки в строках 264,265 и 436 mo_basket.inc и 76 mo_trulypersistent.inc, перезакачал тест №12. Была неправильная адресация к полям, в результате чего после добавления нового класса или изменения порядка регистрации классов процедура загрузки игры с треском падала.
Кроме того, вылезла ещё одна хворь: русские буквы в сообщении об ошибке где-то попути от модуля к ядру превращаются в знаки вопроса.
05.08.2006
Тест №12 готов и выложен для скачки! Теперь бы только денег на Интернет добыть...
03.08.2006
Наконец-то оптимизация достигла такой степени, что вызовы конструкторов при загрузке объектов занимают 40% времени. Для выбранной мной структуры достигнут предел. Конструкторы буду оптимизировать потом, на более поздних стадиях.
Чтобы пощупать производительность в "реальных боевых", я замедлил свою машину до минимальных системных требований: 1000МГц процессор/200МГц память.
Если состав полей класса изменился со времени сохранения, загрузка объекта идёт по более сложному алгоритму, замедляясь раза в два-три. Стоит заметить, что объекты неизменившихся классов это не затрагивает.
24.07.2006
День испытаний под нагрузкой. Я, наконец, завершил то, о чём мечтал: систему сохранения. И оказался совершенно недоволен её производительностью. 200 тысяч объектов в секунду - это ни в какие ворота не лезет.
Пришлось изобрести средство поиска узких мест в коде - топорное, но точное и эффективное ({$include + Asm + RDTSC = сила), и хорошенько прошерстить им своё творение.
Результаты оказались малость шокирующими. Основное время, как оказалось, жрали вовсе не выделение памяти или вызовы виртуальных методов... Кто бы мог подумать, что одно обращение к полю поля объекта из массива объекта объекта окажется тормознее, чем дюжина вызовов виртуальных методов, активно копирующих данные через TmemoryStream... Чебу на заметку: *не увлекаться* сложными структурами данных. Компилятор такая заумь вгоняет в тоску, потому как ему её в жизни не оптимизировать.
Короче, буду переделывать.
Кто-то может спросить: а на кой?.. Игровой мир из миллиона объектов - это ведь в любом случае изврат, так никто не делает... Но дело в том, что я всю жизнь мечтал вставить в свою игрушку некоторые заковыристые заклинания вроде предчувствия опасности (реального, а не на эвристике!) или возможности прыгнуть на несколько секунд в прошлое, и полюбоваться на себя самого, отбивающегося от монстров. Всё это требует или создания копии игрового мира, выполняющейся параллельно с основным, или сохранения мира в буфер каждый кадр. Так что быстродействие перзистентной системы для меня весьма критично.
20.07.2006
Слов нет. Кроме матерных.
Какого хрена RTL Фри Паскаля сообщает о переполнении стека как о "неизвестной ошибке 202"?!.. Я несколько часов мудохался с отладкой прежде чем догадался применить директиву {$memory}, и установить гигабайтный предел для размера стека. И Инета ещё нет, на форумах не посоветуешься. Блин. Воистину, блин.
03.07.2006
Он дышит! Он дышит!!! Му-ха-ха-ха-ха-ха!!!
Моя мечта, моя система сохранения уже работает! Ещё день-другой - и выдам я на гора тест №12, тест самого дорогого для меня - моей persistency system. И здравствуй тогда обратная совместимость, да валидатор с парсером ядрёные, что на пути моей рассеянности великой могучим заслоном встанут!..
25.06.2006
Ну, ещё немного... Ещё чуть-чуть... И моя стародавняя мечта наконец сбудется!
23.06.2006
Я обновил архивы(ы) теста №11 на странице скачки. Исправления:
1. Лицензия GNU GPL теперь вложена в архив, как и должна была.
2. Проектный файл Лазаря обновлён, включена опция "длинные строки", как и должна была.
3. Я, случаем, не забыл объявить о выходе теста в свет когда выкладывал его?..
22.06.2006
Осторожно, во дворе злой валидатор...
29.05.2006
Диспетчер модулей готов на 90%, консоль - на 80% (так-то готова, но слегка подглючивает). После этого ядро движка можно будет считать условно доделанным, и приступать к самому интересному - модулям как таковым!
26.05.2006
Как гласит народная мудрость - "Лучше день потратить на написание валидатора, чем потом неделю мудохаться, отлавливая банальную ошибку"...
17.05.2006
И что бы вы думали?.. Шедшие в комплекте с Фри Паскалем классы для чтения графических форматов оказались полнейшим отстоем!.. Тесты выявили, с крошечной .PNG картинкой 256x256 они возятся двадцать (!) секунд. Для сравнения: LibPng декодирует монстра размером 4096x4096 всего за две с половиной секунды! ...Короче, пришлось вытащить с пыльной полки и прикрутить обратно модуль для работы с LibPng.
07.05.2006
Ядро движка близко к завершению (что ещё ни о чём не говорит: ядро у меня - не более чем негр, выполняющий всю черновую работу). Кто бы подумал, что при создании действительно качественной вещи бОльшая часть работы уходит на "подводную часть айсберга"!.. Хотя, без этой подводной части надводная слишком легко опрокидывается - что нам и демонстрируют многие образчики говна в глянцевой упаковке...
18.04.2006
а.) Пересмотрел стратегию. На слишком уж эпические высоты я замахнулся, вот и застрял. Поэтому, следуя мудрому принципу, который открыл Оккам-дзисан, я взял эту самую бритву, и обкромсал весь лишний балласт: 1) систему моддинга (нужна только если в проекте пожелают участвовать другие люди, в чём я всё больше сомневаюсь), 2) автоматическое создание методов сохранения/загрузки для класса по списку полей объектов (могу и ручками), 3) встроенный редактор + возможность вызова компилятора из движка (по крайней мере, временно).
б.) Пересмотрен проект игры, которая будет использовать движок. Вкратце, это должен быть гибрид Diablo и Doom II, где от первого будут автогенерация подземелий, куцая ролевая система и наличие магии, а от второго - монстры и стволы (имеющийся сонм моделей к Doomsday избавляет от необходимости тратиться на создание контента и редакторов для него). Число монстров и оружия будет увеличено за счёт "цветовой дифференциации штанов".
24.07.2005
Как я мог не заметить - поддержка PNG во ФриПаскале входит в стандартный набор модулей! И LibPng нафиг не нужна!
Идиёт.
05.06.2005
Configuration manager исправлен путём массированного обрезания - слишком много было ненужных наворотов.
Следующей норов показала LibPng, с достойным лучшего применения упорством отказывавшаяся грузиться под Вынью 98...
Как только я не трахался, как не гемороился - уж и альтернативные версии в Инете искал, и целую навороченную систему проверки
зависимостей построил... А она не идёт- и всё тут. Когда совсем уже отчаялся - обнаружил, что паскуда просто не видит zlib1.dll, лежащую
в одной с ней папке. Добавил команду SetCurrentDir(<папка, где всё это добро лежит>) - заработала как шёлковая... Нет, а?.. А под Маздаем 2000 и XP спокойно шло без этих турусов, мать ихнюю...
15.05.2005
После перезда на Маздай XP всплыла новая проблема.
Причина её, как ни странно, не в кознях Билла Гейтса, а во внутреннем раздрае RTL ФриПаскаля: объявление SetWindowLong конфликтовало с некоторыми константами WinAPI, компилятор орал об ошибке проверки диапазона при компиляции, но программа запускалась, и, вроде, даже шла... Пока я не запустил её на Выни XP, которая подавилась моим криво заданным окном. Видели бы вы, как её расколбасило при попытке спереключить видеорежим!..
Но ладно, это поправил, переопределил SetWindowLong по нормальному (а заодно доложил о баге №4043)... Теперь новая проблема: я-то думал, у меня менеджер конфигурации давно доделан, а он, оказывается, глючит по чёрному...
05.11.2004
Сегодня линуксовая версия впервые встала на свои хилые лапки, и даже сделала пару неуверенных шагов... Резайс окна игнорирует, в полноэкранный режим переключаться не умеет, но уже бодренько рисует средствами OpenGL, и даже мышей ловит...
27.10.2004
Мертвяк пошевелился. Не лежится ему спокойно, значить...
25.01.2004
Наконец-то удалось приручить последнюю бета-версию компилятора (1.9.2). Оказалось, в cgebuild.bat в командной строке компилятору скармливалось столько всякого мусора (в смысле, опций всяких ненужных), что поэтому-то программа м падала прямо после запуска... Впору бить себя по лбу. Тяжёлым предметом. :(
18.01.2004
Структура движка превратилась в нечто более-менее упорядоченное, принцип компилируемости "на лету" отлажен, и теперь отсоединяемая часть движка имеет прямой доступ к функциям OpenGL32.dll, загружаемой программой-маткой.
Принято решение вынести в изменяемую часть движка как можно больше, в том числе почти весь рендеринг (хотя окном, контекстом прорисовки и текстурами по-прежнему будет заведовать программа-матка).
Да, и я не забыл упомянуть, что появилась консоль?.. В отличие от большинства движков, она лишь средство просмотра лога, поскольку для управления программой у нас будут куда более мощные механизмы. Прокручивается мышьим колесом.
15.01.2004
После долгого простоя проект разморожен
03.06.2003
Нет, это не "Кровавая Месть Вращающегося Кубика - II". Это - первые шаги по пути самокомпилируемости. Уже позволяет менять часть кода "на лету", без перезапуска программы, рестарта OpenGL и перезагрузки ресурсов... Хотя, вру: ресурсов она пока не использует.
Выложил тест-версию№7. Сырая как сырьё.
2 Июня 2003
Тупая Дельфя глючит при попытке три раза подключить один и тот же кусок кода директивой {$include} с разными ключами компилятора к одному и тому же модулю. Поддержка Дельфей прекращена.
23.05.2003
Начиная с этого дня, движок можно компилировать и на ФриПаскале.
11.04.2003
Смена курса:
Ранее все силы были нацелены на сохранение играбельности и управляемости при крайне низких FPS (порядка 10..15) - поскольку я в течение многих лет привык играть при жёсткой нехватке аппаратных ресурсов, и поэтому строил структуру движка на принципе разделения физики+управления и графики на два независимых потока.
После тяжёлого, продолжительного раздумья я пришёл к выводу, что это в принципе неправильно, и постановил считать игру при FPS ниже 30 особо изощрённой разновидностью мазохизма...
Новая стратегия основана на принудительном понижении качества картинки пока FPS 'ы не достигнут как минимум 25. Для этого будет применяться рисование статических 3d объектов в спрайты, с перерисовкой каждого один раз в несколько кадров.
Многопоточность будет использоваться только для фоновых задач вроде загрузки текстур или сохранения игры.
18.01.2003
+ кой-какая опtимизация: 1000-ёлковый лес рисуеtся на 35 FPSах!
13.01.2003
+ загрузка и оtрисовка *.CME и *.MD2
+ переключение режимов фильtрации(би- и tрилинейная, анизоtропная) и смещений LOD
20 Декабря 2002
Борланд задрала цену на Дельфи до небес - начал мигрировать на FreePascal.
29.11.2002
+ классы меню (пока tолько на основе гиперtексtа)
+ главное меню и меню выбора видеорежима
- некоtорые баги.. :)я начинаю повtоряtься
27.11.2002
+ рабоtеt выравнивание tексtа: по ширине, по ценtру, по правому краю.
+ рабоtаюt гиперссылки
- некоtорые баги
20.11.2002
+ Вывод tексtа с авtоподгонкой и авtомасшtабированием
+ показываеt FPSы
+ жрёt музыку пракtически в любом формаtе - оt OGG и MP3 до S3M и MID - спасибо FMOD.
- некоtорые баги
12.11.2002
+ рабоtа со списками оtображения, эксtраполяция и компенсация низкой часtоtы кадров.
10.11.2002
+ живёt и дышиt, рисуеt кубик!