funduke Posted February 7, 2006 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 0 Share this post Link to post
Graf Zahl Posted February 7, 2006 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. 0 Share this post Link to post
funduke Posted February 7, 2006 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 0 Share this post Link to post
Scuba Steve Posted February 9, 2006 I think it has a problem though that it aligns things to the bottom of the sprite and not the bottom of the coordinates. 0 Share this post Link to post
Graf Zahl Posted February 9, 2006 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. 0 Share this post Link to post
Scuba Steve Posted February 9, 2006 So you're sayin' software is the best? 0 Share this post Link to post
Graf Zahl Posted February 9, 2006 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. 0 Share this post Link to post
rpeter Posted February 10, 2006 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.) 0 Share this post Link to post
Graf Zahl Posted February 10, 2006 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. 0 Share this post Link to post
rpeter Posted February 10, 2006 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. 0 Share this post Link to post
Graf Zahl Posted February 10, 2006 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. 0 Share this post Link to post
rpeter Posted February 10, 2006 Thanks for the explanation, I'm getting a better picture of the problem now. 0 Share this post Link to post
JacKThERiPPeR Posted February 10, 2006 I think it's because the A_Fall Action Special. I THINK. I'm not sure. 0 Share this post Link to post
insertwackynamehere Posted February 10, 2006 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. 0 Share this post Link to post
Graf Zahl Posted February 10, 2006 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 0 Share this post Link to post
Graf Zahl Posted February 10, 2006 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: 0 Share this post Link to post
insertwackynamehere Posted February 10, 2006 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 :( 0 Share this post Link to post