3D standards questions
  • Yokemate of Keyboards
    Yokemate of Keyboards
    amigadave
    Posts: 2561 from 2006/3/21
    From: Lake Arrowhead...
    I admit that my knowledge of 3D graphics standards, such as OpenGL, of which MorphOS supports a small amount of with something called "TinyGL", is very weak, and my understanding of programming in general is not much better (or is it worse?), so forgive me if any of these questions don't make any sense, or are very naive.

    I'll assume that supporting a subset of OpenGL was chosen because its documentation is public knowledge, and DirectX versions probably are not (please correct me if I am wrong). I'll also assume that TinyGL was created, because of some limitations of MorphOS which prevent, or make it difficult to completely support even some of the older versions of OpenGL. Or is TinyGL limited because the work to support a complete version of OpenGL just too much work for the one or two developers who probably created TinyGL?

    Is there likely to be any updates to TinyGL, or is it more likely that new graphic improvements for MorphOS will come in the form of SDL updates (I know nothing about SDL either)?

    Is there zero chance that MorphOS will ever get any type of DirectX support, that would allow old games to be ported to MorphOS (like DirectX v9, or even earlier versions)? The one game I currently enjoy playing uses DirectX v12 I believe, it's an old 2012 game that used an even older game engine I think.

    I know that the programmer (Daniel, can't remember his last name atm)who has ported some recent games to AmigaOS4.x, AROS, and MorphOS, uses his own custom graphics tricks and tools, to help speed up and improve graphics display of ported games. Is there any chance that MorphOS will get any new tools, library's, translation layers, MUI classes, etc. that will improve our chances to more easily port games, and other graphical programs to MorphOS from Linux, or even Windows?

    To put it more simply, what is the general outlook for porting games and programs to MorphOS that require 3D support to work, and is there anything that can be done to improve the current situation? What would it take to make porting newer stuff possible, and writing new games and programs natively for MorphOS able to use newer 3D standards?

    If Bigfoot is going to spend his free coding time giving us better video card drivers, it sure would be nice to take advantage of the increased 3D power & speed, with newer games and programs, using newer 3D standards.
    MorphOS - The best Next Gen Amiga choice.
  • »02.03.19 - 03:10
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    BSzili
    Posts: 471 from 2012/6/8
    From: Hungary
    When you are using OpenGL with SDL you are still using TinyGL.
    I see the jimmies have been rustled.
  • »02.03.19 - 10:08
    Profile Visit Website
  • Order of the Butterfly
    Order of the Butterfly
    beworld
    Posts: 263 from 2010/2/10
    From: FRANCE
    Hi BSzilli ! and others !

    Any chance to view update for SDL2, SDL2_mixer etc... ?
    with any 3D support (same as AOS 4)

    Thanks
    PowerMac 2.7ghz MOS 3.10
    PowerBook 1.5Ghz MOS 3.10
    My MOS ports
  • »02.03.19 - 16:18
    Profile Visit Website
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 10448 from 2003/5/22
    From: Germany
    > I'll assume that supporting a subset of OpenGL was chosen
    > because its documentation is public knowledge, and DirectX
    > versions probably are not (please correct me if I am wrong).

    Direct3D API is openly documented as well, else you couldn't easily write programs that use it. Reason for implementing (subset of) OpenGL over Direct3D was most likely that OpenGL has always been on all platforms including Windows whereas Direct3D is a Windows-only thing.

    > Is there likely to be any updates to TinyGL

    Latest TinyGL updates are as recent as MorphOS 3.10. It's not unlikely that MorphOS 3.12 will contain further updates.

    > or is it more likely that new graphic improvements for MorphOS
    > will come in the form of SDL updates [...]?

    SDL does not contain a 3D graphics API so must be combined with an existing 3D API like OpenGL. Besides, MorphOS itself does not contain SDL (PowerSDL has been a 3rd party download so far).

    > is there anything that can be done to improve the current situation? What
    > would it take to make porting newer stuff possible, and writing new games
    > and programs natively for MorphOS able to use newer 3D standards?

    Simple: implement a recent OpenGL version ;-) AROS for instance has OpenGL 4.3 (through Mesa 12), and A-Eon's approach for OS4 (Warp3D Nova + OpenGL ES 2 + GL4ES/EGL, effectively giving OpenGL 2.1) is better than nothing.

    > If Bigfoot is going to spend his free coding time giving us better video card
    > drivers, it sure would be nice to take advantage of the increased 3D power
    > & speed, with newer games and programs, using newer 3D standards.

    Absolutely. Part of the problem may be kiero's limited availability.

    https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=12010&forum=3
    https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=11947&forum=49
    https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=12368&forum=3&start=18
    https://morph.zone/modules/newbb_plus/viewtopic.php?topic_id=11770&forum=32&start=33
  • »02.03.19 - 16:58
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    BSzili
    Posts: 471 from 2012/6/8
    From: Hungary
    Quote:

    beworld wrote:
    Hi BSzilli ! and others !

    Any chance to view update for SDL2, SDL2_mixer etc... ?
    with any 3D support (same as AOS 4)

    Thanks


    I'd be interested in updating it (I made small contributions to the OS4 SDL2 port), but only itix has the source code for PowerSDL2.
    I see the jimmies have been rustled.
  • »02.03.19 - 19:11
    Profile Visit Website
  • Paladin of the Pegasos
    Paladin of the Pegasos
    Papiosaur
    Posts: 1212 from 2003/4/10
    From: France
    It will be excellent for MorphOS users to have SDL2!

    BeWorld and others devs could be ports many news games!

    Thanks for your proposition:

    I hope Itix would like share his code.
  • »03.03.19 - 06:50
    Profile Visit Website
  • Order of the Butterfly
    Order of the Butterfly
    beworld
    Posts: 263 from 2010/2/10
    From: FRANCE
    Yes, there no more game in SDL 1.2.....

    Itix if you hear us :-)

    [ Edité par beworld 04.03.2019 - 19:38 ]
    PowerMac 2.7ghz MOS 3.10
    PowerBook 1.5Ghz MOS 3.10
    My MOS ports
  • »03.03.19 - 08:04
    Profile Visit Website
  • Yokemate of Keyboards
    Yokemate of Keyboards
    amigadave
    Posts: 2561 from 2006/3/21
    From: Lake Arrowhead...
    Thank you Andreas_Wolf, for the simple and straight forward answers to many of my questions. Your answers cleared up a lot of misconceptions I had on this topic.
    MorphOS - The best Next Gen Amiga choice.
  • »07.03.19 - 16:02
    Profile
  • Priest of the Order of the Butterfly
    Priest of the Order of the Butterfly
    KennyR
    Posts: 636 from 2003/3/4
    From: #AmigaZeux, Gu...
    Just a heads up: SDL's use seems to have declined greatly in the last 10 years. Unity and libgdx are more likely to see FOSS games developed for them.
  • »07.03.19 - 16:08
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    BSzili
    Posts: 471 from 2012/6/8
    From: Hungary
    Quote:

    KennyR wrote:
    Just a heads up: SDL's use seems to have declined greatly in the last 10 years. Unity and libgdx are more likely to see FOSS games developed for them.


    SDL and Unity can't really be compared, and libGDX is for Java. As long as people develop their own engines in C/C++, there will be a demand for SDL. It's not like Unity will be ported to MorphOS, so a complete implementation of SDL2 will be useful to have.
    I see the jimmies have been rustled.
  • »08.03.19 - 16:38
    Profile Visit Website
  • Order of the Butterfly
    Order of the Butterfly
    beworld
    Posts: 263 from 2010/2/10
    From: FRANCE
    Quote:

    BSzili a écrit :
    SDL and Unity can't really be compared, and libGDX is for Java. As long as people develop their own engines in C/C++, there will be a demand for SDL. It's not like Unity will be ported to MorphOS, so a complete implementation of SDL2 will be useful to have.





    +1, We need SDL 2
    PowerMac 2.7ghz MOS 3.10
    PowerBook 1.5Ghz MOS 3.10
    My MOS ports
  • »09.03.19 - 07:50
    Profile Visit Website
  • Paladin of the Pegasos
    Paladin of the Pegasos
    Papiosaur
    Posts: 1212 from 2003/4/10
    From: France
    A bounty for SDL2 is open on WArMUp website :

    https://www.warmup-asso.org/sections.php?op=viewarticle&artid=33&prev=1

    @Itix: can i attribute it to you ?
  • »09.03.19 - 08:56
    Profile Visit Website
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4855 from 2009/1/28
    From: Delaware, USA
    Quote:

    Andreas_Wolf wrote:
    > I'll assume that supporting a subset of OpenGL was chosen
    > because its documentation is public knowledge, and DirectX
    > versions probably are not (please correct me if I am wrong).

    Direct3D API is openly documented as well, else you couldn't easily write programs that use it. Reason for implementing

    >Absolutely. Part of the problem may be kiero's limited availability.

    Mark did mention that he would want kiero's help for any serious upgrade to our OpenGL implementation (or the implementation of something to replace it).
    "Never attribute to malice what can more readily explained by incompetence"
  • »15.03.19 - 16:39
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 10448 from 2003/5/22
    From: Germany
    >> Part of the problem may be kiero's limited availability.

    > Mark did mention that he would want kiero's help for any
    > serious upgrade to our OpenGL implementation (or the
    > implementation of something to replace it).

    Yes, my third link is to where you reported this in May 2018 :-)
  • »15.03.19 - 17:46
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4855 from 2009/1/28
    From: Delaware, USA
    Quote:

    Andreas_Wolf wrote:
    >> Part of the problem may be kiero's limited availability.

    > Mark did mention that he would want kiero's help for any
    > serious upgrade to our OpenGL implementation (or the
    > implementation of something to replace it).

    Yes, my third link is to where you reported this in May 2018 :-)


    My apologies, master indexer.
    I'm all for a better OpenGL implementation, as long as it isn't something like OpenGL ES.
    DirectX isn't possible, its proprietary.

    What other options might be possible?
    "Never attribute to malice what can more readily explained by incompetence"
  • »16.03.19 - 00:38
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4855 from 2009/1/28
    From: Delaware, USA
    Wrappers and reimplemented Microsoft APIs...how about just an updated OpenGL without the complications?

    [ Edited by Jim 16.03.2019 - 03:55 ]
    "Never attribute to malice what can more readily explained by incompetence"
  • »16.03.19 - 01:39
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 10448 from 2003/5/22
    From: Germany
    > how about just an updated OpenGL without the complications?

    I'm all for it, but the hurdle seems to be the limited developer resources. And I think that updating to a more modern version of OpenGL by implementing OpenGL ES and using an existing wrapper on top of it is better than no updated OpenGL at all.
  • »16.03.19 - 12:35
    Profile
  • Jim
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Jim
    Posts: 4855 from 2009/1/28
    From: Delaware, USA
    Quote:

    Andreas_Wolf wrote:
    > how about just an updated OpenGL without the complications?

    I'm all for it, but the hurdle seems to be the limited developer resources. And I think that updating to a more modern version of OpenGL by implementing OpenGL ES and using an existing wrapper on top of it is better than no updated OpenGL at all.


    Like HunoPPC's work? What makes OpenGL ES that much easier to implement? And how much performance would be lost using a wrapper?

    The whole idea reeks of OS4.
    "Never attribute to malice what can more readily explained by incompetence"
  • »16.03.19 - 16:06
    Profile
  • Moderator
    Kronos
    Posts: 1879 from 2003/2/24
    Quote:

    Jim wrote:

    The whole idea reeks of OS4.




    HyperionOS4 or CloAEONtoOS4 ????

    *runs*
    --------------------- May the 4th be with you ------------------
    Mother Russia dance of the Zar, don't you know how lucky you are
  • »16.03.19 - 16:28
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    Andreas_Wolf
    Posts: 10448 from 2003/5/22
    From: Germany
    >> I think that updating to a more modern version of OpenGL
    >> by implementing OpenGL ES and using an existing wrapper
    >> on top of it is better than no updated OpenGL at all.

    > Like HunoPPC's work?

    Yes, but more like Daytona675x's, ptitSeb's and kas1e's work.

    > What makes OpenGL ES that much easier to implement?

    I don't know, but I guess there's a reason Daytona675x implemented OpenGL ES instead of OpenGL.

    > how much performance would be lost using a wrapper?

    Spectre660 reported some OGLES+GL4ES vs. MiniGL performance comparisons for Quake 3 in August 2018 here on MorphZone.

    > The whole idea reeks of OS4.

    Yes, I was explicitly using OS4 as reference in comments #4 and #16. And this way, OS4 (with 3rd party enhancements) has better OpenGL support than MorphOS.
  • »16.03.19 - 17:18
    Profile
  • Yokemate of Keyboards
    Yokemate of Keyboards
    amigadave
    Posts: 2561 from 2006/3/21
    From: Lake Arrowhead...
    Quote:

    Jim wrote:
    Quote:

    Andreas_Wolf wrote:
    > how about just an updated OpenGL without the complications?

    I'm all for it, but the hurdle seems to be the limited developer resources. And I think that updating to a more modern version of OpenGL by implementing OpenGL ES and using an existing wrapper on top of it is better than no updated OpenGL at all.


    Like HunoPPC's work? What makes OpenGL ES that much easier to implement? And how much performance would be lost using a wrapper?

    The whole idea reeks of OS4.




    As Andreas_Wolf states in a post after the one I quoted above, yes, he was reffering to what is being done on OS4. Maybe something the same or similar could be done to improve the ability to port 3D software to MorphOS. Why would be doing something similar to the 3D work being done by 3rd parties for AmigaOS4 be a bad thing? I think having a compatible 3D support system for MorphOS and AmigaOS4 would be a great thing, as it would make it easier for the limited number of remaining programmers making ports, or original software for both AmigaOS4 and MorphOS, to create software content for both platforms. Hans DeRueter (sp) is doing great work from what I can tell, in expanding 3D support, and writing drivers for newer video cards for OS4. I don't see any reason for Mark and Hans to not collaborate with each other, if they can benefit each other's work.

    Although MorphOS and AmigaOS4 share the same targeted users, I no longer see them as direct competition, the further apart they grow. When/If MorphOS NG for x64 is released, the two OSes will be miles apart and essentially traveling in almost opposite directions. It will almost be like the difference between AmigaOS4 and AmigaOS for 68k, and AmigaOS running via any version of UAE, in regard to users anyway. Many WinUAE users no longer use 68k hardware, and some users only run OS4 via WinUAE. Fewer and fewer users own and use 68k and PPC hardware regularly, and also use any version of UAE. I think that most users have made their choices between hardware or emulation, to reduce redundancy, even if many who use emulation primarily also own real hardware that is stored in a closet somewhere.

    [ Edited by amigadave 17.03.2019 - 10:14 ]
    MorphOS - The best Next Gen Amiga choice.
  • »17.03.19 - 18:56
    Profile
  • Butterfly
    Butterfly
    Samurai_Crow
    Posts: 94 from 2009/12/10
    From: Colorado, USA
    What might be better is that if a newer GCC comes out like is happening on AROS, Mesa can be ported from there. The latest version supports Vulkan, OpenGL ES and legacy OpenGL.

    By the way, if MorphOS gets multithreaded architecture OpenGL ES is more threadable anyway and OpenGL contexts will fade into the sunset.
  • »18.03.19 - 09:51
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    Spectre660
    Posts: 221 from 2015/6/30
    From kas1e
    Quote:

    Warp3DNova is not OpenGL, its more lowlevel api, kind of DirectX from Win32. To compile OpenGL code which will works over Warp3DNova you need to use gl4es which works over Warp3DNova through ogles2.library (which give us OpenglES2).

    Or you can skip gl4es if you will do pure OpenglES code


    Source
  • »18.03.19 - 12:36
    Profile
  • Order of the Butterfly
    Order of the Butterfly
    Spectre660
    Posts: 221 from 2015/6/30
    OpenGL ES 2 version 2.1 now in testing. (this is ogles2.library)

    Quote:

    Daniel Müßener

    OpenGL ES 2 version 2.1 for Warp3D Nova / AmigaOS4 is on my FTP for testers to test now.

    - added support for so called 2D rectangle textures. The most important difference compared to "normal" 2D textures is that you access it by texel-coordinates and not by normalized UVs. Use GL_TEXTURE_RECTANGLE instead of GL_TEXTURE_2D for glBindTexture. Use sampler2DRect instead of sampler2D inside your fragment-shaders.

    - consequently, glGetActiveUniform can now return the uniform-type GL_SAMPLER_2D_RECT.

    - consequently, glGet now supports GL_TEXTURE_BINDING_RECTANGLE.

    - consequently, the library's internal patcher enables the GL_ARB_texture_rectangle extension so that the library's internal glsl-compiler swallows fragment shaders which use sampler2DRect etc.

    - updated the glslangvalidator-redux command line program with that behaviour as well.

    - consequently, added GL_ARB_texture_rectangle and GL_EXT_texture_rectangle to the extensions string.

    - performance: lots of micro optimizations (e.g. more branch hints, etc.)

    - performance: VBO multibuffering values further tuned.

    - performance: DBO multibuffering.

    - performance: memcopy-with-stride optimized for different element-sizes.

    - performance: hash-with-stride optimized for different element-sizes.

    Those optimizations gave us some significant gains here and there and especially corrected the slight losses on some games introduced with the last version, but after trying a lot I'm out of more options for now ;)
    Thanks and greets to Kasie Kasovich (kas1e) for feature-requesting and testing :)

    Cheers,
    Daytona675x


    [ Edited by Spectre660 18.03.2019 - 07:41 ]
  • »18.03.19 - 12:39
    Profile