Page 3 of 38

Re: LZDoom [beta 4 11/29 released]

Posted: Tue Dec 18, 2018 4:25 am
by drfrag
But what the problem is? Is it looping or not? The sound code is exactly the same as in GZDoom, have you tried with GZDoom? Even 3.3.2?

Re: LZDoom [beta 4 11/29 released]

Posted: Tue Dec 18, 2018 6:25 am
by kondoriyano
yes and here the comparison video im using gzdoom 3.3.2 x64
in gzdoom version the song is loop perfectly


and here the latest lzdoom x64 version the song not loop perfectly and interupted

Re: LZDoom [beta 4 11/29 released]

Posted: Tue Dec 18, 2018 8:56 am
by drfrag
This is a GZDoom bug and it was introduced in "Update GME up to 0.6.2 version". LZDoom beta 2 was not affected while legacy devbuilds are.
Edit: created a bug report here: viewtopic.php?f=104&t=62613#p1084087

Re: LZDoom [beta 4 11/29 released]

Posted: Wed Mar 13, 2019 11:16 am
by TDRR
drfrag, any idea why MD3 models don't render at all in first person on the software and softpoly modes? MD2 and UTX work fine, but i don't know why MD3 won't.

And is it at all possible to increase max player count? 16 would be a neat number, 32 even better but that's getting a bit too far for a peer-to-peer multiplayer system.

What is are some estimated minimum playable system requirements? I assume you need D3D9, OpenGL 2.0, 512MB of RAM and a 1.2GHz CPU, maybe Pentium 3 or Pentium 4.

Re: LZDoom [beta 4 11/29 released]

Posted: Sat Mar 16, 2019 4:28 am
by drfrag
No idea, did they work in GZDoom 3.3.2? I can't look into it right now anyway.
LZDoom requires SSE2 (release builds) but you can compile without the TC_USE_SSE2 option and i tested on an athlon xp and a pentium 3 1.0 ghz, it was playable with vanilla maps (i tried software only on the p3 i think). I think you'd also need to recompile the dlls with MinGW-w64 and/or use older versions. But it requires win xp, 98 ran like shit due to the new timing code (i only tested without sound there).
Edit: now that i think of it model support in software was added later, so we'd need to compare with more recent versions.

Re: LZDoom [beta 4 11/29 released]

Posted: Wed Apr 10, 2019 12:43 pm
by RSSwizard
Got a crash on my first run with LZ 3.61 (32 bit)
"Framebuffer must have exactly 1 lock to be updated"
Using doom_complete.pk3 wadsmoosh, started a game under plutonia experiment, map 01 (the pk3 is in proper working order)
I didnt fiddle with any options yet because I wanted to test performance.
Also the default starting action to go to fullscreen did some funky stuff to my desktop, pretty much resizing my display to 640 and when I hit alt+enter to go to windowed mode the windows taskbar "clung" to the side of the game window for a moment. It rearranged some of the icons on my desktop.

There was also a noticeable delay of about 4-7 seconds after the intitial startup had done loading, before the game responded and went to fullscreen and displayed things.

I do have a 64bit os, but I was testing the 32bit because I prefer to use 32 versions of programs absolutely whenever I possibly can.
Ill check (and edit post) if I get the same problems on the x64 version.

Stats:
Windows 8.1 Pro x64
4gb ram, 1.3ghz AMD dual core
AMD radeon 6310 graphics with 384mb vram shared
Lenovo Thinkpad



EDIT:
The x64 version runs but when I was trying to get "square pixels" set up in the video mode options it did this to me. First I set the resolution to 1024x600 then I set the resolution scale to 640x400, and then I set forced aspect ratio to 5:4
(im aware that the original game didnt have square pixels because of imperfections in crt/320x200. But I need my pixels to be square and all the same size like they used to be in zdoom)

This is some really weird stuff and it even crushes the options menu options to where its hard to see those to fix them.
Also (error002b) I closed the program then ran it again to see if the graphics glitch was temporary, and IT IS NOT.

Re: LZDoom [beta 4 11/29 released]

Posted: Mon Apr 15, 2019 4:15 am
by drfrag
For me it doesn't crash. That's not a common resolution, it's there becouse it's reported by your video driver. The scale factor never worked properly in D3D.
Then you're forcing a very different aspect ratio. The D3D backend had known issues, some resolutions gave problems (specially LB modes with certain video drivers).
The rearranged icons thing happened with all old games using real fullscreen and low resolutions, perhaps i should change the default resolution to 1024 (640 was the default for ZDoom). It's surprising ZDoom worked well with those settings for you, i guess you were using a different computer/video card.
I need to update this, right now is ahead GZ 3.6.1.

@TDRR: I need a small running sample for the issue with md3 models.

Re: LZDoom [beta 4 11/29 released]

Posted: Mon Apr 15, 2019 10:38 am
by TDRR
fps-models.zip
(9.91 KiB) Downloaded 94 times
Here it is, use the IDKFA cheat and press slot 2. I recommend you use FOV 120 so it's more visible. It's also flickery and i have no idea what's causing it, if you know then i would appreciate you tell me how to fix it.

Re: LZDoom [beta 4 11/29 released]

Posted: Thu May 02, 2019 2:00 pm
by drfrag
And clearly you haven't done your homework here, your model doesn't work in software neither in the vintage build nor in modern GZDoom. Should they? If so then it's a GZDoom bug.
Edit: largemodel.pk3 is an MD3 and it works.

Re: LZDoom [beta 4 11/29 released]

Posted: Thu May 02, 2019 2:05 pm
by drfrag
I need help with this test: largemodel.pk3. In LZDoom the flashlight only works when i'm firing, what is this code supposed to do? May be something went wrong with the lighs refactor i don't know. I've edited the ZScript version.
Edit: i see Nash posted it.
Edit2: no idea of what's happening but Steve's flashlight works.

Code: Select all

version "3.8"

class TestPlayer : DoomPlayer
{
	DynamicLight light;

	override void Tick(void)
	{
		Super.Tick();

		if (!light)
		{
			light = DynamicLight(Spawn("DynamicLight", Pos, NO_REPLACE));
			color c = color(255, 255, 255);
			light.args[0] = c.R;
			light.args[1] = c.G;
			light.args[2] = c.B;
			light.args[3] = 150;
			light.bAttenuate = true;
			light.bSpot = true;
			light.SpotInnerAngle = 30;
			light.SpotOuterAngle = 40;
		}
		else if (light)
		{
			Vector3 lightPos = (Pos.X, Pos.Y, Pos.Z + player.viewheight);
			light.SetOrigin(lightPos, true);
			light.Prev = Prev;
			light.Angle = Angle;
			light.Pitch = Pitch;
		}
	}
}

class Test : Actor
{
	Default
	{
		Radius 220;
		-SOLID
	}

	States
	{
	Spawn:
		MEDI A -1;
		Stop;
	}
}

Re: LZDoom [beta 4 11/29 released]

Posted: Thu May 02, 2019 3:07 pm
by TDRR
Yeah, for some reason dynamic lights don't work in certain configurations, i can't tell you the exact details but at least in Vault dynamic lights are entirely broken.

Re: LZDoom [beta 4 11/29 released]

Posted: Thu May 02, 2019 3:36 pm
by drfrag
But since when? What is Vault?
Edit: found it, but this is a very recent test and this problem has nothing to do with yours.

Re: LZDoom [beta 4 11/29 released]

Posted: Fri May 03, 2019 4:31 am
by drfrag
I've come to the conclusion that the light exists but for some reason i can't see it unless there's another one. Any ideas?

Re: LZDoom [beta 4 11/29 released]

Posted: Fri May 03, 2019 8:20 am
by drfrag
It's fixed, i was suspicious about something i did. BTW if (!light) else if (light) doesn't make sense in C.
https://github.com/drfrag666/gzdoom/com ... 971cd5a212

Now there's a crash with 64 bit MinGW builds, i need to ask Blzut3. I think it was introduced in "- removed all remaining native parts of APlayerPawn" and it's fixed with "- switched the Windows backend to use the Windows Unicode API." but i haven't made the switch here.

Code: Select all

#0  FConsoleCommand::FConsoleCommand (this=0x188aa80 <Cmd_event_Ref>, 
    name=0x1077c14 <DStaticEventHandler_Find_Hook+660> "event", 
    runFunc=0x9f22a2 <Cmd_event(FCommandLine&, AActor*, int)>)
    at C:\DEV\lzdoom\src\c_dispatch.cpp:1002
#1  0x00000000009f256c in __static_initialization_and_destruction_0 (
    __initialize_p=1, __priority=65535) at C:\DEV\lzdoom\src\events.cpp:1242
#2  0x00000000009f25bc in _GLOBAL__sub_I_E_FirstEventHandler ()
    at C:\DEV\lzdoom\src\events.cpp:1284
#3  0x0000000000b107a2 in __do_global_ctors ()
#4  0x000000000040139a in __tmainCRTStartup ()
#5  0x00000000004014cb in WinMainCRTStartup ()
Edit: fixed, i forgot to revert the stack protection. It was broken and made it crash on 64 bit windows.
Now i'm going to add a command line ZScript version override, LZDoom only supports up to 3.8. Edit: done.

Re: LZDoom [beta 4 11/29 released]

Posted: Sun May 05, 2019 1:28 pm
by TDRR
Why is LZDoom actually slower than QZDoom? At minimum, QZDoom runs 2x faster than LZDoom, and in the best of cases it can grant a 3x speed advantage over LZDoom. Why is this the case? I thought GZD 3.3.2 would be at least a bit faster, but apparently that isn't the case.