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.

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Kappes Buur » Fri Aug 18, 2017 4:15 pm

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
Kappes Buur
 
 
 
Joined: 17 Jul 2003
Location: British Columbia, Canada

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Martix10 » Sat Aug 19, 2017 4:03 am

Here the log file:
Spoiler:


And a crash file:
Spoiler:
User avatar
Martix10
 
Joined: 30 Jul 2014

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Sat Aug 19, 2017 5:57 pm

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
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Martix10 » Sun Aug 20, 2017 4:46 pm

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..
You do not have the required permissions to view the files attached to this post.
User avatar
Martix10
 
Joined: 30 Jul 2014

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Sandro » Mon Aug 21, 2017 3:23 pm

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
Sandro
 
Joined: 05 Oct 2013
Location: Erathia

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Thu Aug 24, 2017 7:28 am

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
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Martix10 » Thu Aug 24, 2017 9:46 am

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
Martix10
 
Joined: 30 Jul 2014

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Fri Aug 25, 2017 6:05 am

This is really OS-dependent. Do you have Win10?
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Martix10 » Fri Aug 25, 2017 3:34 pm

Yep.
User avatar
Martix10
 
Joined: 30 Jul 2014

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Sat Aug 26, 2017 2:34 pm

Well that's probably it. Something could update silently in the background and break things :roll: That's what Win10 does.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Nash » Sat Aug 26, 2017 3:06 pm

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...)
You do not have the required permissions to view the files attached to this post.
User avatar
Nash
AKA Nash Muhandes! Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Sat Aug 26, 2017 4:48 pm

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
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Nash » Sat Aug 26, 2017 5:02 pm

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
Nash
AKA Nash Muhandes! Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby ZZYZX » Sat Aug 26, 2017 5:30 pm

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
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: GZDoomBuilder-Bugfix, a maintenance fork of GZDB

Postby Kappes Buur » Sun Aug 27, 2017 11:56 am

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 :)
User avatar
Kappes Buur
 
 
 
Joined: 17 Jul 2003
Location: British Columbia, Canada

PreviousNext

Return to Abandoned/Dead Projects

Who is online

Users browsing this forum: No registered users and 1 guest