BlitzQuake

[Michael]

Found another 100% leak case.

To test, run -game malice -windowmode
and wait for the demos to roll
When we enter second demo after a few seconds (just after the parachute jump) we get the first 20 pxl wide stripe through the screen.
Then just a few seconds later the top half screen gets trashed.
Reproducible 100% with all last Q-WOS versions.

[Michael]

Tested the 68k test version for the same, and they do not have this bug.
But! When the demos are running or you play the game,
you do get a top half frame trashed frame inside the window that is obviously cleared with the next frame. Happens once every 2 minutes or so, or maybe depending on what is happening in game.

[Cowcat]

@Michael
I don't know. In fact I don't remember the bogus color dots because anyway my system is trashed & punished and can't fix what I can't really see. You tell that it happens only in window mode with 320x240 low resolution on your Permedia: Well I see yellow squares on every half texture even using -maxsize to lower texture load, but I know it's my system......
There are some funny things that happen on some systems but not on others like misaligned fonts on help menu as some notice: There are no fonts, they're textures loaded the same way that other textures in the game. Some people have that bug but others not.

Still bugs arise: Some in older libs, some in compilers, some in the game. In fact we spend more time fixing & doing workarounds for those than updating the game. And now I know that some people couldn't run the game since version 5.2....

Window mouse pointer limit: If a fellow coder knows a way to check the pointer against an intuition window without big overhead applied to something like Quake & without context switches on WOS please post code (Quake2 code is not a valid example).

By the way, the newer build has besides other things, mouse handler more optimized.


Edit: I see more things Michael!
More Edit: Are you using DOpus for WB Michael?

[Cowcat]

@Michael
I run newer & older WOS builds with Malice as you did and didn't see that screen mess.

[matthey]

@Michael
I had a problem with a trashed screen kind of like that (but the whole screen) with the Mediator. It was the new pci.library 9.9. I went back to pci.library 9.7 and the problem went away. Something like this could be a bug in the P96/CGFX system or 2D driver or in the I/O bus software. Something like this is not necessarily 3D related.

[Cowcat]

Hope that those work for everyone.
Optimizations + bug fixes for sound on 68k & more math code from Matthey.
Mouse Handler optimized + code cleaning + requester bug.

Little "loading disc" is disabled by default (again) but can be enabled with option
-ddisc, but that workaround doesn't work at all for some systems....

The old Blitz Docs are also inside plus new readme.

[Michael]

The purple dots of 320x window mode only, all versions 68k/WOS

[Cowcat]

@Michael

See those pictures: 1024x768 WB (right picture, the other is 800x600) has that behaviour on my system (yellow blocks on 320x200), but I know that it's my ppc hardware. Anyways both screen modes don't have any purple bugs.

So?

[Alexco]

I tested the new 5.6 version on both Voodoo3 and Permedia2. No issues so far. The only thing is on V3 with the -ddisc parameter the menu gets trashed (those texture thing) on both 68k and PPC versions.

[Cowcat]

@Alexco
On your V3, "disc icon" is the thing that messed all. Works for Matthey's V4 & Permedia. Also fixing the screen requester lock that worked for you, didn't worked for V4 AFAIK. Juggling bug fixes on either side.

[Alexco]

So what exactly is the purpose of this disc icon? I don't see a difference with or without on my p2?

[Cowcat]

So what exactly is the purpose of this disc icon?

To show disc data access. Also if someone says "Candyman" every time it appears, something wrong could happen, so for security reasons I disabled it.

[Michael]

Small update with my bugs...

-ddisc works ok here, wb screnmode changes do not get locked.

1. Purple dots bug
Actually, all you need to do after booting is change screenmode once.
Then, running any version Q in 320x window mode works ok.
Running Q straight after booting will give the purple pixls and eventually corrupt console font bug (320x window mode only!).

2. The trashing of screen with Malice demo2
This bug seems to be cured in 5.6 update, running in a loop for an hour, no problems. But I did notice one odd thing, this happens only on first loop of demo2 after running Q, and does not happen later. If previously I had the outside window corruption, now I get 3-5 badly rendered frames while demo2 is doing it's first loop. The frames themselves are probably ok, but the colours are odd, usually all bright green or something, as if blue and red are missing. This 3-5 frames happen at around 30 sec intervals. Maybe something misses the caches on first run...

[jack-3d]

5,6 testing (included new Warp3D.library and new Warp3DPPC.library):

A4000 (604e/200+Permedia2) = 20,9
A1200 (603e/330+Voodoo3) = 28,5

PPC is working fine, but I see some strange performance difference in 68k:

A4000 (060/50+Permedia2) = 11,4
A1200 (060/66+Voodoo3) = 12,1
A1200 (060/50+Voodoo3) = 9,6

The 060 version seems to be very different on Permedia2 and Voodoo3. I tested also Blitzquake version 5,3 060 version and it seems to be a bit faster:

A4000 (060/50+Permedia2) = 11,5
A1200 (060/66+Voodoo3) = 12,5
A1200 (060/50+Voodoo3) = 9,7

Now tell me why is the Voodoo3 slower then the Permedia2? I think it should be vice-versa.

Last test I did was Quake 2 68k (by Hyperion) and it confirmed situation:

A4000 (060/50+Permedia2) = 10,1
A1200 (060/50+Voodoo3) = 7,8

[matthey]

Originally Posted by jack-3d

5,6 testing (included new Warp3D.library and new Warp3DPPC.library):

A4000 (604e/200+Permedia2) = 20,9
A1200 (603e/330+Voodoo3) = 28,5

PPC is working fine, but I see some strange performance difference in 68k:

A4000 (060/50+Permedia2) = 11,4
A1200 (060/66+Voodoo3) = 12,1
A1200 (060/50+Voodoo3) = 9,6

The 060 version seems to be very different on Permedia2 and Voodoo3. I tested also Blitzquake version 5,3 060 version and it seems to be a bit faster:

A4000 (060/50+Permedia2) = 11,5
A1200 (060/66+Voodoo3) = 12,5
A1200 (060/50+Voodoo3) = 9,7

Now tell me why is the Voodoo3 slower then the Permedia2? I think it should be vice-versa.

The Voodoo 3 Avenger is a much faster gfx chip than the Permedia2. However, the Voodoo 3 is usually going over a slow gfx bus, has to do BYTEREV/SWIZZLING for registers accesses and the 68k W3D driver is less optimized than the Permedia2 driver. I would still expect the Voodoo 3 to be faster than the Permedia2 in most cases. Perhaps Quake is selecting a big endian (BE) gfx mode for you. BE modes are significantly slower for some Voodoo 3 operations. LE gfx modes have a "PC in the name. I am using a Voodoo 4 on a Mediator and Quake does choose a LE "PC" mode for me in all cases. Maybe we need a BlitzQuake "-mode modeid" and "-mode ?" (for a screen mode requester) command line option .

[jack-3d]

I will soon test that also on Blizzard PPC (also 330 MHz and 060) and BVision and compare it with that two systems. BTW I use Avenger LEM and BEM, I mean have those in Libs, could it be the problem?

[Cowcat]

Now tell me why is the Voodoo3 slower then the Permedia2?

Try V3 + same machine window mode & full screen. It is discused posts ago that mediator drivers have something weird for full screen that make it slower than window mode. @Bamiga2000 did "FullWin" because of this.

@Jack-3d
Ok on those tests but what are the options used? I guess you use FS & few options.

On my experimental W3DPPC lib: Some difference after using old lib? @Alexco told me that made timedemo 1-2 FPS faster on both cgx cards. A new one is on the way but I don't know if it works with Mediator hardware: I have disassembled mediator-ppc-lib but some of the tricks to be done, I can't test without the hardware.

@Michael
Finally you found how to deal with purple dots.

@Matthey
I should compose a song: "The more bug fixes, the more mode options".

[matthey]

Originally Posted by jack-3d

I will soon test that also on Blizzard PPC (also 330 MHz and 060) and BVision and compare it with that two systems. BTW I use Avenger LEM and BEM, I mean have those in Libs, could it be the problem?

The Mediator 1200 has a slower gfx bus than the big box Mediators. Cosmos has experimented with trying to speed up the W3D Avenger LEM and BEM libraries. He claims to have a version that works without the many NOP instructions (very slow on 68040+) in the original executables (in all the W3D Avenger libraries but not the Permedia2 libraries). There is not much difference between the Elbox and original W3D libraries. They are both embarrassingly awful 68k code. The BVision avoids the gfx bus bottleneck by connecting directly to the CPU card.

[jack-3d]

Originally Posted by Cowcat

Try V3 + same machine window mode & full screen. It is discused posts ago that mediator drivers have something weird for full screen that make it slower than window mode. @Bamiga2000 did "FullWin" because of this.

060/50 full screen = 9.6
060/50 window = 9.9

Originally Posted by Cowcat

@Jack-3d
Ok on those tests but what are the options used? I guess you use FS & few options.

I use still th same recommended parameters:
-particles 256
-texturemode gl_nearest
-extensions
-gamma 0.8
-width 640
-height 480

Originally Posted by Cowcat

On my experimental W3DPPC lib: Some difference after using old lib? @Alexco told me that made timedemo 1-2 FPS faster on both cgx cards. A new one is on the way but I don't know if it works with Mediator hardware: I have disassembled mediator-ppc-lib but some of the tricks to be done, I can't test without the hardware.

I speak about BlizzardPPC, Mediator and Voodoo3, because I tested various libraries only there (on CGX and Permedia I will teste it later). So I guess you mean Warp3D.library. I tested one in version 4.2 (67648 bytes), I also tested betaversion 4.3 (66132 bytes) and also yours (38640 bytes). No big difference in performance.

[Cowcat]

Embarrassingly awful 68k code

Not so ugly for WOS code but I should mention how w3dppc lib works on some important functions & what I'm trying to achieve (it's coders board anyways):

I borrowed Cosmos's idea about removing all version 3 warp3d code that lurked the lib & that's why almost 40k are gone on my experiment (someone has Envarc:warp3d/forceversion/off on a version 4 lib?)

The problem, to my logic, is not that that version 3 code is totally unused, is that 16 registers & half a
K stack frame is used every time a check for "forceversion" is done on 2 important functions. The check for normal "version 4" goes to a call to a simple offset every time, but you still have that overhead (and 10k of code lying arround doin' nothing for years).

Multiply the thousands of times W3D_DrawArray or W3D_DrawElements functions do on programs like GLQuake......

Don't try to sell anything of what is better or not, but some care could have be done on all those libs "a decade ago" OR PUT THE OLD SOURCES TO THE PUBLIC.