English Amiga Board Amiga Lore


Go Back   English Amiga Board > Coders > Coders. General

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

 
Join Date: Dec 2015
Location: USA
Posts: 488
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, 17:25   #102
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 259
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, 01:47   #103
grelbfarlk
Registered User

 
Join Date: Dec 2015
Location: USA
Posts: 488
Any possibility of adding widescreen modes?
grelbfarlk is offline  
Old 04 February 2017, 10:30   #104
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 259
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, 21:43   #105
ancalimon
Supernormal

ancalimon's Avatar
 
Join Date: Jul 2007
Location: Istanbul / Turkey
Age: 36
Posts: 1,229
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, 13:14   #106
Hedeon
Sonnet Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 257
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, 11:12   #107
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 259
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, 16:41   #108
Hedeon
Sonnet Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 257
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, 19:21   #109
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 259
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, 21:34   #110
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,199
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 offline  
Old 22 March 2017, 07:21   #111
Hedeon
Sonnet Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 257
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 22 March 2017, 07:28   #112
Hedeon
Sonnet Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 257
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 22 March 2017, 18:08   #113
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,199
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; 22 March 2017 at 21:55.
matthey is offline  
Old 22 March 2017, 22:02   #114
Hedeon
Sonnet Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 257
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  
Old 22 March 2017, 23:19   #115
matthey
Registered User
 
Join Date: Jan 2010
Location: Kansas
Posts: 1,199
Quote:
Originally Posted by Hedeon View Post
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.

Code:
- 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)
matthey is offline  
Old 23 March 2017, 00:17   #116
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 950
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.
phx is offline  
Old 20 May 2017, 14:52   #117
trixster
Guru Meditating
trixster's Avatar
 
Join Date: Jun 2014
Location: York
Posts: 679
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.
trixster is offline  
Old 20 May 2017, 18:46   #118
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 259
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.
Cowcat is offline  
Old 20 May 2017, 21:32   #119
trixster
Guru Meditating
trixster's Avatar
 
Join Date: Jun 2014
Location: York
Posts: 679
Cool, thanks.

And am I best using Paula or AHI? In AHI does "Paula" use Music Unit or Unit 0?
trixster is offline  
Old 21 May 2017, 11:28   #120
Cowcat
Registered User
 
Join Date: Apr 2013
Location: Mallorca / Spain
Posts: 259
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".
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) 130 27 January 2017 22:17
Anim Workshop Manual _amigan request.Other 0 03 December 2012 15:30
Looking for Anim Workshop 2.0 amigagenie request.Apps 12 10 July 2011 17:07
Quake, Quake 2 and Heretic 2 don't run after update to Mediator TX Turrican(AEB) support.Games 14 25 August 2008 21:11
Workshop Pron Boot_WB Hardware pics 19 06 June 2008 20: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 05:33.


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