GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Projects that have specifically been abandoned or considered "dead" get moved here, so people will quit bumping them. If your project has wound up here and it should not be, contact a moderator to have it moved back to the land of the living.
Locked
User avatar
Mav3r1ck
Posts: 262
Joined: Thu Jul 16, 2015 11:09 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Mav3r1ck »

Kappes Buur wrote:
Mav3r1ck wrote:I just got my first gaming computer and attempted to start up GZDB-BF but when I do it will show the cursor as if it was opening up the program and then nothing happens. I'm not sure of what to do here.
Check the bottom of this webpage for requirements.
I tried an earlier revision and it started up but crashed when I loaded a map. It was something about the Slim and it said "ERROR_MOD_NOT_FOUND".

My new computer came with DirectX 12. Do I need DirectX 9 to run this?
User avatar
Kappes Buur
 
 
Posts: 4114
Joined: Thu Jul 17, 2003 12:19 am
Graphics Processor: nVidia (Legacy GZDoom)
Location: British Columbia, Canada
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Kappes Buur »

Mav3r1ck wrote: I tried an earlier revision and it started up but crashed when I loaded a map. It was something about the Slim and it said "ERROR_MOD_NOT_FOUND".
Since r3030, GZDB-BF is compiled with .NET 4.
Go to the SlimDX website and download
the End User Runtime for ".NET 4.0", either "x86 Download" or "x64 Download", depending on which version of GZDB-BF you use.

Mav3r1ck wrote: My new computer came with DirectX 12. Do I need DirectX 9 to run this?
Since GZDB-BF is derived from GZDB, yes you need to install DirectX 9.
User avatar
Mav3r1ck
Posts: 262
Joined: Thu Jul 16, 2015 11:09 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Mav3r1ck »

Can I run DirectX 9 alongside DirectX 12? It won't replace DirectX 12 will it?
User avatar
PlayerLin
Posts: 580
Joined: Sun Nov 11, 2007 4:20 am
Graphics Processor: nVidia with Vulkan support
Location: XinZhuang, XinBei/New Taipei City(Former Taipei County), Taiwan.
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by PlayerLin »

Mav3r1ck wrote:Can I run DirectX 9 alongside DirectX 12? It won't replace DirectX 12 will it?
Each version of Direct X is independent, never replace the other versions, so yes, you can run, you just needed to install it if your system never installed any of Direct X 9 runtimes(same goes with 10 and 11).
User avatar
MartinHowe
Posts: 2022
Joined: Mon Aug 11, 2003 1:50 pm
Location: Waveney, United Kingdom
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by MartinHowe »

Interesting issue here: Application crash on startup from 64 bit build but not on 32 bit build:

Code: Select all

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	Builder.exe
  Application Version:	2.3.0.3039
  Application Timestamp:	5b5875c0
  Fault Module Name:	KERNELBASE.dll
  Fault Module Version:	6.1.7601.24231
  Fault Module Timestamp:	5b6db5dd
  Exception Code:	e0434352
  Exception Offset:	000000000001a06d
  OS Version:	6.1.7601.2.1.0.256.48
  Locale ID:	2057
  Additional Information 1:	367e
  Additional Information 2:	367e805d0e7c1ec3f63b05bb5ce5c416
  Additional Information 3:	3838
  Additional Information 4:	3838c9f6226fa1f240e24ad80883af36
This is the build of GZDB from DRDTeam date July 25
The machine is a Windows 7 Pro x 64 VM hosted in VirtualBox on 64 bit Xubuntu. The graphics driver is the experimental WDDM VBox driver so I thought that might be the problem; however, the 32 bit build of GZDB runs fine.

If you would need more information, is there a debug build of the 64 bit version of GZDB that I can try?
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

This is probably caused by DevIL. There isn't a special debug build available, I can make one but you seem to have a crash in native code so making a debug GZDB probably wouldn't help...
User avatar
MartinHowe
Posts: 2022
Joined: Mon Aug 11, 2003 1:50 pm
Location: Waveney, United Kingdom
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by MartinHowe »

ZZYZX wrote:This is probably caused by DevIL. There isn't a special debug build available, I can make one but you seem to have a crash in native code so making a debug GZDB probably wouldn't help...
OK; I guess I can live with it as the 32-bit build works OK. I'm just puzzled that the bit size makes a difference. Or is DevIL a 32-bit only library and the WoW64 doesn't interact with it correctly?
User avatar
Siberian Tiger
Posts: 476
Joined: Fri Jun 12, 2009 11:23 pm
Preferred Pronouns: He/Him
Operating System Version (Optional): Windows 10 Pro. 22H2
Graphics Processor: nVidia (Modern GZDoom)
Location: United States
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Siberian Tiger »

Hallo,

If I may ask for a small feature request (or maybe it is a bug?), is it possible that the UI for the Script Editor be changed (or scaled) to be viewed better with screen resolutions that have a high-DPI? Presently, the icons and the taps are kinda small for me to read or see.

For example, I am using my Surface Pro 4 using a screen resolution of 2736x1824 with the DPI scaling set to 200%
Spoiler: Images

Thank you for your time,
User avatar
Empyre
Posts: 68
Joined: Thu Apr 05, 2007 10:39 pm
Location: Garland, TX, USA

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Empyre »

I have an idea that might have been brought up before in this long thread: When opening or saving a map, let the user open a PK3 file as if it were a folder, so he can browse within it for wads containing maps, which could then be edited in situ. The only thing left after that would be to add the ability to make a new PK3 like you would a new folder. Oh, and the ability to save-as a copy of the PK3 like you can now with wads.

Another issue that I have mentioned before is that the Zandronum UDMF config file is doing something wrong that the ZDoom UDMF config file is doing right, causing textures and flats from a PK3 to be missing in the 3D view. Somebody who knows how to edit those config files, which I don't, could probably fix that relatively easily.

These are suggestions, not demands. I understand that you are doing this as a hobby, not as a job, and I appreciate what you are doing.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

PK3 editing is complex.
I'll look at the Zan config though.

Also: I don't have a high DPI screen to test >_>
The script editor basically uses ScintillaNET from what I know.

Also (x2): Empyre do I look like maxed? lol. (about the last line :Р)

Also (x3):
MartinHowe wrote:OK; I guess I can live with it as the 32-bit build works OK. I'm just puzzled that the bit size makes a difference. Or is DevIL a 32-bit only library and the WoW64 doesn't interact with it correctly?
I have no idea how/why DevIL breaks, I just know that it's actually the only native library used by GZDB and most crashes in native code are caused by that one. It also started to happen after DevIL update (because the old one, used in R3012 and earlier, doesn't have a 64-bit version). Also in some crash logs it states DevIL.dll as the cause, but not always.
User avatar
Empyre
Posts: 68
Joined: Thu Apr 05, 2007 10:39 pm
Location: Garland, TX, USA

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Empyre »

I am not suggesting that you open a PK3 like a WAD. If you open a PK3 like a folder (it is just a ZIP file, after all), any map inside will have to be in a WAD file, which you already know how to edit. If it is not as simple as I think it is, I will take your word for it and drop it.

i wasn't even thinking about MaxEd. I just thought I might be coming across as some jerk making demands, and I also thought that maybe you could use some encouragement, but I do remember what happened with maxEd, and I don't want that to happen again.
User avatar
Devianteist
Posts: 945
Joined: Wed Sep 24, 2014 4:07 pm
Location: Creating a SPACE HULK conversion!
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Devianteist »

So, I'm not sure what's going on, but GZDoom Builder Bugfix will not launch, nor does it even seem to try. I've read the OP, downloaded everything, but it still doesnt work.

What did I do wrong?


Update your DirectX Runtimes my friends. It will save you exposing how silly you are, like I just did.
Last edited by Devianteist on Fri Oct 05, 2018 7:08 pm, edited 1 time in total.
Xabis
Posts: 63
Joined: Wed Mar 06, 2013 7:15 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Xabis »

Hello,

Trying to build from a fresh clone and there seems to be a missing file. Was it not checked in?
Error CS2001 Source file 'C:\dev\GZDB\Source\Core\Controls\FolderSelectDialog.cs' could not be found.

This change was made in commmit 1933b0b6de32bd1ba422971442998658796de898. back in July.
User avatar
ZZYZX
 
 
Posts: 1384
Joined: Sun Oct 14, 2012 1:43 am
Location: Ukraine
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by ZZYZX »

Empyre wrote:I am not suggesting that you open a PK3 like a WAD. If you open a PK3 like a folder (it is just a ZIP file, after all), any map inside will have to be in a WAD file, which you already know how to edit. If it is not as simple as I think it is, I will take your word for it and drop it.
This is not complex as in very complex algorithms involved, but more complex as in it requires some non-monkey coding to accomplish and might take some days to implement.
The difference between loading a WAD from a folder and loading a WAD from a PK3 is that I load it from folder by using one API (filesystem one), while with filesystem->PK3->WAD there's one layer added.

I also have no idea how I'll implement saving into a PK3 because I haven't looked into the current load/save mechanism much and I think saving into PK3 would require severe refactoring (because there's 2 levels of abstraction and I'll have to save the current PK3 and the location of WAD and mapname inside that PK3 instead of just mapname, also "unpack wad -> save map -> pack wad", plus I'm not sure if the ZIP library used supports writing, not just reading...)

Also: there are at least two ways to add maps in a PK3, they look similar but one is intended while another works by accident. First, you can put your map to /maps/ and then it'll be loaded as wad's name (IIRC). Second, you can put your map to a .wad file that sits anywhere in your PK3, and then it'll load by "wad in zip" mechanism. So yea this will need some actual nested file selection dialog to work.

So to sum it up: not interested right now, might do in few days/weeks :roll:


Xabis: yes. One moment, will fix. Sorry for that.
edit - pushed
User avatar
Empyre
Posts: 68
Joined: Thu Apr 05, 2007 10:39 pm
Location: Garland, TX, USA

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Empyre »

ZZYZX wrote:not interested right now, might do in few days/weeks :roll:
There is no hurry. If you do it at any time in the future, that would be awesome. If you decide not to, I am pleased that you at least considered it.
Locked

Return to “Abandoned/Dead Projects”