BlitzQuake

[Cowcat]

@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

[matthey]

Originally Posted by Cowcat

@matthey
InitFPU doesn't seems to cure it, at least for me :/ (no mathieeeboubbas.library opened appears on Snoopdos).

InitFPU sets the FPCR=0 which is the default for the 68k FPU. This sets rounding to round to nearest (best accuracy) and round to extended precision (best precision). The mathieeedoubxxx.library sets the FPCR=0x90 which is round toward zero (trunc) and round to double precision which is more IEEE compliant (but still not for floats).

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:

#include "stdio.h"
#include "fenv.h"

int main()
{
int fpcr;

fpcr=fegetprec()|fegetround();
printf("fpcr= 0x%lx\n", fpcr);
}

That would create a program to display the FPU FPCR. For BlitzQuake you can also "#include fenv.h" and then change (initialize) the FPCR with code like:

fesetprec(FE_DBLPREC);
fesetround(FE_TOWARDZERO);

This would be the same as the IEEE double libraries sets the FPCR too. You could also try:

fesetprec(FE_DBLPREC);
fesetround(FE_TONEAREST);

This hasn't been tried yet but may be better. The values you can change to are defined in fenv.h if you want to take a look. They can be changed anytime within the program. The fenv is the same format as an FPCR value by the way so the fenv can be saved and restored with the other c99 functions. The FE_DFL_ENV can't be used without the new libraries though. Let me know if you have any problems or find any bugs.

Edit: Also maybe worth a try:

fesetprec(FE_LDBLPREC);
fesetround(FE_TOWARDZERO);

[Cowcat]

@matthey

[Cowcat]

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:

-mattfpu    
and these values : DTN, LTZ, LTN, FTZ, FTN. (low or higher case)

Rounding precision:

D for double, L for long double & F for float.

Rounding mode:

TN for Towards Nearest & TZ for Towards Zero.

so -mattfpu ltz enables "longdoubletowardszero" & so on.

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.

[matthey]

@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.

[Cowcat]

@matthey I assume that new build works, besides experimental options.

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?

..... and lagging that happens just before drawn options,loading picture,etc: Refresh problems that put sometimes the infamous black screen.

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

LTZ is one option that AFAIK reduces seconds on timedemo. Don't know if it affects smoothness between frames.

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.

I told Karlos about the bug. He maintains the Permedia W3D driver for AmigaOS 4.x

Yep. I read that he has also experimental wos drivers, and there's a video of Quake3 arena
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.

I expect Alain Thellier is aware of these bugs and more.

As he told on other forums, a lot is going on with old/new mgl.lib also. I talk a little on my old thread "wos blues" & still find some that affects both cpu's. I don't have the knowledge to decode those & nowadays few care about it (problem with the compilers, drivers, old code?)

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.

[matthey]

Originally Posted by Cowcat

@matthey I assume that new build works, besides experimental options.

Yes, as far as I tested.

Originally Posted by Cowcat

..... and lagging that happens just before drawn options,loading picture,etc: Refresh problems that put sometimes the infamous black screen.

The whole Permedia2 driver causes lagging. It's code quality is miserable. You saw how I was able to reduce the Warp3D.library to almost 1/2 the original size? This library needs the same treatment.

Originally Posted by Cowcat

LTZ is one option that AFAIK reduces seconds on timedemo. Don't know if it affects smoothness between frames.

Did you actually test and compare results? The calculations are always done at full FPU register precision so should take no longer and round to zero is the least amount of work but again should offer no advantage. The fastest I tested on my 68060 was LTN by .1 fps (not statistically significant) in timedemo while all the others were similar. The 68040 is different though.

Originally Posted by Cowcat

Yep. I read that he has also experimental wos drivers, and there's a video of Quake3 arena running on A1200. Could Hyperion allow, a decade later, to bring out those drivers?

I think Karlos would like to but everything else is higher priority and he may not have permission. Hyperion could care less about 68k. The only thing a new 68k version of the Permedia2.library would show is how slow and buggy the old version was. Hyperion used to say how the 68060 was too slow for the newer games but who would have known it was their fault.

Originally Posted by Cowcat

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.

You won't get banned here .

Originally Posted by Cowcat

As he told on other forums, a lot is going on with old/new mgl.lib also. I talk a little on my old thread "wos blues" & still find some that affects both cpu's. I don't have the knowledge to decode those & nowadays few care about it (problem with the compilers, drivers, old code?)

I think most of the minigl problems for Permedia2 users will come down to the Permedia2.library. Most things work well on the Voodoo/Avenger.

Originally Posted by Cowcat

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???

I wouldn't be surprised if this is a Permedia2 bug also.

[Michael]

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?!

[Michael]

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.

[Cowcat]

@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.

You saw how I was able to reduce the Warp3D.library to almost 1/2 the original size? This library needs the same treatment.

Yes, of course. I reduced mine like 2% with a simple reassembly . I know that Cosmos worked on those libraries, even the permedia ones. Maybe should try to patch, but nothing for WOS......

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

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.

Yep. Rendered trash on WB when FS doing timerefresh. But haven't got a freeze or anything like that: Got 25 fps looking down . On windowmode no problem.

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.

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?

mmm....Don't think (today) that has something to do as Q icon problem. If you use the fpu value FTN (the funny mess) you will see it placed where it belongs at beginning. It's behind principal screen, still not in front. Some locks that I applied to the drawing function allows it only to live on other screens: Without those we'll get the infamous "hits".

Priority for quake? Scout do that if it's needed, no?

[Michael]

Originally Posted by Cowcat

Priority for quake? Scout do that if it's needed, no?

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.

[Cowcat]

@michael
Sent to you a new version with your requests to test. If it is ok, I'll apply it to 060.

[Cowcat]

[Michael]

Digging deeper and deeper ;-)

[matthey]

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

[jack-3d]

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)

[Cowcat]

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:

-particles 256 -texturemode gl_nearest -extensions

less definition with gl_nearest but faster & -extensions should be only used with high resolutions: It's slower with 320x240. Check old blitz readme or this thread.

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.

[jack-3d]

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.

[Cowcat]

@jack-3d

I build the machine last weekend

Like me a year before. It gets better when you install 3.9 with BB2 and deal with all blizkick options & modules, patches or new libs.
Search for all of that in the forums & in the end you should get a better fp quake rate, even on default settings.

[jack-3d]

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.