Quake 2 WorkShop

[grelbfarlk]

My problem is I did just what Cowcat said not to do, I had Cowcat's gameppc.dll in the baseq2 folder for the original version. The error message was something along the lines of Could not load file. Did not list what file that was.

Cowcat do you have any idea what I'm saying about the explosions not looking right? Like the explosion at the end of demo1 and grenade explosions where the yellow color is very dark?

[Cowcat]

explosions not looking right

Was that exposed previously? Matthey talked about problems with certain Voodoo cards and funny colors, not explosions in his case but the cube explosive items. If there are ok in Hyperion version could be the unreleased minigl code that probably fixes it. On source code there's a fix for some Permedia stuff (don't know what it does), but no Voodoo fixes are shown anywhere.

[grelbfarlk]

Any possibility of adding widescreen modes?

[Cowcat]

Any possibility of adding widescreen modes?

I have that for almost a year, but never released
A matter of time....

[ancalimon]

Originally Posted by Cowcat

Not a lot info to make a diagnosis.

If original works, certainly vbcc version should work better for a lot of reasons.

Could be a mismatched mix of different dll libs & cfg's of different Quake2 versions in the same place. Basically: Backup Hyperion version, or use a new Quake2 directory to test.

Don't use QuakeIIGUI exec (hyperion version) for loading vbcc version. No script lines or nothing: Launch "quake2" exec from shell or whatever launch options (I use ToolsDaemons).

For me, Hyperion version doesn't work quite right with my external keyboard: "Crouching" key event is missed somewhat.

It is finally running. Had to replace the gameppc.dll file inside baseq2 dir. The game was crashing with a failed requester and I fixed it by using Scout to remove the cocoline interrupt (I guess it is installed by the MX1000.driver that came with the optic mouse I got from AmigaKit)

I tried the beta2 version. Will try the vbcc verison later.

[Hedeon]

Could this (and/or BlitzQuake) benefit from AltiVec? If yes, in what parts would that be? (C2P for example?). Just asking.

[Cowcat]

AltiVec?

Certainly, but not pointing to Quake code but minigl.
I remember some mesa/gl PPC (or was old AmigaOS 4-minigl / Morphos-tiny-gl ?) code that have altivec related to matrix stuff. Basically find that old mesa stuff (nowadays there's no ppc support from mesa) & try to adapt it to existing old minigl.

But before going Altivec route I would have a C PPC backend that fully supports all float registers from G3/G4 in classic Amiga, so a lot of stuff related to keeping the pipeline happy (as Surgeon did in matrix.c) could be updated to "newer" G3/4.

Another hacky way could be tinker the output asm and move around stuff to be Altivec compliant. Maybe using output code from AmigaOS 4 ->minigl / Morphos stuff and compare with old minigl warpos output.
Sometimes I do stuff like that: Gears demo being a 10% faster using "frsqrte" instead of sqrt/divisions in the loop of "v_GenTexCoords/draw.c". But not of this is used in Quake (anyway gentexcoords is slow)

[Hedeon]

Stupid question (while recompiling vbcc :-P) but can't help vsc (part of the vbcc package) with that? It claims to schedule instructions (on a source level) to keep the pipeline happy.

Now I must admit that Frank only implemented 603/604 i see. But could an updated version help?

[Cowcat]

Question for me? wrong guy

How sonnet binaries look at assembly level? like a 603e ?
How Morphos binaries are scheduled given that all is g3/g4/g5 cpus ?
What about OS4 ?

If someone compiles the quake sources/minigl with 604 in mind, they see a real/big difference?. Some question could arise then: Are comercial warpos programs scheduled for 604 or 603e? My guess is 604 on ridiculous high 03 optimizations, but no vbcc is used.

The wizards of vbcc have those answers.

[matthey]

Originally Posted by Hedeon

Stupid question (while recompiling vbcc :-P) but can't help vsc (part of the vbcc package) with that? It claims to schedule instructions (on a source level) to keep the pipeline happy.

I believe only assembly sources are scheduled by vsc. This is low level code from the compiler backend.

high level language source code
|
v
compiler front end
|
| (intermediate code)
|
v
compiler back end
|
| (assembly code)
|
v
instruction scheduler
|
| (assembly code)
|
v
assembler
|
| (object file)
|
v
linker
|
v
executable

Originally Posted by Hedeon

Now I must admit that Frank only implemented 603/604 i see. But could an updated version help?

I would not expect an updated version of the vbcc PPC instruction scheduler to help much for a G3/G4. My logic follows.

1) not major changes in PPC designs between 604/G3/G4
2) superscalar scheduling is mostly not CPU specific
3) OoO already helps instruction scheduling
4) most PPC instructions are already 1 cycle
5) the backend code generation is more important than scheduling

There probably is some PPC code which is sensitive to CPU specific instruction scheduling like around FPU instructions, Altivec instructions, integer divide, etc.

[Hedeon]

Doesn't the number of pipelines also matter? Thought the G3 and G4 had more than the 603/604. Then it would help to schedule abcabcabc instead of ababab (3 vs 2 pipelines in this example). Information on wiki differs with other info (4 vs 5 stages for a 603, 1 versus 2 integer execution units.... etc.). So I'm not sure what the actual numbers are.

[Hedeon]

Originally Posted by Cowcat

Question for me? wrong guy

How sonnet binaries look at assembly level? like a 603e ?

I haven't looked. but the default settings for most stuff is 603. I compile with a 750 switch. I should do some testing if there is a difference.

Originally Posted by Cowcat

If someone compiles the quake sources/minigl with 604 in mind, they see a real/big difference?. Some question could arise then: Are comercial warpos programs scheduled for 604 or 603e? My guess is 604 on ridiculous high 03 optimizations, but no vbcc is used.

They used gcc. I'm not sure how the old gcc stands versus the new vbcc. You know this better ;-) I think I compiled your BlitzQuake sources against a 750, but seeing that 400MHz and 500MHz don't show a lot of difference regarding fps in this game, the bottleneck is somewhere else.

[matthey]

Originally Posted by Hedeon

Doesn't the number of pipelines also matter? Thought the G3 and G4 had more than the 603/604. Then it would help to schedule abcabcabc instead of ababab (3 vs 2 pipelines in this example). Information on wiki differs with other info (4 vs 5 stages for a 603, 1 versus 2 integer execution units.... etc.). So I'm not sure what the actual numbers are.

The 604(e) could issue 4 and complete 6 instructions every cycle using 6 execution units (2xsimple integer, 1xcomplex integer, 1xload/store, branch, FPU). This was the high end PPC for workstations and servers sparing no expense for large L1 caches either. The G3 could issue 2 and complete 6 instructions using 6 execution units (2xsimple integer, 1xcomplex integer, 1xload/store, branch, FPU). The shallower 4 stage pipeline length is borrowed from the 603(e) which saves transistors for a L2 cache (PPC needs huge caches for good performance) but also limits clock speeds. The G3 is a hybrid of both the 603 and 604 designs. While a similar clocked and die size 604e might outperform the G3 in a few benchmarks, the G3 is a more efficient design with resources where needed (604e: 64kB L1, 1MB ext L2, 5.1 million transistors G3: 64kB L1, 256MB-1024MB (ext then integrated) L2, 6.35 million transistors). The G4 design is practically a G3+SIMD unit. It looked like PPC might be able to outperform x86 when the G3 came out until they tried to clock up this shallow pipeline design. More G3 cores with SMP could have been added but single core performance would suffer (for games) and already large caches would grow more (due to poor code density). The '90s G3 design was relegated to energy efficient embedded uses and what is left of "modern" PPC processors from Freescale/NXP/Qualcomm. The G5 was an aggressive new high performance PPC design based on the 64 bit IBM POWER4 but turned out to be horribly inefficient.

I expect a G3/G4 would perform much better with 604 instruction scheduling than 603 instruction scheduling. It may even be desirable to schedule for the 604 if only one executable is released for 603/604/G3/G4. G3/G4 support with latencies for the CIU, FPU and SIMD unit (G4 only) probably wouldn't be difficult to add but would likely only make a difference for code using these units frequently and the code would have to be compiled for that specific processor (multiple executables). You could always e-mail Frank Wille and ask about G3/G4 vsc support but he is on this forum and may see posts here.

Originally Posted by Hedeon

They used gcc. I'm not sure how the old gcc stands versus the new vbcc. You know this better ;-) I think I compiled your BlitzQuake sources against a 750, but seeing that 400MHz and 500MHz don't show a lot of difference regarding fps in this game, the bottleneck is somewhere else.

There is a new version of vbcc on the way. It is mostly bug fixes but some of those bug fixes may improve performance (there is one fix which does improve performance for the 68k). The vbcc PPC backend is much better than the 68k backend.

[Hedeon]

Thanks for the extensive answer. And sorry for being a bit off topic. A new vbcc is cool. I just compiled from source for 68k and wos. Will the release be very much different from the current sources?

[matthey]

Originally Posted by Hedeon

Thanks for the extensive answer. And sorry for being a bit off topic. A new vbcc is cool. I just compiled from source for 68k and wos. Will the release be very much different from the current sources?

I doubt the main vbcc sources will have major changes. The following changes are likely.

- Power-of-two optimizations.
- Warn when truncating constants.
- fixed some shortcut-optimizations that were calculating an expression in the target type even if that was larger due to casts
- Fixed -deps dependency generation for including local header files.
- New option -no-cpp-warn to turn off all preprocessor warnings.
- Fixed gcc-compatibility of #pragma pack() and documented it.
- m68k: struct copy was using byte-copy also for aligned data
- vclib/atari: Fixed problem with receiving a trash-character on stdin.
- vclib/amiga: Include missing cia protos and inlines.
- vclib: New target m68k-kick13 (Kickstart 1.x with 1.x OS headers)
- vclib: m68k-jaguar (Atari Jaguar)

[phx]

Right. vbcc's PPC scheduler only supports 603 and 604 so far. And it uses 604 scheduling for any CPUs it doesn't know...

I should have certainly updated the scheduler for at least G3 and G4, but I never found the motivation to look up all information about their pipelines, latencies, etc.. And as Matthey already mentioned, the gain would not be that dramatic. Anybody interested may have a look at vbcc/machines/ppc/schedule.[ch]. It's not so difficult to add new models.

[trixster]

I'm trying this with a 66mhz 060 and Voodoo3 using ref_glnolru.

Can i just check where all the files from the archive are meant to go? I've put everything except game68k.dll into the Quake2 root directory. game68k.dll is in baseq2. Is this correct?

I'm trying to stop the constant stuttering. Can I ask what gl_buffers and gl_texturecache do?
I know the 060 is going to slow things considerably but im seeing lots of stop-start stuttering like the game isnt buffering correctly.

[Cowcat]

Looks like you have the files where belong: Everything out baseq2 but game.dll

"gl_buffers" are well...the screen buffers , must be "3" for triple-buffer/non sync draw.

"gl_texturecache" - well.... should be "4000000"

Maybe you're missing "gl_guardband" that should be on "1" for Voodoo.

Also, some optimizations are explained through this thread, like gl_flashblend, gl_mintriarea, gl_particles, gl_skipparticles, etc . Those are important to check out.

[trixster]

Cool, thanks.

And am I best using Paula or AHI? In AHI does "Paula" use Music Unit or Unit 0?

[Cowcat]

Use Paula if you don't have better hardware for AHI (don't know about Music Units and ahi related stuff, sorry : )

By the way, use "gl_vertex_arrays".