30 March 2014, 13:59 | #101 |
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 764
|
@matthey
InitFPU doesn't seems to cure it, at least for me :/ (no mathieeeboubbas.library opened appears on Snoopdos). Related to mieee.lib: Programs compiled with it, open mathieebbb.library. Programs with -cpu -fpu -lm040 options don't. The symtomps are very visible for blitz on slow 040 cpu: At the beginning you see the menu has problems rendering little quake symbol animation before options. Same with loading boxes: Like a delayed rendering (black). But it doesn't seem to affect final game speed (?) doing my "trick" or not. An old quake software rendering 68k version compiled by me has similar effects. My 2 cents. EDIT: Didn't understand what InitFpu does. Ok, you still need to open an old gl program before blitz Last edited by Cowcat; 30 March 2014 at 14:27. |
30 March 2014, 19:46 | #102 | |
Banned
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
|
Quote:
I have attached my beta vbcc_c99_includes.lha which give some helpful macros if you put fenv.h in the includes for the 68k. These includes should work with the old libs although you should make backups of the originals. With fenv.h you can do: Code:
#include "stdio.h" #include "fenv.h" int main() { int fpcr; fpcr=fegetprec()|fegetround(); printf("fpcr= 0x%lx\n", fpcr); } Code:
fesetprec(FE_DBLPREC); fesetround(FE_TOWARDZERO); Code:
fesetprec(FE_DBLPREC); fesetround(FE_TONEAREST); Edit: Also maybe worth a try: Code:
fesetprec(FE_LDBLPREC); fesetround(FE_TOWARDZERO); Last edited by matthey; 31 March 2014 at 01:22. |
|
31 March 2014, 12:25 | #103 |
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 764
|
@matthey
|
31 March 2014, 22:41 | #104 |
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 764
|
Ok. I've implemented MattHey code in this special version for m68k (040)
Should have all later problems resolved & of course the usual fixes. Hope that nothing is broken. It works for me. Experimental: This one has a new startup command to enable fpu parameters: Code:
-mattfpu and these values : DTN, LTZ, LTN, FTZ, FTN. (low or higher case) Code:
D for double, L for long double & F for float. Code:
TN for Towards Nearest & TZ for Towards Zero. DTZ (doubletowzero) is implemented as default just like Matthey said. DTN & LTN show the old problems but I leave those for further testing FTN is a funny mess Fpu modes can be seen written on principal screen (change those decimal to hex & check Matt's code). (another hidden option is -wd but who cares ) Test & play. Last edited by Cowcat; 31 March 2014 at 22:58. |
01 April 2014, 06:16 | #105 |
Banned
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
|
@Cowcat
DTZ, LTZ, LTN and DTN all work correctly on the Avenger/Voodoo. The default for the 68k FPU and x86 FPU is round to zero and round to extended precision. This is what I expect vbcc will use after initializing the 68k FPU (although you can change with fenv.h functions). I think the problems are rounding bugs in the Permedia2 Warp3D driver. kas1e describes having to set colors to 0.99 instead of 1.0 as a workaround for some functions or he would get a black color. Does black sound familiar? I expect Alain Thellier is aware of these bugs and more. I told Karlos about the bug. He maintains the Permedia W3D driver for AmigaOS 4.x. I asked for a new 68k version with bug fixes and he didn't sound opposed to it but it has never materialized. I think it would be best to query W3D for a Permedia2 and switch to LTZ rounding if found as a workaround for the bug. Otherwise, use the default LTN rounding. Even though I didn't notice any difference with LTZ, I know some vbcc fp math functions will give slightly different results with round to zero. These should be fixed but some of the code is complex and needs testing after changes. I was aware that the rounding mode could be changed when writing the new c99 functions so they should be fine. Changing the rounding precision can affect the result also but usually only up to the lesser precision. Changing to round to single (float) precision obviously isn't going to work well in most cases. |
01 April 2014, 12:25 | #106 | ||||
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 764
|
@matthey I assume that new build works, besides experimental options.
Quote:
Quote:
I left my last workaround (opening mathieedbb.library) out. Being opened, all options didn't show any bugs, but don't know if it could affect them. Quote:
running on A1200. Could Hyperion allow, a decade later, to bring out those drivers? Also, what about a "real windowmode play with full mouse support" on their old releases (like I implemented the amateur way?) Too late. Maybe I'll get banned for saying all this. Quote:
Now BlitzQuake: I know the buggy things: 1 example is why console transparency works with Malice but not with quake as @michael pointed out? Why it works with old wos GlQuake and not with new and old blitz??? Funny times. Will erase my old builds just to keep the forum/site clean. And probably upload a 060 version like last one. Last edited by Cowcat; 01 April 2014 at 12:32. |
||||
01 April 2014, 19:20 | #107 | ||||||
Banned
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
|
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
I wouldn't be surprised if this is a Permedia2 bug also. |
||||||
01 April 2014, 19:43 | #108 |
A1260T/PPC/BV/SCSI/NET
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 841
|
040_5.4
Just a quick confirm, yes the black squares and black text/icons are fixed with default options. Window mode width 320 still purple pixels and later corrupt console text. Full screen 320 works ok now, and window from 328+ is ok too. Looks like a sizing issue (4+4) are default border sizes for amigaos windows. So we are writing or doing something odd similar to Q icon problem? And a strange one, after running FS 512x384 for 2 mins, Quit, returned to WB and had half of frame from Q overwriting my desktop, could be cleared later by moving a window over it. (layers problem? or we write to odd mem again like Q icon problem?) Default (-3) lower task priority for 68k please. PS: Talking of Permedia2 / W3D bugs, it was always a shame for Wipeout to loose engine flare/trails with the updated 4.2 libs when 4.0 worked fine. Will/would the newer ones fix it?! Last edited by prowler; 02 April 2014 at 00:17. Reason: Back-to-back posts merged. |
01 April 2014, 20:05 | #109 |
A1260T/PPC/BV/SCSI/NET
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 841
|
Ha! Did not take me long to find this one ;-)
Start Q, Start game (Entry hall), look at floor, open console, do timerefresh. Should get a quick screen refresh, but GL does not update the screen rendering. Where does it go? Correct, it renders to WB screen! Try window more and timerefresh..... Everything freezes dead. |
01 April 2014, 22:52 | #110 | |||
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 764
|
@matthey
Transparency console. Found why doesn't work on normal quake: one alpha comparison was disabled on original code. You enable it and you got transparency like old glquake. But .. IS UGLY But don't count that as a less problem for Permedia drivers. Quote:
I really can't compare fpu tests on turtle speeds & my hot permedia allways gets in the way: Now 2 frames up, now half down (on wos). On m68k I only see seconds & seemed to me that LTZ value gave me less. Not a good statistic from me. @michael Quote:
Maybe is because that build is only 040 experiment & a 060 build on yours would work ok. Anyway "timerefresh" doesn't render for now. Still historically bugged for W3D. Quote:
Priority for quake? Scout do that if it's needed, no? |
|||
02 April 2014, 04:37 | #111 |
A1260T/PPC/BV/SCSI/NET
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 841
|
Yes, Q task, or in fact any heavy CPU task needs to be set lower then 0,
This makes multitasking on 68K much better and you don't even notice the load since the system starts to respond. Does not effect the Q speed if you are not running something else heavy in the background. Outsource it is also possible to use nice or something similar to run Q, but it would be nice if it had the option to do so and defaulted to it. The WOS version is not effected much cos it's running independent of the OS. |
02 April 2014, 14:20 | #112 |
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 764
|
@michael
Sent to you a new version with your requests to test. If it is ok, I'll apply it to 060. |
05 April 2014, 13:15 | #113 |
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 764
|
|
06 April 2014, 09:45 | #114 |
A1260T/PPC/BV/SCSI/NET
Join Date: Jan 2013
Location: Moscow / Russia
Posts: 841
|
Digging deeper and deeper ;-)
|
06 April 2014, 22:28 | #115 |
Banned
Join Date: Jan 2010
Location: Kansas
Posts: 1,284
|
I have created a fix for the 68k W3D_Permedia2.library rounding and black color bug. I have created another thread about it.
http://eab.abime.net/showthread.php?p=947723#post947723 |
09 April 2014, 00:40 | #116 |
kLiker
Join Date: Mar 2011
Location: Brno / Czech Republic
Posts: 371
|
WOS version is finally stable (previous versions always generated "Sam Jordan" message). Thank you guys!
WOS version 5.2 on A4k 604e/200 timedemo demo1 640x480 = 14 fps 060 version 5.3 on A4k 060/50 timedemo demo1 320x240 = 12,3 fps (sometimes 12,2 and sometimes 12,5) |
09 April 2014, 09:50 | #117 |
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 764
|
You're welcome!
@jack-3d WOS 14 fps??? With your equipment it should be like 24 fps Just tested next release with my hardware (603e/175) with only -width 640 & got 15 fps. Maybe check your system (but I don't know the options you use ) It's advised to add some options like: Code:
-particles 256 -texturemode gl_nearest -extensions Of course every known patch, rom to ram, etc, helps a little & 60ns memory too. Just recently guessed a slowdown with blitz on my system: Forgot that I changed the screen resolution to higher Hz. For me 60Hz display is ok. |
09 April 2014, 10:26 | #118 |
kLiker
Join Date: Mar 2011
Location: Brno / Czech Republic
Posts: 371
|
You are right, but my system is quite new (I build the machine last weekend). I am not using any patch, no blitzkick, just KS3.1, OS3.9 (no BB) yet and have just libraries to be able to run stuff. I am mostly demscene fan, so more patches means less compatibility with demos. But if you tell me what patches to test I can do it and let you know results.
Also my quake parameters were default and I defined only screen width, height and bpp. I will test those parameters in the evening. |
09 April 2014, 13:45 | #119 | |
Registered User
Join Date: Apr 2013
Location: Mallorca
Posts: 764
|
@jack-3d
Quote:
Search for all of that in the forums & in the end you should get a better fp quake rate, even on default settings. |
|
09 April 2014, 14:19 | #120 |
kLiker
Join Date: Mar 2011
Location: Brno / Czech Republic
Posts: 371
|
OT: For example BB2 caused me ansynchronous music with many demos. So I dont experiment much when things works "OK". I bring my Amigas to the parties and play demoscene prods on screen and I dont like when some demo crashes and I look like fool.
So I will rather have two operating systems, one clean and fresh without patches to be compatible with demos and another one patched for hi-performance in games. |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
BlitzQuake - Flashing White Screen? | fitzsteve | support.Games | 20 | 21 October 2010 23:49 |
Blitzquake (GLquake) mouse look | Angus | support.Games | 0 | 11 October 2008 00:46 |
BlitzQuake Install | Coolit | support.Games | 0 | 02 September 2005 21:33 |
|
|