Quake 2 WorkShop

[Cowcat]

@matthey
Just a few reports from "testers" could shed some light about this bug.
Used the new c99 math libs with a new Q2 040 version: Works

[Michael]

Some news from the problems side...

Don't use FFS for Q2, it seeks a lot and goes very slow at loading. SFS on the other hand is just a second to load a game!

Speeds...

This are a bit disappointing
Also here is how to do it.

Enter console and type.
TIMEDEMO 1
DEMOMAP DEMO1.DM2

The demo will start in full screen and show the results.

TIMEREFRESH - gives FPS for rendering with GFX card
TIMEREFRESH ] - give FPS for CPU only, no time waste for GFX card


The results for BVPPC!

320x240 soft
Q2-HYPE - 71.5s 9.6 FPS
Q2-VBCC - 71.0s 9.7 FPS

So it looks like the new compiler is a bit better

512x384 or 640x480 (no difference!)- GL with 8bit Texture set to yes or no (no difference)
Q2-HYPE - 57.7s 11.5 FPS (GUI launcher optimised settings)
Q2-VBCC - 72.7s 9.5 FPS (default options)

HYPE version fails to start in GL by default if stated from shell

GL No LRU give a 0.5 FPS boost

MAX FPS so far gained is in GL 320x240 and 12.6 FPS


Since TIMEREFRESH gives much higher results, software rendering is as fast as GL in 320 cases, it is clear that the the limit is my weak ppc cpu or the engine is much slower. Which is proved by test results and by running the same maps under Q1 engine, that performs at least 2 times better the Q2.

Out best hope is to find some performance boosts/optimizations in the cpu area of the game engine.

[Cowcat]

@Michael
There are no surprises performance-wise. It's a beast of a program, but no new optimizations are done on the code: Those builds aren't modded anyways. We'll see if we can do some of that in future.
Still amazes me that it works after all

Cool that on your system there's little difference on minigl vs miniglnorlu (mine is more, but not saying my nolru is faster). But ref_gl still have memory problems: Doesn't work well for Warpos. 68k seems to work OK.

Anyways the things that slow the game are particles+ visuals (same as Quake1).

Cool Performance tips:
gl_texturemode GL_NEAREST (said before)
gl_drawparticles: It's on "1" by default. "0" nothing, but you can use "2" instead (you still have blood but fast).
gl_skipparticles 0(default) to "4".
gl_mintriarea 0.5(default) to "10.0".

Those values are saved on config.cfg file on ending.
Now you have "more fps"

EDIT: By the way, there's an auto-stack (no need for stack 3 millions on shell). Hope that is enough.

[Cowcat]

512x384 Q2-VBCC - 72.7s 9.5 FPS (default options)

mmmm...on my poor system I get 70.3s 9.8 on windowmode & 67.7s 10.2 on fullscreen (with default options)

Be aware of using the same config.cfg from Hyperion Q2 (better not use it). See if gl_vertex_arrays is on "1".

[Michael]

My original defaults


With some of your performance tips I get much better results!
Now 57.7s 11.9 FPS for demo1 (HYPE)

And just for playing the response is much much better, playable!

no GL_NEAREST so far, just gl_skipparticles "4". gl_mintriarea "10.0".

[Michael]

Having more fun with options...
Now improved the colour blends and enabled more GL effects, flares, lights.
Looks gorgeous now, was too bright at defaults and lacked atmosphere.
And guess what, I am up to 46.0s and 15.0 FPS (DEMO1)!

[Cowcat]

My tests for Q2 vbcc wos using only particles(2)/skipp (0) 512x384 Full Screen

New build with some minor fixes from first release: 64.8s 10.6 FPS.
New build with experimental mouse handler: 60.9s 11.3 FPS.

[Michael]

cl_maxfps 25 is a good thing for slow machines!
Now the game plays smoothly and levels out FPS in struggling situations.
Don't know if it gave the effect, but I am up again!
42.1s 16.3 FPS with bells and whistle enabled in DEMO1
And even faster in DEMO2.
So if you get some math improvements from new vbcc, this is going to go as fast a Q1.

[thellier]

Hello
Does it run In WinUAE/Wazp3D (renderer:hard) ?

Alain

[Cowcat]

@thellier
Don't know. Should be more Wazp3D happy because it uses the "normal" minigl functions. HyperQ2 had some experimental functions like "mglMultiModeDrawElements" that aren't on aminet sources and that's what make it faster (?).

[Michael]

Had some more fun today with experiments...

Same settings and config files for both versions (GL 512x384).

HYPE gives 42.3 s - 16.3 fps
VBCC gives 46.7 s - 14.8 fps

Now what is interesting is that the WOS/CPU load is measured at around 90% throughout the demo real. VBCC version is a bit more spread 85-95% compared to H load of 88-92%. What's also odd, in software mode cpu usage goes up to a constant 97-98%.

Furthermore GL 800x600 does not change the CPU load, it stays at 90%.
And time demo1 give a reasonable 12 fps!

VBCC version missing GL_SHOWFPS

Both versions have GL 320x240 window bug, console text corrupts like in Q1.

VBCC version has a bug, can't run up the ladders! Only jumping
But the real window mode is much better then in H version

Have you asked H for the latest sources? The licence is supposed to be that way, if you request it, they should give it to you.

[Michael]

New finding!
By default GL goes into 15 bits, and looks dithered.
By changing to 16 bits in config file, the picture improves, and fps goes higher!
New record 39.8 s 17.3 fps

[phx]

And was the previous Hyperion Q2 benchmark based on 15 or 16 bits?

[Michael]

Previous was 15 bit

[Cowcat]

@Michael
Maybe you can post your optimized settings.

in software mode cpu usage goes up to a constant 97-98%.

Obviously

VBCC version missing GL_SHOWFPS

gl_framestat

Both versions have GL 320x240 window bug, console text corrupts like in Q1.

We talked about that on BlitzQuake Thread.

VBCC version has a bug, can't run up the ladders! Only jumping

I know. It's a feature of the original code I still have to find where it's done (for good or bad). Did check some other sources like Yamagy to see where is the problem (time to really check all that).

By changing to 16 bits in config file, the picture improves, and fps goes higher!

Not for me. What set are you using ? (gl_forcedepth 16?).

Bringing up this version was/still is hair pulling, 'couse small parts of the drawing code doesn't work with old minigl sources, so no especial speed gain in this area. In fact using gl_ext_multitextures works but it is slow: There is no vertex_array support for it on the old minigl sources (I don't remember if Permedia had fully support anyways), so I have it disabled on my setting.

Probably the comercial Q2 has more things added after the sources where released, but given that 12 years passed I don't dare to ask for new code: "Hey, I want to make a faster version of Q2 just give me those minigl extras & all goes for free for everybody".....

[Reynolds]

Haven't visited EAB for a while, but I was really happy to see this thread.

Thanks for all efforts, can't wait to try out these ports on my classic PPCs.

[Cowcat]

@Reynolds
You're welcome

Time for some questions:

// gettimeofday pasted here from posix.lib (conflict with sys/time.h include) Cowcat

#define UNIXOFFSET 252460800  /* seconds from 1.1.70 to 1.1.78 */

int gettimeofday (struct timeval *tv)
{
  struct DateStamp ds;

  DateStamp(&ds);
  tv->tv_secs = (long)(UNIXOFFSET + ds.ds_Days*(60*60*24) +
                      ds.ds_Minute*60 + ds.ds_Tick/TICKS_PER_SECOND);  		// maybe ulong?
  tv->tv_micro = (long)(ds.ds_Tick%TICKS_PER_SECOND)*(1000000/TICKS_PER_SECOND); // "
  return 0;
}

unsigned int inittime=0L;

unsigned int timeGetTime(void)
{
  struct timeval tv;
  unsigned int currenttime;
  gettimeofday(&tv);
  
  currenttime=tv.tv_secs-UNIXOFFSET;  // tv.tv_secs-2922*1440*60
  
  if(inittime==0L) inittime=currenttime;

  currenttime=currenttime-inittime;

  return currenttime*1000+tv.tv_micro/1000;
}

Classic unix/gcc timeGetTime for Q2. Now I tried using GetSysTime.

unsigned int timeGetTime(void)
{
  struct timeval tv;
  unsigned int currenttime;

  GetSysTimePPC(&tv);
  currenttime=tv.tv_secs-UNIXOFFSET;

  if(inittime==0L) inittime=currenttime;

  currenttime=currenttime-inittime;

  return currenttime*1000 + tv.tv_micro/1000;
}

Somewhat works but have problems with two keys events at the same time (crouch & move forward for example). Is there a better alternative to the original one code, using GetSystime for example?.


2nd Question: Warpos RemTailPPC

#ifdef __VBCC__
#define __inline inline
#endif

static __inline void HARD_MaybeFreeSomeMembers(hard_cache *cache, int size)
{    
    hard_node *member;
    hard_node *node;

    while (cache->currentsize + size > cache->maxsize)
    {
	#ifdef __PPC__
	node=(hard_node *)RemTailPPC((struct Node *)&(cache->CacheList));
	#else
	node=(hard_node *)RemTail((struct List *)&(cache->CacheList));
	#endif

        if (node) cache->currentsize -= node->size;
        node->CacheNode.ln_Succ = NULL;
        node->CacheNode.ln_Pred = NULL;
        node->in_list = 0;
        member = node;
        if (member == NULL)
        {
            fprintf(stderr, "ERROR: Out of memory\n");
            exit(10L);
        }
        cache->Swap(member->data, (int)(member-cache->cache_entries));
        member->is_swapped = 1;
    }
}

As I said there are problems with Warpos version ref_gl for cleaning unused stuff (textures, etc) on playing time. As saw in the code, the only way to proper compile it is using (struct* Node) for the Warpos version.
Why warpos Remtail is different from 68k?

Warpos:  struct Node * __RemTailPPC(void *, struct Node * list)
vs
68k: struct Node * __RemTail(__reg("a6") void *, __reg("a0") struct List * list)
??

[Cowcat]

Re-upload: Fixed ladders bug (not really, only was "disabled" )
Sorry about the inconvenience .68k versions ASAP (testing new c99 fpu libs)

[phx]

Originally Posted by Cowcat

unsigned int timeGetTime(void)
{
  struct timeval tv;
  unsigned int currenttime;

  GetSysTimePPC(&tv);
  currenttime=tv.tv_secs-UNIXOFFSET;

  if(inittime==0L) inittime=currenttime;

  currenttime=currenttime-inittime;

  return currenttime*1000 + tv.tv_micro/1000;
}

Somewhat works but have problems with two keys events at the same time (crouch & move forward for example). Is there a better alternative to the original one code, using GetSystime for example?.

No. GetSysTime is only slower than GetSysTimePPC. I am using a quite similar solution in Quake 1 (refer to Quake/warpos.c). As long as Quake2 has no different requirements, this should be fine.

Why warpos Remtail is different from 68k?

Warpos:  struct Node * __RemTailPPC(void *, struct Node * list)
vs
68k: struct Node * __RemTail(__reg("a6") void *, __reg("a0") struct List * list)
??

A bug in clib/powerpc_protos.h. Of course it should be a "struct List *". And internally WarpOS is certainly treating the argument as a List. The vbcc inlines are created with fd2pragma, which reads the types from powerpc_protos.h.

[Cowcat]

A bug in clib/powerpc_protos.h.

Yep. I did change before the inline code manually, to struct List * list but no luck. Just needed to have sure about that. Still have the problem anyways: Doesn't seems to work well....

Oks. The 68k builds.
Re-Upload: