Quake 2 WorkShop

[Cowcat]

As promised, the whole code.

You need to compile the old minigl aminet sources using the modded code provided (it is exactly the same lib/mod used on BlitzQuake 2014 + fixes). A must.
You need posix lib from vbcc packages + includes, also Amitcp includes.
Compile the dll lib of Quake2, of course.

Things to still be tested/fix:
The net code: Don't know if it works, and some code still messed up with the includes.
The renderercache for warpos.
Probably remove the posix lib & make 100% free unix code (used in few places).
A better makefile: Not 100% proof-include-depends.

Feel free to use it & make it better (already testing new code).

[matthey]

@Cowcat
I compiled a new version of the c99 math libs for vbcc with a fix to the m060.lib and m060s.lib. Frank Wille found and fixed a problem that caused the 68020 versions of some functions (using trapped integer 64 bit instructions) to be used instead of the 68060 versions. The new archive is here:

http://eab.abime.net/showthread.php?t=74692

Also, Cosmos pointed out the following link to MiniGL in case you didn't know about it.

http://www.hyperion-entertainment.bi...iGL/trunk/src/

[Cowcat]

@matthey
Fixes are cool

Yep, I'm aware of that trunk minigl code: Sometimes I take a look if there's something to benefit the old code, but it's radically different and a daunting task to reimplement the whole thing.
Nowadays I'm cleaning the code +fixes (again) and trying different implementations of different Quake codes from all sources possible: From Yamagi to last 2.3.24 quake2.

My newest WarpOS version is to my tests slightly faster, but seems to be nothing gained for 68k version given the new code (weird).
Recently gl_shadows option uses vertex arrays + fixes on minigl code, so there's room for improvement. Also some of these ideas can be probably applied to a BlitzQuake future version. We'll see

[Michael]

Sweet. Can't wait for an update and hopefully some more fixes ;-)

[Cowcat]

@michael
New things & maybe a small speed boost.

Cool option for a future release: Third person view camera.

[Michael]

Hmm... nice. Was not it available before ? Even Q1 used it in many places with the mods.

[Cowcat]

@michael
Not in the Q2 original sources exists that option, even for some later updates. It's a fun option for tweak & play, but still some things to do for a new release.

[Cowcat]

New warpos upload:

Two versions of glnolru inside (ref_gl is faked name). Test one against the other & old quake2 versions. The "ref_gl" has reenabled code that was not complete at the time plus workaround for "multimodedrawelements".
Changed "gettimeofday" for warpos (now uses getsystimeppc).
Original ref_gl still is a problem on warpos (anyways is slow & doesn't clean resources as old m68k version).
As comented before gl_shadows option is now faster & fixed (no impossible shadows, no shadows on blasters, etc).

New options: ThirdPersonView camera.
- cl_3dcam, cl_3dcam_angle, cl_3dcam_dist. Some values to see the effect: 40 for angle & 70 for dist. (Now you're a poligon )

- cl_drawfps (a simple one).

There's an option that was disabled by default "gl_closeworkbench": If you have problems with full display (some corruption) or low memory maybe enable it, but you loose multitasking (no switch to workbench screen).

Also a new warp3dppc version I've been using for a while.....

[Cowcat]

Test it.

[Michael]

Quake2_wos_beta2 (with original W3D)
ref_gl - 45.5s - 15.1 fps
ref_gl_no_lru - 47.2s - 14.3 fps

no optimizations, just run it as is, I think with same settings HQ2 gives 42.4s - 16.2 fps
but really need to play around with this toys to see how things work and what effects what.

[Cowcat]

Beta2 source:
New minigl workaround/fix used for faster shadows: See what it is all about on my old Warpos Minigl Blues thread & some inline vbcc w3d code just in case.

Cleaned sources: All checks for stereo googles interface are disabled (somebody has one?)
New code for 3dcam & shadow test is located on client dir (taken from kmquake2) & some code is left there (disabled )for future use. A lot to do with that.
Some optimized (?) code on a q_shared alternative version (maybe is usefull to try), besides some silly things I used for this new version.

Important for coders: Every new version invalidates saved gaming & every modification on important headers leads to unexpected crashes & bad behaviour. Is the way it is with Q2, so you need a full recompile (probably you know this already).

[matthey]

Originally Posted by Cowcat

Test it.

I tried out the Quake 2 68060 build a bit. Aiming with the mouse seems easier. I can put the dot on the enemies now except when the game slows down and gets jerky. It might be quite playable if I try some of the speedup settings suggested in this thread. I can also use stairs without having to jump on them. Overall, the game is less frustrating and more playable. I didn't have any crashes in my short trial although I didn't check for MuForce hits. I do still have the color distortion issue I mentioned earlier and sometimes I hear clicking sounds which I didn't notice in the earlier build (probably just me not noticing). The sound effects are generally low quality and cut out when the display is jerky for an extended period which may be part of the problem. I can play with the settings and/or optimize some more vbcc code to free some CPU performance. Nice job!

[Cowcat]

@matthey
Thanks !

To alleviate the mouse jerkiness I use "m_filter 1" & "cl_maxfps 25" (those vars aren't recorded on config.cfg when out).

My config nowadays looks like this:
gl_texturemode GL_NEAREST
gl_drawparticles 2
gl_skipparticles 2
gl_particle_size 20
gl_mintriarea 2.5 -> this value is for 512x384 screen. On blitzquake thread the formula to round the needed value for other screen modes is explained.

gl_flashblend 1

Of course gl_vertex_arrays is on "1" by default & in my case gl_ext_multitexture is on "0".

Another thing is "r_vertexlighting 1" that bypasses....lights !, if you go only for speed.

Some simple optimizations that work can be done on the sources: Manual unrolling for example on gl_mesh.c -> DrawAliasFrameLerp (those i<3 loops) or on gl_light.c on AddDynamiclights,R_buildlightmap, etc,etc. Just experiment: Unexpected unrolling in some places didn't make the binary bigger, quite the contrary (at least on warpos).

In fact I had a faster warpos version time ago but messed to much with it and probably ended with the relative 68k version being slower....so I had to redo all quite a few times.
Another option maybe for 68k could be an eclock version for gettimeofday on q_shamiga.c, just like the hack I did with getsystimeppc.

Note: Still don't know those color issues...

[matthey]

Originally Posted by Cowcat

To alleviate the mouse jerkiness I use "m_filter 1" & "cl_maxfps 25" (those vars aren't recorded on config.cfg when out).

My config nowadays looks like this:
gl_texturemode GL_NEAREST
gl_drawparticles 2
gl_skipparticles 2
gl_particle_size 20
gl_mintriarea 2.5 -> this value is for 512x384 screen. On blitzquake thread the formula to round the needed value for other screen modes is explained.

gl_flashblend 1

I tried your settings and didn't notice any difference in quality but it was enough faster that I had to turn the mouse sensitivity down more. It's pretty playable now at 512x384 in 16 bit without reducing the screen size.

Originally Posted by Cowcat

Another thing is "r_vertexlighting 1" that bypasses....lights !, if you go only for speed.

I tried turning it off to see if my color distortion problem was related to lighting. No difference.

Originally Posted by Cowcat

Some simple optimizations that work can be done on the sources: Manual unrolling for example on gl_mesh.c -> DrawAliasFrameLerp (those i<3 loops) or on gl_light.c on AddDynamiclights,R_buildlightmap, etc,etc. Just experiment: Unexpected unrolling in some places didn't make the binary bigger, quite the contrary (at least on warpos).

I don't know how unrolling would shrink the executable size. Sometimes reordering, simplifying or changing the data types of variables inside a loop will make a big impact though. It would be better if compilers were smart enough to do it because some optimizations are CPU dependent. The 68060, for example, benefits very little from loop unrolling and may actually be slower if a lot of loop unrolling kicks code out of the ICache. The 68060 is the rare exception as most other processors are not as efficient at loops to perform the same magic. Think how much ICache could be saved if loops didn't need to be unrolled.

Originally Posted by Cowcat

In fact I had a faster warpos version time ago but messed to much with it and probably ended with the relative 68k version being slower....so I had to redo all quite a few times.
Another option maybe for 68k could be an eclock version for gettimeofday on q_shamiga.c, just like the hack I did with getsystimeppc.

What is faster for the 68040 might not be for the 68060. The 68060 may be more like modern processors but the RISC PPC is quite a bit different too.

Originally Posted by Cowcat

Note: Still don't know those color issues...

I attached a screen grab (grab.png) with a picture of the distorted colors on some barrels. There are some places where the color distortion is this bad but there are also some places that there doesn't seem to be a problem. I tried gl_forcedepth "16" but it didn't help. I wish there was a gl_endian setting that would choose LE or BE gfx modes. The Elbox 2D Avenger driver has color distortion problems in BE modes on the Voodoo 4.

[Cowcat]

@matthey

it was enough faster that I had to turn the mouse sensitivity down more.

Cool. I talked about my mouse settings & just yesterday found that newer optimizations made unnecessary to mess with the options & felt like playability was much better. Tempted to upload new ref_gl's for all versions(we'll see).....but

The 68060, for example, benefits very little from loop unrolling and may actually be slower if a lot of loop unrolling kicks code out of the ICache.

.....probably is what I felt with the 040 version too (060 is out of question for me). Some Q2 code out there is modded that way but I experienced that applying some of those unrollings in other places (like for example on pmove.c on qcommon dir) you end with a totally wrong slow code .

I wish there was a gl_endian setting that would choose LE or BE gfx modes.

Now I understand with the picture. A simple toggle could be made for bypassing all those "littlefloat, long, short" endianess checks whenever a model-entity colour load happens. But of course, when is needed or not is the problem as you say that sometimes there's no distortion.

[Cowcat]

More wood:

Some new code to apply & try for the gl dlls. Only made this for glnolru so apply to the normal gl.
Besides some attemp to unroll some of the loops (more or less luck), there's an awesome optimization on gl_rsurf.c (r_recursiveworldnode) that makes more responsive gameplaying, for example less lag is noticed (or very few) on first level when you go out in open air.

[Cowcat]

Did someone notice that 3D models work for the new thirdcamera option?

I admit didn't know it
Just using the players/male dir & files from Quake2 demo pak (grunt, skin, tris,weapon,etc) does the trick -> Full thirdperson playing.
"developer" command option show what is needed.

Also a "hidden" cl_3dcam_alpha option (that I didn't tell but it was on last compile) makes the model transparent when camera is on back.

[matthey]

@Cowcat
You have been quiet lately. The new version of vbcc 0.9d is out now and there is already a small 68k FPU math bugfix here:

http://eab.abime.net/showthread.php?p=969253

Has the new version of vbcc been working ok? Have you noticed any improvements?

[Cowcat]

@Matthey
Happy new year mate !

Yep. Realized that the new vbcc version appeared & still have to do a full 68k test. Some funny mistakes by me with newer vasm made me email Phx for nothing

The "-nowarn=62" wasn't on my config (I didn't copy the new ones), so one thing lead to another So now if in any makefile is called vasm you need that option with new vbcc 9d pack, just to get rid of those innocuous "warns".

Hope that those who download the sources have a working Q2 binary or started to fix some of the code like network (untested) or adding newer things: Say something !

Busy with some ppc asm code for Q2 that could be added for educational purpose (frsqrte). Don't know if it really improves performance, but those ideas were already used in BlitzQuake by Phx.

Don't really know why but my new wos binary is someway faster: Is the new code added?, the warp3dppc mod ? We'll see for 68k.

[matthey]

Originally Posted by Cowcat

@Matthey
Happy new year mate !

Yep. Realized that the new vbcc version appeared & still have to do a full 68k test. Some funny mistakes by me with newer vasm made me email Phx for nothing

The "-nowarn=62" wasn't on my config (I didn't copy the new ones), so one thing lead to another So now if in any makefile is called vasm you need that option with new vbcc 9d pack, just to get rid of those innocuous "warns".

I did notice the change in the config and copied it over but I wasn't getting warnings before that. I am using an even newer version of vasm than in vbcc 0.9d though.

Originally Posted by Cowcat

Hope that those who download the sources have a working Q2 binary or started to fix some of the code like network (untested) or adding newer things: Say something !

I would play with it if I didn't have other projects. I haven't even tried Arti's gl HHexen yet.

Originally Posted by Cowcat

Busy with some ppc asm code for Q2 that could be added for educational purpose (frsqrte). Don't know if it really improves performance, but those ideas were already used in BlitzQuake by Phx.

For other's educational learning or for yours?

Originally Posted by Cowcat

Don't really know why but my new wos binary is someway faster: Is the new code added?, the warp3dppc mod ? We'll see for 68k.

There are several changes in vbcc 0.9d that could help the speed. From the changelog, it looks like the PPC mostly received bug fixes. The 68k side received a few optimizations though .