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

Martix10 wrote:Well suddenly my GZDB starts to crash everytime I try to enter in visual mode. It doesn't show any errors just freezes and close. Can anyone help ?
Not with such skimpy information.
At the very least upload the logfile.
User avatar
Martix10
Posts: 51
Joined: Wed Jul 30, 2014 10:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Martix10 »

Here the log file:
Spoiler:
And a crash file:
Spoiler:
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 »

Do you have a map or some flow to reproduce this? I looked at the code and I understand why this happens, but the funny thing is that if it was THAT broken, it should've happened to everyone.
I'd like a scenario before I do hack-and-patch way of fixing without knowing the actual cause.
User avatar
Martix10
Posts: 51
Joined: Wed Jul 30, 2014 10:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Martix10 »

Well it all started with the map that I uploaded, now it happens to any map, even if I create one and just draw a single square. And if I switch back to older versions it crashes too..
Attachments
map01.wad
(165.46 KiB) Downloaded 28 times
User avatar
Sandro
Posts: 173
Joined: Sat Oct 05, 2013 8:03 am
Location: Erathia

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Sandro »

Hey ! After few weeks of hesitation, I finally switched to this bugfix fork, and I'm really enjoying it, so thanks a lot ZZYZX ! :)


I have minor requests, if you don't mind, about the texture browser :

- Would it be possible to have a toggle to display used textures also in the "all textures" list ? I use to compare some used textures with those I didn't choose to make sure my choice is the best, especially when there's only tiny difference between them.

- Would it be possible to keep memory of the panel display ? I have a lot of textures sets and I can't see them all at once if the "Doom2.wad" folder is open. I have to close it manually every time I open the browser and it's quite annoying.
Spoiler:
- Also, selecting the file name on the panel now shows only the directories and not the textures inside anymore. Is there a reason for that ? (Asking for the same reason above, I'd like to save space for the sets)

- Finally, dunno if it's because of that, but the reaction time when I click on the 'All' subdirectory of my wad to see all the textures I got is now waaay slower than before, takes like ~ 2-3 seconds (when GZDB used to display them all when clicking on the file name, it was almost instantly)
(Happens the same for the general 'All' in the menu ; but I don't use it anyway since I don't want the doom2 stock textures to be displayed with the others)


Thank you anyway.
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 »

So I did read the source a bit more and found a funny sequence of events that apparently leads to this esoteric crash.

1. Switching to a visual mode causes VisualMode.OnEngage and then BaseVisualMode.OnEngage to be executed. In this order, this is important.
2. VisualMode.OnEngage calls MainForm.EnableProcessing, which starts sending periodic events through Windows messages (which are not locked to the current thread technically).
3. "Processing" here means that every 10 milliseconds it would call MainForm.processor_Tick, which also calls OnProcess of the current mode (always BaseVisualMode, this is not used in regular modes AFAIK).
4. BaseVisualMode.OnProcess requires a variable to be initialized. It's only initialized in BaseVisualMode.OnEngage.
5. So if BaseVisualMode.OnProcess gets executed between VisualMode.OnEngage (which enables processing) and BaseVisualMode.OnEngage (which initializes the variable), you get the crash.

Now the funniest part: it's been like this ever since CodeImp codeimped it and no one ever noticed :roll: I can congratulate you with having a really fast parallel CPU :lol:
Or perhaps someone did, but it'd manifest itself as even more random crashing with less useful stacktraces. Like these camaxide's bug reports that no one else can reproduce...

Anyway, try testing pls.
User avatar
Martix10
Posts: 51
Joined: Wed Jul 30, 2014 10:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Martix10 »

Looks like my bad luck was useful .. it worked!! But what could have started it? It never happened before and after the first crash it didn't work anymore even if I uninstall and install it again ..weird :shock: :?:
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 really OS-dependent. Do you have Win10?
User avatar
Martix10
Posts: 51
Joined: Wed Jul 30, 2014 10:37 pm

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Martix10 »

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

Well that's probably it. Something could update silently in the background and break things :roll: That's what Win10 does.
User avatar
Nash
 
 
Posts: 17434
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Nash »

Image

GZDB 2.3.0.2988 (b8e6808) vs in-game g3.2pre-467-g1bc8fe7

Sorry I can't track at which version of GZDB did this start displaying wrongly (it used to display correctly in both the editor and in game).

(Why do I feel like the model stretching has been fixed and unfixed so many times throughout these years...)
Attachments
test.pk3
(14.78 KiB) Downloaded 29 times
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 »

Are maps no more stretched vertically in GZDoom? Because I just ran devbuild of GZDoom g3.2-presomething and pixels look square at 1920x1080, not stretched. Please unfix things back for backwards compatibility on GZDoom's side.
User avatar
Nash
 
 
Posts: 17434
Joined: Mon Oct 27, 2003 12:07 am
Location: Kuala Lumpur, Malaysia
Contact:

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Post by Nash »

That has nothing to do with pixel stretching. The model's Z scaling in GZDB's visual mode isn't matching what is seen in GZDoom.

(But to answer your curiosity why are pixels square when you run my WAD, that is because I added PixelRatio 1.0 to my MAPINFO)

Nothing changed in GZDoom, game-wise the model has always looked correct. It's the rendering inside GZDB that somehow was changed and quite recently too because I have been working on the project that uses that model all this time.

But again, please understand carefully what's going on here. This has nothing to do with pixel stretching, but the model scaling. Even if you remove the PixelRatio from my MAPINFO, the model rendering between GZDB and GZDoom will still not match.
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 »

Model's Z scaling is adjusted in a way that it's not scaled along with the map, while the map is. That is, in GZDB.
The only bug that I see is that it unconditionally scales everything by 1.2 (if the scaling is on), without respect to PixelRatio.
Nash wrote:Nothing changed in GZDoom, game-wise the model has always looked correct. It's the rendering inside GZDB that somehow was changed and quite recently too because I have been working on the project that uses that model all this time.
What was recently changed is that Tormentor had a problem with HIS models that models with default scaling (1.0, 1.0, 1.0) didn't fit maps with default scaling (1.2 height). I changed GZDB to fix that and apparently it broke your map, because apparently, I have to somehow account for changed PixelRatio and scale back by 1.2 :roll: Will look into it.

P.S. idk how were you deleting the PixelRatio from MAPINFO but for me removing it resulted in this http://i.imgur.com/nh6Lf9V.png so it indeed is the cause.

edit: FIXED
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 »

Request:

Concerning screenshots taken with F10, could the extra 7 pixel frame on the sides and the bottom be eliminated.
Spoiler:
That's been bugging me for some time now. Having to get rid of the frame in another app is just getting to me.

Thank you :)
Locked

Return to “Abandoned/Dead Projects”