Testers and reviewers wanted: BFG-style vertex cache

[duzenko]

11 minutes ago, lowenz said:

Please, guide me from here:

 

Look for the call stack tab on the bottom right half, near where you get the compile errors for TypeInfo project now.

[lowenz]

[duzenko]

Great job!

@stgatilov

How do we link to OpenAL these days? Static lib? What's the right way to debug this error? Does it make sense to update our AL version?

[duzenko]

3 hours ago, lowenz said:

 

What happens if you comment out the device enumeration code (if alcIsExtensionPresent...)?

[lowenz]

In snd_system?

Edited October 2, 2019 by lowenz

[duzenko]

15 minutes ago, lowenz said:

In snd_system?

Yes, the part that crashes

What is your sound card BTW?

[lowenz]

Crashing with a Realtek, lastest drivers! (Realtek does not provide a specific implementation of OpenAL as Creative does with ct_oal.....and I have a good old X-Fi Titanium too for testing - June/July 2019 drivers  )

Edited October 2, 2019 by lowenz

[lowenz]

Maaaaaaaaan, it's working!

It's THAT piece of.....code! 

Edited October 2, 2019 by lowenz

[lowenz]

Using the debug version just built and your last glprogs folder, this is the result (in A New Job FM) with and old GeForce 750 Ti, 436.xx drivers, all maxed out (AA 4x too) !

Edited October 2, 2019 by lowenz

[lowenz]

(of course with no audio enabled )

[duzenko]

You should still have sound, on your default device

No use to test speed on debug build - you need a 'release' build for that.

[lowenz]

I know I know, will build the release version but all seems good!

[lowenz]

Release version has the same performance (and it's very good for a 750 Ti with all maxed out)

Can't have audio working, though!

Edited October 2, 2019 by lowenz

[duzenko]

1 hour ago, lowenz said:

Release version has the same performance (and it's very good for a 750 Ti with all maxed out)

Can't have audio working, though!

Did you comment out too much code?

[duzenko]

@cabalistic

You might want to review svn rev 8377

Recently I kept catching occasional AVs in CopyBufferSSE2. I suppose it's caused by 'aligning up' memory address range so that in the end it reads from unallocated memory.

Finally today I was able to reliably reproduce the crash in a particular Rightful Property location. I changed the code so that VertexCache aligns memory internally and only asks to copy the actual size of the source.

For now I only fixed R_CreatePrivateShadowCache because that's where it crashed from. I am going to fix other places as they crash for me.

[lowenz]

Is it possible to decouple in the next builds / final 2.08 build the openal soft lib from the main exe? (thedarkmod.exe+openal32.dll / thedarkmode64.exe+openal64.dll) so we can play with fresh/new openal soft build ?

[duzenko]

7 hours ago, lowenz said:

Is it possible to decouple in the next builds / final 2.08 build the openal soft lib from the main exe? (thedarkmod.exe+openal32.dll / thedarkmode64.exe+openal64.dll) so we can play with fresh/new openal soft build ?

@stgatilov?

[stgatilov]

16 hours ago, lowenz said:

Is it possible to decouple in the next builds / final 2.08 build the openal soft lib from the main exe? (thedarkmod.exe+openal32.dll / thedarkmode64.exe+openal64.dll) so we can play with fresh/new openal soft build ?

Only if you will build it yourself. I can try to make some experiments, probably it could work with little changes --- then I could send you a patch on source code.

Separating one DLL from EXE means you will either have two CRT or you need to separate CRT into its own DLL too, in which case you also need to install VC redistributable on every player's machine... Let's say we had this for 2.06 and 2.07 and it did not work well enough, so we have reverted to the old way, "acknowledging the wisdom of our ancestors" For the majority of players having one EXE with everything is much better.

 

UPDATE: BTW, setting cvar s_nosound or something like this should disable all sound. It would probably circumvent the crash, but of course at the cost of sound.

We can try to update OpenAL. Initially, we had version 1.18.2 in 2.06. Then I updated it to 1.19.0 somewhere after 2.07, but it caused some problems, so we reverted it back. Now 1.19.1 is out, maybe it would fix both problems.

[lowenz]

OpenAL Soft dev did solve a good number of issues in the last weeks.....1.19.1 (October 2018, 1 year ago) is good but there's a bad issue with resampling above "linear" default option.

Edited October 9, 2019 by lowenz

[duzenko]

@stgatilovcan we have a debug openal build so that we can see where the crash comes from exactly?

[stgatilov]

On 10/10/2019 at 1:01 AM, duzenko said:

@stgatilovcan we have a debug openal build so that we can see where the crash comes from exactly?

I have built RelWithDebInfo x64 library for versions 1.18.2, 1.19.0, and 1.19.1. There are here. You can replace the lib "rel" version with any of them, build TDM, and it will produce PDB with symbols for OpenAL. On the other hand, if you want to see the place in debugger, then you will have to download source code and point MSVC to it.

Maybe we should build most of the libraries with debug info to make debugging easier.

P.S. Conan has one major issue: it has steep learning curve. I wish more people try to use it, but understand that it is not trivial.

[lowenz]

Thanks!

Will test when SVN server will come up again!

 

And about GLprogs folder? Any more recent version? (is it still necessary with the SVN built, right?)

Edited October 22, 2019 by lowenz

[lowenz]

SVN still offline!

[lowenz]

Up! Why still offline? It's moving to github?

Edited October 25, 2019 by lowenz

[duzenko]

27 minutes ago, lowenz said:

Up! Why still offline? It's moving to github?

That's what I suggested after the last incident but I was outvoted.

I even prepared an alternative free svn hosting but ALAS.