BlitzQuake

[Cowcat]

Old WOS_Blitz does not work (anymore) it shows this exception error window.

Old Blitz wos crash with (some/all?) Permedia2. That's why I rebuild Blitz it in the first time. It doesn't crash on Morphos but rendering window bugs/hits/etc.etc still remain even that test (68k or Wos).

On my system Intuition is not able to do the change, the requester stays.

Yep. Same happens with oldglquake and minigl.lib demos. It's a problem with minigl.lib AFAIK. Will check that. I think other apps non related with w3d had the same issue with my system: A big full window program usually did that with me (or maybe not )

There's no Permedia2 3D driver on old/new Morphos so.......

For Morphos 1.4 I renamed/saved W3D Mos libraries & copied old W3D amiga libs in it. Nothing more if I remember well.

But you need a stack like 819200 for everything WOS related & -ahi command too. Old Morphos 1.4 is unstable on my system anyways

EDIT:

- copied from my OS3.9 lowlevel.lib, all warp libs and the Warp3d drawer to Sys:Libs

No. Everything but lowlevel.lib to Morphos/Libs.

[Cowcat]

@Alexco.

LOL ! Seems that old glgears 68k/wos in windowmode also breaks the screen requester/intuition, but not for full mode screen (at least on my system). Not really a CLI thing. The same for maybe all w3d programs that I have coded.

If it doesn't affect Voodoo users, probably is another more bug found for Permedia2/Gfx drivers.

[Cowcat]

Found that a lonely LockPubScreen for window output was kept on mgl.lib code & that prevents intuition from changing modes. Yep, that is on old W3D demos....

So if someone needs that fixed I will upload a new Blitz build (ow wait till next version)

[matthey]

Originally Posted by Cowcat

Found that a lonely LockPubScreen for window output was kept on mgl.lib code & that prevents intuition from changing modes. Yep, that is on old W3D demos....

Maybe you should become the new MiniGL maintainer. If you put together a bug fixed MiniGL then these problems would be fixed once and for all.

I found what looks like a bug in snd_mixamiga68k.s which I am investigating. This code:

   move.l a1,d0
   and.b #$fc,d0   ; 32-bit aligned output?
   beq.b .loopaligned

Should probably be:

   move.l a1,d0
   and.w #3,d0   ; 32-bit aligned output?
   beq.b .loopaligned

I don't think it will make the sound work as the sound doesn't work with the original C source. Maybe it will be a little faster as the assembler code will often fall through to the unaligned Paula 8 bit mixing routine. I have made some other changes to try and improve the code for the 68060. Unfortunately, it's kind of difficult to test without the sound working.

[Cowcat]

bug in snd_mixamiga68k.s

The PPC original code is:

loop8:
	andi.	r31,r3,3
	beq	loop8_aligned
	# unaligned, bytewise transfer

Certainly it's what you propose.

If you put together a bug fixed MiniGL then these problems would be fixed once and for all.

You know it should be tailored for every program. And "once and for all" is a quote written in the context.c source, that ironically broke a lot of things.

// set constant elements of vertexpointers once and for all
        context->w3dContext->CPFlags = 0;
        context->w3dContext->VPFlags = 0;
        context->w3dContext->TPFlags[0] = W3D_TEXCOORD_NORMALIZED;
        context->w3dContext->TPVOffs[0] = 4;

And that TPFlags f****me up for half a year

Still don't know if it's a w3d library problem or a minigl one. Refer to my old "warpos-minigl blues".

[jack-3d]

I have finally tested the Blitzquake 5-5 060 and PPC on my second Amiga (A1200, BPPC/060, Mediator TX, Voodoo3 3k). When I start both versions everything works and looks very nice (I mean when wathing the realtime demo play) but just until I initiate game menu with pressing ESC. Here is what happen then:

Blitzquake 5-5 PPC: demo that was playing still continues nicely on the background, but the game menu is not readable, it looks just like strange artifacts. Game quite works, but menu is absolutely unreadable.

http://jack.untergrund.net/Amibay/Q1/DSC03291.JPG
http://jack.untergrund.net/Amibay/Q1/DSC03293.JPG

Blitzquake 5-5 060: game looks perfect, but then when menu is initiated, polygons in the game start to appear randomly the graphics is chaotic. Menu is also unreadable and when I find how to quit game my Amiga freeze.

http://jack.untergrund.net/Amibay/Q1/DSC03294.JPG

Libs:
powerpc.library 16.1beta1 (7.1.2001)
warp.library 5.1 (7.2.2001)
warp3d.library 4.2 (01-Oct-11)
warp3dppc.library 4.2 (03-Sep-01)
w3d_avengerBEM and LEM all 4.2 (17-Feb-02)
Picasso96/Voodoo.card 4.30 (03-Sep-10)

And as I said before, on my A4000 Cyberstorm PPC and CVision PPC game runs absolutely nice, no problems, no artifacts, game quit works on both versions.

[Cowcat]

@jack-3d

Oops. Ok, the same happens for windowmode? How about old wos Blitz (should work for Mediator)?
We need more help from Mediator users about that: There's no bad report AFAIK from 68k or WOS users on that configuration.

[jack-3d]

I will check Window mode this evening. Old Blitz PPC makes only "Sam Jordan" error report window, and this is done on all of my PPC Amigas. Only the old Blitzquake 68k was working if I remember well but I will check that too to be sure.

Anyway the game play is beatifully fast, light effects are nice, console font is also working fine, just the menu graphics does not work, I can blindly browse menu start ne game or do quit, so I quess just some small bug. The 68k also works nice and fast (I have 060/66 and it is beautifully playable), but everything nice stops when going to menu.

[Cowcat]

I copy-pasted the original readme from old Blitz (some posts before) about Mediator libs use & heavy corruption: Maybe there's something in it for that issue.

[matthey]

@jack-3d
I use a Mediator+Voodoo4 (also have a Voodoo3) without this problem. I also have an overclocked CSMK3 68060@75MHz. The original and my modified W3D libraries both work without this corruption.

[Alexco]

Originally Posted by jack-3d

Blitzquake 5-5 PPC: demo that was playing still continues nicely on the background, but the game menu is not readable, it looks just like strange artifacts. Game quite works, but menu is absolutely unreadable.

http://jack.untergrund.net/Amibay/Q1/DSC03291.JPG
http://jack.untergrund.net/Amibay/Q1/DSC03293.JPG

That is exactly the same thing I mentioned some posts above. In my case the textures are not so colourful, they have more or less the colours from the game textures.
My system is a A4000D with CSPPC 200MHz (I think…) and G-Rex Voodo3. For Permedia 2 I do not have this issue.

[Cowcat]

Well, 2 similar problems :/

-Just to be on the same page, read my post "old readme Blitz" & try different options & windowmode.
-Any problem with W3D old demos? Maybe I will post a couple of minigl demos to try just in case.
-At beginning is "Voodoo" hardware recognized?
-Download old 5beta or 5_2 WOS version that stills here, important to know the behaviour (some small things were changed after those).

[jack-3d]

I just tested on BPPC + Mediator + Voodoo3:
68060 5.3 - everything is working fine
WOS 5.2 - everything is working fine

so only 5.5 is bad

Update: 5.5 in Window mode makes absolutely the same problem. So staying on 060 5.3 and WOS 5.2 and satisfied ;o)

[Cowcat]

Lucky I didn't erase those builds. The new 5-5 has better optimizations besides new options & cosmetics.
68060 old version had those colour bugs of course & new Permedia2 lib from Matthey is needed.

@jack-3d Have an idea of what it's the problem, PM me and I will send you a couple of versions to try.
Hope that those builds also work for @Alexco .

[Cowcat]

Well, seems that the problem is localized for some configurations but that means recompiling.

So as soon as possible I will upload the new builds: More optimizations & small bug fixes.

[Cowcat]

A little experiment.

[Cowcat]

We had some difficulties to test properly the new builds with bugfixes/optimizations. So I post two 060 versions to test.
Version A should work for everyone (if not I'm doomed), but has the old requester bug.
Version B works for me on Permedia2, but we had problems with Voodoo cards for implementing a workaround for that bug.
So test & comment !

[matthey]

@Cowcat
Both versions work fine here on my Mediator Voodoo 4. The bug in full screen mode is gone on both versions.

[Cowcat]

@matthey
Finally ! Well now I know why the LockPubScreen was maintained on mgl.lib all the time (but not closed): Seems that is needed that way for other gfx cards but Permedia & if I'm correct, opening a window mode poked on screen context & reverse (weird). That's why the latest attempt to fix it worked with window mode & not on full screen.

Well I wait a little for more comments, then I will upload the other versions.

[Michael]

Well, both versions seem to work fine or the same here on PM2.

But I have found the bogus purple dots and corruption solution!

This is tricky to reproduce, but it works!!!!

Load system 1024x768x16b screen
Change screenmode to 800x600x16b mode
Run glquake060_vbccB (double click file) no options
runs Q in default FS screen 320x240
Quit

Now run glquake060_vbccB again, but this time add -windowmode
Q runs in a 320 window and there is no corruption of console or purple gfx dots.

Whats interesting now, ran any version of Q, 68k or WOS and all work fime!
No GFX trashing.

But if you run Q first at boot in 320 window, the problem is there with 68k and WOS versions

So something funny is going in between screenmode change and running Q in FS first time. (Some registers setup differently again ?)

PS: The mouse limit to window size should not cause any problems
because screen limits do not cause any problems to rotation movement
I can rotate indefinitely with the mouse on the side of the screen.
And top to bottom view does not require the mouse to move more then 200 pxls anyway. So please look at this issue again when you get the time.