|
The MiniGL thread |
Posted on: 3/16 18:24
#1 |
---|---|---|
Quite a regular
![]() ![]() Joined:
2007/7/14 20:30 From Lothric
Posts: 803
|
Thread for MiniGL-related news and issues.
Before reporting a problem, please do "version full minigl.library" and "list LIBS:minigl.library" to indicate the library version. If you have issues with some 3rd party MiniGL library, please report those issues to people who created it. * Links - version 2.20 (2015): http://os4depot.net/index.php?functio ... river/graphics/minigl.lha - latest test version by Daniel: http://www.goldencode.de/tmp/mgl.zip - source codes: http://www.hyperion-entertainment.com ... /branches/updates-kc/src/ * Open issues: - "suspicious code in mgl_CreateContext" - * Fixed issues: - extension string buffer allocation (r537) Edited by Capehill on 2019/3/17 7:23:28
|
|
|
Re: The MiniGL thread |
Posted on: 3/16 19:28
#2 |
---|---|---|
Home away from home
![]() ![]() Joined:
2007/9/11 11:31 From Russia
Posts: 5536
|
@Daniel
copy of my last message: With latest one i run about 10 times testgl, then Cube run/exit few times, then Q3 sdl1 version, then Q3 sdl2 version, then cube few times, then testgl 5-7 times,then again q3 sdl2 version,then again q3 sdl1 version, then cube,cube,testgl (10 times) and bllbalbalabllba : works ! What is interesting to know, is was then this issue there was for some time ? I mean, why i got that crashes and with version frmo precompiled_bins.7z, while thos eextensions parts was touched after ? Or , memory overwriten was there all the time way before 2.23 and 2.22 ? Also , maybe those "instability" issue with libtxc_dxtn wasn't libtxc_dxtn in end ? Maybe worth to try to bring it back and test all stuff again with latest sources ? Through, one time when i play lot with running/exit few games, few times quake3, and then after a while running the Cube : it then crashes on start the same as before :( But then i can't reproduce it anymore, not with your latest build, not with 2.20 one. Maybe as it crashes on running, its about that thing in context creation about which Capehill made a BZ @Capehill Tried 3 instances of "testgl" at the same time, and iconify one , then another, and running 4st instance lockup os. I.e. not one by one and exit, but one, iconfiy, another instance, etc, and then lockup. So its _much_ better now, but still i had lockup with just pure "testgl". Maybe its even only "testgl" related. Next time i can't just crash it with only 3 instances, but it takes 5 running ones and iconified, then running 6st one / exit, and then uniconify one back and close , and then GR. Even catch the stack trace: For sake of test i tried minigl.library 2.20 with "testgl" and can reproduce the lockup too ! That what you need to try: 1). start shell 2) testgl & (so to run it in background in the same console) 3) now start to run new instanses by the same "testgl &" one by one, let's say 10 of them. 4). move all windowses in all directions, and then iconify them all 5). start to deiconify them, and close, and run again and iconify, and play a little like this => crash. And that even with minigl 2.20 from os4depot. Probabaly can be related to iconify itself dunno. Edited by kas1e on 2019/3/16 19:55:24
Edited by kas1e on 2019/3/16 20:25:16 |
|
|
Re: The MiniGL thread |
Posted on: 3/16 20:23
#3 |
---|---|---|
Home away from home
![]() ![]() Joined:
2007/9/11 11:31 From Russia
Posts: 5536
|
@Daniel
So far tried with last mgl2.23 build: games: Lugaru Cube Quake1 Darkplace Q3 (sdl1 and sdl2 versions) Return to castle wolfstain Smocking guns LettersFall3 NeverBall/NeverPutt some scene stuff: nce-trylobyte (music disk) anti-dominium (demo) editors: blender lodepaint All seems to works and renders correctly as before, and they all works. I even tried them running one after one : no lockup or crash. Or we can bump revisions and release is at it, or if you still share motivation we can try to test the same things with enabled back libtxc_dxtn, as maybe issues happens not because of that, but because of what you fix lately. |
|
|
Re: The MiniGL thread |
Posted on: 3/16 21:18
#4 |
---|---|---|
Home away from home
![]() ![]() Joined:
2006/12/2 3:55 From Italy, Perugia
Posts: 3146
|
Copied from the old thread
@Daytona675x Can you update the version and date binaries ? Actually we have: minigl.library 2.23 ( 2-May-2018) mglut.library 2.21 (30-Nov-2015) Perhaps both release numbers should be updated at 2.23 ? |
|
|
Re: The MiniGL thread |
Posted on: 3/16 21:50
#5 |
---|---|---|
Home away from home
![]() ![]() Joined:
2006/12/2 3:55 From Italy, Perugia
Posts: 3146
|
Have quick tested IoQuake3 and Smoking's guns .. both games now they showed a sort of FPS "broken" counter in the top area of the window
See grab here: https://ibb.co/wdVMJZF Are this added automatically from MiniGL ? With past version of the library i did not remember to have seen it |
|
|
Re: The MiniGL thread |
Posted on: 3/16 22:33
#6 |
---|---|---|
Just popping in
![]() ![]() Joined:
2016/3/10 14:15 From Poland
Posts: 50
|
|
|
|
Re: The MiniGL thread |
Posted on: 3/17 5:59
#7 |
---|---|---|
Home away from home
![]() ![]() Joined:
2007/9/11 11:31 From Russia
Posts: 5536
|
@samo79
Quote:
Yeah, something wrong at left side on top of window, but i didn't have that (not with last verison, not with previous ones). Are you sure you falsely didn't use for this test again that library from Huno ? It just looks like something from wazp3d which Huno inbuild for version you have from him. Retest it again with proper hard-reboot, etc and be 100% sure you test correct library @amiga_os Can't see what wrong there , is problem on first screenshot what is keeps on the wall after sword, and on second one are the shadows on the face ? Did that part looks any different in compare with minigl 2.20 / 2.21 ? |
|
|
Re: The MiniGL thread |
Posted on: 3/17 7:28
#8 |
---|---|---|
Quite a regular
![]() ![]() Joined:
2007/7/14 20:30 From Lothric
Posts: 803
|
@kas1e
Did you grab the serial logs of new "testgl issue"? |
|
|
Re: The MiniGL thread |
Posted on: 3/17 11:32
#9 |
---|---|---|
Home away from home
![]() ![]() Joined:
2007/9/11 11:31 From Russia
Posts: 5536
|
@Capehill
Tried to reproduce it hard now , and can't from first try. Then, i keep about 5 instances working on the screen, and go to street for a hour, then when i back , they all crashes, with the same crash which i catch yesterday. There is: Quote:
As you can see ABADCAFE in DAR , which mean we have accessed uninitialized memory. Stack trace point out in end of all on Warp3DNova, but that can be and SDL itself which cause that, and MiniGL, and Nova itself.. I will try now to just run 2 instances and keep they working for a while. |
|
|
Re: The MiniGL thread |
Posted on: 3/17 12:04
#10 |
---|---|---|
Quite a regular
![]() ![]() Joined:
2007/7/14 20:30 From Lothric
Posts: 803
|
@kas1e
There is no SDL in the stack trace. This line: (0x5A603B40) testgl:RunGLTest()+0x52c (section 7 @ 0x18C8) points to glClear() call. Maybe Daniel can tell what is this: module LIBS:minigl.library at 0x7F2D95A4 (section 0 @ 0x6580) I hope also Hans would take a look at the crash. I will try to reproduce it again but if it has to be a some kind of stress test, it will be hard and time-consuming. |
|
|
Re: The MiniGL thread |
Posted on: 3/17 13:20
#11 |
---|---|---|
Home away from home
![]() ![]() Joined:
2007/1/26 21:48 From New Zealand
Posts: 2196
|
@kas1e
Quote:
Correct. The program has somehow ended up using uninitialized memory. Quote: Stack trace point out in end of all on Warp3DNova, but that can be and SDL itself which cause that, and MiniGL, and Nova itself.. Actually, that's clearly MiniGL + Warp3D (the old one). Try not to get the old Warp3D and Warp3D Nova mixed up. @Capehill Quote: I hope also Hans would take a look at the crash. I will try to reproduce it again but if it has to be a some kind of stress test, it will be hard and time-consuming. Based on the stack trace, the driver is calling IExec->AllocItemPool() but the pointer to the item pool is obviously wrong. Possible reasons why that could happen: - Random memory trashing has corrupted the RadeonHD_RM.resource context (or not so random memory trashing, like an app/lib writing beyond the end of an array - The pointer to said context itself has been corrupted - The RadeonHD_RM.resource context was destroyed, but it's still being used No idea why any of the above would suddenly happen. Hans |
|
_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. https://keasigmadelta.com/ - more of my work |
||
|
Re: The MiniGL thread |
Posted on: 3/17 16:36
#12 |
---|---|---|
Not too shy to talk
![]() ![]() Joined:
2015/6/11 8:51 From Cologne
Posts: 281
|
@Capehill
Thanks for that fresh thread ![]() @kas1e Quote: Also , maybe those "instability" issue with libtxc_dxtn wasn't libtxc_dxtn in end? May well be! That extension string thingy caused all kinds of undefined trouble, and it probably was pure coincidence that replacing the dxt stuff seemed to improve the situation on my side. Quote: For sake of test i tried minigl.library 2.20 Yes, that's what I expected and said yesterday: if you go for it you will get the old 2015 MiniGL lib by Hans to crash / freeze in similar ways. Naturally, after all it's even more buggy than our new version ![]() Quote: All seems to works and renders correctly as before, and they all works. I even tried them running one after one : no lockup or crash. Quote: Tried to reproduce it hard now , and can't from first try. Then, i keep about 5 instances working on the screen, and go to street for a hour, then when i back , they all crashes, with the same crash which i catch yesterday. I'd say, let's release the current version as 2.23 and remove Hans' old 2015 download from os4depot. The new version apparently is at least equally stable and contains many fixes and new features required for some newer applications. Regarding dxt: I put a new version online for you to check out. If that one behaves equally stable as the other, then I see no reason why not to use it. http://www.goldencode.de/tmp/mgldxt.zip @samo79 Quote: Can you update the version and date binaries? ... Perhaps both release numbers should be updated at 2.23 ? Yes, once we decided which of the two lib variants to use, I'll adjust version numbers, readme etc., and commit everything to the SVN. I'll also update the 7z there. Then we should use those final versions for os4depot too. Quote: Have quick tested IoQuake3 and Smoking's guns .. both games now they showed a sort of FPS "broken" counter in the top area of the window... Are this added automatically from MiniGL? Yes, this is an MiniGL feature, toggle by the env-var MiniGL/FrameStats 1/on. That format string got broken at some point in the past, those broken chars (most likely due to some UTF8 editor madness) should be µs ;) Well, and the output formatting itself completely fails. IUtility->SNPrintf is used for formatting, using C printf-style %4.4f and such. AFAIK SNPrintf doesn't support %f, which explains why it shows only funny f's... Apparently this never worked and I have no idea who the hell put that there. I just fixed that too. @amig_os I have no idea how it should look ![]() @kas1e, Capehill, Hans Regarding that crash ending up inside W3D_SI: maybe give it a try on an R200 system and see what happens? Quote: No idea why any of the above would suddenly happen. ![]() Other than that, from my side, I'd say: step by step. I think we all agree that we can now more than safely get rid of that antique more buggy 2015 MiniGL on os4depot. Fixing even more bugs is sth. for the next version, especially if it's sth. were you have to stress the system quite a bit to provoke it. |
|
|
Re: The MiniGL thread |
Posted on: 3/17 17:33
#13 |
---|---|---|
Home away from home
![]() ![]() Joined:
2006/12/2 3:55 From Italy, Perugia
Posts: 3146
|
@Daytona675x
Thanks for the fix, will going to test it ![]() Just some more minor problems to report: TestGL example of SDL1 leave some garbage graphics on screen as soon as you quit the window, atleast this is reproducible with latest MiniGL 2.23 See grab: https://ibb.co/QdwHvmv Another issue is related to Quake3 Since pratically forever (using MiniGL 2.20 and even using older version of the library) i have a systematic system freeze when i'm turning back into the main area of Quake 3 This one: https://tcrf.net/images/thumb/3/34/Qua ... png/320px-Quake3title.png What is curious is that freeze happen only when i'm stuck in that specific area, and not in other areas of the game option Initially i though it was because a buggy version of Quake3 i've used, however i noted that all Quake3 port under OS4 seems affected by this, so or it's a bug of the original source of Q3 or it's MiniGL |
|
|
Re: The MiniGL thread |
Posted on: 3/17 17:43
#14 |
---|---|---|
Not too shy to talk
![]() ![]() Joined:
2015/6/11 8:51 From Cologne
Posts: 281
|
@samo79
Quote: Thanks for the fix, will going to test it Now you can. Just now I updated both versions mgl / mgldxt accordingly. Quote: TestGL example of SDL1 leave some garbage graphics on screen as soon as you quit the window, atleast this is reproducible with latest MiniGL 2.23 Actually that's sth. I know from all MGL versions or raw Warp3D stuff. Happens from time to time here, seems to depend on hardware and the weather outside ![]() Quote: Since pratically forever (using MiniGL 2.20 and even using older version of the library) i have a systematic system freeze when i'm turning back into the main area of Quake 3 Phew, no idea. Sounds as if it could be anything, not even related to MGL. I suggest to file a bug and not to expect too much ![]() |
|
|
Re: The MiniGL thread |
Posted on: 3/17 17:52
#15 |
---|---|---|
Quite a regular
![]() ![]() Joined:
2007/7/14 20:30 From Lothric
Posts: 803
|
@Daytona675x
Actually both issues have been reported a long ago to Hyperion. For example running MiniGL Gears demo and resizing window can trigger garbage. (Sam440/M9 for example). Q3 menu freeze has happened from the day one on certain graphics cards (for example M9). It was debugged in ~2008 and W3D never returned from W3D_DrawElements call. For me it's hard to believe Q3 is buggy. I don't like to blame anyone/thing but for me the most logical place is W3D driver. People like to blame Q3 but they don't seem to understand that there is no Amiga-specific rendering code in Q3. Draw calls are delegated to MiniGL + Warp3D :( |
|
|
Re: The MiniGL thread |
Posted on: 3/17 18:04
#16 |
---|---|---|
Home away from home
![]() ![]() Joined:
2007/9/11 11:31 From Russia
Posts: 5536
|
@Daniel
Tried http://www.goldencode.de/tmp/mgldxt.zip , and it all the same in terms of rendering and stability as S2TC was. Just the library size smaller on about 500-600kb with dxt. I do test the same list as i test with last mgl, so far all the same, run them also one after another, etc. So its good to keep imho and probabaly worth of made a release with what we have now. Anything else can keep for later, or it all will be forever song called "i found another bug, Daniel should fix it" :) So if you will bump the revision/date and prebuild everything, i can then take ppc ones, put all nicely in archive, and upload there so all can tests if all is fine, and then os4depot and forget about for a while :)) |
|
|
Re: The MiniGL thread |
Posted on: 3/17 18:07
#17 |
---|---|---|
Home away from home
![]() ![]() Joined:
2006/12/2 3:55 From Italy, Perugia
Posts: 3146
|
@Daytona675x
Quote: Now you can. Just now I updated both versions mgl / mgldxt accordingly. Yeah tested, problem gone ![]() Quote: Phew, no idea. Sounds as if it could be anything, not even related to MGL. I suggest to file a bug and not to expect too much Yep I've reported years ago and not only once, i've reported the issue to atleast two Quake 3 porters (first to Max Tretene and then to HunoPPC), then to the old MiniGL mantainers and even in Hyperion forum but no luck ... At some point i give up @Capehill Indeed, i have exactly one of this system, Sam440 Flex 800 with Radeon 9250 |
|
|
Re: The MiniGL thread |
Posted on: 3/17 18:08
#18 |
---|---|---|
Not too shy to talk
![]() ![]() Joined:
2015/6/11 8:51 From Cologne
Posts: 281
|
@Capehill
Quote: People like to blame Q3 but they don't seem to understand that there is no Amiga-specific rendering code in Q3. Draw calls are delegated to MiniGL + Warp3D :( Absolutely. I don't blame Q3 neither. But there's more than MGL and W3D to make Q3 run on AOS4. And both libs rely on others. And then there's the fact that some issues are super hard to reproduce depending on hardware (or simply only appear on some hardware, starting with different gfx cards). So I'm not surprised that those issues aren't fixed yet. @kas1e Very well! Then I'll clean it up, adjust version numbers, do the commits of the latest fixes etc. and then report back. Won't happen today anymore though. @samo79 Quote: Yeah tested, problem gone Very well ![]() |
|
|
Re: The MiniGL thread |
Posted on: 3/17 18:27
#19 |
---|---|---|
Quite a regular
![]() ![]() Joined:
2007/7/14 20:30 From Lothric
Posts: 803
|
@Daytona675x
As I have never seen W3D driver code, it's easy for me to suspect them ;) I don't mean this in a bad way. It just my traces ended up in MiniGL and when we tried to debug W3D using a serial cable, things became too slow to test. It was kinda frustrating. Somebody closed the BZ, I reopened it because it's still there :) If I remember correctly, Q3 menu (flame anim) drawing is time-based. I was thinking about somehow "seeding" the time parameter to get the freeze immediate but then I lost either time or motivation. By the way, thanks for the new MiniGL release Daniel, Hans, Bzili, kas1e and others: it's nice to have new features and fixes after many years :) |
|
|
Re: The MiniGL thread |
Posted on: 3/17 18:27
#20 |
---|---|---|
Just popping in
![]() ![]() Joined:
2016/3/10 14:15 From Poland
Posts: 50
|
http://www.hyperion-entertainment.com/index.php/news
Shogo: Mobile Armor Division available as digital download for AmigaOS 3 and 4 EntwicklerX Rulez ! |
|