Lazarus
Programming => Graphics and Multimedia => Games => Topic started by: turrican on January 05, 2018, 09:40:47 am
-
Hi,
I like ZenGL very much... It's very simple and well made. But has a little bugs that need to be fixed. I want to fix these bugs but I cannot do it alone.
Somebody is interested helping me to make this engine more awesome?
I'm developing a high level framework for ZenGL OOP and Event driven if you want to code fast : https://github.com/turric4n/SimpleZGL
-
Hi turrican
can you state the bugs you have found in zengl ?
-
The most annoying bug is the next one :
- ZenGL on Windows 10 (OpenGL and DirectX) FreePascal or Delphi (LCL or VCL). ignited on a handle of a form (A canvas for example).
zgl_InitToHandle(Canvas.Handle) -> This is working, but form components example a button will stop receiving messages. Will be related on ZGL mainloop Winapi and send
messages to form making it unresponsive. Related here : http://zengl.org/forum/index.php/topic,704.0.html
-
Andru started github repos for ZenGL
https://github.com/andru-kun/zengl
at least it could be used as a single place for committing patches.
-
Andru started github repos for ZenGL
https://github.com/andru-kun/zengl
at least it could be used as a single place for committing patches.
https://github.com/andru-kun/zengl/tree/0.3.x
Wow latest source Is 4 years old! I remember writing the first tutorial on the Lazarus wiki-
-
Andru started github repos for ZenGL
https://github.com/andru-kun/zengl
at least it could be used as a single place for committing patches.
https://github.com/andru-kun/zengl/tree/0.3.x
Wow latest source Is 4 years old! I remember writing the first tutorial on the Lazarus wiki-
We are ready to mantain/improve this project, I think :)
-
Скачал, посмотрел, удалил...
Я три раза!!!! ТРИ!!! Повесил систему!!!
Очень плохая наработка, которая не проверялась на других компьютерах!
Если вы хотели улучшить ZenGL и/или доработать, то это у вас не получилось.
Извиняюсь, переводить не буду, use Google translate.
Но это было полезно, теперь введу проверку при создании приложения на полный экран, чтоб не было проблем у других при случайном неверном использовании.
-
@Seenkao
Tone done please.
@turrican
I am also interested by the idea. By the way I also had created some OO framework for ZenGL some time ago.
@skalogryz
This Git repository seems to be a mirror. I guess would could ask Andrew where the current code is.
-
Скачал, посмотрел, удалил...
Я три раза!!!! ТРИ!!! Повесил систему!!!
Очень плохая наработка, которая не проверялась на других компьютерах!
Если вы хотели улучшить ZenGL и/или доработать, то это у вас не получилось.
Извиняюсь, переводить не буду, use Google translate.
Но это было полезно, теперь введу проверку при создании приложения на полный экран, чтоб не было проблем у других при случайном неверном использовании.
Пришел. Увидел. Не победил.
А зачем ты за него брался ? Есть куча других ...
-
Пришел. Увидел. Не победил.
А зачем ты за него брался ? Есть куча других ...
Я занимаюсь им, а не брался. Переработанная версия с поддержкой андроид ZenGL 3.20 уже выложена, но не в репозиториях. На русскоязычном форуме.
А эту версию проверил для себя, если бы было что интересное, то спросил бы у человека разрешения добавить в библиотеку. Но после таких глюков интерес к данной версии пропал.
Запустить эти демки я запустил.
@Seenkao
Tone done please.
Извиняюсь!!! Просто уже надоело, с такими то глюками вообще не должен был сталкиваться...
P. S. в следующей версии ZenGL невозможно будет данным способом подвесить систему.
-
Making errors is part of the process of programming. Being unfriendly about it is unfair to our human nature.
Fixing errors is a team effort: by reporting bug and finding people to fix them. We are not customers, this is free software so the only thing we can do is to be part of the team.
If you want the library to be bug free, you can contribute in this direction. But don't use the situation to let off steam.
-
Да, я тут не прав, но... (опять же видимо на себя смотрю) зачем браться не разбирая изначальный код? Сверху на ZenGL повесили очередную такую же оболочку, автоматически увеличили размер получаемого приложения, но проблем изначальных не решили.
Я занимаюсь ZenGL, но сейчас приходится больше доработками под android заниматься, так же надо сделать поддержку сохранения файлов. Понятно дело что не всех, но если мы хотим разрабатывать приложения, то надо чтоб библиотека отвечала минимальным требованиям.
Вообще я начинал разбираться с OpenGL, но наткнувшись и разобравшись с кодом ZenGL, пришлось его дорабатывать, чтоб можно было не пользоваться громадными библиотеками LCL и не тратить лишние ресурсы. Вдобавок оказалось что ZenGL может делать приложения под Android, но так же только "поверхностно" и не доработано. Пришлось дорабатывать библиотеки и их настройки.
Теперь делаю джойстики и клавиатуру, чтоб были независимыми и их можно было сразу использовать при разработке.
А тут ещё выявляются проблемы с компиляцией под Lazarus/FPC... в общем ... "бодания" со всеми проблемками поднадоели уже...
google translate:
Yes, I’m not right here, but ... (again, I’m probably looking at myself) why take it without disassembling the original code? On top of ZenGL they hung another shell of the same kind, automatically increased the size of the resulting application, but did not solve the initial problems.
I’m doing ZenGL, but now I have to do more improvements for android, I also need to make support for saving files. It’s clear that not everyone, but if we want to develop applications, we need the library to meet the minimum requirements.
In general, I started to understand OpenGL, but when I came across and figured out the ZenGL code, I had to modify it so that I could not use the huge LCL libraries and not waste extra resources. In addition, it turned out that ZenGL can make applications for Android, but also only “superficially” and has not been finalized. I had to modify the libraries and their settings.
Now I make joysticks and a keyboard so that they are independent and can be used immediately during development.
And here still problems with compilation under Lazarus / FPC come to light ... in general ... "butting" with all problems fed up already ...
ZenGL 3.20 на русском форуме.
-
I think we need a Git repository. Has someone contacted Andru already?
We can then have branches and propose changes to be reviewed by others.
-
Нет, я извиняюсь, но я не буду пользоваться репозиториями. Если есть желание, то у Andru уже были сделаны репозитории.
Я так же буду заканчивать с библиотекой ZenGL. Доделаю её до рабочего состояния и оставлю. Если есть поступающие предложения так же могу рассмотреть. Но лично я бы часть кода просто не включал в библиотеку. Как параллельные библиотеки - пожалуйста, как часть ZenGL - надо рассматривать всё что хотят включить(весь код, что предлагают), возможно переработать и после этого включить в библиотеку ZenGL.
translate:
No, I'm sorry, but I will not use the repositories. If there is a desire, then Andru has already made repositories.
I will also end up with the ZenGL library. I will finish it to working condition and leave it. If there are any proposals, I can also consider it. But personally, I would simply not include part of the code in the library. As parallel libraries - please, as part of ZenGL - you need to consider everything you want to include (all the code that they offer), it is possible to process it and then include it in the ZenGL library.
-
Why wouldn’t you want to share your improvements?
I don’t really understand what you are saying.
-
Всё останется в свободном доступе! :)
Сначала - доделываем ошибки, не выкладывая.
Когда основная часть доделана- выкладываем.
Если у кого-то есть какие-то наработки - я готов выслушать. Но не добавить! Добавить только когда уверен, что код подойдет для библиотеки. - когда эти наработки - доработаны!
ZenGL 3.20 уже выложен на русском форуме! Я продолжаю с ним работать.
translate:
Everything will remain in the public domain! :)
First, we finish the mistakes without spreading them.
When the main part is completed, lay out.
If you have any developments, I’m ready to listen. But do not add! Suitable for the library. - when these developments are finalized!
ZenGL 3.20 has already been posted on the Russian forum! I continue to work with him.
-
New version: https://yadi.sk/d/s2D7RYTuGlVagw - ZenGL 3.24
Sorry, look to Russian forum. And information in Russian... :-[
-
Hi, thanks for sharing.
I tried it on MacOS 64 bit, though it does not compile.
in zgl_log, from line 60, the {$IfDef UNIX} and {$IFDEF MACOSX} directive are both active. This can be solved by merging then:
{$IfDef UNIX}
{$IFDEF MACOSX}
if not Assigned(logFile) Then
logFile := utf8_GetPAnsiChar(appWorkDir + '../log.txt')
{$ELSE}
if not Assigned(logFile) Then
logFile := utf8_GetPAnsiChar('log.txt')
{$ENDIF}
{$ENDIF}
Then there are missing functions in FreePascal and I don't know what to do.
In zgl_utils, on line 498, the StandardAlert function is used. It seems to be in MacWindows unit but adding it doesn't help because the function is included only for 32bit system.
Same problem in zgl_windows, on line 163, the functions SelectWindow and ShowWindow are not available.
-
for macos 64-bit try this zengl (https://github.com/skalogryz/zengl) fork
Even though the fork might compile it's outdated from Apple perspective.
For audio a deprecated API is used.
OpenGL/OpenGLES is still in used and Metal implementation is required.
-
Same problem in zgl_windows, on line 163, the functions SelectWindow and ShowWindow are not available.
project parameters:
operating system -> Darwin (not MacOS!!!!)
processor family -> x86_64
try and please tell me the result
If you check the demo versions, then use "demoN" but not "demoN_macosx" (as a recommendation :-[ ) and also report the result.
Sorry, google translate...
-
OpenGL/OpenGLES is still in used and Metal implementation is required.
Нет, не отказались от OpenGL ES, но в ZenGL используется эмулируемая часть OpenGL ES, точнее версия 1.0.
google translate:
No, they did not abandon OpenGL ES, but ZenGL uses the emulated part of OpenGL ES, more precisely version 1.0.
-
Нет, не отказались от OpenGL ES, но в ZenGL используется эмулируемая часть OpenGL ES, точнее версия 1.0.
I'm referring to Apple. macOS and iOS still support OpenGL/OpenGLES supported applications.
Yet, Apple suggests that Metal should be used.
I do have a ZenGL game published on AppStore. (it was not a success), but the Apple has not removed it yet from the Apple store due to the use of outdated APIs.
Yet, I think Apple will require me to update API use, if I try to release another version of the game.
-
Да, вероятнее всего вы правы. Но OpenGL ES не показывается на их сайте сейчас в числе устаревших.
Но требовать они будут Metal.
google translate:
Yes, you are most likely right. But OpenGL EU is not showing up on their website now as outdated.
But they will demand Metal.
-
project parameters:
operating system -> Darwin (not MacOS!!!!)
processor family -> x86_64
try and please tell me the result
If you check the demo versions, then use "demoN" but not "demoN_macosx" (as a recommendation :-[ ) and also report the result.
Same error in all cases.
for macos 64-bit try this zengl (https://github.com/skalogryz/zengl) fork
It does not find DMGetGDeviceByDisplayID used in zgl_opengl. It seems to be in Displays unit but not available on 64 bit CPU.
About OpenGL, it still works on iMac 64 bit.
-
https://youtu.be/5Uz-TvmTn7Y - this is how it looks for me.
Possible Solution: in zgl_config.cfg
// macOS ???
{$IFDEF MacOSAll}
{$DEFINE MACOSX}
{$ENDIF}
but I do not know what the result will be for other computers and not only.
(но я не знаю какой будет результат для других компьютеров и не только)
-
Yeah I understand. I tried it but the problem is in the FreePascal library.
I am using Lazarus 2.0.10 with FPC 3.2.0. Maybe it was fixed in trunk?
Below the code in the files. In MacWindows, a directive deactivates the code.
-
to check, write this define (if this define...)
именно для 64-х битных систем
specifically for 64 bit systems (google translate)
apparently it is not spelled out somewhere or is disabled for something
... вообще странные танцы с бубном...
emulator MacOS?
-
circular,
http://zengl.org/wiki/doku.php?id=compilation:ios
http://zengl.org/wiki/doku.php?id=compilation:basics
take a look, maybe it will be useful.
-
It does not find DMGetGDeviceByDisplayID used in zgl_opengl. It seems to be in Displays unit but not available on 64 bit CPU.
I take this back now.
I didn't update it to be macOS 64 bit compatible. I only made it to work for iOS 64-bit
ZenGL for macOS was written using Carbon. it needs to be updated to use Cocoa (AppKit)
iOS application was written using UIKit already.
About OpenGL, it still works on iMac 64 bit.
Sure it does. But the question is IF Apple accepts applications written with OpenGL use to their AppStore.
-
Attention!!!!
In Unix-system, in non-LCL in the launched module, you must set:
uses
{$IfDef UNIX}
cthreads
{$EndIF}