The WIP Thread

If it's not ZDoom, it goes here.

Re: The WIP Thread

Postby dpJudas » Fri Feb 19, 2021 11:31 pm

Let's play Doom software rendered at 8K (7680x4320) :P

This is with the transposed video buffer that GooberMan demonstrated is faster even if it requires you to do perspective division for the spans.
Joined: 28 May 2016

Re: The WIP Thread

Postby InsanityBringer » Sat Feb 20, 2021 9:50 am

How frequently are you doing perspective division on the spans? I seemingly remember Gooberman only doing the perspective divide every 8 or 16 pixels, going linear between them.

Though it still amuses me greatly that memory speeds and the value of cache is such that it's faster to actually bite the bullet and do the divides because the other way when transposing the framebuffer is so slow because memory is slow.
User avatar
Joined: 05 Jul 2007
Location: opening the forbidden box
Discord: InsanityBringer#9908

Re: The WIP Thread

Postby dpJudas » Sat Feb 20, 2021 11:10 am

On the screenshot I'm doing the perspective divide every pixel. In some of my earlier tests I was using randi's tilted span drawer to do it (it does it every 16 pixels) and I didn't see much speed difference. I had to drop using randi's version though because I needed to support all the blending modes and NPOT textures that flat planes also supports (her drawer only supported opaque). On the plus side it means the tilted spans now also supports those blending modes. On the Frozen Time bridge the transpose makes no speed difference at all. This only really speeds up simpler scenes.

In theory I have no doubt it is faster not to do the divide every pixel, but because the drawer is using integer math for all the other parts they may be working in parallel. The version where you only do the divide once in a while also puts a larger pressure on registers as you need to store the delta values when doing the linear interpolation. In a SSE version it also can do 4 divisions and multiplications at the same time. This stuff gets really complicated on modern CPUs when all cores have multiple ALUs that all can work in parallel.
Joined: 28 May 2016

Re: The WIP Thread

Postby Nash » Sun Feb 21, 2021 3:01 am

Actor visibility filtering in mirrors. These are two new flags to make an actor either only be visible in reflections, or make an actor cast no reflections. Works in hardware and software rendering (thanks to dpJudas for helping me figure out the SW part!).

In this demo, the zombieman and player is unaffected. The demon is only ever visible in reflections, while the cyberdemon doesn't have reflections. Works correctly with recursive mirrors, and appears to work fine with renderstyles too (the demon has a ghostly additive translucency applied, for demonstrational purposes).
User avatar
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: The WIP Thread

Postby Vostyok » Sun Feb 21, 2021 3:42 am

Bring on the spooky vampire mods. This is cool, yo.
User avatar
I'm living in a cardboard box
Joined: 17 Jan 2015
Location: New Eden
Discord: Vostyok#3164

Re: The WIP Thread

Postby Blzut3 » Mon Feb 22, 2021 4:44 am

dpJudas wrote:This is with the transposed video buffer that GooberMan demonstrated is faster even if it requires you to do perspective division for the spans.

If I recall correctly GooberMan also found a benefit from just transposing the buffer to column major regardless of if the span drawer was changed to columns. (I.e. taking the cache hit on spans instead of columns.) As you've already done the work to go all the way I realize it doesn't really matter now, but based on your wording of "requires" I'm curious if you've tried this and found that the same didn't hold true for GZDoom?

Given that (G)ZDoom already had a multicolumn buffer to mitigate the cache usage issue that it's indeed true that a straight transpose wouldn't have done anything (or made it worse), but curious what your thoughts are?
Pronounced: B-l-zut
Joined: 24 Nov 2004
Github ID: Blzut3
Operating System: Debian-like Linux (Debian, Ubuntu, Kali, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: The WIP Thread

Postby Graf Zahl » Mon Feb 22, 2021 5:02 am

The multicolumn buffer has been removed when all the assembly code was replaced because it showed no performance gain.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Joined: 19 Jul 2003
Location: Germany

Re: The WIP Thread

Postby dpJudas » Mon Feb 22, 2021 10:51 am

Blzut3 wrote:If I recall correctly GooberMan also found a benefit from just transposing the buffer to column major regardless of if the span drawer was changed to columns.

Actually the way I read those numbers it depends on what is more dominant in the scene. A normal (not transposed) scene might be faster than transposing it if you're viewing an area that is dominated by spans. On the other hand if the scene is dominated by columns then the transpose is faster. Some parts of his demo test was dominated by one, some by the other.

Randi's multicolumn mitigation did indeed reduce the pressure on the cache (by a factor of 4), but the devil is in the detail. I removed the multicolumn thing back in the day because I couldn't measure any improvement. This may have been caused by increased setup time when I was already using threads to split up the scene. When randi implemented multicolumn she clearly could see a speed boost. My old multithreading code split the scene into rows, so that row 1 belongs to thread 1, row 2 to thread 2 and so on. That means each thread back then worked on less of the frame buffer and thus less cache was needed for each thread. At the time I couldn't ever get doom to run 60 fps at 4K, which seemed to imply that once I hit that resolution I probably exhausted the cache.
Joined: 28 May 2016

Re: The WIP Thread

Postby zrrion the insect » Mon Mar 01, 2021 12:52 am

Still messing with my old enhancer mod, finally converted the thing to zscript so I can start adding fun stuff

User avatar
zrrion the insect
Like a fish in a child's hands.
Joined: 25 Jun 2009
Location: Time Station 1: Moon of Glendale

Re: The WIP Thread

Postby MartinHowe » Mon Mar 01, 2021 3:13 pm

IDK how many people are following it, as it had a few likes but not much comment, but the Black Cats of Doom has been quiet for a while. This is because while it is feature complete, it's probably my biggest Doom-related software development project so far.

There is one serious bug that doesn't manifest often but is a big PITA when it does: the cats can get stuck running around in circles in small areas even when there would be - to a human or a real cat - an obvious way out. This will require upgrading the cats' custom A_Chase() function and while I am not looking forward to writing yet more code, it looks as if something similar to Josh 771's advanced AI pack will be required to fix this. There is also the odd crash of GZDoom now and then which may be down to the cats mod or not.

So it's currently in long-term play testing. I've been meaning to do more playing of the game instead of modding it, so this is as good a reason as any.

I also want to add some sort of artefact to ascend the remaining cats on a level to cat heaven; if I need the level cleared of cats during testing, I don't like killing them; besides, it's more in-keeping with the theme of them being 'black magic cats summoned by the Gods to fight against evil'; I did have this working in my experimental Farmville mod but only used a cheap teleport flash effect; really, they need a Heretic Golem style 'souls ascending to heaven' effect for this to look properly cool.
User avatar
In space, no-one can hear you KILL an ALIEN
Joined: 11 Aug 2003
Location: Waveney, United Kingdom


Return to Off-Topic

Who is online

Users browsing this forum: No registered users and 0 guests