[SOLVED] Need help with GZDoom merge

[drfrag]

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.

[drfrag]

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.

[Rachael]

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.

[drfrag]

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.

[Rachael]

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.

[drfrag]

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

[drfrag]

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 all

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

[drfrag]

Well, you won't believe this but it's fixed. 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 , i'll port some stuff from ZDoom32 such as the render culling.

https://github.com/drfrag666/gzdoom/commits/gzdoomle

[drfrag]

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.

[drfrag]

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