[SOLVED] Need help with GZDoom merge

Discuss anything ZDoom-related that doesn't fall into one of the other categories.

[SOLVED] Need help with GZDoom merge

Postby drfrag » Thu Jun 08, 2017 4:37 am

I've been messing around lately with the GZDoom 1.8.3 source, i've managed to compile it thanks to Blzut3's patches and runs fine. Then i fixed my repository (originally i created a new repo). In case someone's interested i created a new branch from ZDoom maint and merged my ZDoom LE repo into it using '--allow-unrelated-histories'. Then i resolved conflics keeping my versions, i think git assumes your modifications come later or else this wouldn't work. Then i merged that branch into another one created from the 1.8.3 source and resolved conflicts. I think this went well.
Then i applied manually some patches from GZDoom, cherry-picking would have created a lot of conflicts, to make it compile again. There were a lot of modifications in ZDoom in nearly three years of development (from august 2013 to march 2016), the renderer floatification didn't make it into the maint branch BTW.

So now this GZFDoom (Franken) runs in software but in hardware the menus are fine however when i start a new game after the wipe nothing is rendered, i still see the menu and title pic and when i press ESC the menu appears on a yellow background.
I guess some data structures have changed, i've made only the minimal modifications to make this compile. I don't get any error messages.
So some help from the devs (specially Graf) would be greatly appreciated, i know i cannot count on it. I just need some clue on where to start (which module) to begin tracking modifications in order to backport some patches. Thanks in advance.

I've uploaded my modifications in case someone's willing to help here:
https://github.com/drfrag666/gzdoom/commits/gzdoomle

My new repo for the LE version is also there (zdoomle branch).
The question you may ask is does all this make sense? To me it does, if just for getting experience and learn something. What's more i want to rise the feature level from 2.7.1 to 2.8.1 for this renderer so people with very old machines can still play with OpenGL.
Last edited by drfrag on Mon Jul 31, 2017 5:19 am, edited 1 time in total.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: [Source] Need help with GZDoom merge

Postby drfrag » Fri Jun 09, 2017 5:22 am

Why has this been moved to General? Or am i imagining things? (has to do with a project). I've done a backtrace but didn't help.
@Graf Zahl @devs:
I really want to get this working so with the above symptoms (no rendering upon starting a map after the wipe) what comes next? I mean which file should i check to track changes? Thanks again.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: [Source] Need help with GZDoom merge

Postby Rachael » Fri Jun 09, 2017 5:30 am

The software and ports is for active actual projects only - not for questions related to them. I end up having to move at least 4-5 topics out of there every month because people are confused about what the purpose of that forum is - it's a projects forum, just specifically dealing with software and utilities.

As for your question - no, sorry, I do not have an answer. I'd take advantage of Git's history though instead of trying to override it. GZDoom's releases are all tagged, as are ZDoom's - you can create a repository that uses both as remotes and then do a "git fetch --all" - and then you can merge common histories together. I didn't mention this previously because it looks like you managed to get it to compile - but honestly, I'd just merge in an older version of GZDoom's renderer and push forward with that. You're going to have to be really careful and meticulous how you do the merges though since, obviously, as you found out some of the data structures that the GL renderer uses have changed, and the GL renderer's source files will have to be updated at the same pace as ZDoom's are.

Basically, your best bet is to simply start from GZDoom's equivalent release (I think it was 1.7.x) and then merge in your LE-specific changes.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: [Source] Need help with GZDoom merge

Postby drfrag » Fri Jun 09, 2017 5:55 am

Thanks, actually i've used the git history if i'm not wrong. I created a gzdoom branch from august 2013 and merged in the zdoom version from april 2016 (previously i merged my project into a zdoom branch i created from maint). I'm pretty sure the merge went well (i've checked it again and only got a few conflicts) but 've seen some data structures have changed. I think the gl renderer cannot get the data from those structures anymore.
Merging with a more modern version of GZDoom would be the logical thing to do but i want to use an old renderer for old machines (old intel graphics with GL 1.x support for instance) or else it wouldn't make much sense adding it, you could just use GZDoom instead. Of course the Franken name was a joke, Graf mentioned on doomworld his old GL project with code from PrBoom and ZDoom calling it 'frankenstein', it would be interesting to see that one released some day. Thanks again.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: [Source] Need help with GZDoom merge

Postby Rachael » Fri Jun 09, 2017 6:00 am

Well I don't know how helpful I really was - and also I was wrong about the version number (it was 1.8.x - what you were using - my apologies).

Anyway, later versions of GZDoom do include some maint branch fixes I am sure, but it would probably be better to just rebase your own Git history on top of a stock GZDoom release and not even bother with the maint branch at all - GZDoom had a much more frequent release schedule and that's never changed. You could probably rebase on top of 1.8.6 since that's the version that still supported OpenGL 1.2 and drop the maint branch altogether since 1.8.6 should probably have had most of it embedded by that time, anyway.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

Re: [Source] Need help with GZDoom merge

Postby drfrag » Sat Jun 10, 2017 3:48 am

Of course no neeed to apologize, thanks for replying. Since i created a new repo from the maint branch those changes were already there in the initial commit, they won't harm anyway.
IMHO 1.8.6 wouldn't make a difference (was only a few months later and based on ZDoom 2.7.1 as well), the maint branch was developed until much later. Moreover 1.8.6 required OpenGL 1.4 i think. The equivalent version would be 1.9.1 but that one already required GL 2.0.
I've backtracked some modules but without luck so i'm afraid Frankie is dead, i don't know up to which point the renderer is screwed probably it's just a silly minor issue but don't have the skills to fix this. So if someone wants to continue this task be my guest, the link to the experimental branch is above. AFAIK the merge went well (i used tortoisegitmerge and a diff from an old merge as a guide to check it).
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: [Source] Need help with GZDoom merge

Postby drfrag » Sun Jul 23, 2017 5:57 pm

I still don't know what happened but i've run the bench command both on this (no rendering ingame) and on 1.8.3.
Could any of the devs explain the meaning of these results? Apparently everything is right but the finish value which is very low. So where should i look? I now think this could be some silly bug due to a bad merge somewhere.

Code: Select allExpand view
Map map01: "entryway",
x = -96.0000, y = 784.0000, z = 97.0000, angle = 90.0000, pitch = 0.0000
Walls: 43 (0 splits, 0 t-splits, 184 vertices)
Flats: 18 (66 primitives, 366 vertices)
Sprites: 8, Decals=0, Portals: 0
W: Render=0.532, Split = 0.000, Setup=0.074, Clip=0.044
F: Render=0.384, Setup=0.023
S: Render=0.131, Setup=0.035
All=2.271, Render=1.146, Setup=0.206, BSP = 0.027, Portal=0.000, Finish=0.720
DLight - Walls: 2 processed, 1 rendered - Flats: 2 processed, 1 rendered
Missing textures: 0 upper, 0 lower, 0.000 ms
316 fps

Map MAP01: "entryway",
x = -96.0000, y = 784.0000, z = 97.0000, angle = 90.0000, pitch = 0.0000
Walls: 43 (0 splits, 0 t-splits, 184 vertices)
Flats: 18 (66 primitives, 366 vertices)
Sprites: 8, Decals=0, Portals: 0
W: Render=0.435, Split = 0.000, Setup=0.044, Clip=0.020
F: Render=0.369, Setup=0.012
S: Render=0.108, Setup=0.016
All=10.445, Render=0.981, Setup=0.103, BSP = 0.011, Portal=0.000, Finish=9.187
DLight - Walls: 2 processed, 1 rendered - Flats: 2 processed, 1 rendered
Missing textures: 0 upper, 0 lower, 0.000 ms
91 fps
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: [SOLVED] Need help with GZDoom merge

Postby drfrag » Mon Jul 31, 2017 5:18 am

Well, you won't believe this but it's fixed. :D I've found the problem by pure luck. The low detail modes somehow screwed the OpenGL renderer.
The 3D scene viewport position and size were wrong, viewwindowx and viewwindowy had bad values due to detailxshift and detailyshift not being initialized. I changed (viewwidth<<detailxshift) to realviewwidth and (viewheight<<detailyshift) to realviewheight in that r_utility.cpp ancient code. I also had to change viewwidth and viewheight to realviewwidth and realviewheight in a couple of spots.

Good news is OpenGL for everyone @2.8.1 feature level, i think this ancient renderer runs on GL 1.2 hardware.
There's a minor problem, hqnx scaling does not work with gcc. I'll probably add that codegoogle C++ intrinsic version or the implementation by _mental_, but that one requires MMX if i'm not wrong and this needs to compile with gcc 2.6.1. I wonder if this thing will still run on win95 BTW. May be i should drop 95 support i don't know.
So Frankie is alive and ZDoom LE is not dead after all :lol: , i'll port some stuff from ZDoom32 such as the render culling.

https://github.com/drfrag666/gzdoom/commits/gzdoomle
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: [SOLVED] Need help with GZDoom merge

Postby drfrag » Tue Aug 01, 2017 10:16 am

For now i've added the HQX google code version and apparently runs well and looks good but of course i'm no expert. It didn't compile at first with MinGW but i changed some defines. Of course the MSVC version is faster.

This no longer runs on 95, gives an user32.dll error about ChangeDisplaySettingsExA. I'll try to fix it but also has the OpenAL problem with Brutal Doom torches playing at full volume even with EFX disabled , i would need to apply later patches and modify a more recent dll to make it run on 95. I don't know why hail-to-the-ryzen chose 1.12.854 BTW. I never managed to compile it myself since i would need to modify CMakelists.txt to find directsound on my system. Not with the DX9 allegro libraries nor even with the official DX 8.1 SDK installed. Maybe Chris could help.
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666

Re: [SOLVED] Need help with GZDoom merge

Postby drfrag » Wed Aug 02, 2017 5:23 am

Continuing with my private Dev diary:
I've tested this on a Geforce 2 with an old driver with OpenGL 1.2 support on win98 and runs fine. Only problem i've experienced is i only see a grey screen during the wipe. And there was a silent crash when trying to change renderers on the fly.
This is shaping up quite nicely. Now i think i'm going to drop win95 support, i know how to fix it (with GetProcAddress and ChangeDisplaySettings) but i don't think it's worth. So i'll go back to FModEX.
I don't think that's a problem since i'm going to try to add xbrz support next, this is an old renderer. Nash already did in GZDoom-GPL so if there's something i should know...
User avatar
drfrag
Os voy a romper a pedazos!
Vintage GZDoom Developer
 
Joined: 23 Apr 2004
Location: Spain
Discord: drfrag#3555
Github ID: drfrag666


Return to General

Who is online

Users browsing this forum: No registered users and 1 guest