DRD Team

Soon coming to a Doom near you!

This is interesting, indeed... somehow I get the feeling I know where this is going.

Hooked it up to the sky code now. If you enable r_cubesky you'll see it use this drawer to draw a clipped cube skybox. There's a minor bug somewhere in the clipdistance clip code that creates some hall of mirrors, but once I got that working I'll get it to sample from a texture and we can draw more complex shapes. Personally I'd really like to see how sky textures look like when plastered on a cube, and if that looks terrible I might just loot GZDoom's skydome. I really do not like ZDoom's sky.

Doom's skies look terrible plastered onto a cube. But the cube will be useful for ... other purposes. >_> <_< So don't let that discourage you!

Hehe, wouldn't surprise me if it did. If a cube texture would have done the trick then I'm sure Graf wouldn't have bothered creating the skydome. Nevertheless, I'm curious enough that I want to see how it looks like before moving on to figuring out where to grab the skydome vertices from.

You can use that cube for your cube texture sky btw.

dpJudas wrote:You can use that cube for your cube texture sky btw.

Well - I wasn't ... exactly... er, yes I was actually. <_<

Still - this also has very useful applications elsewhere, too. If this is capable of doing only one column at a time, then you could render models to a special buffer to be retrieved by sprite drawers. As I am sure you by now know, though, the Doom engine does not store z-depth buffer information, so getting that to work by-column is very important. I don't know how much this will slow things down, though.

That's the beauty of my triangle drawer. It already uses the column min/max clipping buffers that everything uses. Just feed it the sprite "short *" clip arrays that is used to clip the sprite and my triangle drawer will clip it automatically.

Interesting...

I'll take a look at this later. At the moment I am trying to get CMake to find the LLVM libraries on FreeBSD. It's ... harrowing. I have a feeling I am going to have to create a script like the one I found for Ubuntu.

Would this work in 8 bit, too? Having those skyboxes in ZDoom is actually one of the oldest open feature suggestions.

I really don't see why not. Some code will have to be moved from GZDoom to ZDoom (parts of the GLDEFS parser) but if any special drawers are used I am sure they can be rewritten for ZDoom, just they will lack ASM counterparts. (I could try and write the ASM code, but... I prefer code readability rather than speed ... plus, I do not know hardly any i686-specific code at all anyway)

The triangle drawer can easily be made to support 8 bit too (basically, just replace uint32_t with uint8_t in its current form and it will output 8 bit). Of course, like all drawers, it could use an assembly version to speed things up further. At this stage I don't even have a LLVM version yet though - need to make it work right first before making it fast.

Edit: as usual I should have read Eruanna's post before wasting half of my post replying the same thing.

Screw assembly. Randi kann take care of that later if it is deemed necessary but I'd rather have these features than not.

So, toying a bit more with the triangle drawer I got it to work well enough to draw a cube sky with texturing (set r_cubesky 1 to see this live in master):

(Never mind the top sky part, I didn't have a texture there - this was as close as I could get to a fake cap color blend)

Wasn't a cube sky supposed to look horrible? This looks quite alright to me.

Sadly there seems to be some minor fill convention bug still in the drawer, but once I get that fixed this drawer can be added to ZDoom. Drawing a cube is a bit too overkill for it, but maybe the dome will be a good enough excuse to include it.

A cube sky will look as horrible as the texture data you use. If the textures are all in the base palette or close enough to it, it'll be fine, if you use a JPG with smooth gradients, it'll look like shit.

dpJudas wrote:Sadly there seems to be some minor fill convention bug still in the drawer, but once I get that fixed this drawer can be added to ZDoom.

Can this drawer be used to render GZDoom's MODELDEF models in software... ? :O