Shadow Warrior - "New Episode" - Duke4.net Forums

44 Pages
« First
←
33
34
35
36
37
→
Last »

You cannot start a new topic
You cannot reply to this topic

Shadow Warrior - "New Episode"

#1021 Posted 17 July 2017 - 10:39 AM

axl, on 17 July 2017 - 10:35 AM, said:

I wanted to test your latest version but things seem to mess up at startup. See screenshot below... Am I doing something wrong here? Sorry if I overlooked something.

Are you running in Polymer/Polymost? I only ask because I don't support classic mode, and this looks like a classic renderer issue.

This post has been edited by icecoldduke: 17 July 2017 - 10:39 AM

#1022 Posted 17 July 2017 - 10:44 AM

icecoldduke, on 17 July 2017 - 10:39 AM, said:

Are you running in Polymer/Polymost? I only ask because I don't support classic mode, and this looks like a classic renderer issue.

Aha, polymer works just fine ! Both polymost and classic give me weird issues...

#1023 Posted 17 July 2017 - 10:46 AM

axl, on 17 July 2017 - 10:44 AM, said:

Aha, polymer works just fine ! Both polymost and classic give me weird issues...

I'll look into that tonight(I'm at work). I haven't seen any Polymost issues with the latest CL. I always play through in Polymost because there is a non prog in Polymer on the first level(the camera that displays the room were you drive the car, doesn't render because there isn't a proper Polymer implementation of DrawMirrors).

This post has been edited by icecoldduke: 17 July 2017 - 10:48 AM

axl

#1024 Posted 17 July 2017 - 10:58 AM

icecoldduke, on 17 July 2017 - 10:46 AM, said:

Thank you. Apparently the port always resets to polymost after quitting the game. So I have to check the polymer box before starting. Anyway, this looks promising. Really appreciate the key / mouse bindings fix as this facilitates testing.

Small question: can I alter maxfps or vsync anywhere? Just to do some smoothness tests.

Keep up the good work.

Master O

#1025 Posted 17 July 2017 - 01:08 PM

icecoldduke, on 17 July 2017 - 10:46 AM, said:

Can you look at fixing classic rendering at some point, too?

icecoldduke

#1026 Posted 17 July 2017 - 01:17 PM

Master O, on 17 July 2017 - 01:08 PM, said:

Can you look at fixing classic rendering at some point, too?

Classic should work if you run non widescreen. There is some ui rendering issues with eduke32, widescreen, and shadow warrior classic rendering. I have basically buried the issue by forcibly including widescreen assets. So to be clear, Polymost/Polymer widescreen or 4:3 should work. Classic Mode 4:3 should work. Classic Mode widescreen will have broken UI but should work other then that.

Hank

#1027 Posted 17 July 2017 - 02:26 PM

icecoldduke, on 17 July 2017 - 01:17 PM, said:

I tried a few non-widescreen settings, and they do not work for me. Be it windowed or full screen, polymost or classic.
All what works for me is Polymer.

icecoldduke

#1028 Posted 17 July 2017 - 02:28 PM

Hank, on 17 July 2017 - 02:26 PM, said:

I tried a few non-widescreen settings, and they do not work for me. Be it windowed or full screen, polymost or classic.
All what works for me is Polymer.

Does Polymost widescreen work for you? Can you try launching as Polymer then switching to Polymost in the menu?

This post has been edited by icecoldduke: 17 July 2017 - 02:29 PM

Hank

#1029 Posted 17 July 2017 - 02:36 PM

icecoldduke, on 17 July 2017 - 02:28 PM, said:

Does Polymost widescreen work for you? Can you try launching as Polymer then switching to Polymost in the menu?

I tried it with 1920x1080; the moment I switch to either Polymost or Classic, in game, the screen goes nuts.

icecoldduke

#1030 Posted 17 July 2017 - 02:39 PM

Hank, on 17 July 2017 - 02:36 PM, said:

I tried it with 1920x1080; the moment I switch to either Polymost or Classic, in game, the screen goes nuts.

I can't repo that on my PC. What are your specs? You tried in windowed mode?

This post has been edited by icecoldduke: 17 July 2017 - 02:44 PM

Hank

#1031 Posted 17 July 2017 - 02:57 PM

icecoldduke, on 17 July 2017 - 02:39 PM, said:

I can't repo that on my PC. What are your specs? You tried in windowed mode?

No luck in Windowed mode.

Specs
Screen: HP 27c
Video: Quadro 4000
Comp: Intel Xeon
Ram: 16
OS Windows 7

icecoldduke

#1032 Posted 17 July 2017 - 04:29 PM

I have identified the problem. It has something to do with sdl_mixer and sdl being statically linked, I switched the project over to directsound and the problem is fixed. I need to test audio and other things before I commit, but I'll get binaries up shortly.

Posted Image

This post has been edited by icecoldduke: 17 July 2017 - 04:30 PM

Mblackwell

Evil Overlord

#1033 Posted 17 July 2017 - 04:33 PM

Directsound is Windows only, so... Maybe don't do that.

Should figure out how to really prevent it, whether it's the code setup or the specific sdl mixer version since that's not really a fix.

icecoldduke

#1034 Posted 17 July 2017 - 04:43 PM

Mblackwell, on 17 July 2017 - 04:33 PM, said:

Directsound is Windows only, so... Maybe don't do that.

Should figure out how to really prevent it, whether it's the code setup or the specific sdl mixer version since that's not really a fix.

It's fixes the build in the meantime. I plan on rewriting the sound engine.

icecoldduke

#1035 Posted 17 July 2017 - 05:00 PM

Actually disregard the directsound implementation is to broken to use. I'm going to try to come up with something else.

Hendricks266

Weaponized Autism

#1036 Posted 17 July 2017 - 05:02 PM

icecoldduke, on 17 July 2017 - 04:43 PM, said:

It's fixes the build in the meantime. I plan on rewriting the sound engine.

You're never going to get something you write from scratch to sound accurate to the original.

icecoldduke, on 17 July 2017 - 05:00 PM, said:

Actually disregard the directsound implementation is to broken to use. I'm going to try to come up with something else.

If you're delving into the DirectSound layer of ASS, you're doing it wrong. There should be nothing wrong with the sound library itself.

Hint: Compare the parameters between jfaudiolib and EDuke32's audiolib.

icecoldduke

#1037 Posted 17 July 2017 - 05:19 PM

Hendricks266, on 17 July 2017 - 05:02 PM, said:

You're never going to get something you write from scratch to sound accurate to the original.

I wrote that fast from my phone, and doesn't directly relate to what I want to do. That was my bad.

You may have sold me on SDL2, but I don't like sdl_mixer. Let me dig deeper. This issue is definitely causing what people are seeing in my port.

This post has been edited by icecoldduke: 17 July 2017 - 05:22 PM

Hendricks266

Weaponized Autism

#1038 Posted 17 July 2017 - 05:21 PM

We don't like SDL_mixer either. We're only keeping it around to use the TiMIDIty version for MIDI playback on anything not Windows.

TON

#1039 Posted 18 July 2017 - 05:05 AM

axl, on 17 July 2017 - 10:44 AM, said:

Aha, polymer works just fine ! Both polymost and classic give me weird issues...

I had the same problem with the binaries in eduke32_sw_july162017.rar , but compiling the rev from github solves the problem.

icecoldduke

#1040 Posted 18 July 2017 - 07:35 AM

TON, on 18 July 2017 - 05:05 AM, said:

I had the same problem with the binaries in eduke32_sw_july162017.rar , but compiling the rev from github solves the problem.

It seems to be something with release builds, caused by mixing sdl_mixer and sdl. I'm looking into it. Debug builds do not have this problem.

icecoldduke

#1041 Posted 18 July 2017 - 11:24 AM

Alright I have decided that I'm going to be doing some deep modifications to the audio layer in the engine. This will take some time. If you would like to play on the latest CL, running debug works just fine in Classic/Polymost. The binary released works just fine in Polymer. On some computers(like my main computer), you may not see problems at all. If you are seeing problems, that will be fixed after my audio changes.

Hendricks266

Weaponized Autism

#1042 Posted 18 July 2017 - 12:08 PM

icecoldduke, on 18 July 2017 - 11:24 AM, said:

Alright I have decided that I'm going to be doing some deep modifications to the audio layer in the engine. This will take some time.

Let it be known that I tried to talk you out of this.

High Treason

#1043 Posted 18 July 2017 - 12:23 PM

Why do I get the feeling that this will prove to be a pain in the ASS?

Ba-dum-tss

icecoldduke

#1044 Posted 18 July 2017 - 04:41 PM

Came across this little gem today in DoZillaMove :/.

    static int handle;

    // Random Zilla taunts
    if (!FX_SoundActive(handle))

Handle will have some random value because handle isn't initialized.

TerminX

el fundador

#1045 Posted 18 July 2017 - 05:01 PM

icecoldduke, on 18 July 2017 - 04:41 PM, said:

Came across this little gem today in DoZillaMove :/.

    static int handle;

    // Random Zilla taunts
    if (!FX_SoundActive(handle))

Handle will have some random value because handle isn't initialized.

Handle will be 0 because handle is static.

Hendricks266

Weaponized Autism

#1046 Posted 18 July 2017 - 05:06 PM

What happened to multithreading?

icecoldduke

#1047 Posted 18 July 2017 - 05:45 PM

TerminX, on 18 July 2017 - 05:01 PM, said:

Handle will be 0 because handle is static.

I actually didn't know that(learn something new every day!), regardless the logic would be wrong because its checking to see if channel 0 isn't playing any audio. Looping ambient audio could be thrown onto channel 0, and if it does then this logic wouldn't ever execute.

Hendricks266, on 18 July 2017 - 05:06 PM, said:

What happened to multithreading?

I'm having some memory stoppage that I can't track down. I'm fixing compile warnings, this was one of the things that came up.

This post has been edited by icecoldduke: 18 July 2017 - 05:46 PM

TON

#1048 Posted 19 July 2017 - 03:14 AM

I think that your new fix has the same problem:


    static int handle = -1;

    // Random Zilla taunts
    if (handle == -1 || !FX_SoundActive(handle))
    {

Because the condition is ever true

icecoldduke

#1049 Posted 19 July 2017 - 03:38 AM

TON, on 19 July 2017 - 03:14 AM, said:

I think that your new fix has the same problem:


    static int handle = -1;

    // Random Zilla taunts
    if (handle == -1 || !FX_SoundActive(handle))
    {

Because the condition is ever true

No it wouldn't. Handle is a static variable, which means the value of handle stays around after code exits the function scope. The logic behind the change, is it guarantees the sound to get a handle from the sound system. Before FX_SoundActive would check to see if channel 0 had any audio on it. Channel 0 from my experience always has something playing, so that would mean this logic had a good chance of not executing. So the logic behind the change, is it allows the sound code in DoDillaMove to at least get executed once on first play through. Looking at that change, its still wrong. I need to global scope that variable and reset it on map restart.

The bigger issue is FX_SoundActive, from what I can tell, is wrong. Only checking to see if a audio channel has audio on it is only half of the check. You need to also check if audio playing on that channel is the audio your expecting. It could be some other system kicked off audio, and the mixer put that piece of audio on that channel instead of the audio your expecting to play. That paticular circumstance was the cause of a lot of ambient audio fuckage in earlier builds, it seems like the issue extends to non ambient audio as well.

This post has been edited by icecoldduke: 19 July 2017 - 03:43 AM