English Amiga Board Amiga Lore


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 02 February 2017, 03:17   #101
grelbfarlk
Registered User

 
Join Date: Dec 2015
Location: USA
Posts: 196
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?
grelbfarlk is offline  
AdSense AdSense  
Old 02 February 2017, 18:25   #102
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 217
Quote:
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.
Cowcat is offline  
Old 04 February 2017, 02:47   #103
grelbfarlk
Registered User

 
Join Date: Dec 2015
Location: USA
Posts: 196
Any possibility of adding widescreen modes?
grelbfarlk is offline  
Old 04 February 2017, 11:30   #104
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 217
Quote:
Any possibility of adding widescreen modes?
I have that for almost a year, but never released
A matter of time....
Cowcat is offline  
Old 09 February 2017, 22:43   #105
ancalimon
Supernormal

ancalimon's Avatar
 
Join Date: Jul 2007
Location: Istanbul / Turkey
Age: 35
Posts: 1,228
Quote:
Originally Posted by Cowcat View Post
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.
ancalimon is offline  
Old 17 February 2017, 14:14   #106
Hedeon
Sonnet Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 150
Could this (and/or BlitzQuake) benefit from AltiVec? If yes, in what parts would that be? (C2P for example?). Just asking.
Hedeon is offline  
Old 18 February 2017, 12:12   #107
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 217
Quote:
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)
Cowcat is offline  
Old 21 March 2017, 17:41   #108
Hedeon
Sonnet Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 150
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?
Hedeon is offline  
Old 21 March 2017, 20:21   #109
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 217
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.
Cowcat is offline  
Old 21 March 2017, 22:34   #110
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,004
Quote:
Originally Posted by Hedeon View Post
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

Quote:
Originally Posted by Hedeon View Post
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.
matthey is online now  
Old Yesterday, 08:21   #111
Hedeon
Sonnet Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 150
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 is offline  
Old Yesterday, 08:28   #112
Hedeon
Sonnet Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 150
Quote:
Originally Posted by Cowcat View Post
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.

Quote:
Originally Posted by Cowcat View Post

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.
Hedeon is offline  
Old Yesterday, 19:08   #113
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,004
Quote:
Originally Posted by Hedeon View Post
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.

Quote:
Originally Posted by Hedeon View Post
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.

Last edited by matthey; Yesterday at 22:55.
matthey is online now  
Old Yesterday, 23:02   #114
Hedeon
Sonnet Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 150
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?
Hedeon is offline  
AdSense AdSense  
 


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

Similar Threads
Thread Thread Starter Forum Replies Last Post
ADF-Workshop (formerly DMS-Workshop) Crashdisk project.TOSEC (amiga only) 130 27 January 2017 23:17
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 00:07.


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