Hello,
I think there is a global feeling that GLdc became a good alternative for libGL...
Is there anything I can do to help merge it into kos(-ports) ?
Has there also been a general reflexion on how to integrate it -
hard break (there are some breaking changes after all) or soft transition via co-existence / conditional switch ?
I'll have some free time beginning of january, if I can help facilitate the process, please tell me...
GLdc integration into kos(-ports) - can I help ?
- T_chan
- DC Developer
- Posts: 32
- https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
- Joined: Mon Aug 22, 2011 12:45 pm
- Has thanked: 12 times
- Been thanked: 22 times
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: GLdc integration into kos(-ports) - can I help ?
Right so my thoughts on this are as follows:
- GLdc is probably ready enough to be moved into kos-ports
- It should replace libgl as the "default" GL implementation, but libgl should remain installable
- libgl shouldn't be built + installed by default, GLdc should...
- However, I don't know whether it's possible to make it switchable somehow so if someone wants to then install libgl?
- GLdc is probably ready enough to be moved into kos-ports
- It should replace libgl as the "default" GL implementation, but libgl should remain installable
- libgl shouldn't be built + installed by default, GLdc should...
- However, I don't know whether it's possible to make it switchable somehow so if someone wants to then install libgl?
- These users thanked the author kazade for the post (total 2):
- Ian Robinson • SiZiOUS
- T_chan
- DC Developer
- Posts: 32
- Joined: Mon Aug 22, 2011 12:45 pm
- Has thanked: 12 times
- Been thanked: 22 times
Re: GLdc integration into kos(-ports) - can I help ?
"Not built by default":
probably better indeed if you want to avoid to always have to regression-test both solutions...
But that means that libgl will only still work for x versions, until the changes to kos become too many to fix libgl.
Positive is to let people focus on only 1 lib, and let the past vanish quietly & silently.
"Switchable":
The libs and includes are links, so that should be easy to make switchable I suppose, eg via a small helper script if really needed.
You could also think of an extra variable in environ*.sh that (un)blocks the build with all the rest of kos/kos-ports
The examples... are more tricky:
- GLdc defines a glkos.h, libgl uses glut...
ideally there would be only 1 set of OpenGL examples, not 2...
But even if we go for 1 set of examples, some examples are not supported at all by libgl, so there would be separate folders for some examples anyways...
So not sure if it's worth the effort, I suppose it's better to just have a folder next to the kgl samples folder...
- Personal feeling - just an idea - there is some dreamcast-specific things (#ifdef) in the OpenGL (GLdc) examples...
Ideally this would be even more obfuscated,
so that people can just drop any OpengL program & it can compile for kos... or at least with very minimal effort...
But that would eg mean the usage of an extra widely used/cross-platform library for eg the pad input...
... and could be done in a later step after the merge...
(based on a very quick analysis)
probably better indeed if you want to avoid to always have to regression-test both solutions...
But that means that libgl will only still work for x versions, until the changes to kos become too many to fix libgl.
Positive is to let people focus on only 1 lib, and let the past vanish quietly & silently.
"Switchable":
The libs and includes are links, so that should be easy to make switchable I suppose, eg via a small helper script if really needed.
You could also think of an extra variable in environ*.sh that (un)blocks the build with all the rest of kos/kos-ports
The examples... are more tricky:
- GLdc defines a glkos.h, libgl uses glut...
ideally there would be only 1 set of OpenGL examples, not 2...
But even if we go for 1 set of examples, some examples are not supported at all by libgl, so there would be separate folders for some examples anyways...
So not sure if it's worth the effort, I suppose it's better to just have a folder next to the kgl samples folder...
- Personal feeling - just an idea - there is some dreamcast-specific things (#ifdef) in the OpenGL (GLdc) examples...
Ideally this would be even more obfuscated,
so that people can just drop any OpengL program & it can compile for kos... or at least with very minimal effort...
But that would eg mean the usage of an extra widely used/cross-platform library for eg the pad input...
... and could be done in a later step after the merge...
(based on a very quick analysis)
- SiZiOUS
- DC Developer
- Posts: 404
- Joined: Fri Mar 05, 2004 2:22 pm
- Location: France
- Has thanked: 27 times
- Been thanked: 19 times
- Contact:
Re: GLdc integration into kos(-ports) - can I help ?
Just wondering Kazade,
When GLdc will be integrated in kos-ports, do you will maintain/upgrade it directly in kos-ports?
I usually "transfer" the ownership of my projects as soon they are included in KOS official trunk but I wondering if really this is a "good" practice...?
When GLdc will be integrated in kos-ports, do you will maintain/upgrade it directly in kos-ports?
I usually "transfer" the ownership of my projects as soon they are included in KOS official trunk but I wondering if really this is a "good" practice...?
- BlueCrab
- The Crabby Overlord
- Posts: 5666
- Joined: Mon May 27, 2002 11:31 am
- Location: Sailing the Skies of Arcadia
- Has thanked: 9 times
- Been thanked: 69 times
- Contact:
Re: GLdc integration into kos(-ports) - can I help ?
There is no reason that things absolutely have to be in the KOS sourceforge git repository.
I would recommend that things designed for KOS specifically get mirrored there and on the KOS GitHub organization (for safe keeping), but it isn't a hard requirement by any means.
I would recommend that things designed for KOS specifically get mirrored there and on the KOS GitHub organization (for safe keeping), but it isn't a hard requirement by any means.
-
- Insane DCEmu
- Posts: 145
- Joined: Tue May 02, 2017 3:11 pm
- Has thanked: 3 times
- Been thanked: 34 times
Re: GLdc integration into kos(-ports) - can I help ?
I can certainly mirror GLdc (and ALdc) over to the KOS GitHub organisation - that's easy enough. Once I get Driving Strikers launched I'll try to sort it out.