English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 18 August 2014, 11:04   #21
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
@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
Cowcat is offline  
AdSense AdSense  
Old 18 August 2014, 21:57   #22
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 600
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.
Michael is offline  
Old 18 August 2014, 22:58   #23
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
@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.

Last edited by Cowcat; 18 August 2014 at 23:35.
Cowcat is offline  
Old 18 August 2014, 23:21   #24
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
Code:
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".

Last edited by Cowcat; 18 August 2014 at 23:27.
Cowcat is offline  
Old 19 August 2014, 19:16   #25
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 600
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".
Attached Thumbnails
Click image for larger version

Name:	Q2-GUI.PNG
Views:	544
Size:	15.9 KB
ID:	41109  
Michael is offline  
Old 19 August 2014, 19:29   #26
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 600
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)!
Michael is offline  
Old 19 August 2014, 20:02   #27
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
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.
Cowcat is offline  
Old 19 August 2014, 20:39   #28
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 600
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.
Michael is offline  
Old 19 August 2014, 20:41   #29
thellier
Registered User
 
Join Date: Sep 2011
Location: Paris/France
Posts: 155
Hello
Does it run In WinUAE/Wazp3D (renderer:hard) ?

Alain
thellier is offline  
Old 19 August 2014, 21:01   #30
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
@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 (?).
Cowcat is offline  
Old 26 August 2014, 18:53   #31
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 600
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 is offline  
Old 26 August 2014, 19:07   #32
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 600
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
Michael is offline  
Old 26 August 2014, 21:37   #33
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,004
And was the previous Hyperion Q2 benchmark based on 15 or 16 bits?
phx is offline  
Old 26 August 2014, 21:40   #34
Michael
A1260T/PPC/BV/SCSI/NET

Michael's Avatar
 
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 600
Previous was 15 bit
Michael is offline  
Old 27 August 2014, 00:07   #35
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
@Michael
Maybe you can post your optimized settings.
Quote:
in software mode cpu usage goes up to a constant 97-98%.
Obviously
Quote:
VBCC version missing GL_SHOWFPS
gl_framestat
Quote:
Both versions have GL 320x240 window bug, console text corrupts like in Q1.
We talked about that on BlitzQuake Thread.
Quote:
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).
Quote:
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".....

Last edited by Cowcat; 27 August 2014 at 10:37.
Cowcat is offline  
Old 27 August 2014, 22:06   #36
Reynolds
Alien Breeder
Reynolds's Avatar
 
Join Date: Dec 2007
Location: Szigetszentmiklos / Hungary
Age: 40
Posts: 540
Send a message via Skype™ to 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.
Reynolds is offline  
Old 28 August 2014, 13:55   #37
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
@Reynolds
You're welcome

Time for some questions:

Code:
// 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.

Code:
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

Code:
#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?

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

Last edited by Cowcat; 28 August 2014 at 16:06.
Cowcat is offline  
Old 31 August 2014, 23:05   #38
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
Re-upload: Fixed ladders bug (not really, only was "disabled" )
Sorry about the inconvenience .68k versions ASAP (testing new c99 fpu libs)

Last edited by Cowcat; 27 October 2017 at 22:22.
Cowcat is offline  
Old 01 September 2014, 12:22   #39
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,004
Quote:
Originally Posted by Cowcat View Post
Code:
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.


Quote:
Why warpos Remtail is different from 68k?

Code:
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.
phx is offline  
Old 02 September 2014, 00:55   #40
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca
Posts: 293
Quote:
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:

Last edited by Cowcat; 27 October 2017 at 22:22.
Cowcat is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
ADF-Workshop (formerly DMS-Workshop) Crashdisk project.TOSEC (amiga only) 134 28 July 2017 19:39
Anim Workshop Manual _amigan request.Other 0 03 December 2012 16:30
Looking for Anim Workshop 2.0 amigagenie request.Apps 12 10 July 2011 18:07
Quake, Quake 2 and Heretic 2 don't run after update to Mediator TX Turrican(AEB) support.Games 14 25 August 2008 22:11
Workshop Pron Boot_WB Hardware pics 19 06 June 2008 21:02

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 19:01.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.29702 seconds with 13 queries