[REL/FINAL] GZDoom-GPL 2.4 - now with software renderer
Re: [source] GZDoom-GPL - GPL'ed GZDoom for indies
Yeah but we'd need Vladimir Arnost to also relicense to make MAME's relicense worth considering.
Re: [source] GZDoom-GPL - GPL'ed GZDoom for indies
Blzut is right. If some wants to commercially take advantage of the software renderer then he should put the work in. Not the Zdoom developers.
Is any serious project in the works for the already released GPL forks?
Is any serious project in the works for the already released GPL forks?
- Sarah
- Posts: 551
- Joined: Wed Sep 06, 2006 12:36 pm
- Preferred Pronouns: She/Her
- Operating System Version (Optional): Debian 11 (bullseye), Windows 10
- Location: Middle of Nowheresville Il.
- Contact:
Re: [source] GZDoom-GPL - GPL'ed GZDoom for indies
I've had my eye on GLOOME for a bit now, but I didn't want to be back on the 1.8 rendering, so I'm really glad to see this project!
Couple (A) questions, since I'm new to compiling the engine:
I figured out my sound problem. It was simply a bad configuration file. I'm still wondering about the poor performance, but I do still have to reconfigure everything yet so my hope is that I was experiencing lag from the lack of sound.
**Edit:
Reconfigured, performance is still pretty poor. Basically I'm experiencing lag in parts of C01 that have not in the past.
***Edit:
I've been reading a bit, and it seems that Visual Studio is likely my culprit. Looking into compiling with MinGW instead, and will update further.
Couple (A) questions, since I'm new to compiling the engine:
- 1 - Do I still need FMod?
- - I ask because all three builds have had no sound
- 2 - On the same subject, what about FluidSynth?
- - What about pointing CMake at those files?
- - I tried to add FLUIDSYNTH_LIBRARIES & FLUIDSYNTH_INCLUDE_DIR but the values disappeared.
- - What about pointing CMake at those files?
- 3 - I noticed that all three builds I've made run poorly, one much more than the other two. Is that sound related or something I'm doing wrong?
Spoiler: CMake Info*Edit:
I figured out my sound problem. It was simply a bad configuration file. I'm still wondering about the poor performance, but I do still have to reconfigure everything yet so my hope is that I was experiencing lag from the lack of sound.
**Edit:
Reconfigured, performance is still pretty poor. Basically I'm experiencing lag in parts of C01 that have not in the past.
***Edit:
I've been reading a bit, and it seems that Visual Studio is likely my culprit. Looking into compiling with MinGW instead, and will update further.
Re: [source] GZDoom-GPL - GPL'ed GZDoom for indies
Have you tried building Graf Zahl's official GZDoom to check if the bad performance happens on that one as well? If it does, then it's not a problem with the code base, but your build environment.
- Sarah
- Posts: 551
- Joined: Wed Sep 06, 2006 12:36 pm
- Preferred Pronouns: She/Her
- Operating System Version (Optional): Debian 11 (bullseye), Windows 10
- Location: Middle of Nowheresville Il.
- Contact:
Re: [source] GZDoom-GPL - GPL'ed GZDoom for indies
I haven't tried that. I've been trying to get MinGW to work but builds keep failing. It's very late so I'll do as you suggest tomorrow. If it is my build environment, what can I do?
Re: [source] GZDoom-GPL - GPL'ed GZDoom for indies
Hey Nero, just curious if you're still experiencing those slowdowns and what did you do to fix them (if you fixed them)? Would be useful to know.
- Sarah
- Posts: 551
- Joined: Wed Sep 06, 2006 12:36 pm
- Preferred Pronouns: She/Her
- Operating System Version (Optional): Debian 11 (bullseye), Windows 10
- Location: Middle of Nowheresville Il.
- Contact:
Re: [source] GZDoom-GPL - GPL'ed GZDoom for indies
I haven't touched the project in a while, and no I didn't get anything fixed. I do remember that the compiled executable was an unusual 8mb to the normal 4mb, which happened regardless of the version I compiled, even the official source. Changes to settings in CMake didn't have any effect so I began to suspect Visual Studio and my current OS setup. Speaking of Visual Studio and the OS, this is the third or fourth time I've reinstalled Visual Studio and prereqs for GZD, which leads me to think that I've got a mess under the hood that would best be cleaned up by just formatting and reinstalling. As it stands now, I've got one final to go this semester, so when that's done and winter break is officially in full swing I'll be willing to take a crack at it again.
Re: [source] GZDoom-GPL - GPL'ed GZDoom for indies
Ah yeah that sounds like something royally messed up and it would better to just start fresh. I also recently formatted and installed a new OS with minimal programs and tools, and building GZDoom is flawless. :D Good luck!
Re: [source] GZDoom-GPL - GPL'ed GZDoom for indies
I am having trouble building the program, when I build the solution I get the error "error LNK2026: module unsafe for SAFESEH image. C:\Users\User\Desktop\Game Engine Code\Visual studio\Gz-doomgpl\src\OpenAL32.lib(dwpdbs00022.o) zdoom". I have reinstalled all the required libraries and that doesn't seem to help, the only time I don't get the error is when I build without openal. Am I doing something wrong?
Re: [source] GZDoom-GPL - GPL'ed GZDoom for indies
Thanks, that works.
- Sarah
- Posts: 551
- Joined: Wed Sep 06, 2006 12:36 pm
- Preferred Pronouns: She/Her
- Operating System Version (Optional): Debian 11 (bullseye), Windows 10
- Location: Middle of Nowheresville Il.
- Contact:
Re: [source] GZDoom-GPL - GPL'ed GZDoom for indies
Good news, Nash!
Wait, that's not good news
But there is good news to be had! I also reinitialized my system on a trusty backup HDD and quickly set about putting together a minimalist build and after a few false starts the engine compiled and Visual Studio yielded a file of about 8MB, again; that build ran fine running Doom, but I did not test it with C01 as past experience told me it wasn't worth the time. Still waiting for the good news? Well I discovered that indicating that I'd like a "Release" build in CMake meant jack squat to Visual Studio when I opened the solution properties; Visual Studio was still configured to make a Debug build, which I'm guessing is not optimized for speed (something C01 needs). I changed the configured settings to Release, cleaned the solution, recompiled, and found an executable of about 4MB! This one I have tested with C01 and the only lag I have experience has been predictable, ie my own stuff is causing it. Another side effect of VS ignoring CMake does seem to be the GZD PK3 size, which the one I've generated is 968kb over the downloaded 666kb, but that is minor.
There's good news in there somewhere To sum up, I got it working! It seems it was mostly user error, so I'll fiddle with CMake and see if I missed something.
Spoiler: The Over-Excited VersionI've spent the past few days in an attempt to isolate a bad component in my system, and eureka! It's my SDD!
Wait, that's not good news
But there is good news to be had! I also reinitialized my system on a trusty backup HDD and quickly set about putting together a minimalist build and after a few false starts the engine compiled and Visual Studio yielded a file of about 8MB, again; that build ran fine running Doom, but I did not test it with C01 as past experience told me it wasn't worth the time. Still waiting for the good news? Well I discovered that indicating that I'd like a "Release" build in CMake meant jack squat to Visual Studio when I opened the solution properties; Visual Studio was still configured to make a Debug build, which I'm guessing is not optimized for speed (something C01 needs). I changed the configured settings to Release, cleaned the solution, recompiled, and found an executable of about 4MB! This one I have tested with C01 and the only lag I have experience has been predictable, ie my own stuff is causing it. Another side effect of VS ignoring CMake does seem to be the GZD PK3 size, which the one I've generated is 968kb over the downloaded 666kb, but that is minor.
There's good news in there somewhere To sum up, I got it working! It seems it was mostly user error, so I'll fiddle with CMake and see if I missed something.
Re: [source] GZDoom-GPL - GPL'ed GZDoom for indies
Good to hear! Yes, you will always have to set the build mode to Release on your own if you're not planning on using a debug executable... this has always been the case, even with ZDoom, for pretty much forever. :D
Happy game-making and good luck with your project!
Happy game-making and good luck with your project!
Re: [source] GZDoom-GPL - GPL'ed GZDoom for indies
Hello, tell me, GZDoom-GPL, developed in parallel with the usual GZDoom? May I ask the developer to enter into the engine pre cache 3d models? It's just not necessary to when 3D models much on the level and make it more customizable MENUDEF?
Many thanks to Nash =)
Many thanks to Nash =)
Re: [source] GZDoom-GPL - GPL'ed GZDoom for indies
So far, GZDoom-GPL is 1:1 with the latest version of the official GZDoom codebase (except for the last few days' worth of changes, they're big so I will need some time to carefully merge them and make sure I don't mess anything up)... unfortunately, by principle, I will not add anything that is not in the official GZDoom because it's supposed to be exactly "GPL version of GZDoom".
But what you can do is, you can fork/base your game off GZDoom-GPL, receive the benefits of the latest bleeding edge GZDoom codebase, and add the 3D model precaching yourself as an exclusive engine feature. Unfortunately I know nothing about 3D graphics programming, I am just doing maintenance to this project. :S Sorry I can't help you!
But what you can do is, you can fork/base your game off GZDoom-GPL, receive the benefits of the latest bleeding edge GZDoom codebase, and add the 3D model precaching yourself as an exclusive engine feature. Unfortunately I know nothing about 3D graphics programming, I am just doing maintenance to this project. :S Sorry I can't help you!