Cheb's Game Engine

Планы, идеология, архитектура и т.п.

Модератор: Модераторы

Re: Cheb's Game Engine

Сообщение Сквозняк » 30.07.2018 20:00:02

Cheb писал(а):и, по возможности, upx

Собирал ли в линуксе, и если да, то как решал вопрос с нахождением программой каталога в которой она запущена? Я ничего лучше чем при запуске передавать пожатому upx бинарнику путь в командной строке не придумал.
Сквозняк
энтузиаст
 
Сообщения: 658
Зарегистрирован: 29.06.2006 22:08:32

Re: Cheb's Game Engine

Сообщение Cheb » 30.07.2018 20:20:21

Сначала никак не решалось - только не использовать upx.
Потом, что самое характерное, изъян в upx исправили, и стало работать банальное ExtractFilePath(ParamStr(0));
То есть, нужна современная линуксятина с вменяемым upx.
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 693
Зарегистрирован: 06.06.2005 15:54:34

Re: Cheb's Game Engine

Сообщение Сквозняк » 01.08.2018 05:36:17

Cheb писал(а):Сначала никак не решалось - только не использовать upx.

Можно решать без обновлений. Запускаешь бинарник шеллскриптом
Код: Выделить всё
#!/bin/sh
p=`(echo ${BASH_SOURCE[0]}) 2>&1`
p=${p%%:*}
d=${p%/*}
bin/./fyle $d'/' fyle
А потом в файле ловишь послание.
Сквозняк
энтузиаст
 
Сообщения: 658
Зарегистрирован: 29.06.2006 22:08:32

Re: Cheb's Game Engine

Сообщение Cheb » 01.08.2018 08:35:44

:shock: Это... Интересное решение, но для меня неприменимое. Приложение может быть, в том числе, портируемым, на уровне "пользователь должен уметь найти екзешник и тыцкнуть на него мышкой". Откуда, планируемый состав базовой поставки - только Win32, как для винды так и для линукса (подразумеваем бубунту, в которой вайн, скорей всего, уже установлен - сам я её не люблю, но вероятность найти работающие драйвера видеокарты и человека, который на этом вообще играет, гораздо выше с бубунтой или похожим дистро).

А Win64, родное линуксовое - это всё будет поддерживаться, но не прилагаться по принципу "вам эту экзотику надо - сами и компилируйте из исходников".
Отдельный готовый пакет будет только для Raspberry Pi 3.
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 693
Зарегистрирован: 06.06.2005 15:54:34

Re: Cheb's Game Engine

Сообщение Сквозняк » 01.08.2018 13:16:12

Cheb писал(а):Откуда, планируемый состав базовой поставки - только Win32

Почему? Win64 тоже ничего, я в него примерно так компилирую, из вайна батником:
Код: Выделить всё
SET PATH=c:\lazarus-1.4.4-fpc-2.6.4-win64\fpc\2.6.4\bin\x86_64-win64;%PATH%

del demo*.o
del ..\..\..\src\*.o
del ..\..\..\src\*.ppu

fpc demo15.pas -Fu../../../lib/*/x86_64-win64 -Fu../../../lib/msvcrt/x86_64 -Fu../../../headers -Fi../../../headers -Fu../../../extra -Fu../../../src -FuC:\lazarus-1.4.4-fpc-2.6.4-win64\fpc\2.6.4\units\x86_64-win64\* -TWIN64 -Px86_64 -WG -O3 -XsX -CX -Sd

Сначала wine cmd, а потом запускаешь собственно нужный батник.
Один батник для Win32, другой для Win64, запускаются из одного и того же вайна. А лазарусов в нём установлено несколько. Ставишь Win64 лазарус и получаешь в комплекте Win64 fpc, который можно так вызывать батником. И приложения с использованием лазаруса тоже так компилируются. Сложность - только написать скрипт в первый раз. Можно написать и такие шеллскрипты, которые в 64 бит линуксе по клику мышкой сами запускают вайн и компилируют под нужную платформу.
Сквозняк
энтузиаст
 
Сообщения: 658
Зарегистрирован: 29.06.2006 22:08:32

Re: Cheb's Game Engine

Сообщение Cheb » 01.08.2018 20:20:06

Поскольку сижу сейчас под виндой, то все разрядности собираются из одного .bat файла.
Проект лазаренезависимый, для компиляции нужен чистый fpc.
Код: Выделить всё
set FPC_VER=3.0.4
rem set FPC_VER=2.6.4
set COLDPATH=%PATH% 
set PATH=c:\FPC\%FPC_VER%\bin\i386-win32\;..\..\..\bin\;%COLDPATH%     

set CGE64_OPT=-Twin64 -gl -gs -gp -dcge -dnotlaz -dcge_rc_directly -Mobjfpc -Rintel
set CODE64_OPT=-O3 -Opathlon64 -CfSSE64 -Co -Cr -Ct -Sa -Sh -Sc
set MOTHER64_OPT=%CGE64_OPT% %CODE64_OPT% %THRID_PARTY_PATHS% -FE..\..\..\tmp\main-x86_64\ -FU..\..\..\tmp\main-x86_64\ -Fu..\..\..\tmp\main-x86_64\
set MOTHERDBG64_OPT=-ddebug_build -Co -Cr %CGE64_OPT% %CODE64_OPT% %THRID_PARTY_PATHS% -FE..\..\..\tmp\main-x86_64-debug\ -FU..\..\..\tmp\main-x86_64-debug\ -Fu..\..\..\tmp\main-x86_64-debug\
set DLL64_OPT=-dcgemodule -dcgehub %CGE64_OPT% %CODE64_OPT% -FU..\..\..\tmp\%MODNAME%-x86_64\ -Fu..\..\..\tmp\%MODNAME%-x86_64\

rem -a -al -Amasm -sh to get intel assembler output (but no actual exe)
set CGE32_OPT=-Twin32 -gl -gs -gp -dcge -dnotlaz -dcge_rc_directly -Mobjfpc -Rintel
set CODE32_OPT=-O3 -OpPentiumM -CfSSE2 -vq -Sa  -Sh -Sc -Xi -XX
set MOTHER32_OPT=%CGE32_OPT% %CODE32_OPT% -CX -FU..\..\..\tmp\main\ -FE..\..\..\ %THRID_PARTY_PATHS%
set MOTHERDBG32_OPT=-ddebug_build -Co -Cr -CX %CGE32_OPT% %CODE32_OPT% -FU..\..\..\tmp\main-debug\ -FE..\..\..\ %THRID_PARTY_PATHS%
set DLL32_OPT=-dcgemodule -dcgehub %CGE32_OPT% %CODE32_OPT%  -FU..\..\..\tmp\%MODNAME%\ -Fu..\..\..\tmp\%MODNAME%\


Код: Выделить всё
ppcrossx64 chentrah.lpr %MOTHER64_OPT%
if errorlevel 1 goto err
incbuild build.h
move ..\..\..\tmp\main-x86_64\chentrah.exe ..\..\..\chentrah-x86_64.exe
extractdwrflnfo-x86_64 ..\..\..\chentrah-x86_64.exe ..\bin\lineinfo\
if  "%NOSTRIP%" == "0" (
x86_64-win64-strip ..\..\..\chentrah-x86_64.exe  --verbose
upx -9 --force ..\..\..\chentrah-x86_64.exe
)
finalizedwrflnfo ..\..\..\chentrah-x86_64.exe ..\bin\lineinfo\   


Код: Выделить всё
del /Q ..\..\..\chentrah.exe
ppc386 chentrah.lpr %MOTHER32_OPT%
if errorlevel 1 goto err
incbuild build.h
extractdwrflnfo ..\..\..\chentrah.exe ..\bin\lineinfo\
if  "%NOSTRIP%" == "0" (
strip ..\..\..\chentrah.exe  --verbose
rem  --only-keep-debug --strip-unneeded
upx -9 --force ..\..\..\chentrah.exe
)
finalizedwrflnfo ..\..\..\chentrah.exe ..\bin\lineinfo\
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 693
Зарегистрирован: 06.06.2005 15:54:34

Re: Cheb's Game Engine

Сообщение Сквозняк » 02.08.2018 01:12:15

https://sourceforge.net/projects/freepascal/files/ И где мы видим Win64 fpc? Чтобы добыть его без компиляций, нужно ставить лазарус, а пользоваться потом можно одним fpc.
Сквозняк
энтузиаст
 
Сообщения: 658
Зарегистрирован: 29.06.2006 22:08:32

Re: Cheb's Game Engine

Сообщение Cheb » 02.08.2018 15:51:25

Внури раздела Win32 - разделы по версиям. Внутри раздела по версии - несколько файлов: основной win32, дополнение для кросскомпиляции под Win64 (например, https://sourceforge.net/projects/freepa ... e/download ), кросскомпиляции под arm, jvm, android... нас интересует первый.
Устанавливаешь.
Вызываешь ppcrossx64 вместо fpc.
Скрипач не нужен.

З.Ы. Теоретически, кросскомпиляция в Win64 должна работать даже из 32-разрядной ОС. Себе на заметку, попробовать потом.
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 693
Зарегистрирован: 06.06.2005 15:54:34

Re: Cheb's Game Engine

Сообщение Сквозняк » 02.08.2018 17:28:11

Коряво находясь на ПК, в 64 битной ОС компилировать в неё через кросскомпиляцию, как на арм какой-нибудь.
Сквозняк
энтузиаст
 
Сообщения: 658
Зарегистрирован: 29.06.2006 22:08:32

Re: Cheb's Game Engine

Сообщение Cheb » 02.08.2018 17:45:18

Стабильные вездеходы - это наше всё.
Работает? Работает.
Самый безгеморройный способ? Да.

плюс, я *немножечко* недолюбливаю 64-битные екзешники, поскольку фри паскаль, даже 3.0.4, *по прежнему* не умеет генерировать для них отладочную информацию stabs. Получаешь только убогий dwarf2, причём - битый, с дырами в покрытии диапазона.
Что-то там в формате не срастается, stabs не хватает диапазона адресов или что-то в этом роде, не вникал.
Факт, однако, что при работе с x86_64 имеем ~30% вероятность вместо внятного бектрейса получить голые адреса или вообще битую лабуду.

Плюс, раньше оптимизация кода (не знаю, как сейчас) под x86_64 хромала.
Плюс, меньшая стабильность 64-битных екзешников.

Так что, нет. Разработку буду вести под x86, а 64-битные версии выкачу когда игра будет готова и подходить к завершению стадии беты.

Добавлено спустя 19 минут 26 секунд:
Плюс, ещё одна причина "любить" Win64: фри паскаль так устроен, что AV в игровой DLL ловятся по нормальному только в линуксе. В виндовс-версии они бомбят насквозь, всегда приводя к crash-to-desktop. Чтобы этого избежать, потребовался мозговыносящий механизм с ручным жонглированием обработчиками исключений.
Причём, для Win32 я его отладил, кровью потом и слезами, и он работает железно.
А для Win64 - понадобился совершенно другой механизм. Я его слабал, абы было, но он хромает и глючит, и пойди ещё пойми - почему.

В качестве примера, текущее состояние движка:

x86:
<----=* ERROR! ---- (look below for details) *=---->
Found a screened exception, going BSOD...
119AFEA9h is D:chentrahtemporary-filesbin_hub.dll, base 11940000h
..file "D:chentrahtemporary-filesbin_hub.zstabs", exists=True..
found 37120 Stabs and 795 Kbytes of strings. Base 11940000h, image base 10000000h.

================== Error message: ==================

Failure in threads synchronization for render routine

Rendering subroutine failure

Call stack:
mo_logic.pp:823 (TLogic.Render) in _hub.dll
mo_threads.pp:612 (LogicDoRender) in _hub.dll
mo_threads.pp:637 (TThreadManager.CallLogicForRender) in _hub.dll
mo_module.pp:208 (TModule.Pulse) in _hub.dll
_hub.lpr:115 (Pulse) in _hub.dll
cl_module.inc:764 (TModule.Pulse) in debug-chentrah.exe
framework_basic.pp:410 (TBasicFramework.Pulse) in debug-chentrah.exe
framework_winapi.pp:1322 (TWinApiFramework.Heartbeat) in debug-chentrah.exe
framework_basic.pp:558 (TBasicFramework.MainThreadMainLoop) in debug-chentrah.exe
cl_main.inc:448 (Run) in debug-chentrah.exe
chentrah.lpr:99 ($main) in debug-chentrah.exe

Mother has passed an unhandled exception to the module in thread main thread

SEH caught C0000005h, Access Violation,
Attempt to read from the NULL address
un_fixed_font.inc:117 (FixedFont.SetRenderState) in _hub.dll

====================================================

THE MODULE HAD BEEN UNLOADED.

PRESS "SPACE BAR" TO RESTART THE MODULE,
"F12" + "BACKSPACE" TO CHOOSE ANOTHER MODULE
OR "ESC" TO EXIT THE PROGRAM.


x86_64:
<----=* ERROR! ---- (look below for details) *=---->

================== Error message: ==================

VEH caught E0465043h, (unknown code E0465043h)
at 7FEFDC3A06Dh in KERNELBASE.dll

(no debug info available: doesn't include this address range; the RTL function failed to find built-in Stabs line info)

Module logic thread #0:
VEH caught E0465043h, (unknown code E0465043h)
at 7FEFDC3A06Dh in KERNELBASE.dll

(no debug info available: doesn't include this address range; the RTLfunction failed to find built-in Stabs line info)

Failed to register class THubLogic

VEH caught E0465043h, (unknown code E0465043h)
at 7FEFDC3A06Dh in KERNELBASE.dll

(no deug info available: doesn't include this address range; the RTL function failed to find built-in Stabs line info)

VEH caught E0465043h, (unknown code E0465043h)
at 7FEFDC3A06Dh n KERNELBASE.dll

(no debug info available: doesn't include this address range; the RTL function failed to find built-in Stabs line info)

Crashed while preparing data for savin.

VEH caught C0000005h, Access Violation,

Attempt to read from 0000004D12814808h

04D12813000h..7FEDD34FFFFh (8261905652K): free;

04D12814000h..7FEDD34FFFFh (826190648K): free;

7FEDD350000h..7FEDD351000h (4K): committed by ig4icd64.dll, shared, read only.
at 0011000770Ah in _hub-x86_64.dll

(no debug info available: No valid externa files with Dwarf2 debug info found for C:windowsSYSTEM32ntdll.dll; No valid external files with Dwarf2 debug info found for C:windowssystem32KERNELBASE.dll; the RTL functio failed to find built-in Stabs line info)

VEH caught E0465043h, (unknown code E0465043h)
at 7FEFDC3A06Dh in KERNELBASE.dll

(no debug info available: doesn't include this addess range; the RTL function failed to find built-in Stabs line info)

Failed to register class THubLogic

VEH caught E0465043h, (unknown code E0465043h)
at 7FEFDC3A06Dh in KERNEBASE.dll

(no debug info available: doesn't include this address range; the RTL function failed to find built-in Stabs line info)

VEH caught E0465043h, (unknown code E0465043h) at 7FEFDC3A06Dh in KERNELBASE.dll

(no debug info available: No valid external files with Dwarf2 debug info found for C:windowsSYSTEM32ntdll.dll; No valid external files wih Dwarf2 debug info found for C:windowssystem32KERNELBASE.dll; the RTL function failed to find built-in Stabs line info)

Crashed while preparing data for saving.

EAccessViolaion: Access violation
at 0011000770Ah in _hub-x86_64.dll

(no debug info available: No valid external files with Dwarf2 debug info found for C:windowsSYSTEM32ntdll.dll; theRTL function failed to find built-in Stabs line info)

Call stack:
0011003831Eh in _hub-x86_64.dll
001100385BDh in _hub-x86_64.dll
0011004F998h in _hub-x86_64.dll
0011004E4Ah in _hub-x86_64.dll
00110057264h in _hub-x86_64.dll
001100459EBh in _hub-x86_64.dll
00110060470h in _hub-x86_64.dll
00110065647h in _hub-x86_64.dll
00110001B03h in _hb-x86_64.dll
00110060291h in _hub-x86_64.dll
0011005B382h in _hub-x86_64.dll
00110065502h in _hub-x86_64.dll
001100657FBh in _hub-x86_64.dll
00110001B74h in _hub-x86_64.ll
0011006024Ch in _hub-x86_64.dll
0011005B382h in _hub-x86_64.dll
0011009BF8Eh in _hub-x86_64.dll
0011009C255h in _hub-x86_64.dll
0011008B8BDh in _hub-x86_64.dll
0011001BA6h in _hub-x86_64.dll

VEH caught C0000005h, Access Violation,

Attempt to read from 0000004D12814808h

04D12813000h..7FEDD34FFFFh (8261905652K): free;

04D1281400h..7FEDD34FFFFh (8261905648K): free;

7FEDD350000h..7FEDD351000h (4K): committed by ig4icd64.dll, shared, read only.
at 0011000770Ah in _hub-x86_64.dll

(no debug info avilable: No valid external files with Dwarf2 debug info found for C:windowsSYSTEM32ntdll.dll; the RTL function failed to find built-in Stabs line info)

VEH caught C0000005h, Acess Violation,

Attempt to read from FFFFFFFFFFFFFFFFh


at 00077C6B766h in ntdll.dll

(no debug info available: No valid external files with Dwarf2 debug info found for CwindowsSYSTEM32ntdll.dll; the RTL function failed to find built-in Stabs line info)

Mother has passed an unhandled exception to the module in thread Module logic thread #0

VE caught C0000005h, Access Violation,

Attempt to read from 0000004D12814808h

04D12813000h..7FEDD34FFFFh (8261905652K): free;

04D12814000h..7FEDD34FFFFh (8261905648K) free;

7FEDD350000h..7FEDD351000h (4K): committed by ig4icd64.dll, shared, read only.
at 0011000770Ah in _hub-x86_64.dll

(no debug info available: ; the RTL function faied to find built-in Stabs line info)

====================================================

THE MODULE HAD BEEN UNLOADED.
PRESS "SPACE BAR" TO RESTART THE MODULE,
"F12" + "BACKSPACE" TO CHOOSE ANOTHER MODULE
OR "ESC" TO EXIT THE PROGRAM.

...бооооль :evil:

Добавлено спустя 1 час 18 минут 31 секунду:
Пы.Сы.

Я допускаю, что у 3.0.4 просто кросс-компилятор кривой, т.к. x86_64 версия, собранная фпц 2.6.4 имеет stabs, почти рабочая, и только при выходе впадает в рекурсию исключений:

<----=* ERROR! ---- (look below for details) *=---->

Found a screened exception, going BSOD...
001100A222Eh is D:\chentrah\temporary-files\bin\_hub-x86_64.dll, base 00110000000h
..file "D:\chentrah\temporary-files\bin\_hub-x86_64.zstabs", exists=True..
found 37461 Stabs and 786 Kbytes of strings. Base 00110000000h, image base 00110000000h.

================== Error message: ==================

Failure in threads synchronization for render routine

Rendering subroutine failure

Call stack:
mo_logic.pp:823 (TLogic.Render) in _hub-x86_64.dll
mo_threads.pp:612 (LogicDoRender) in _hub-x86_64.dll
mo_threads.pp:648 (TThreadManager.CallLogicForRender) in _hub-x86_64.dll
mo_module.pp:208 (TModule.Pulse) in _hub-x86_64.dll
_hub.lpr:115 (Pulse) in _hub-x86_64.dll
00000472536h in debug-chentrah-x86_64.exe
000005059ABh in debug-chentrah-x86_64.exe
00000506463h in debug-chentrah-x86_64.exe
00000479B17h in debug-chentrah-x86_64.exe
00000401A7Eh in debug-chentrah-x86_64.exe

Mother has passed an unhandled exception to the module in thread main thread

VEH caught C0000005h, Access Violation,
Attempt to read from the NULL address
at 0000041C299h in debug-chentrah-x86_64.exe
(no debug info available: doesn't include this address range; the RTL function failed to find built-in Stabs line info)

VEH caught C0000005h, Access Violation,
Attempt to read from the NULL address
un_fixed_font.inc:117 (FixedFont.SetRenderState) in _hub-x86_64.dll

====================================================
THE MODULE HAD BEEN UNLOADED.
PRESS "SPACE BAR" TO RESTART THE MODULE,
"F12" + "BACKSPACE" TO CHOOSE ANOTHER MODULE
OR "ESC" TO EXIT THE PROGRAM.
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 693
Зарегистрирован: 06.06.2005 15:54:34

Re: Cheb's Game Engine

Сообщение Cheb » 04.08.2018 00:04:22

Моя raspberry Pi 3 неработоспособна (на плате отпаялся, повиснув на ниточке, конденсатор, и после каждого выключения файловая система оказывается битая, приходится втыкать карточку в линуксовый писюк и лечить fsck ). Мне теперь надо купить новую, а жаба не даёт это сделать, не попытавшись эту заразу припаять обратно - хотя и так видно, что бесполезно: конденсатор - не больше крупинки сахара.

Достал с пыльной полки такую древность, как Raspberry Pi 2 (в комплекте: Raspbian 8, fpc 2.6.4, Lazarus 1.2.4, все свежаки 14 года) и попробовал собирать на ней. Бился с отладкой лбом об стенку пока не осознал одну простую истину: нельзя ставить оптимизацию выше -O1.
Потому что уже при -O2 компилятор начинает выкидывать как якобы ненужные вызовы процедур, которые результат своей работы пишут по указателям, полученным через тайпкасты. И всё логирование ошибок идёт фтопку.

Конкретный пример:
-O2
Нет самого главного сообщения, которое позволяет понять, что и почему (лечится вставлением пустого writeln; в одну из служебных процедур, вызываемых из специфической Die() - но откуда я знаю, *что ещё* жизненно важного оптимизатор выкинул?)
================== Error message: ==================

Failed to load the module lib_hub-armv7l.so.

Call stack:
cl_module.inc:357 (TModule___LoadMeDll) in chentrah-armv7l
cl_module.inc:123 (TModule__Load) in chentrah-armv7l
cl_module.inc:610 (TModule__Pulse) in chentrah-armv7l
framework_basic.pp:410 (TBasicFramework__Pulse) in chentrah-armv7l
cl_main.inc:448 (Run) in chentrah-armv7l
chentrah.lpr:99 ($main) in chentrah-armv7l

====================================================


-O1 -OoCSE -OoTAILREC -OoLOOPUNROLL
Всё работает как положено:
================== Error message: ==================

Failed to load the module lib_hub-armv7l.so.

dlopen() returned NULL

(/home/cheb/raid2000/chentrah/temporary-files/bin/lib_hub-armv7l.so: undefined symbol: TC_SYSTEM_ISLIBRARY)

Call stack:
cl_module.inc:357 (TModule___LoadMeDll) in chentrah-armv7l
cl_module.inc:123 (TModule__Load) in chentrah-armv7l
cl_module.inc:610 (TModule__Pulse) in chentrah-armv7l
framework_basic.pp:410 (TBasicFramework__Pulse) in chentrah-armv7l
framework_basic.pp:560 (TBasicFramework__MainThreadMainLoop) in chentrah-armv7l
cl_main.inc:448 (Run) in chentrah-armv7l
chentrah.lpr:99 ($main) in chentrah-armv7l
76C91294h in libc.so.6

====================================================


Добавлено спустя 12 часов 19 минут 13 секунд:
.. а фри паскаль 2.6.4 мне вдруг говорит человечьим голосом:
Здесь кончаются края, мне на веки верные,
Распрощаемся, друзья, здесь на веки вечные!

..короче, не умеет он генерировать не битые DLL для платформы armhf.
Ставлю на вторую малину наипоследнейший распбиан.
ИЧСХ - встаёт, собака!
Значит, с точки зрения софта вторая и третья вполне себе совместимые.

Добавлено спустя 7 часов 6 минут 17 секунд:
Собралось, запустилось. UPX воротит нос от моей дллы: "убери от меня эту бяку, она не PIC". Фпц 3.0.0 забивает на команду -Cg большой и толстый. Ну, хоть так работает.
Попутно полезли странные глюки (очень похоже, длла пытается загрузить функции OpenGL, хотя ясно сказано: GL ES!) и со строками в бектрейсах как-то совсем не весело.
Но это ладно, обнаружилась ещё засада:
Распбиан сейчас - с заводскими настройками, включающими толстые рамочки по краям экрана (для любителей старины, вестимо, чтобы аналоговый вывод на телевизор через S-Video нормально работал). Так вот, оказалось, что аппаратный сурфейс создаётся в абсолютных координатах физического экрана, игнорируя эти рамочки. Но иксы-то работают, считая, что экран на них только начинается! В результате, 3d вывод съезжает налево вверх, визуально перекрывая заголовок окна. Причём, у Minecraft Pi та же байда:
Изображение
Лол. :lol: Не знаю даже, стоит ли это пытаться чинить или забить на это.

Добавлено спустя 16 часов 31 минуту 53 секунды:
.. в общем, продолжу осенью. Сейчас на работе слишком плотно чтобы ещё на движке уматываться, да и два фанфика недописанных висят!

Для возвращения к статус кво (вращающемуся кубику) надо:
- догрести перелопачивание отрисовки текста
- реорганизовать разбросанный по всему коду зоопарк условий типа glBlend туда, glAlphaTest сюда в централизованный менеджер шейдеров
- домучить оконный менеджер для X11, чтоб работали полноэкранный режим и захват мыши
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 693
Зарегистрирован: 06.06.2005 15:54:34

Re: Cheb's Game Engine

Сообщение Сквозняк » 05.08.2018 15:08:15

Если не использовать лазарус, то это минус несколько метров от веса бинаря. Неужели и после этого бинарь такой страшный, что для игры надо использовать динамические библиотеки? Миллион фич функционала ведь написать за это время не мог.
Сквозняк
энтузиаст
 
Сообщения: 658
Зарегистрирован: 29.06.2006 22:08:32

Re: Cheb's Game Engine

Сообщение Cheb » 06.08.2018 11:16:52

См. вдоль темы взад, там где-то завалялось подробное объяснение.
TL;DR вес пофиг, вынесение в длл - это хитрое средство ускорения разработки и повышения удобства отладки (перезагрузка всего игрового кода БЕЗ потери контекста и текстур OpenGL и даже без закрытия открытых на чтение .pk3 файлов).
На моём вращающемся кубике впору писать "Look on my works, ye Mighty, and despair!", ибо в фундаменте - такая мощь, такой потенциал, такие выверты логики и кода...

З.Ы. Во время оно у меня даже был "релизный" вариант билда с игровым модулем, вкомпилируемым напрямую в екзешник. Потом бросил, слишком уж всё получалось запутанно.
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 693
Зарегистрирован: 06.06.2005 15:54:34

Re: Cheb's Game Engine

Сообщение Cheb » 10.08.2018 01:41:38

Гребу иногда помаленьку.

было:
Код: Выделить всё
  procedure TRect.Render;
  procedure RenderRect(bev: GLfloat);
  begin
    glBegin(GL_LINE_LOOP);
      glVertex2f(x + bev, y - bev);
      glVertex2f(x + Width.Current - bev, y - bev);
      glVertex2f(x + Width.Current + bev, y + bev);
      glVertex2f(x + Width.Current + bev, y + Height.Current - bev);
      glVertex2f(x + Width.Current - bev, y + Height.Current + bev);
      glVertex2f(x + bev, y + Height.Current + bev);
      glVertex2f(x - bev, y + Height.Current - bev);
      glVertex2f(x - bev, y + bev);
    glEnd();
  end;
  begin
    inherited;
    glDisable(GL_TEXTURE_2D);
    glEnable(GL_LINE_SMOOTH);
    glEnable(GL_BLEND);
    glDisable(GL_ALPHA_TEST);
    glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
    glLineWidth(RectShadeThickness());
    glColor4f(0, 0, 0, Color.Current[3]);
    RenderRect(2);
    glLineWidth(RectLineThickness());
    glColor4f(Color.Current[0]*Mother^.Display.FadeIn, Color.Current[1]*Mother^.Display.FadeIn, Color.Current[2]*Mother^.Display.FadeIn, Color.Current[3]);
    RenderRect(2);
  end; 


стало:
Код: Выделить всё
  procedure TRectControl.Render;
    procedure RenderRect(bev: GLfloat);
    var
      x0, x1, x2, x3, y0, y1, y2, y3: GLfloat;
      Mesh: TDumbUniMesh;
      c: TVector4f;
    begin
      x0:=x;
      x1:=x0 + bev;
      x3:=x + Width.Current;
      x2:=x3 - bev;
      y0:= y;
      y1:= y0 + bev;
      y3:= y + Height.Current;
      y2:= y3 - bev;
      c:= Color.Current * Mother^.Display.FadeIn;
      c[3]:= Color.Current[3];
      Mesh:= TDumbUniMesh.Create;
      Mesh.Color(c);
      Mesh.SetLineTexCoords;
      Mesh.AddLineLoop([x1, y0, x2, y0, x3, y1, x3, y2, x2, y3, x1, y3, x0, y2, x0, y1], RectShadeThickness());

      Mesh.Render;
      Mesh.Free;
    end;
  begin
    inherited;
    TGAPI.SwitchToDefaultShader(gadesh_FlatGUI);
    if HasBorder then RenderRect(2);
  end;


Упёрся в новую отрисовку текста, которая оказалась пустой затычкой. Странно, думал, что сделал полностью.
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 693
Зарегистрирован: 06.06.2005 15:54:34

Re: Cheb's Game Engine

Сообщение Cheb » 02.09.2018 12:29:50

На работе *всё ещё* завал и проект стоит - но поковырялся сегодня с утра пока солнце в монитор и невозможно бета-тестить очередной релиз брутал дума.

Сделал тяп-ляп затычку для отрисовки текста. Наконец-то длл встала и пошла! Уже можно ковыряться с логикой и гуём, где залежи говен немереные.
Вставил отлюбленную ежами glPixelStorei(GL_UNPACK_ALIGNMENT, 1); - обычная GL без этого работала, а выдранная из файрфокса GLES-поверх-DirectX делала всё строго по спецификации, и загружаемые текстуры развозило.

Добавлено спустя 10 часов 11 минут 55 секунд:
Толи лыжи не едут, толи я...
Error at startup.

Crashed trying to analyze OpenGL 2.1 quirks

Crashed trying texture formats combo texformat_Depth16 / GL_DEPTH_COMPONENT / GL_DEPTH_COMPONENT / GL_HALF_FLOAT

EInvalidOp: Invalid floating point operation
at 00007F2360B0E6F7h in nouveau_dri.so

(no debug info available: No valid external files with Dwarf2 debug info found for /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so; the RTL function failed to find built-in Stabs line info)

Call stack:
0000000000436364h in debug-chentrah-x86_64
0000000000435F89h in debug-chentrah-x86_64
000000000045CA88h in debug-chentrah-x86_64

...........................Chentrah log end


Добавлено спустя 1 час 54 минуты 28 секунд:
..короче, Фри Паскаль *жёстко* сливает x86_64: программа крашится, а место угадать невозможно, поскольку отладочная информация - полное говно, в бектрейсах - одни шестнадцатеричные сопли..

И так - для 64-битных версий под *любые* платформы, что линукс что виндовс. Stabs? Не, не слышали. Жри свой Dwarf2. Жри, %$@#!

Поскольку убунту 32-битной больше не делают, а установка 32-битного fpc на 64-битную убунту... Не, спасибо, еле ноги оттуда унёс... Так вот, установлю в виртуалке 32-битную дебиан и буду собирать линуксовую версию в ней. 32-битную! С нормальной отладкой!
Аватара пользователя
Cheb
энтузиаст
 
Сообщения: 693
Зарегистрирован: 06.06.2005 15:54:34

Пред.След.

Вернуться в Разработки на нашем сайте

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 0

Рейтинг@Mail.ru