Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
funduke

gzdoom: dead marine bodies sink into floor

Recommended Posts

Hello Graf Zahl!

Many thanks for the new v. 0.9.27 of gzdoom.
I like your port very much.
There is something (also in the previous versions of GZDooM), that might have been mentioned before (i haven't read everything, that has been talked about gzdoom), so please don't feel diappointed, if i repeat something well-known:
The dead bodies of the space-marines 'sink into the floor', so the grapic of that sprite is not fully displayed. Can you fix that? Or, maybe can i use some parameter to tell the port to display that graphic a little bit higher?

Greetings
Funduke

Share this post


Link to post

Go to the options menu, select 'display options', then 'OpenGL options' and set 'adjust sprite clipping' to 'always'. That lifts all sprites out of the floor.

Share this post


Link to post
Graf Zahl said:

Go to the options menu, select 'display options', then 'OpenGL options' and set 'adjust sprite clipping' to 'always'. That lifts all sprites out of the floor.


It works!
I'm happy! :)
Many thanks for the quick help!

Greetings
Funduke

Share this post


Link to post

That is unavoidable. There is no way to tell a z-buffer to ignore certain parts of a floor and still clip properly to walls.

Share this post


Link to post

No. But the ways these 2 renderers work are too different that everything can be ported 100%. If I thought that software was best I wouldn't have bothered writing a hardware renderer, would I?

I can live with the small inaccuracies. The glitches the sofware renderer can produce are often much worse.

Share this post


Link to post

I don't quite get it. Sprites sinking into the floor seems to be a common problem for most 3D ports. Some use some hack to compensate the effect like shifting the world down a bit.

Why does a sprite that is placed on the floor sink into it? Let's draw a quad from bottom using the floor's height to the top using the sprite height (and topoffset if any) and this is a quad that sits on the floor and has the correct dimensions to stretch the sprite texture onto it. Billboarding does not alter the quads vertical position. (Well, for unclamped mouselooking billboarding can shift it but only upwards).

No nagging, but I cannot simply accept that this ugly effect is unavoidable if I see a single 3D port that does not suffer from this. How about ancient Doom3D? Sample:

int spritenum = sprframe->lump[rot];

if (sprframe->flip[rot])

offs=1.0f;

else

offs=0.0f;



doomvertices[0].tu = doomvertices[1].tu = offs;

doomvertices[2].tu = doomvertices[3].tu = 1.0f - offs;

doomvertices[0].tv = doomvertices[2].tv = 1.0f;

doomvertices[1].tv = doomvertices[3].tv = 0.0f;

offs = -fspriteoffset[spritenum];

doomvertices[0].x = doomvertices[1].x = x + fviewsin * offs;

doomvertices[0].y = doomvertices[1].y = y - fviewcos * offs;

offs += fspritewidth[spritenum];

doomvertices[2].x = doomvertices[3].x = x + fviewsin * offs;

doomvertices[2].y = doomvertices[3].y = y - fviewcos * offs;

if ( thing->z == thing->floorz )

z = F2D3D ( thing->z ) + fspriteheight[spritenum];

else

z = F2D3D ( thing->z ) + fspritetopoffset[spritenum];

doomvertices[0].z = doomvertices[2].z = z - fspriteheight[spritenum];

doomvertices[1].z = doomvertices[3].z = z;

etc...
(Vertex order is according to Direct3D, not OpenGL.)

Share this post


Link to post

You don't understand the problem. This happens because the origin of the sprite is not at the bottom line but higher. So if positioned correctly the sprite's lower edge is below the floor and thus invisible. Only solution: Lift the sprite up a few pixels.

Share this post


Link to post

Well, I started out by saying I didn't quite get it...

So there's the bitmap for a spriteframe. I stretch it onto a quad standing on the floor. If the actual picture on the bitmap does not stand on the lower edge of the bitmap then the picture actually hovers a few pixels above the floor, which looks to be the case with Doom3D's approach.

I still have no idea how a sprite can sink into the floor unless the quad itself sinks as well, becoming a prey for the Z buffer.

But at least I understand why the tall torches are jumping in Doom3D: the pictures in the frames have varying offset from the bitmap's bottom.

Share this post


Link to post
rpeter said:

So there's the bitmap for a spriteframe. I stretch it onto a quad standing on the floor. If the actual picture on the bitmap does not stand on the lower edge of the bitmap then the picture actually hovers a few pixels above the floor, which looks to be the case with Doom3D's approach.


That's exactly the same approach every other hardware rendering port uses as well. And because I don't like this hovering effect I added the 'smart' option which only does it for monsters and pickup items. For most decorations I don't like the effect at all and if I knew a better method I'd use it.

Share this post


Link to post
JacKThERiPPeR said:

I think it's because the A_Fall Action Special. I THINK. I'm not sure.



You so far off it is almost unbelievable! :D

Share this post


Link to post
insertwackynamehere said:

i think its probably partially related to the fact that rendering 2D images in a 3D environment is different than rendering them in a 2D environment that simulates a 3D environment.



Well, both have their disadvantages. With Doom's sprite clipping you might get this:

Share this post


Link to post
Graf Zahl said:

Well, both have their disadvantages. With Doom's sprite clipping you might get this:


heh yeah i know, i wasnt dissing 3D renderers, i was just saying there were differents. I actually dont have anything against 3D renderers and last time I tried GZDoom i liked it. Of course i havent done much doom stuff recently cause of school :(

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×