BlitzQuake

[Cowcat]

See if using only -ahi, those hits dissapear.

some *_RGB added that does the funny rendering mode.

This is for Colored Light Maps http://aminet.net/package/game/data/BlitzQuake_lit

No luck for Permedia users

By the way: Any idea for using Enforcer or some debugger like that ?: It hangs on my system.

[Michael]

I am running SegTracker 45.1 and CyberGuard 2.6 all the time, never had problems.
With default P5 libs (68060 and powerup).
It also works fine with warpup after termination or BPPCfix.

As for Q1....

-ahi <- did not help, same hits
-nosound <- still get the hits, but they point to other locations now, and change!

Some other version I have tried failed with newer audio.device,
and worked fine with the rom based one or with ahi (I am using the newer C version 6.7).


Name: "Shell Process" CLI: "glquake68060_vbcc" Hunk 0000 Offset 0000B268
03-Mar-14 19:14:53
WARNING: ENFORCER HIT!
LONG-READ from 3F7FFC82 PC: 44B3FDEA
USP: 456BC320 SR: 0000 FLSW: 01010200 TCB: 449D0140
Data: 00000001 00000001 00000080 00000000 44AEF1F0 00000001 00000060 01400000
Addr: 44CE4ED8 44B3551C 3F7FFC7A 455CA0BC 455C7610 455CA044 44000AE8 456BC320
Stck: 455CA0BC 44CE4EB8 44CE4EC4 44CE4ED0 455CA0C0 C0000000 92F26FD5 DEE42672
Stck: 40050000 F7786D00 00000000 44B40FD6 455CA0BC 455C6D5C C0000000 92F26FD5
Stck: DEE42672 44B411F0 3F7FFA57 00000001 00000000 44B08358 40030000 B2768B5C
Stck: BFF47736 40030000 B2768B5C BFF47736 40030000 44B08358 44B6FDEE 44D86268
----> 44B3FDEA - "Work:Games/Quake/glquake68060_vbcc" Hunk 0000 Offset 0000B27A
----> $44b3fdea: FMUL.S $0008(A2),FP1
----> $44b3fdf0: FMOVE.X FP1,FP2
----> $44b3fdf4: FADD.X FP0,FP2
----> $44b3fdf8: LEA $0010(A7),A7
----> 455CA0BC - "Work:Games/Quake/glquake68060_vbcc" Hunk 0005 Offset 008F0B7C
----> $455ca0bc: MOVE.W (A0)+,-(A7)
----> $455ca0be: MOVE.B -(A4),A0
----> $455ca0c0: CHK.W A2,D1
----> $455ca0c2: BEQ.S $455ca096
----> 44CE4EB8 - "Work:Games/Quake/glquake68060_vbcc" Hunk 0005 Offset 0000B978
----> $44ce4eb8: DC.W $3df2
----> $44ce4eba: DC.W $df3d
----> $44ce4ebc: DC.W $bf7e
----> $44ce4ebe: DC.W $2dfd
----> 44CE4EC4 - "Work:Games/Quake/glquake68060_vbcc" Hunk 0005 Offset 0000B984
----> $44ce4ec4: DC.W $bf7e
----> $44ce4ec6: MOVE.W #$bdf2,$e295(A0)
----> $44ce4ecc: OR.B D0,D0
----> $44ce4ece: ORI.B #$a1,D0
----> 44CE4ED0 - "Work:Games/Quake/glquake68060_vbcc" Hunk 0005 Offset 0000B990
----> $44ce4ed0: MOVE.W -(A1),(A5)
----> $44ce4ed2: MOVE.L D7,-(A3)
----> $44ce4ed4: CMP.B $a7c6(A0),D6
----> $44ce4ed8: DC.W $455c
-cut-

Name: "Shell Process" CLI: "glquake68060_vbcc" Hunk 0000 Offset 0000B25C
03-Mar-14 19:14:55
WARNING: ENFORCER HIT!
LONG-READ from 3F7FFB72 PC: 44B3FDD8
USP: 456BC320 SR: 0000 FLSW: 01010200 TCB: 449D0140
Data: 00000001 00000001 00000080 00000000 44AEF1F0 00000001 00000060 01400000
Addr: 44CE4ED8 44B3551C 3F7FFB6E 455CA0BC 455C7610 455CA044 44000AE8 456BC320
Stck: 455CA0BC 44CE4EB8 44CE4EC4 44CE4ED0 455CA0C0 40010000 80000000 00000000
Stck: 40060000 82080000 00000000 44B40FD6 455CA0BC 455C6D5C 40010000 80000000
Stck: 00000000 44B411F0 3F7FFF4A 00000001 00000000 44B08358 40030000 C6338E6D
Stck: 15AD106F 40030000 C6338E6D 15AD106F 40030000 44B08358 44B6FDEE 44D86268
----> 44B3FDD8 - "Work:Games/Quake/glquake68060_vbcc" Hunk 0000 Offset 0000B268
----> $44b3fdd8: FMUL.S $0004(A2),FP1
----> $44b3fdde: FADD.X FP1,FP0
----> $44b3fde2: FMOVE.S $44ce4ecc.L,FP1
----> $44b3fdea: FMUL.S $0008(A2),FP1
----> 455CA0BC - "Work:Games/Quake/glquake68060_vbcc" Hunk 0005 Offset 008F0B7C
----> $455ca0bc: EOR.B D7,$3703(A5)
----> $455ca0c0: CHK.W A4,D1
----> $455ca0c2: EOR.W D2,(A1)
----> $455ca0c4: ORI.B #$00,D0
----> 44CE4EB8 - "Work:Games/Quake/glquake68060_vbcc" Hunk 0005 Offset 0000B978
----> $44ce4eb8: MOVE.W A2,A7
----> $44ce4eba: DC.W $ad36
----> $44ce4ebc: EOR.W D7,$44ce3993(PC)
----> $44ce4ec0: MOVE.W D1,A6
----> 44CE4EC4 - "Work:Games/Quake/glquake68060_vbcc" Hunk 0005 Offset 0000B984
----> $44ce4ec4: EOR.W D7,$44ce3e16(PC)
----> $44ce4ec8: CMP.W A2,D7
----> $44ce4eca: CMPA.W (A5),A0
----> $44ce4ecc: OR.B D0,D0
-cut-

Name: "Shell Process" CLI: "glquake68060_vbcc" Hunk 0000 Offset 0000B268
03-Mar-14 19:14:58
WARNING: ENFORCER HIT!
LONG-READ from 3F0885A6 PC: 44B3FDEA
USP: 456BC320 SR: 0000 FLSW: 01010200 TCB: 449D0140
Data: 00000001 00000001 00000080 00000000 44AEF1F0 00000001 00000060 01400000
Addr: 44CE4ED8 44B3550C 3F08859E 455CA0BC 455C7610 455CA044 44000AE8 456BC320
Stck: 455CA0BC 44CE4EB8 44CE4EC4 44CE4ED0 455CA0C0 00000000 00000000 00000000
Stck: 40050000 BC100000 00000000 44B40FD6 455CA0BC 455C6D5C 00000000 00000000
Stck: 00000000 44B411F0 3F336197 00000001 00000000 44B08358 40040000 FB9F1843
Stck: C3A42F1F 40040000 FB9F1843 C3A42F1F 40040000 44B08358 44B6FDEE 44D86268
----> 44B3FDEA - "Work:Games/Quake/glquake68060_vbcc" Hunk 0000 Offset 0000B27A
----> $44b3fdea: FMUL.S $0008(A2),FP1
----> $44b3fdf0: FMOVE.X FP1,FP2
----> $44b3fdf4: FADD.X FP0,FP2
----> $44b3fdf8: LEA $0010(A7),A7
----> 455CA0BC - "Work:Games/Quake/glquake68060_vbcc" Hunk 0005 Offset 008F0B7C
----> $455ca0bc: CLR.W -(A7)
----> $455ca0be: MOVE.B (A7),(A3)
----> $455ca0c0: CHK.L $e5(A6,A0.W*2),D1
----> $455ca0c4: ORI.B #$00,D0
----> 44CE4EB8 - "Work:Games/Quake/glquake68060_vbcc" Hunk 0005 Offset 0000B978
----> $44ce4eb8: CMPM.B (A0)+,(A7)+
----> $44ce4eba: BCC.S $44ce4ec9
----> $44ce4ebc: DC.W $bcbf
----> $44ce4ebe: BMI.S $44ce4e9b
----> 44CE4EC4 - "Work:Games/Quake/glquake68060_vbcc" Hunk 0005 Offset 0000B984
----> $44ce4ec4: EOR.B D6,$f2(A3,D7.L)
----> $44ce4ec8: DC.W $3f7f
----> $44ce4eca: ABCD -(A7),-(A0)
----> $44ce4ecc: OR.B D0,D0

[phx]

All hits I have seen are falling into a region between offset $b25c and $b27a of the first hunk. Looks pretty reproducible.

I would suggest not to strip any symbols froms the Quake executable (e.g. compile with -g option) and then use a tool like FindHunkOffset
http://sun.hasenbraten.de/~frank/projects/download/FindHunkOffset.lha
to determine the C function's name.

If you don't immediately spot an error in the C source, you can compile the appropriate module with -S option and find the hit-location in the compiler's assembly output.

Could also be in a part which was optimized in assembler.

[matthey]

Originally Posted by Cowcat

By the way: Any idea for using Enforcer or some debugger like that ?: It hangs on my system.

BDebug will read the vbcc debug info (compiled with -g option) and display the appropriate source if it finds it. BDebug is here:

http://aminet.net/dev/asm/BarflyDisk2_00.lha

BDebug is not a source level debugger so there is still a learning curve. Some CPU specific knowledge is required.

Instead of Enforcer, you could also try:

http://aminet.net/util/sys/Mu680x0Libs.lha

Take the time to read the documentation to avoid problems.

I also recommend Frank's vbcc specific version of FindHunkOffset he links to above .

The hits (x3 reads in a row) come from V_CalcRoll() in view.c. It looks like the pointer to the velocity vector passed to V_CalcRoll() is bad. If it doesn't go away after fixing a few more compiler warnings then I'll try to trace it back to the source. I'll not strip the debug info from the executables next time. It doesn't look like the hits are sound related.

Edit: I tested Cowcat's newest 040 build and the hits have gone away. The sound problems remain.

[Cowcat]

Ok. So the "little disk quake loading icon" is disabled on my last build, because those old reported problems. So I reenabled it in this 040 build to find a solution of what happens & an exercise for debug.

Debuggin': Used segtracker, Muforce and the output to Sashimi.

MuForce hit! Bad program!

LONG READ from 00000018                        PC: 6816D3EE
USP : 6715F566 SR: 0009  (U0)(-)(-)  TCB: 66552A20
Data: 00000000 00000010 00000400 665562C0 00000000 00010040 00000028 666FA004
----> 666FA004 - "glquake68040_vbcc"  Hunk 0000 Offset FFFFFFFC
Addr: 665527AC 66554D3C 6655286C 00000018 6655531C 6715F616 66553E84 6600260C
Stck: 00000004 665562C0 00000000 00010040 00000028 667A1154 6655531C 6655531C
Stck: 05BC0000 03F0006A 29C30000 00006654 D3900025 420CFFFF FFFF6672 63266715
----> 6816D3EE - "LIBS:Warp3D/HWdrivers/W3D_Permedia2.library"  Hunk 0000 Offset 0000016E
----> 667A1154 - "glquake68040_vbcc"  Hunk 0005 Offset 00021ADC
PC-8: 48E73E38 226D0008 70002051 24680034 243C0000 0400600A 2669000C D6FC0018
PC *: 20130C80 00000020 65EE47E9 00782013 662C47E9 0078202B 00046622 47E90078
6816d3ce :  48e7 3e38                  movem.l d2-d6/a2-a4,-(a7)
6816d3d2 :  226d 0008                  movea.l $8(a5),a1
6816d3d6 :  7000                       moveq.l #$0,d0
6816d3d8 :  2051                       movea.l (a1),a0
6816d3da :  2468 0034                  movea.l $34(a0),a2
6816d3de :  243c 0000 0400             move.l #$400,d2
6816d3e4 :  600a                       bra.s $6816d3f0
6816d3e6 :  2669 000c                  movea.l $c(a1),a3
6816d3ea :  d6fc 0018                  adda.w #$18,a3
6816d3ee : *2013                       move.l (a3),d0
6816d3f0 :  0c80 0000 0020             cmpi.l #$20,d0
6816d3f6 :  65ee                       bcs.s $6816d3e6
6816d3f8 :  47e9 0078                  lea.l $78(a1),a3
6816d3fc :  2013                       move.l (a3),d0
6816d3fe :  662c                       bne.s $6816d42c
6816d400 :  47e9 0078                  lea.l $78(a1),a3
6816d404 :  202b 0004                  move.l $4(a3),d0
6816d408 :  6622                       bne.s $6816d42c
6816d40a :  47e9 0078                  lea.l $78(a1),a3
Name: "Background CLI"  CLI: "glquake68040_vbcc"  


MuForce hit! Bad program!

LONG READ from 00000018                        PC: 6816D3EE
USP : 6715F566 SR: 0009  (U0)(-)(-)  TCB: 66552A20
Data: 00000000 00000010 00000400 665562C0 00000000 00010040 00000028 666FA004
----> 666FA004 - "glquake68040_vbcc"  Hunk 0000 Offset FFFFFFFC
Addr: 665527AC 66554D3C 6655286C 00000018 6655531C 6715F616 66553E84 6600260C
Stck: 00000004 665562C0 00000000 00010040 00000028 667A1154 6655531C 6655531C
Stck: 05BC0000 03F0006A 29C30000 00006654  00000400 665562C0 00000000 00010040 00000028 666FA004
----> 666FA004 - "glquake68040_vbcc"  Hunk 0000 Offset FFFFFFFC

Disassembled both W3D_Permedia.lib and this new build with Ira & Adis.

So, all that dissasembly is located at beginning of Permedia lib. Found it in source.

Then the output for hunk in quake (if I'm not wrong usign it):

findhunkoffset glquake040  0x0005 0x00021adc
 Section 5, offset 0x00021adc is at
__lastfile + 0x00011200

Questions for ace coder fellows:

Section 5 is "hunk_5,BSS" or "Section S_5,BSS" depending of using Adis or Ira for disassembling (I suppose that ! ) . Correct me if I'm wrong.

__lastfile is a "ds.l 1" located at that section.

Then from here, I'm puzzled of where the offsets go or represent. Where I have to point next?

Another question is where is the address (beginning) of program in memory from output of Muforce & if it is possible on Adis or Ira to put that address to compare.

This exe is only for testing that problem (-g compiled ) not a future one

P.S. Of course those problems happen for Mediator+Voodoo users also.

[Michael]

You are very lucky, I get a pool of hits. Have to break cyberguard in order for the game to start in FS, otherwise only grey screen. After exiting the game from FS, system crashes/freezes dead. On WB screen we see artefacts of disk icon in several places! How come they are drawn on a public screen?
PS: in game icon seems to work in FS mode (sort of).

[Cowcat]

Yes. If you have "hit finders" enabled all the time you can't do a thing. That's why I used serial output tooltype on Muforce and a shell with "sashimi > debug" to capture all hits that go to infinify. You need a reset Normally the game works with that problem as old builds did. Maybe the -g compile it's more prone to fail under this "debuggin set".

As I told to Michael, I blamed all WB screen artifacts to my hot Permedia so thought I had to live with that. Good that he spotted same problem ( yep, the day before I was amazed that tinkering the code that dissapeared)

Edit:
It's a crazy thing: Those disk wrong drawings happen at beginning and when you switch to menu or in between. You see that disk is drawn when you start the game, so it's drawn allways but not in the correct place, specially on windowmode. Now, if I code to only draw disk in FS the same hits happen (but you see it from the beginning). Nothing I did !!! it's also recurrent on old Glquake or BlitzQuake 68k original.

2nd Edit:

Disk icon uses originally the same function that put first quake picture. So something weird loading the texture ? Maybe we can have a pool to vote for killing disk

[Michael]

Managed to get OS4 version of GLQuake (1.09 - beta 7) up and running.
Problems the same ;-)
Disk icon rendering outside window!!! (just under bottom right corner of window)
Can't figure out how to get the texture for walls, the effect is similar to -lm_RGB flag
but slightly worse since a lot of polygons fan out and everything looks really odd.
Any ideas, commands, settings?

With this crap on screen timedemo1 gives 13 FPS in 512x384-16 window

[matthey]

Originally Posted by Cowcat

Ok. So the "little disk quake loading icon" is disabled on my last build, because those old reported problems. So I reenabled it in this 040 build to find a solution of what happens & an exercise for debug.

Debuggin': Used segtracker, Muforce and the output to Sashimi.

There is nothing wrong with using Sashimi, especially if you have other programs producing debug output, but you can use the FILE option of MuForce also. Examples:

FILE=CON:0/40/640/100/MuForce_Hit/Auto
FILE=t:MuForce_Hits.txt

The same FILE output is also used by MuGuardianAngel.

Originally Posted by Cowcat

MuForce hit! Bad program!

LONG READ from 00000018                        PC: 6816D3EE
USP : 6715F566 SR: 0009  (U0)(-)(-)  TCB: 66552A20
Data: 00000000 00000010 00000400 665562C0 00000000 00010040 00000028 666FA004
----> 666FA004 - "glquake68040_vbcc"  Hunk 0000 Offset FFFFFFFC
Addr: 665527AC 66554D3C 6655286C 00000018 6655531C 6715F616 66553E84 6600260C
Stck: 00000004 665562C0 00000000 00010040 00000028 667A1154 6655531C 6655531C
Stck: 05BC0000 03F0006A 29C30000 00006654 D3900025 420CFFFF FFFF6672 63266715
----> 6816D3EE - "LIBS:Warp3D/HWdrivers/W3D_Permedia2.library"  Hunk 0000 Offset 0000016E
----> 667A1154 - "glquake68040_vbcc"  Hunk 0005 Offset 00021ADC
PC-8: 48E73E38 226D0008 70002051 24680034 243C0000 0400600A 2669000C D6FC0018
PC *: 20130C80 00000020 65EE47E9 00782013 662C47E9 0078202B 00046622 47E90078
6816d3ce :  48e7 3e38                  movem.l d2-d6/a2-a4,-(a7)
6816d3d2 :  226d 0008                  movea.l $8(a5),a1
6816d3d6 :  7000                       moveq.l #$0,d0
6816d3d8 :  2051                       movea.l (a1),a0
6816d3da :  2468 0034                  movea.l $34(a0),a2
6816d3de :  243c 0000 0400             move.l #$400,d2
6816d3e4 :  600a                       bra.s $6816d3f0
6816d3e6 :  2669 000c                  movea.l $c(a1),a3
6816d3ea :  d6fc 0018                  adda.w #$18,a3
6816d3ee : *2013                       move.l (a3),d0
6816d3f0 :  0c80 0000 0020             cmpi.l #$20,d0
6816d3f6 :  65ee                       bcs.s $6816d3e6
6816d3f8 :  47e9 0078                  lea.l $78(a1),a3
6816d3fc :  2013                       move.l (a3),d0
6816d3fe :  662c                       bne.s $6816d42c
6816d400 :  47e9 0078                  lea.l $78(a1),a3
6816d404 :  202b 0004                  move.l $4(a3),d0
6816d408 :  6622                       bne.s $6816d42c
6816d40a :  47e9 0078                  lea.l $78(a1),a3
Name: "Background CLI"  CLI: "glquake68040_vbcc"  


MuForce hit! Bad program!

LONG READ from 00000018                        PC: 6816D3EE
USP : 6715F566 SR: 0009  (U0)(-)(-)  TCB: 66552A20
Data: 00000000 00000010 00000400 665562C0 00000000 00010040 00000028 666FA004
----> 666FA004 - "glquake68040_vbcc"  Hunk 0000 Offset FFFFFFFC
Addr: 665527AC 66554D3C 6655286C 00000018 6655531C 6715F616 66553E84 6600260C
Stck: 00000004 665562C0 00000000 00010040 00000028 667A1154 6655531C 6655531C
Stck: 05BC0000 03F0006A 29C30000 00006654  00000400 665562C0 00000000 00010040 00000028 666FA004
----> 666FA004 - "glquake68040_vbcc"  Hunk 0000 Offset FFFFFFFC

Disassembled both W3D_Permedia.lib and this new build with Ira & Adis.

So, all that dissasembly is located at beginning of Permedia lib. Found it in source.

The hit is coming from in W3D_Permedia2.library. It looks like either a bad context was passed in, there is a bug in the library or there is corrupted data in the context. Let's look at the problem:

   movea.l (8,a5),a1   ;W3D_Context
   moveq #0,d0
   movea.l (a1),a0   ;W3D_Context->driver
   movea.l ($34,a0),a2  ;W3D_Context->driver->??? (private)
   move.l #$400,d2
   bra.b lab_170
lab_166:
   movea.l ($c,a1),a3  ;W3D_Context->regbase=NULL (Permedia2)
   adda.w #$18,a3   ;($18,regbase)= inFIFOSpace (Permedia2 register)
   move.l (a3),d0   ;<-read hit ($18,regbase)=($18+0)=($18)
lab_170:
   cmpi.l #$20,d0   ;reset value=$20
   bcs.s lab_166   ;busy loop until Permedia2 FIFO is empty?

W3D_Context->regbase should not be NULL! This code is used a lot from various W3D functions, for example W3D_DrawPoint(), W3D_DrawLine(), etc. Is this hit repeatable? If this hit is repeatable, you should try the original W3D libraries to see if it goes away. It may be possible to use a debugger like BDebug that stops at the hit and backtrack out of the W3D_Permedia2.library and Warp3D.library to the glquake040 function call that caused the hit. This is tricky as sometimes multitasking can be turned off or problems happen when the hardware is accessed too slowly.

Then the output for hunk in quake (if I'm not wrong using it):

findhunkoffset glquake040  0x0005 0x00021adc
 Section 5, offset 0x00021adc is at
__lastfile + 0x00011200

Questions for ace coder fellows:

Section 5 is "hunk_5,BSS" or "Section S_5,BSS" depending of using Adis or Ira for disassembling (I suppose that ! ) . Correct me if I'm wrong.

__lastfile is a "ds.l 1" located at that section.

Then from here, I'm puzzled of where the offsets go or represent. Where I have to point next?

The PC points to where the hit is which is in W3D_Permedia2.library. This offset in glquake040 is from data that is on the stack. It's common to have function return addresses on the stack but this isn't one. You used FindHunkOffset correctly but it's useless information in this case. It should be possible to use the MuForce STACKLINES=num option to get more potential return addresses in the hit output.

Another question is where is the address (beginning) of program in memory from output of Muforce & if it is possible on Adis or Ira to put that address to compare.

You should be able to find the base hunk addresses with Scout or other programs. I am not aware of an option in ADis or IRA to add a value to the base address. ADis -a2 or -a3 does allow to display the start of each hunk from 0 which matches the offset MuForce outputs.

This exe is only for testing that problem (-g compiled ) not a future one

I want the future one yesterday .

[Cowcat]

Good explanations

you should try the original W3D libraries to see if it goes away

Yep, I'm using the original ones.

So to be more precise someone should check if the same output debug happens for W3D_Avenger libs.
Oddly enough, the old gcc 68k has a different output and no W3D libs appear in it AFAIK.

Anyways, my guess for today is that something in minigl lib could be one of the causes:

That leads to my old thread "WarpOS minigl blues" and how I modded minigl code to work with simple vertex array programs for PPC: So now with more knowledge and proper tools , the problems (hits) are in 68k demos also !! (varray.c, varray_new.c) but didn't crash.

So.....not to worry for this for now: New warpos & 040 Blitz versions are now build with better code (maybe faster for wos) & multitasking for Full Screen that I forgot (someone notice !) Time.

[Michael]

Done some more tests, and they are very good
Multitasking works and we have some free cpu time!
68K/WOS/PPC meters.
Interestingly, the loads don't change much in 320, 512 or 640 modes.
Also interesting to see where Quake struggles and where its free
the meters can change from 50% to 98%, but generally it's 75-95%

[Cowcat]

New ones

Didn't put any icon or script in it. Apparently it seems that there's no need for "stack".

I use this:

glquakewhatever -windowmode 512 -nocdaudio -nojoy -nopsx -particles 512 -texturemode gl_nearest -extensions   (-maxsize 128 for gfx hardware with problems or low memory).

Test & play. A 060 version should follow in future

[Michael]

Check this out! Two Quakes at the same time in 512x384 windows
Resources are divided equally, and give 8 fps for both doing a simultaneous demo run. PPC CPU resources are 100% busy now, WOS Kernel is at 90%, and 68K is at 25%.
So I guess the main speed limiter is the Permedia2 and further improvement in speed is in GL optimization. Of course any further optimization is welcomed

[Michael]

The 5.2 040 build is amazing! Running 17 fps in 320x240 and 13 fps in 512x384.
No hits so far, but it did freeze the OS on exit.
I guess there is space for ppc code to be much faster too!

[Cowcat]

Two Quakes at the same time in 512x384 windows

040 build.  No hits so far, but it did freeze the OS on exit.

Yep. That's something I found that happens also in my system on 68k builds maybe from time to time. Never warpos.

Yesterday I did some full running timedemos & kept debuggers running for every session.
No crash but grabbed something interesting related to RAM hits on exit, but nothing related to Quake.

@Michael, try it. Maybe is an undisclossed system bug under heavy conditions.
Too lazy today to post a full debug but something like "Rom - ram 44.23 (8.4.2001)" it's in it.

EDIT:

IMPORTANT: All 68k builds need "CopyMem" patch program to run. Not for WarpOS in this moment..

[James]

Originally Posted by Michael

No hits so far, but it did freeze the OS on exit.

Only tested in WinUAE, but not only does quitting cause a freeze occasionally, it always makes the AmiStart bar disappear. I have to use CxControl at the end of my launch script to make it appear again...

[Cowcat]

always makes the AmiStart bar disappear

Installed AmiStart 0.64. The bar is allways drawed (tested both versions)

[James]

Originally Posted by Cowcat

Installed AmiStart 0.64. The bar is allways drawed (tested both versions)

Sorry, should have said I was using 0.66c from AmiKIT:

http://amikit.amiga.sk/download/misc...66c-AmiKit.lha

Maybe that will work for you too, it could be something particular to my config that causes it. I run thousands of different games and programs on this setup though, and this seems to be the only program that causes this to happen...

[Cowcat]

@James.
Of course, testing every possible patch or wb feature or WinUAE it's a task one alone can't do. But it's good to know if something can fail to be aware of it.

My system is pretty much clean: 3.9 BB2, Blizkick with patched rom + some modules. Original W3D libs (sometimes others to test) and WB with only Magic Menu + ToolsDaemon. Boring but less to take care of.

[Michael]

What other W3D libs ?! Basically you have the latest betas 4.2a (I think) or (4.0 for WipeOut if you need engine trails). There are a few hacks for 68k, but ppc ?!

Also wondering what's so special about copymem patches for 68k? I believe I have used CMQ forever and it is supposed to be one of the fastest. Anything else?

And one more thing, current 68k build has a problem with LOADING message and PANEL when the levels / demos chage, they are all black squares. WOS version is ok.

All version have a broken transparent water. It just goes crazy when you enable it. And screen rendering goes nuts ;-) (Works, sort of, in the old first GLQuake)