DRD Team

Hello!
I am from Russian Doom2D community.
We are making our own Doom2D for OpenGl and can't make a proper effect of invulnerability (on the bottom screen):



But in GZDoom, invulnerability in OpenGL looks like vanilla - inverted and black/white. How you do it?

P.S. May be, I wrote here already.

P.P.S. http://doom2d.org (translated from Russian by google)

why are you pleased to make again the wheel ?!?
(explanation: why do you want to make what was already been made?)

Jabberwock wrote:
But in GZDoom, invulnerability in OpenGL looks like vanilla - inverted and black/white. How you do it?

There's 2 implementations:

For old hardware I create a second set of textures in the proper colors.
For new hardware I use a GLSL shader to process the pixels when they are rendered.

Graf Zahl wrote:

Jabberwock wrote:But in GZDoom, invulnerability in OpenGL looks like vanilla - inverted and black/white. How you do it?

There's 2 implementations:

For old hardware I create a second set of textures in the proper colors.
For new hardware I use a GLSL shader to process the pixels when they are rendered.

Thanks. Maybe it will useful.

Jive wrote:what are you pleased to make again the wheel ?!?

And why people makes GZDoom, jDoom, Vavoom and other advanced ports of classic Doom?

To be very clear, I understand absolutely not, and I'm very serious !!
I don't understand, for example, why people are playing with Zdoom, when we have Gzdoom...

Because ZDoom gets more frequent SVN updates, and some features only fit well into ZDoom to be filtered down into GZDoom later.

Not everyone likes OpenGL - unfortunately...

To be honest with you, there's some things I don't like about the OpenGL rendering, although you've managed to fix a few of them Graf.

Fact of the matter is, it's always gonna be a challenge to render something as vintage as Doom under something else that's modern and was never designed to actually handle sprites the way Doom does.

Thing that frustrates me quite a bit is with the GL renderer, everything is clipped even when it shouldn't be. Of course, for all intents and purposes it has to be because of how OpenGL handles the z-field, but even so, if there's a screaming revenant coming down a narrow corridor, I'd like to be able to see more than just his legs.

Curse id for making the sprite larger than the actor...

nothing is perfect under the satan's sun...

SoulPriestess wrote:Thing that frustrates me quite a bit is with the GL renderer, everything is clipped even when it shouldn't be. ...but even so, if there's a screaming revenant coming down a narrow corridor, I'd like to be able to see more than just his legs.

Whilst, obviously, things like revenants and archviles having their tops chopped off looks bad, because I play GZdoom so much, I also now find the way that sprites can extend into the floor/ceiling in software mode increasingly obvious and bizarre looking. Take for example this Zdoom screenshot on MAP02 where the feet of the zombies and the health bottles all seem to be poking down below the platform that they are standing on because of how the sprites are offset in the Y direction.

It's quite easy to change the offsets, using WinTex... and more complicated with XWE.
It's what I done with some sprites of my collections ("Wads1or2.wad", "Wads1to2.wad, AddonFor1.wad" and "AddonFor2.wad"). Playing with my addons let you have sprites correctly looking.
By the way, did you know that the SKY1 is bugged within the Iwad? Don't tell me that my version is screwed, because it's coming from the CD that I bought: "Ultimate Doom : Thy Flesh". This sky has a y offset wrongly declared to be "-8"...



This Doom iwad is dated, on the CD, wednesday june 12, 1996, 16:59:02
A lot of errors like this one are present within the iwads...
So yes, WE have to do the job by ourself.
You could do the same thing?

Yeah, I wouldn't normally bother changing the sprite offsets because they don't bother me that much. Anyway, I usually play in GZdoom which moves them up for me and if I'm putting my own sprites into a WAD for some project or other, I usually put them in with more GL compatible offsets these days too.

And yes, I did know about SKY1.

Jive wrote:why are you pleased to make again the wheel ?!?

Why do you want to reinvent the wheel ?!?
or simply
Why reinvent the wheel ?!?

Jive wrote:It's quite easy to change the offsets, using WinTex... and more complicated with XWE.

Well, I don't know about that. What could be easier than clicking and holding the mouse on the sprite and moving it into the proper offset?

NeoHippo wrote:Well, I don't know about that. What could be easier than clicking and holding the mouse on the sprite and moving it into the proper offset?

Whilst I agree with you - I really like the ability to click and drag for offsets in a GUI - sooner or later you will need to be precise and input numeric values too. Of course, XWE allows that as well, I'm just saying.