Click Here
home features news forums classifieds faqs links search
5759 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
Home
Features
News
Forums
Classifieds
Links
Downloads
Extras
OS4 Zone
IRC Network
AmigaWorld Radio
Newsfeed
Top Members
Amiga Dealers
Information
About Us
FAQs
Advertise
Polls
Terms of Service
Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
19 crawler(s) on-line.
 17 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 A1200:  35 mins ago
 matthey:  36 mins ago
 MEGA_RJ_MICAL:  37 mins ago
 K-L:  50 mins ago
 kolla:  57 mins ago
 Fairdinkem:  1 hr ago
 Bezzen:  1 hr 2 mins ago
 Argo:  1 hr 20 mins ago
 pvanni:  1 hr 49 mins ago
 mariaoziwa:  2 hrs 29 mins ago

software OS4   software OS4 : Enhancer update: new ogles2, Warp3DNova and RadeonHD
   posted by kas1e on 25-Dec-2019 13:56:24 (1396 reads)


Everyone who has registered a copy of the Enhancer Software with Enhancer Software Graphics Upgrade pack can fire-up Updater now and got a new version of ogles2.library (v2.11), warp3dnova.library (1.68) and RadeonHD (3.7).



Since last public version there was numerious bug-fixes and imporvemnts, such as:

ogles2.library by Daniel "Daytona" Muessener.





Changes since 2.8 version:

- Fix: if an enabled vertex-attribute-array was being disabled then the corresponding generic vertex-attribute wasn't applied eventually, resulting in semi-random vertex-attribute data.This will rarely happen in a real-world app, which is why this bug wasn't found earlier. Thanks to Juha Niemimaki (Capehill) for reporting!

- extension to the glGetString GL_VERSION query: it will now not only return the ogles2 lib's version but also the Nova version! Programs should check both versions because especially GLSL functionality depends on Nova, not so much on ogles2. The returned string now looks like this: "OpenGL ES 2 2.9 on top of Warp3D Nova 1.65". Thanks to Hubert Maier (Raziel) for indirectly inspiring me to do this one ;)

- and for convenience (or if you find it too hard to parse the 2nd version number (cough, Frank, cough ;) ) which may appear at different positions depending on the 1st one) the Nova version number is also appended to the GL_RENDERER string which now reads like: "Warp3D Nova 1.65"

- Implemented the OES_get_program_binary extension as requested by Kasie Kasovich (kas1e). Because Nova doesn't provide any support here, this implementation works with the internal SPIR-V code of all shaders that make up the respective program. So the binaries here are no true machine-code but intermediate code, packed into a proprietary format. Providing such binaries essentially skips the vertex- and fragment-shader's GLSL compilation steps. Anyway, this means:

- new function glGetProgramBinaryOES to extract such a binary representation of the respective successfully linked shader program.

- new function glProgramBinaryOES to supply the GL with such a cached binary.

- support for the glGet parameter GL_NUM_PROGRAM_BINARY_FORMATS_OES - which returns 1 now.

- support for the glGet parameter GL_PROGRAM_BINARY_FORMATS_OES, which returns one single format ID identifying my binary format (0xC00DA675)

- support for the glGetProgramiv parameter GL_PROGRAM_BINARY_LENGTH_OES which gives you the buffer size required to store the binary for the respective program.

- consequently added GL_OES_get_program_binary to the extension string.

- added glProgramBinaryOES and glGetProgramBinaryOES to the stubs library for direct use.

- Fix: aglGetProcAddress returned function pointers in the Amiga interface style, with the first parameter being a pointer to the interface. Now the compatible "stub"-style signature is being returned which matches the GL function pointer prototypes. Apparently nobody used aglGetProcAddress before, so this went unnoticed. On our ogles2.lib even the extension functions are all simply directly accesible just like all other functions, so if you code for Amiga only you don't need aglGetProcAddress. gl4es however uses it - and this was where it all exploded now :) Thanks to Kasie Kasovich (kas1e) for reporting!

- Fix: glScissor didn't gracefully handle negative xy or height. Thanks to Kasie Kasovich (kas1e) for reporting.

- Improvement: under certain circumstances ogles2 could be triggered to resize its internal client-RAM-emu-VBOs multibuffer to very very large values, in fact so large that Nova allocated almost all VRAM for those. At least on some Nova/RadeonHD.chip/graphics.lib setups the VBO resizing also triggered a crash bug in Nova's DeleteBuffer function under such low VRAM conditions. This improvement therefore also acts as a workaround for that issue. This fixes all such issues with some of kas1e's Irrlicht engine examples. Thanks to Kasie Kasovich (kas1e) for reporting.

- Fix: there was a bug in the copy-converter for 8bit and 16bit index arrays (Nova doesnt support 8bit indices and is very slow with 16bit indices, therefore those are converted to 32bit internally, even if the ogles2-client passes them inside his own VBO, then a "hidden" 32bit clone is prepared and used) which in theory could result in the indices not being updated at all. It was extremely unlikely to happen and AFAIK it never did, but anyway: fixed.

- Workaround/Fix: if you attached a GL_BGRA_EXT texture as color render target to an FBO, then the texture's red and blue channels would appear to be swapped when you later used that texture for rendering. The reason for this is that the BGRA texture's internal pixel format is actually RGBA, only that its channels are "swizzled". At the moment Nova ignores that swizzle setting when rendering to the texture. The current workaround is to reset any eventual swizzle to the defaults if the texture is being used as FBO render target, so simply spoken an BGRA texture becomes an RGBA texture if you use it as render target. This fixes color bugs in e.g. an irrlicht demo and Tuxkart. Thanks to Kasie Kasovich (kas1e) for reporting.

- maintenance, C++ modernizations: all attribute initializations moved from constructor initializer lists into the respective class definitions. Makes the code smaller and it's harder to forget something (and oops, I actually found one unitialized attribute during the process (uncritical though)...).

- maintenance, C++ modernizations: "auto" return-value replacement run on all inline functions, where appropriate.

- (small) hashing functions speed-up (without hash quality loss).

- Fix: a bug in the uniform shader variable handler resulted in same-named (and thus logically identical) vertex- and fragment-uniforms to eventually be assigned different virtual location numbers. If the user issued a glUniform(location_number,xyz) call then the lib would only find and set the vertex-shader's uniform and skip the writing to the fragment-shader's uniform because it would simply not find it. OpenGL doesn't distinguish between such same-named but physically different uniform variables in the shaders of a GPU program - in stark contrast to Nova, where all that info is shader and not shader-program based. Consequently Nova's ShaderGetObjectInfo, which is used to query uniform variable information, works on shaders only. Also, Nova only gives us a GLSL / GL compatible "location" info if that has been explicitely defined inside the shader, otherwise it doesn't generate one but only returns W3DN_NOLOCATION. Because of all this ogles2.lib has to generate such location infos by itself, in a GL compatible way. Which means that in case of a same-named variable in both of a program's shaders the same uniform location has to be enforced. Which is where the flaw was. In gl4es this bug manifested in fog not working. Thanks to kas1e for reporting and testing!


Warp3DNova.library by Hans de Ruiter.



Changes since 1.65 version:

- Implemented W3DN_Q_TEXUREEXTSHARE

- Added W3DN_Q_TEXTURE_1D_ARRAY, W3DN_Q_TEXTURE_2D_ARRAY, & W3DN_Q_TEXTURE_CUBEMAP_ARRAY queries (NOTE: No drivers support them yet)

- Implemented W3DN_Q_ENDIANNESS and the ability to disable endianness conversion for VBOs & DBOs

- Migrated to GCC8, refactored shader compiler to use stdlib smart pointers instead of boost, and enabled optimization when compiling the shader compiler (bug #413)

- Fixed a null pointer bug in the shader compiler (bug #452)

- Using texture samplers with an offset variable would lock up an SI GPU. FIXED

- Sin()/cos() shader functions couldn't handle input values. FIXED (bug #407)

- Refactored the shader compiler to use make_shared (reduces memory allocation overhead)

- Failure when creating a VBO, DBO or other object could result in a crash. FIXED (bug #447)

- Added a null index buffer pointer check to the DrawElements()

- The register allocator was leaving large gaps in the register file, resulting in it running out of registers. FIXED (bug #407)

- The shader compiler was reusing the function execution thread mask in multiple functions, causing potential data loss and image corruption with multiple nested functions. FIXED (bug #409)

- The register allocator shader log output now lists all registers when printing the final register allocations

- Some GLSL special functions such as sign() and smoothstep() couldn't be used in if/else loops; caused compilation failure. FIXED (bug #401)

Radeon HD driver by Hans de Ruiter.

Changes since 3.6 version:

- 64-bit internal GPU addresses were accidentally being truncated to 32-bits, causing a crash (bug 457). Issue happens on X5000 and Tabor when fill more than 256mb of GPU video memory. FIXED

- Added buffer ownership checks to the render manager's buffer locking and free code for extra safety (needed to share buffers between multiple drivers)


The Enhancer Software package has been the result of a small dedicated team who have committed great efforts to this body of work. A-EON would like to thank the developers, beta testers and translators for their significant contributions.

    

Related Links
· More about software OS4
· News by kas1e


Most read story about software OS4
Homebank 4.4 for AmiCygnix released

Last news about software OS4
New version 1.6 of AmiCygnix available
Printer Friendly Page  Send this Story to a Friend

PosterThread
Drakken 
Re: Enhancer update: new ogles2, Warp3DNova and RadeonHD
Posted on 25-Dec-2019 17:54:53
#1 ]
Member
Joined: 14-Nov-2014
Posts: 10
From: Germany

Thanks for the Update


_________________
X5000 P5020, OS4.1-FE U1 (Pre)

 Status: Offline
Profile     Report this post  
outrun1978 
Re: Enhancer update: new ogles2, Warp3DNova and RadeonHD
Posted on 25-Dec-2019 21:59:54
#2 ]
Cult Member
Joined: 22-Feb-2015
Posts: 577
From: Unknown

Yes guys thanks for the update and your hard work.

@kas1e A special thanks for the update to Super Tux Kart it looks amazing in HD and runs so much quicker now on my X5000 thanks to the new drivers.

Any chance of having some joypad/joystick support for this?


_________________
Amigaone X5000/20 4GB Radeon RX 550 Polaris 12 AmigaOS4.1 Final Edition Update 1
Amiga 1200 Workbench 3.1.4
Amiga CD32

 Status: Offline
Profile     Report this post  
Plexus 
Re: Enhancer update: new ogles2, Warp3DNova and RadeonHD
Posted on 26-Dec-2019 15:48:15
#3 ]
Regular Member
Joined: 29-Sep-2003
Posts: 274
From: SWEDEN (Sverige)

@Kas1e & rest of the Amiga developers
Thanks for all hard work with the drivers and new games for AOS4
The best X-Mas present this year
Really Happy for this!


_________________
AmigaOne X5000, AmigaOS 4.1 Final Edition
(Long Live The Amiga)

 Status: Offline
Profile     Report this post  
klx300r 
Re: Enhancer update: new ogles2, Warp3DNova and RadeonHD
Posted on 26-Dec-2019 16:02:11
#4 ]
Elite Member
Joined: 4-Mar-2008
Posts: 3549
From: Toronto, Canada

WoW!!! what a great Christmas present thanks to all involved !!!


_________________
____________________________
c64-2sids, A1000, A1200T-060@50(finally working!),A4000-CSMKIII
! My Master Miggies- Amiga 1000 & AmigaOne X1000 !
mancave-ramblings
X1000 I BELIEVE

 Status: Offline
Profile     Report this post  
DiscreetFX 
Re: Enhancer update: new ogles2, Warp3DNova and RadeonHD
Posted on 26-Dec-2019 23:04:31
#5 ]
Super Member
Joined: 12-Feb-2003
Posts: 1887
From: Chicago, IL

Thanx for the great amiga holiday updates!


_________________
Sent from my Quantum Computer.

 Status: Offline
Profile     Report this post  
Breed 
Re: Enhancer update: new ogles2, Warp3DNova and RadeonHD
Posted on 27-Dec-2019 8:40:49
#6 ]
Regular Member
Joined: 8-Apr-2003
Posts: 197
From: Kuusamo/Finland

Big Thank You for your hard work!!


_________________
5*C-64, C128, A500, A1200 PPC, Micro-A1(sold).....and X1000

 Status: Offline
Profile     Report this post  
[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle