ZDoom

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?

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.

Can I run DirectX 9 alongside DirectX 12? It won't replace DirectX 12 will it?

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).

Interesting issue here: Application crash on startup from 64 bit build but not on 32 bit build:
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?

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...

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?

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

---

Here is my current settings:

MetroControlPanel_DisplaySettings

Here is the script editor with these settings:

ScriptEditor_ScaleIssueDPI

Thank you for your time,

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.

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.

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.

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.

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.

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


Xabis: yes. One moment, will fix. Sorry for that.
edit - pushed

ZZYZX wrote:not interested right now, might do in few days/weeks

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.