ZDoom

@realdevs: Houston, i've got a problem. I decided to port that thing about window resizing and viewport scaling. It works, i guess i should not have done it. But now that line at the bottom of the console appears at the wrong position after resizing. Where is it? Is that even a real line? Help appreciated as always.

Another thing i've noticed is that the weapon no longer appears at the right position in the savegame thumbnail and then it was removed. So that's when it dissapeared, fixing that doesn't look easy.

It's not only that line but the automap background and the squares for the load/save screens.

Hey drfrag, maybe this isn't the right time for it but whenever you can, could you port your fake splitscreen changes in LZDoom to this? ZDoom32 just works faster on more computers so i'd say there's a higher chance of playing a 4 player match

Also, in ZDoom LE Kill scripts don't execute if you use the forcekillscripts MAPINFO flag. Haven't tested here but i think it might be affected too.
You can use this mod: viewtopic.php?f=43&t=65517
to test it. Just set vd_treasure to 1, and kill any monster. If it spawns floating numbers, it works, if it doesn't then it's not working. All relevant code is in MAPINFO and VDACS.acs.

It works, why haven't you tested it yourself? It was not supported in LE.
You should install Git/TortoiseGit.

I've already done it, but there's a problem: you can't resize the window with the old GL renderer (works with D3D). I've ported some code and now it works but there are problems with some 2D stuff: automap background, load/save boxes, console bottom line. They are at the wrong position, what i wrote earlier. Seems some refactoring is required, that was when the F2DDrawer class was introduced. I suspect somehow that stuff is required, i don't know how to make it work without it. Changing video mode fixes it but i can't just do that. Unless someone wants to give some suggestion...

drfrag wrote:It works, why haven't you tested it yourself? It was not supported in LE.
You should install Git/TortoiseGit.

I've already done it, but there's a problem: you can't resize the window with the old GL renderer (works with D3D). I've ported some code and now it works but there are problems with some 2D stuff: automap background, load/save boxes, console bottom line. They are at the wrong position, what i wrote earlier. Seems some refactoring is required, that was when the F2DDrawer class was introduced. I suspect somehow that stuff is required, i don't know how to make it work without it. Changing video mode fixes it but i can't just do that. Unless someone wants to give some suggestion...

Ah so LE is forever without KILL scripts right? Oh well.
I will look into installing it someday, whenever i get my own Internet connection back online.

I guess you could work around it by adding the LZDoom GL 2.0 renderer and having a command line parameter to use it instead? Yeah i know it's a terrible workaround but perhaps it will hold until someone lends you a hand with it.
Honestly i'm fine with those errors as long as they only happen when you resize the window. Not major stuff really, and you could force the overlay automap if video on background is active, like how SSZDoom did it. But again, i'm no real coder and i can't give you any better suggestion than this.

I think i haven't said this before but really thanks for making ZDoom32. It's great and i never thought i could run software truecolor mode so well in this laptop, using it i can play Eviternity at 50+fps after tweaking things like draw distance. Awesome work!

Of course, adding a full GL renderer would be easier. But there's actually an alternative branch with a more modern renderer from that period.

That's not acceptable but now i've noticed those things are actually adjusted, just it's wrong vertically.
Thanks, what makes it so cool is that it has the original dpJudas TC renderer plus the latest stable ZDoom codebase plus the latest incarnation of the old fixed GL renderer.

drfrag wrote:Of course, adding a full GL renderer would be easier. But there's actually an alternative branch with a more modern renderer from that period.

That's not acceptable but now i've noticed those things are actually adjusted, just it's wrong vertically.

Screenshot_Doom_20190802_221624.png

Thanks, what makes it so cool is that it has the original dpJudas TC renderer plus the latest stable ZDoom codebase plus the latest incarnation of the old fixed GL renderer.

Ah now i get what you are saying, this is a GL renderer canvas for the software mode, right? That makes more sense then, because i thought you meant the actual hardware renderer.

At least you are getting a bit closer to the source now, isn't there a way to dynamically apply an offset to a processed image? If you moved it upwards maybe it would work, or the resizing is what's wrong?

Um, i guess these suggestions aren't really helpful coming for someone this illiterate in ZDoom source code but maybe it will give you an idea.

drfrag wrote:ZDoom32 is based on the old Truecolor ZDoom by dpJudas

i considered adding full Decorate support but there was no interest

not gonna lie, a truecolor zdoom port thats compatible with modern mods does sound pretty cool to me, but i guess i already use lz so im not sure what (if any) kind of speed benefits would come from that

ZDoom32 predates LZDoom. Most DECORATE stuff is in but there are a few missing things (from the ZScript branch mainly) and i'd need to update the VM. I don't know to what extent Deco is still being used.

@TDRR: no you don't. Why do you think replacing the entire GL renderer is a "solution" to fix an offset?
When i reduced the window size the gap appeared below. It's fixed now after some investigation and trial and error.
I confirm the weapon dissapeared after "Improved window handling on Windows", fixing it wouldn't be easy and dpJudas chose to remove it. I thought about taking the toscreen parameter to DrawPSprite but there's some code there that apparently doesn't do anything and i don't know how to adjust the position so i've removed it when the view is not maxed out.

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

drfrag wrote:ZDoom32 predates LZDoom. Most DECORATE stuff is in but there are a few missing things (from the ZScript branch mainly) and i'd need to update the VM. I don't know to what extent Deco is still being used.

@TDRR: no you don't. Why do you think replacing the entire GL renderer is a "solution" to fix an offset?
When i reduced the window size the gap appeared below. It's fixed now after some investigation and trial and error.
I confirm the weapon dissapeared after "Improved window handling on Windows", fixing it wouldn't be easy and dpJudas chose to remove it. I thought about taking the toscreen parameter to DrawPSprite but there's some code there that apparently doesn't do anything and i don't know how to adjust the position so i've removed it when the view is not maxed out.

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

I meant that i thought that it was a full hardware renderer that was having the issue, so perhaps just adding an optional LZDoom GL 2.0 renderer would be a half-assed workaround for the problem, not a fix in any real definition of the word. Now that i know it's a canvas for the software renderer (or that's what i understand) i see why that's such a bad idea, you would have to take the software renderer from LZDoom to here, which nulls any benefit at all.
EDIT: Nevermind i got it now, you removed the weapon sprite from savegame screenshots if the view is not at max size, my bad.

My stupid ideas aside, at least it's good that you got it mostly working. You mean the weapon sprite now is removed when the view is smaller than normal or is it just not offset?

I don't know what you're talking about, you're making a mess of it. There were two issues, the misplaced 2D and the weapon offset for savegames. Both were in the hardware renderer. Not counting the third one: the yellow thing when clearing buffers but it's not fixed for performance and because it's the same in D3D.
I've removed the weapon from the thumbnail when not using the full view, it's still always removed in all modern ZDoom based ports. No big deal really.

TDRR wrote:just adding

Merging a renderer is not that easy and besides the complex merge itself requires later adjustments to make it compile and run, that if it would make sense or was doable.

I don't know if Linux and Mac will compile and run (they should), perhaps i should add a Travis config file. And i'd like to add a MinGW target for LZDoom too.

It compiles and runs on linux but without window resizing, same as before. There's no scaling for OpenGL even in fullscreen, that never worked in old versions. It's a GL 2 card tough.

I've released 2.8.5c to fix the crash with the textured automap in the GL renderer. Also added the master volume control and some features from LZDoom: extended joystick support in the background for fake splitscreen (joy_background CVAR) and cull options for the hardware renderer. I had to port the GL window resize feature from QZDoom first.
I haven't done much testing this time.
https://github.com/drfrag666/gzdoom/rel ... 2.8.5c.zip

Sorry for replying to old thread but i think this is the most suitable place to ask

In ZDoom32 the main title screen (titlepic.png) isn't displayed (it appears as a black screen while music is playing) , but credits screen appears normally after a while

This only happens in OpenGL mode , it works without issues in software renderer

The same exact issue also occurs with ZDoom LE

Any ideas about what may be causing it ?

Thanks and best regards,