Wings Remastered

@kas1e
Ah, okay, I didn't know that it was so easy to replace stuff there.
Then I'd say: Go build a fresh one and replace it then
Of course the current MGL version is better in every possible aspect compared to the version on os4depot, there is zero doubt on that.

@Daniel
Yeah, right ! Will do so, and upload it there, thanks ! Hope Biro doesn't mind too

del

@Daniel
Tried to build latest minigl code with both gcc 8.2.0 and with old 4.4.2. And in both cases trying to use 2 variants : pure "makefile" and "makefile_ppc".

In all those 4 cases, the resulted minigl.library just freeze os when i only run quake3 and pressing "enter" after ID logo.

Your precompiled libraries which done before latest fixes works fine through.

As i see after precompiled stuff was added that:

Quote:

Maybe something of that sort cause that ?

And strangely size of my libraries always less than your ones for about 700kb. Which mean that probably something not build in or so, and or it done in light of latest changes, or i just suck some amiga1200 and do something wrong.

Also, makefile_ppc is fail to link minigl.library with words "undefined reference to tx_compress_dxtn" , which objects i had to add manually. Probabaly that one related to latest change about "Replaced S2TC wtih libtxc_dxtn, because the S3TC patents have expired." ?

Also another question : i can't build SPE/tabor bins, should we release it without them, or, we still need to build it and put together into archive ?

@kas1e

Just a quick note about releasing: make sure to bump the revision number if it hasn't been done already, and that the readme/change-log has the new revision noted.

Hans

@kas1e

Quote:

To compile for SPE you need to use gcc 5 or 6. Older and newer versions do not support SPE.

@Hans
Yep, sure

@Daniel

"makefile_ppc.aos4" fail with "undefined reference to tx_compress_dxtn" because at the end of one string there was leaved some non-need it "" , see:

Quote:

Once i removed it, makefile_ppc.aos4 compile things without errors, but result library still smaller than your one on about 600kb and it still freeze the os once i run quake3 and hit enter after ID logo starts.

In Lugaru some textures in menu just white areas.

In Cube some textures also messed a bit (i even can't exit most of time, as it freezes).

Maybe its all about that newly added ibtxc_dxtn ?


EDIT: Ok, size differences can be explained by switching from S2TC wtih libtxc_dxtn (i just tried to use that one instead of ibtxc_dxtn to see that size of library start to be about as yours).

But, that still didn't fixes those issues with the quake3 hang, and lugaru/cube empty textures.

EDIT2: Found issue with broken textures in the Cube and Lugaru : they caused by very last commit where we add Capehill's patch :( Do not know if that can be cause of freezes as well in quake3 (at least, i tried to replace || back on && in both functions which was "fixed" , but it only make textures renders correctly, but quake3 still hangs : that can be something adding before of that patch, like change in drawelements or something).

@kas1e
Let me do it.

That freeze is due to Biró's DXT lib replacement. Why it's freezing on your side even without it, no idea, maybe compiler related. I use a (t)rusted gcc 5.x The resulting lib works stable. Code-size differs due to the lib-change and different compilers.

The code prior to the Capehill patch was broken for sure. If that now happens to break on other games, then it's another side-effect that's being triggered now. Reverting the patch is no solution, it'll break other stuff again.

What do you mean by "precompiled stuff"? There's nothing pre-compiled, as far as I can see.

Regarding SPE: IMHO we should keep it simple for now and only upload the updated std. lib to os4depot.

Note: I asked the mods to create a new thread out of this off-topic-mess here...

@Daniell
By precompiled stuff i mean your precompiled binaries, which done before latest changes, and which works fine (no hangs, no texture trashing).

So while issue with texture trashing its Capehill's changes, the hangs come after changes done when you made precompiled libraries/binaries for ppc/spe/etc (probable DXT replacement yeah, maybe i just wrongly switch it back for tests)

@kas1e
Ah, okay, got it. When I read pre-compiled in relation to sources I though about precompiled obj-files being linked or whatever
EDIT: I think I found the texture problem... ugly... solving...
EDI2: yup, an ugly side-effect with the internal mipmapping-mess under certain circumstances. I now made a workaround which should satisfy both Capehill and others
Here's a test-build for you to test
http://www.goldencode.de/tmp/mgl.zip

@Daytona675x

http://www.goldencode.de/tmp/mgl.zip

I think there are problems with JediAcademy and JediOutcast.
I do not see the game selection menu or black screen or GR or freezes OS4 beta.

======================================

Crash log for task "openjk_sp"
Generated by GrimReaper 53.19
Crash occured in module at address 0xFFCFCFCC
Type of crash: ISI (Instruction Storage Interrupt) exception
Alert number: 0x80000003

Register dump:
GPR (General Purpose Registers):
0: 7F716EE8 3BE73540 00000000 57993300 00000004 00000006 00001405 3CC8A380
8: 00000000 FFCFCFCF FFFFFFFF 7F32FC94 39933333 3BE92CD8 3BE90000 3CBE6E14
16: 5A661DB8 3CC8A380 00000000 3CC8A380 00000000 00000000 00000065 3CC8A380
24: 3CCAA380 00000001 3CBD51EC 3CCAA380 484858A4 3CCAA380 484858C4 00000007


FPR (Floating Point Registers, NaN = Not a Number):
0: nan 0 640 480
4: 0 0 1 1
8: 0.0015625 -0.00208333 -2 1
12: 255 1 0 0
16: 0 0 0 0
20: 0 0 0 0
24: 0 0 4.5036e+15 255
28: 1 0.2 0 0

FPSCR (Floating Point Status and Control Register): 0x82002000


SPRs (Special Purpose Registers):
Machine State (msr) : 0x1200B030
Condition (cr) : 0x00000001
Instruction Pointer (ip) : 0xFFCFCFCC
Xtended Exception (xer) : 0xFFFFFFFF
Count (ctr) : 0x00000001
Link (lr) : 0xFFFFFFFF
DSI Status (dsisr) : 0x00000001
Data Address (dar) : 0xFFFFFFFF



680x0 emulated registers:
DATA: 00000001 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ADDR: 6FFA4000 9305D100 00000000 00000000 00000000 00000000 00000000 3BE81DE0
FPU0: 0 0 0 0
FPU4: 0 0 0 0



Symbol info:
Instruction pointer 0xFFCFCFCC belongs to module "" (HUNK/Kickstart)

Stack trace:
0xFFCFCFCC symbol not available
openjk_sp:_Z14R_DrawElementsiPKj()+0x58 (section 7 @ 0xD1A90)
openjk_sp:_Z23RB_StageIteratorGenericv()+0x1b0 (section 7 @ 0xD44A0)
openjk_sp:_Z13RB_EndSurfacev()+0x1b4 (section 7 @ 0xD1CA4)
openjk_sp:_Z13RB_StretchPicPKv()+0x274 (section 7 @ 0xAB590)
openjk_sp:_Z24RB_ExecuteRenderCommandsPKv()+0x110 (section 7 @ 0xAD984)
openjk_sp:_Z21R_IssueRenderCommandsi()+0x58 (section 7 @ 0xB123C)
openjk_sp:_Z11RE_EndFramePiS_()+0x70 (section 7 @ 0xB12C8)
openjk_sp:_Z16SCR_UpdateScreenv()+0x104 (section 7 @ 0x13268)
openjk_sp:_Z8CL_Frameif()+0x20c (section 7 @ 0x101BC)
openjk_sp:_Z9Com_Framev()+0x290 (section 7 @ 0x443F8)
openjk_sp:main()+0x10c (section 7 @ 0x671F4)
native kernel module newlib.library.kmod+0x00002520
native kernel module newlib.library.kmod+0x000031e4
native kernel module newlib.library.kmod+0x00003558
openjk_sp:_start()+0x170 (section 7 @ 0x16C)
native kernel module dos.library.kmod+0x0002a5c0
native kernel module kernel+0x00041744
native kernel module kernel+0x0004178c

PPC disassembly:
ffcfcfc4: XXXXXXXX illegal address
ffcfcfc8: XXXXXXXX illegal address
ffcfcfcc: XXXXXXXX illegal address
ffcfcfd0: XXXXXXXX illegal address
ffcfcfd4: XXXXXXXX illegal address

System information:

CPU
Model: P.A. Semi PWRficient PA6T-1682M VB1
CPU speed: 1800 MHz
FSB speed: 900 MHz
Extensions: altivec

Machine
Machine name: AmigaOne X1000
Memory: 2097152 KB
Extensions: bus.pci bus.pcie
============================================

@Daytona675x

With your one:

Cube: black screen on running (as amiga_os have with Jedi)
Lugaru: all fine, no white textures
Quake3: the same hang as before

While blackscreen on running seems becaue of latest change you do now, quake3 hangs the same as it hangs for my builds and seems it caused by any of the changes done since you build precompiled libraries (which works fine). Maybe that glDrawRangeElements change make thing going weird somehow ? Or when adding GL_ARB_draw_elements_base_vertex and GL_ARB_map_buffer_range extensions something going weird which can cause q3 use wrong ones or so ?

EDIT: i for now tried to disable GL extensions in Q3 , and then q3 runs with your library. But once they enabled : hangs. Which make me think its indeed can be something about adding extensions (maybe when adding new ones somehow ancidentialy remove some code and old extensions stop work correctly?)

@amig_os
Thanks for checking!

@kas1e
Okay, sounds all plausible now:

1. your continuing Q3 crash may well be because of other config than mine, using certain extensions.
2. Lugaru textures etc. now fixed, because of the new Capehill-et-others workaround.
3. after my working pre-built binaries the only remaining thing that has been added that would explain (1) is rev 533 with those extensions Biró added.

I will now check and fix those extensions.

EDIT: found and fixed a bug inside the new GLDrawElementsBaseVertex implementation. Biró took GLDrawElements and modified it to become that new one.
And there's an ugly bug inside! If flat-shading is enabled and GL_POLYGON is used, then the index-pointer will be incremented one extra time per polygon
This bug has not been added by Biró! It was there before, I only noticed it because Biró modified the buggy line when (correctly) adding the base-vertex feature
Other than that I didn't see anything yet. I doubt that this was it, but updated the test-lib anyway.

EDIT: because I don't see any suspicous anymore, I simply made two additional test-libs; one without the one extension, one without the other. Let's see what happens.
http://www.goldencode.de/tmp/mgl_nodrawelemext.zip
http://www.goldencode.de/tmp/mgl_nomapext.zip

@Daniel
With last one (tmp/mgl.zip) visually all fine, i.e:

Cube : no more black screen, no white textures, all fine
Lugaru: no white textures, all fine
Q3 : runs with extensions too (yeah).


But, also find the new big problem :(

Most of time i can't run many times the same app. For example, if i run Cube and exit and then run again adn exit, and doing that few times it crashes on one of running right at begining in the MiniGL Watch-DOG.

Or, if i run/exit quake3 many times (let's say 3-4-5 times), it also crashes on running on last run.

Or, what is more easy to check, if i just run "testgl" from fresh SDL1 release, exit from, and then run again, it also crashes with ABADCB02 in DAR.

All the time crashes didn't point on any registers, everything freezes before stack trace is dumped. Like something very heavy happens with memory/system/etc.


So i doing tests of all libs flying around:

minigl.library 2.20 : all fine, no such crashes
minigl.library 2.21 : all fine, no such crashes
minigl.library 2.22 : didn't have that one
minigl.library from your precompiled_binaries : all fine, no such crashes
minigl.library from your last test archive : issue there

What it mean that there is something still wrong in changes done after you made precompiled binaries.

It also can be that this problem starts early, just i by some luck can'rt reprodce it with library from precompiled_bins.7z for now

Will check how your last 2 libs reacts

@Daniel
Issue with freezes on running of different minigl apps happens also and with your libraries from precompiled_bins.7z.

For example, i run 5-6 times testgl, then trying to run Cube : os freezes.

With 2.20 and 2.21 all fine.

Can you also build 2.22 for tests so we can rule out versions ?

Probably it can start happens after that heavy refactoring with removing allocvecs, adding tabor, etc , etc.

@kas1e
Bad luck then, and all rather vague. I wouldn't wonder if 2.20 / 2.21 starts to become unstable too if you run everything often enough
Anyway, there's not much stuff that had been done that could provoke a freeze. Pretty much the only thing that is theoretically capable of causing this is the replacement of the deprecated alloc und iorequest functions. The first had been disabled long ago, the other I have reverted back to old style functions right now:
http://www.goldencode.de/tmp/mgl_oldalloc.zip
I'm gone now, for the weekend at least

@Daytona675x

Found potential issue in others.c, extension string buffer is too small in case of VBOs:

if (context->VBOSize > 0) {
size += strlen(" GL_ARB_vertex_buffer_object"); // missing " GL_ARB_map_buffer_range" ?
}

It would be probably safer to use macros here to avoid duplicated strings.

@Capehill
Great, very nice catch! And crap code indeed, yes a macro will do.

Suspicious code in createcontext.c:

else if (privateBuffers == 2 && pFrontBuffer && pBackBuffer) {
width = IP96->p96GetBitMapAttr(pFrontBuffer, P96BMA_WIDTH);
height= IP96->p96GetBitMapAttr(pBackBuffer, P96BMA_WIDTH); // HEIGHT?

Also why other value is read from front and other from back?

@Capehill
Don't ask me, I didn't write that mess
Let's please concentrate on getting the previous changes made straight. The purpose of this here is not to fix every one of the trillion potential other MGL issues while we are at it... :P Report those in the usual way please.

I just fixed the extension-string issue and rewrote this mess so that sth. like that cannot happen anymore. Commited that already to the SVN, feel free to check it out.
Also, because there's a very good chance that this was the reason for those random crashs on kas1e's side thanks to memory being overwritten, I updated the test-build here (and removed those others):
http://www.goldencode.de/tmp/mgl.zip