BlitzQuake

[Cowcat]

Forget now about outside scripts:

Run 7 version(s) from a shell like this:

glquakeWOS_gcc_7 -windowmode -width 640 -ahi -noup

There are multiple options for starting in the Readme provided.

The performance in 7 (gcc)versions are huge compared to the old ones.

[drluking]

Originally Posted by Cowcat

Forget now about outside scripts:

Run 7 version(s) from a shell like this:

glquakeWOS_gcc_7 -windowmode -width 640 -ahi -noup

There are multiple options for starting in the Readme provided.

The performance in 7 (gcc)versions are huge compared to the old ones.

tested in window mode and full screen 7.3 version
I got the same performance as version 6.01, but instead I found it extremely unstable, to the point that after a few minutes everything freezes ..... while with version 6.01 I have no problems and it works very well
So at this point I will continue to use version 6.01 as I have done up to now
If the next versions are stable again, I will try and change it very willingly
Thanks for your help

[Cowcat]

I got the same performance as version 6.01, but instead I found it extremely unstable, to the point that after a few minutes everything freezes

Well, performance if you got enough cpu to test with each compiled versions and with some effects enabled: For example with shadows on, vbcc perfomance drops considerably vs gcc version.

Also (AHI vs Paula) is a fact that Paula is faster without added sound hardware and in gcc-AHI case, performance is maintained (vs vbcc-paula).

Freezing. Well, maybe "now" it needs some stack before starting the game and experiment with options.

Anyways: No pun intended but 6.01 version is from march 2017. What can I say ....?

This: In old Blitz versions, guess what happens in a higher Quake level when you gain "Pentagram of Protection" and its texture was never memory allocated at the start of the game. And nobody reported it.

[drluking]

Originally Posted by Cowcat

Freezing. Well, maybe "now" it needs some stack before starting the game and experiment with options.

hi
I can try again, which stack and which exact command do you recommend to use to be less likely to freeze?

[Cowcat]

@drluking Missed that.

For the old vbcc it was around 700k, but since gcc builds it's recomended 1024k (Specially for Sonnet)

Two (or three points) :

- Theoretically gcc compiled programs would raise "automagically" its stuff, However that's likely not for some Amiga programs, specially with mgl linked it.

- Now, I got the stack hardcoded in code for my own 7.4 wos version to 1024 but don't remember if it was already done for 7.3.

I run all my stuff on Morphos and the stack has to be set manually: 2mg is what I use. More than that it makes no sense at all.


-Third poimt is the README. I wrote some stuff there. The old blitz docs have no use nowadays.

There's some bug in 7.3 (or older) that happens when you close the game (MOS cached in its logs) but future 7.4 doesn't seem to have it. I think Hedeon noticed and fixed some of it like a year or more ago.

[Truxilian]

I have newly returned to the Amiga world after almost two decades.. I never coded anything for Amiga.. BUT I would like the opportunity to share my observations, and hope it can either help others or result in bugfixes.

Blitz GlQuake (Quake1 - Cowcat 7.3) observations:

- ISSUE01: BlitzQuake WOS only works if -AHI is specified. 68k version works fine without -AHI.

- ISSUE02: AHI seems to be using music unit.. If I set Music Unit to Paula Hifi 14 Stereo ++ and Unit 0 to Paula DMA 8 Bit, it says 14 bit hifi in Quake
Maybe add option to choose which AHI unit to use?

- ISSUE03: If Miami is open, it requires an ip specified. I do not know if it means the IP of the Amiga, or of some Quake administration server?
(I use -noudp (which I neither know what actually means) to circumvent this, but it seems like to wrong way to fix problems).

- ISSUE04: When using -AHI there is a clear tendency that GlQuake WOS crashes around the first few explosions from the grenade launcer in the initial demo (usually already at first explosion).
A very crude theory is that it is actually during the sound playback of the grenade launcher and/or explosion, or gibbing sound of the zombies.
I can reboot, start the game again, and this crash will keep occuring almosts every time.. until I perform a power cycle - not just reboot, but a complete power cycle - then it works perfectly
almost every time I run it. If the game passes the first sequence in the demo with lots of grenades going "boom!", it will continue to run perfectly. I have not experienced a crash after this point!
Even after quitting GlQuake and starting it again, the chance that it will not crash this time is quite high (but not 100%, though).
Whatever triggers these crashes, I simply cannot sort out.. Only thing I can say for sure, is that if I use parameter -nosound, it works every time - 100%!.
I have played around with some AHI settings.. At first, I thought it must be because I was using Paula DMA, but it turns out that Paula modes result in crashes! The only way I can use sound through AHI, is Filesave!
(I posess no sound card other that the Paula).
I have tried with AHI devices paula.audio v4.23 and v4.33, same result.
Could it be something external (as in, not a part of GlQuake) that could be ending up in a different state (AHI itself?) for each time I start the system, even though I attempt to recreate the exact same starting conditions?

Now it seems that it will fail every time after having loaded a special application, IBrowse, Miami or similar (maybe anything requiring MUI?), or maybe it is anything that uses or opens or tries to anyways, bsdsocket.library?
Update 1: New tests have proved 100% failure rate, running GlQuake after opening IBrowse, after first successfully having had GlQuake running! (Possible hint: My other screen, connected to the video port, goes white when IBrowse is opened, but goes back to light gray when GlQuake opens the CGX-view, related maybe?)
Update on update 1: False positive it seems.. sigh

Another related observation: Removing the -particles 256 parameter from the call, it now uses default particles (which looks like it is quite a lot more than 256), and it seems to have slightly lower crashing rate? Maybe it simply changes some timing, clashes between creating particles and issuing (AHI?) audio?
Setting no particles with -particles 0, it completely avoids crashes!.

Another detail: I unpacked the .PAK files, and changed the demo order to DEMO2 DEMO1 DEMO3.. Result: After a few runs, it managed to crash in DEMO2, at the first wraith monster..

Summary:
- Setting -particles 0 reduces the failure rate to ZERO!
or
- Setting -nosound reduces the failure rate to ZERO!

Bonus info: Running the Warp3D library patch by Alain does not seem to have neither positive or negative effect, yet it seems to fix an issue with the lines display in Cow3D (but damn, it becomes slow!).

- ISSUE05: Configuration parameter _snd_mixahead = "0.0" causes GlQuake to produce no sound at all. I was hoping it would save processing power, by disabling some kind of audio time-offset, and maybe even mitigate the crashes if ISSUE04, but they still occur with value "0.0".

System: BlizzardPPC 603e@240MHz + MC68060Rev6@50MHz, 128MB 50ns EDO (all wait-states disabled), BVisionPPC. 32GB SD card. AmigaOS3.2.2.
Normal settings: -width 512 -particles 256 -AHI -nocdaudio -noudp

[Cowcat]

- issue01:

The beginnings of changing vbcc code to new gcc warpos compiler.
I believe that Q2 gcc paula code is functional and maybe something could be used to fix Q1 sound but code is different in BlitzQuake.

- ISSUE02:

No idea.

- ISSUE03:

Also no idea with Miami.

Sometimes what it seems a crash in the game is only the OS system trying to figure out if a network is alive while no tcp stack is running and after sometime game starts to run. "-noudp" is the way to disable network support.

- ISSUE04:

No particular problems happened with particles when they were set at low rates in Blitz (default) but a similar problem was detected time ago for Hexen (sw or gl render) and same fix code was used there from Blitz. Maybe a new/old bug ?

The rest of problens should be checked with the "test" cases that are on the Readme. A missed option like a memory set or something can lead to rare behaviour.

Theoretically old vbcc has stack internally set but gcc version needs some around 2mg. specially for Sonnet library users.

Increasing stack for the sake of it doesn't do anything and the problems are in other places.

As in the case of Q2, also I "have to" upload a new gcc version and finally do a github of it.

Tempus fugit.

[Truxilian]

Originally Posted by Cowcat

The beginnings of changing vbcc code to new gcc warpos compiler.
I believe that Q2 gcc paula code is functional and maybe something could be used to fix Q1 sound but code is different in BlitzQuake.

I guess running directly to Paula without AHI would be optimal performance wice.. and since the Paula is a legendary piece of hardware, it would be awesome to be able to keep using it directly :-).


I am fairly sure that all the observations with Miami and other MUI applications were just coincidences. My semi-autistic brain wanting to find connections between anything possible.

Originally Posted by Cowcat

No particular problems happened with particles

Particular with particles

Originally Posted by Cowcat

when they were set at low rates in Blitz (default) but a similar problem was detected time ago for Hexen (sw or gl render) and same fix code was used there from Blitz. Maybe a new/old bug ?

So, in theory, if I set particles high enough, it could migitate crashes? Yet I guess it would be damn slow on my system.. :-)

Originally Posted by Cowcat

The rest of problens should be checked with the "test" cases that are on the Readme.

I am really not sure which test cases you are referring to? I cannot find any such in Readme_7.3.txt - is it in some other readme?

Originally Posted by Cowcat

As in the case of Q2, also I "have to" upload a new gcc version and finally do a github of it.

THB, all versions of Q1 and Q2 I have found, were done by lucky hits in forum entries found by doing google search.. Is there a site, a directory or repository where I can find new and old versions of the various compilations? (Maybe also those not compiled personally by you?)

Originally Posted by Cowcat

Tempus fugit.

Sigh.. yes.. :-)

[Cowcat]

all versions of Q1 and Q2 I have found, were done by lucky hits in forum entries found by doing google search.

Don't do that. Latest BlitzQ1 and Q2 beta versions done by me are uploaded here in EAB on each corresponding thread.

The "Problem" is that unexpected bugs show up but after someone tries a particular unknown version or new beta release after "years" of being done....

...So I'm glad that after all someone points out those issues. Latest Q2 for example has various of those and I've been working lately testing and upgrading it. Very tedious.

if I set particles high enough, it could migitate crashes?

Nope, quite the contrary. On Amiga, IIRW higher than 256(?) crashes all those games using similar code. But I don't know as you pointed out where the problem is.

[Truxilian]

Originally Posted by Cowcat

The "Problem" is that unexpected bugs show up but after someone tries a particular unknown version or new beta release after "years" of being done....

Correct me if I am wrong, but version 7.3 is the newest version uploaded, right? I find this forum very hard to search. :-) Is there some way to see posts with files, or simply see a list of all files submitted to the thread?

At some point I read that a user on this forum had version 6.?.? running without crashes, but that he had crashes with 7.3, that I find as possibly the same as those I am experiencing.

I would like to try that old version, to see if those particular crashes do not occur, as it may give us some kind of lead.. If I knew where to get it.

Originally Posted by Cowcat

...So I'm glad that after all someone points out those issues. Latest Q2 for example has various of those and I've been working lately testing and upgrading it. Very tedious.

Speaking of Q2, there may be a related observation here. I find Q2 WOS to be rock stable.. But I tried some different settings for my BVision, and as soon as I ran it with Semaphores turned off, Q2 crashes after a few seconds of playtime/demo, in the similar way as BlitzQuake7.3, everything locked, sound looping.. (even though the CGX guide says that Semaphores turned ON could cause what seems to be those kind of lock-ups in rare conditions - I observe the direct opposite with Q2). Anyways, does BlitzQuake utilize these Semaphores like Q2 apparently does?

[Cowcat]

At some point I read that a user on this forum had version 6.?.? running without crashes, but that he had crashes with 7.3, that I find as possibly the same as those I am experiencing.

The old versions aren't here due to obvious space constrictions but also because multiple upgrades and bugfixes: One important fix was a crash in a particular level due to a texture bad allocated. I think since 7.xx I moved all to gcc for the warpos version.

I have a 7.4 version for quite a while but let me revise it again. If you don't like it I can provide old versions if needed (I think I have those somewhere). PM me.

Semaphores ? No idea. When I had my old hardware working, those versions run with no apparent problems with "default" system settings but ....

....when you get some experience and better ways to catch bugs you found quite a diverse impresion of what a stable program is. Not only my own stuff but others too.

[ancalimon]

Can anyone confirm if litfiles is working with BVision or CVisionPPC ?