Комментарии 36
Мне бы тоже было бы крайне обидно. Но могу сказать, что получилось очень даже годно =) А это отличный результат =)
У вас ещё 35 килобайт «свободных» осталось, впечатляет. Похоже, можно добавить фон, препятствия и «прокачку», да ещё килобайт 15 останется)
Самый прикол что у меня на компьютере со встроенной видюхой тоже не видно танков. Любопытно.
Странно, потому что разрабатывалось в основном как раз на встроенной Intel. Если не трудно — скиньте лог, который появляется рядом с ехе. Можно в личку скопировать, он небольшой
Скриншот:
Лог чистый:
Мобыть конечно дело в WinXP, но фиг его знает.
Скрытый текст
Лог чистый:
Скрытый текст
:: Start. Tiny glr version: 0.1 :: stable
:: FileSystem: pack files found at "": 0
:: Graphics information
Vendor: Intel
Renderer: Intel® HD Graphics
OpenGL: 3.1.0 — Build 6.14.10.5415
GLSL: 1.40 — Intel Build 6.14.10.5415
:: FileSystem: start reading resource «default assets/SpriteShaderV.txt» directly from file
:: FileSystem: read successfully
:: FileSystem: start reading resource «default assets/SpriteShaderF.txt» directly from file
:: FileSystem: read successfully
:: Texture (ID = 1) load started
:: Texture (ID = 1) load completed
:: Initialize completed
:: FileSystem: start reading LZO resource «shooter/font.bmp» directly from file
:: FileSystem: read successfully
:: Texture (ID = 2) load started
:: Texture (ID = 2) load completed
:: Texture (ID = 3) load started
:: Texture (ID = 3) load completed
:: Appication loop started
:: Appication loop finished
:: End. Errors: 0, warnings: 0
:: FileSystem: pack files found at "": 0
:: Graphics information
Vendor: Intel
Renderer: Intel® HD Graphics
OpenGL: 3.1.0 — Build 6.14.10.5415
GLSL: 1.40 — Intel Build 6.14.10.5415
:: FileSystem: start reading resource «default assets/SpriteShaderV.txt» directly from file
:: FileSystem: read successfully
:: FileSystem: start reading resource «default assets/SpriteShaderF.txt» directly from file
:: FileSystem: read successfully
:: Texture (ID = 1) load started
:: Texture (ID = 1) load completed
:: Initialize completed
:: FileSystem: start reading LZO resource «shooter/font.bmp» directly from file
:: FileSystem: read successfully
:: Texture (ID = 2) load started
:: Texture (ID = 2) load completed
:: Texture (ID = 3) load started
:: Texture (ID = 3) load completed
:: Appication loop started
:: Appication loop finished
:: End. Errors: 0, warnings: 0
Мобыть конечно дело в WinXP, но фиг его знает.
«А в моем случае один буфер используется несколько раз за кадр.» Да, это вы зря, с таким подходом может быть масса проблем. Лучший вариант конечно делать один Draw на кадр если вершинная декларация позволяет и использовать один большой буфер в который в конец дописывать свои вершины.
Привет Daemon! Добро пожаловать на Хабр!
Динамика хороша. Лучше, чем в многих современных гигабайтных играх.
Вы молодец! Судя по видео, игра получилась даже интереснее некоторых своих полноразмерных аналогов.
Классно, но не понял, почему шрифт занимает так много? На скрине картинка 256*128 = 32768 пикселей, в режиме 1 бит на пиксель это всего 4 килобайта.
Когда делал в школе игры под дос, точно так же поступал — писал виндовую утилиту для генерации растровых шрифтов. Только хранил символы 8х16 пикселей отдельно, а не целой картинкой.
Когда делал в школе игры под дос, точно так же поступал — писал виндовую утилиту для генерации растровых шрифтов. Только хранил символы 8х16 пикселей отдельно, а не целой картинкой.
Паскалевская процедура на ассемблере
Procedure PutChar32(X,Y,C,S:DWord; Symbol:Char);Assembler;
Var
DX1: DWord;
Asm
Mov Esi, pFont
Movzx Eax, Symbol
Shl Eax, 4
Add Esi, Eax {Char bitmap}
Mov Edi, LFBMem
Mov Eax, Y
Mul ScreenSX
Add Eax, X
Shl Eax, 2{<>}
Add Edi, Eax
Mov Eax, ScreenSX
Sub Eax, 8
Shl Eax, 2{<>}
Mov DX1, Eax
Xor Ecx, Ecx
Xor Eax, Eax
Mov Cl, 16
@NextTex:
Mov Ebx, 128
LodsB
Mov Bh, Al
Mov Ch, 8
ALIGN 4
@NextDot:
Mov Dl, Bh
And Dl, Bl
Cmp Dl, 0
Je Skip
Mov Eax, C
StosD
Sub Edi, 4
Skip:
Add Edi, 4
Shr Bl, 1
Dec Ch; Jnz @NextDot
Add Edi, DX1
Dec Cl; Jnz @NextTex
{}
End;
Var
DX1: DWord;
Asm
Mov Esi, pFont
Movzx Eax, Symbol
Shl Eax, 4
Add Esi, Eax {Char bitmap}
Mov Edi, LFBMem
Mov Eax, Y
Mul ScreenSX
Add Eax, X
Shl Eax, 2{<>}
Add Edi, Eax
Mov Eax, ScreenSX
Sub Eax, 8
Shl Eax, 2{<>}
Mov DX1, Eax
Xor Ecx, Ecx
Xor Eax, Eax
Mov Cl, 16
@NextTex:
Mov Ebx, 128
LodsB
Mov Bh, Al
Mov Ch, 8
ALIGN 4
@NextDot:
Mov Dl, Bh
And Dl, Bl
Cmp Dl, 0
Je Skip
Mov Eax, C
StosD
Sub Edi, 4
Skip:
Add Edi, 4
Shr Bl, 1
Dec Ch; Jnz @NextDot
Add Edi, DX1
Dec Cl; Jnz @NextTex
{}
End;
Хабраюзер «Skip» незаметно затесался в Ваши исходники.
Пишется полноценный битмап в rgba, соответственно 4 байта на пиксель, RGB — всегда ffffff, альфа варьируется. Очень нерационально, верно. Как минимум, надо отрезать RGB, оставлять только альфу. Утилиту планируется научить всяким эффектам, в том числе цветовым, поэтому изначально писалось с полным хранением RGB. Переписывать под конкурс не было времени.
И как я отметил в посте, намного меньше по размеру была бы генерация на лету. Может быть даже меньше чем хранение битовой маски.
И как я отметил в посте, намного меньше по размеру была бы генерация на лету. Может быть даже меньше чем хранение битовой маски.
Ох, на меня нахлынула лютая ностальгия в комплекте с дежавю :)
Когда-то в 2008 году писал похожую игру на конкурс, проводимый mirgames.ru, только ограничение там было более жесткое — не более 64 кб. В итоге у меня родился Crimsonland-подобный топдаун-шутер с итоговым весом сжатого бинарника в 49 кб. Вкратце: жестко заточенный под конкретную эту игру «фреймворк», юзающий OpenGL для графики, DirectSound для звука, и WinAPI для генерации текстур шрифтов и всего остального. Также в игре присутствует полноценная пиксельная графика, честно украденная из древней DOS-игры (+часть графики генерируется при старте) и звуки. Звуки в итоге и занимают большую часть места, без них и без звукового движка игра весила бы по крайней мере в 2 раза меньше. Использовался Delphi 2007, в качестве упаковщика — 20to4 + UPack. В общем-то, приложив некоторое количество усилий, игру можно было бы еще уменьшить по крайней мере раза 2, но смысла возиться с этим я не видел — игра и так влезала в 64кб с большим запасом.
Позже еще добавил трекерную музыку в XM через MiniFMOD, сжатый бинарник стал весить 110 кб (.xm с музыкой был довольно жирный — 99кб).
Игру также постигла аналогичная вашей проблема — на половине видеокарт от ATI игра упорно падала при старте сурвайвала. Как оказалось, render-to-texture на ATI тогда работал очень хреново, потому я в срочном порядке заменил рендеринг в текстуру на тупой glReadPixels, и все стало работать везде, но… часть голосов я из-за этого тогда тоже недополучил. Но 2 место таки взял %)
Ну и если кому интересно:
Архив с исходниками+бинарниками:
www.dropbox.com/s/q87s3rq8r2g8wm3/extinction.zip?dl=0
(К сожалению, исходников последней версии c музыкой не нашел, сохранился только бинарник. Но вроде бы разница только в отсутствии в исходниках поддержки музыки.)
Когда-то в 2008 году писал похожую игру на конкурс, проводимый mirgames.ru, только ограничение там было более жесткое — не более 64 кб. В итоге у меня родился Crimsonland-подобный топдаун-шутер с итоговым весом сжатого бинарника в 49 кб. Вкратце: жестко заточенный под конкретную эту игру «фреймворк», юзающий OpenGL для графики, DirectSound для звука, и WinAPI для генерации текстур шрифтов и всего остального. Также в игре присутствует полноценная пиксельная графика, честно украденная из древней DOS-игры (+часть графики генерируется при старте) и звуки. Звуки в итоге и занимают большую часть места, без них и без звукового движка игра весила бы по крайней мере в 2 раза меньше. Использовался Delphi 2007, в качестве упаковщика — 20to4 + UPack. В общем-то, приложив некоторое количество усилий, игру можно было бы еще уменьшить по крайней мере раза 2, но смысла возиться с этим я не видел — игра и так влезала в 64кб с большим запасом.
Позже еще добавил трекерную музыку в XM через MiniFMOD, сжатый бинарник стал весить 110 кб (.xm с музыкой был довольно жирный — 99кб).
Игру также постигла аналогичная вашей проблема — на половине видеокарт от ATI игра упорно падала при старте сурвайвала. Как оказалось, render-to-texture на ATI тогда работал очень хреново, потому я в срочном порядке заменил рендеринг в текстуру на тупой glReadPixels, и все стало работать везде, но… часть голосов я из-за этого тогда тоже недополучил. Но 2 место таки взял %)
Ну и если кому интересно:
Архив с исходниками+бинарниками:
www.dropbox.com/s/q87s3rq8r2g8wm3/extinction.zip?dl=0
(К сожалению, исходников последней версии c музыкой не нашел, сохранился только бинарник. Но вроде бы разница только в отсутствии в исходниках поддержки музыки.)
Приглашаем Вас принять участие с Вашей игрой в конкурсе игр для KolibriOS: habrahabr.ru/company/kolibrios/blog/243081/
Боюсь, я не настолько хорош, чтобы осилить такое шаманство :)
Как обстоят дела с у KolibriOS с OpenGL? Только TinyGL и Mesa?
Как обстоят дела с у KolibriOS с OpenGL? Только TinyGL и Mesa?
Есть TinyGL, SDL 1.2.2 и Mesa. Ну и сам FreePascal тоже есть: board.kolibrios.org/viewtopic.php?f=33&t=1020
115кб? Когда-то люди Элиту в 48кб запихивали, а тут 115! А если серьёзно — молодец! Я уже очень давно ушел из программирования, оценить качество работы не могу. Но сам факт старания и стремления… Большинство кодеров давно уже забыли, что такое килобайты, оптимизация и скорость.
Спасибо! Стремление к минимизации пришло от просмотра товарища XProger. Хотя мне до его трехмерного шутера void в 27 килобайт все еще очень далеко :) Который, кстати, на Delphi.
Скриншоты
Ой ну пиристань… у тебя то геймплей есть, молодец! :)
А где можно потрогать этот void?
Тут, но антивирус может ругаться на пожатые exe. Исходники идут в архиве, так что можно пересобрать самому в Delphi начиная с 2006 версии.
НЛО прилетело и опубликовало эту надпись здесь
Перфектно, молодца :)
На будущее, для подобных проектов: есть метод для получения сверхкомпактных .exe (от 1 кб) для Windows, предложенный Максом Феоктистовым (автором Small HTTP Server) на основе компилятора DJGPP, заточенного для генерации .exe, и собственного PE-линкера для Windows. Всё это опубликовано у него на сайте.
smallsrv.com/mkpe/ (если не откроется, есть в кэше гугле)
Мне удалось прикрутить генерацию .exe данным способом к мультитаргетной среде разработки XDev. Вот пример сверхкомпактной оконной программы с исходниками на языке Оберон-2 (для 32 и 64 бит соответственно):
zx.oberon2.ru/forum/viewtopic.php?f=32&t=189#p1180
Раз предпочитаете Дельфи, а не Си, то, возможно, стоит попробовать для разработки компактных игр паскалеподобный Оберон. Если решитесь осваивать — потребует времени на примеривание, разработку биндингов. Но потраченные усилия обязательно окупятся — ведь на XDev можно делать программы не только для Win32/64, но и для Linux, Java microedition и ретро-платформ — DOS, MSX, ZX Spectrum. Если интересно, приходите на форум, будем общаться. :)
Сейчас портирую на Оберон некоторые игры с ZX Spectrum и DOS, например:
Bolder Dash (Владимир Мутель, Turbo C 2.0, DOS): zx.oberon2.ru/dash.htm
Дурак (Вячеслав Медноногов, Laser Basic, ZX Spectrum): zx.oberon2.ru/durak.htm
Dark Woods (Jocke The Beast, Quick Basic 4.5, DOS, no sources (реверс инжиниринг)): zx.oberon2.ru/forum/viewforum.php?f=26
Кто-то игры делает, кто-то портирует. Смысл моей работы по портированию — прояснить алгоритмы, вывести их из малопонятного сильно заточенного под платформу или среду разработки вида в сторону мультиплатформенности. Конечный размер игр (их версий для Спектрума) не может превышать 42 кб даже без упаковки — этот лимит продиктован адресным пространством Спектрума (16 кб занято ПЗУ + 6 кб экранная память; страницами 128 кб-моделей я не пользуюсь). Для Windows (методом Феоктистова) — размер ненамного больше (а с UPX — значительно меньше), просто я сейчас использую для вывода графики библиотеку SDL, а разработка графического движка на WinAPI — только в проекте. uFMOD — отличная библиотека, спасибо за наводку! :)
На будущее, для подобных проектов: есть метод для получения сверхкомпактных .exe (от 1 кб) для Windows, предложенный Максом Феоктистовым (автором Small HTTP Server) на основе компилятора DJGPP, заточенного для генерации .exe, и собственного PE-линкера для Windows. Всё это опубликовано у него на сайте.
smallsrv.com/mkpe/ (если не откроется, есть в кэше гугле)
Мне удалось прикрутить генерацию .exe данным способом к мультитаргетной среде разработки XDev. Вот пример сверхкомпактной оконной программы с исходниками на языке Оберон-2 (для 32 и 64 бит соответственно):
zx.oberon2.ru/forum/viewtopic.php?f=32&t=189#p1180
Раз предпочитаете Дельфи, а не Си, то, возможно, стоит попробовать для разработки компактных игр паскалеподобный Оберон. Если решитесь осваивать — потребует времени на примеривание, разработку биндингов. Но потраченные усилия обязательно окупятся — ведь на XDev можно делать программы не только для Win32/64, но и для Linux, Java microedition и ретро-платформ — DOS, MSX, ZX Spectrum. Если интересно, приходите на форум, будем общаться. :)
Сейчас портирую на Оберон некоторые игры с ZX Spectrum и DOS, например:
Bolder Dash (Владимир Мутель, Turbo C 2.0, DOS): zx.oberon2.ru/dash.htm
Дурак (Вячеслав Медноногов, Laser Basic, ZX Spectrum): zx.oberon2.ru/durak.htm
Dark Woods (Jocke The Beast, Quick Basic 4.5, DOS, no sources (реверс инжиниринг)): zx.oberon2.ru/forum/viewforum.php?f=26
Кто-то игры делает, кто-то портирует. Смысл моей работы по портированию — прояснить алгоритмы, вывести их из малопонятного сильно заточенного под платформу или среду разработки вида в сторону мультиплатформенности. Конечный размер игр (их версий для Спектрума) не может превышать 42 кб даже без упаковки — этот лимит продиктован адресным пространством Спектрума (16 кб занято ПЗУ + 6 кб экранная память; страницами 128 кб-моделей я не пользуюсь). Для Windows (методом Феоктистова) — размер ненамного больше (а с UPX — значительно меньше), просто я сейчас использую для вывода графики библиотеку SDL, а разработка графического движка на WinAPI — только в проекте. uFMOD — отличная библиотека, спасибо за наводку! :)
Не подскажете, насколько важен именно DJGPP в методе Макса Феоктистова? Gcc из DJGPP не хочет запускаться на Win7 x64…
В методе Макса Феоктистова DJGPP занимает ключевую роль. Я использую его для получения сверхмалого размера EXE, но сам Макс писал мне что разработал свой линкер исключительно для производства виндовых приложений в то время когда GCC ещё не умел их генерировать (а MINGW ещё не было), и сегодня Макс советует использовать вместо DJGPP и его линкера CygWin или MINGW. Я ещё использую tcc (Tiny C), который умеет генерировать 32- и 64-битный код для Windows и Linux: для небольших приложений код получается достаточно компактным, но конечно не настолько, как по методу Макса. Для бОльших приложений MINGW выигрывает и по размеру кода, и по быстродействию.
DJGPP является программой для DOS, поэтому и не работает под x64. Если хотите, можно попробовать написать батник, который будет вызывать его с помощью DOSBox. У меня в XDev/DosDev подобным образом вызывается Turbo C:
github.com/Oleg-N-Cher/XDev/blob/master/DosDev/Bin/compile.bat
github.com/Oleg-N-Cher/XDev/blob/master/DosDev/Bin/build.bat
Или же используйте виртуальную 32-битную Windows внутри 64-битной.
Вам могут понадобиться заголовочные файлы DJGPP для WinAPI. Можно взять из MINGW (правда, их придётся модифицировать, всё-таки DJGPP 2.95 это старая версия GCC). Или воспользуйтесь этим:
github.com/Oleg-N-Cher/XDev/blob/master/WinDev/Lib/C/WinApi.h
(безошибочность не гарантируется, я делал этот биндинг сам)
DJGPP является программой для DOS, поэтому и не работает под x64. Если хотите, можно попробовать написать батник, который будет вызывать его с помощью DOSBox. У меня в XDev/DosDev подобным образом вызывается Turbo C:
github.com/Oleg-N-Cher/XDev/blob/master/DosDev/Bin/compile.bat
github.com/Oleg-N-Cher/XDev/blob/master/DosDev/Bin/build.bat
Или же используйте виртуальную 32-битную Windows внутри 64-битной.
Вам могут понадобиться заголовочные файлы DJGPP для WinAPI. Можно взять из MINGW (правда, их придётся модифицировать, всё-таки DJGPP 2.95 это старая версия GCC). Или воспользуйтесь этим:
github.com/Oleg-N-Cher/XDev/blob/master/WinDev/Lib/C/WinApi.h
(безошибочность не гарантируется, я делал этот биндинг сам)
У меня тоже стоит цель получения сверхмалого ЕХЕ. Сейчас собираю с помощью mingw, после UPX размер 30к. Только TCC мне не помогает. Увидел от него профит только на маленьких приложениях, которые используют stdlib. У меня же чистый WinAPI (-nostdlib, -nostartfiles), так что на ТСС получается и жирнее и медленнее.
Значит, скорее всего какого-то значительного уменьшения ЕХЕ-файла при использовании DJGPP мне можно не ждать?
Значит, скорее всего какого-то значительного уменьшения ЕХЕ-файла при использовании DJGPP мне можно не ждать?
Выигрыш в сравнении с MINGW будет. Но чудес конечно не ждите. Смотрите:
zx.oberon2.ru/forum/viewtopic.php?f=32&t=189&p=1385#p1180
Приложенный в архиве файл MoveWindow.exe занимает, как видите, 3 кб. Что он умеет делать — смотрите в исходнике MoveWindow.Mod и сопоставляйте со своими нуждами. Как по мне — добиться меньшего размера EXE, чем с помощью метода Макса Феоктистова, просто невозможно. Если знаете как — напишите, интересно.
Я бы планировал обязательное уменьшение вашего EXE-шника при переходе от MINGW к DJGPP килобайта на 4 (минимум) до 10-16 (максимум). В пожатом UPX виде разница конечно будет не столь значительная.
Также на простую пересборку вашего кода DJGPP я бы не расчитывал. Скорее всего придётся допиливать и биндинги к API, и код.
Так что думайте, стоит ли овчинка выделки.
zx.oberon2.ru/forum/viewtopic.php?f=32&t=189&p=1385#p1180
Приложенный в архиве файл MoveWindow.exe занимает, как видите, 3 кб. Что он умеет делать — смотрите в исходнике MoveWindow.Mod и сопоставляйте со своими нуждами. Как по мне — добиться меньшего размера EXE, чем с помощью метода Макса Феоктистова, просто невозможно. Если знаете как — напишите, интересно.
Я бы планировал обязательное уменьшение вашего EXE-шника при переходе от MINGW к DJGPP килобайта на 4 (минимум) до 10-16 (максимум). В пожатом UPX виде разница конечно будет не столь значительная.
Также на простую пересборку вашего кода DJGPP я бы не расчитывал. Скорее всего придётся допиливать и биндинги к API, и код.
Так что думайте, стоит ли овчинка выделки.
Не, наверное есть ещё способ добиться сверхмалого размера EXE с помощью Sphinx C-- (Michael Sheker), но это будет не Си, а Си-минус-минус, к которому переходить от готового кода на Си смысла мало, лучше писать сразу на минусах.
www.sheker.chat.ru/
Можно составить мнение о языке Си-минус-минус по статье «Sphinx C-- — язык не для всех»:
www.sheker.chat.ru/c--part1.rar
www.sheker.chat.ru/c--part2.rar
Проект давно не развивается.
www.sheker.chat.ru/
Можно составить мнение о языке Си-минус-минус по статье «Sphinx C-- — язык не для всех»:
www.sheker.chat.ru/c--part1.rar
www.sheker.chat.ru/c--part2.rar
Проект давно не развивается.
Шрифт-мейкер дофига похож на тот, что идет в комплекте с ZenGL — и то и то основано на одном и том же?
Принцип генерации и упаковки шрифта в растр практически у всех движков един, отсюда видимо и схожесть интерфейса. Тут сложно придумать что-то новое.
И мой фреймворк, и ZenGL написаны на Free Pascal + Lazarus. Оба рендерят через OpenGL. На этом сходства заканчиваются. Так что в какой-то степени, Да, основаны на одном и том же
И мой фреймворк, и ZenGL написаны на Free Pascal + Lazarus. Оба рендерят через OpenGL. На этом сходства заканчиваются. Так что в какой-то степени, Да, основаны на одном и том же
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка игры в 115 кб — хаки, баги и досада