TDM Engine Development Page

[Tels]

Agreed. It would be good to remove the support for the obsolete graphics apis too. They'll get broken by almost anything new we do, unless we take the trouble to update the obsolete code too, which would mean all improvements taking 5 times as long and how would be test them anyway? Anyone got one of those voodoo2s to help with testing?

 

The Voodoo2 enjoyed remarkably long usage in many computer systems, as a Voodoo2 SLI setup was competitive with newer cards like NVIDIA's RIVA TNT2, Matrox's Millennium G400, and even NVIDIA's GeForce 256. 3dfx's Glide API played an essential role in this longevity because some games were still tailored more towards Glide than Direct3D or OpenGL. Long after the chipset's obsolescence, some dedicated enthusiasts did get later games working with a Voodoo2, e.g. Doom 3.[1]

 

I'm not sure, but if the card doesn't have at least 128 MByte VRAM, TDM is likely not even to start. If we set our min. requirements (like discussed elsewhere) to 256 MByte (which you probably need even for the training mission), then these cards are out, anyway.

 

Plus, does somebody have a PC with a bus compatible with such a card? Would that have more than 1 Gbyte RAM and more than one core, anyway?

[Tels]

So how do you set up AFs without AF editor ?

 

Almost nobody does that for an FM, right? Plus, we used to edit AF just by editing the AF, or you use some other dedicated AF editor. There is not much reason that the AF editor is tied into the game engine.

 

Of course, having real-time in-game editing would be super-cool, but then it should be done right, not in a half-assed half-broken-by-engine-updates way

[Tels]

From: http://www.3dfxzone.it/enboard/topic.asp?TOPIC_ID=1462&whichpage=2

 

Ive tried a number of doom3 beta console commands to enable 16bit colour in the full game but they are not present. As most people here know already, the game is locked to 32bit colour and this is what causes the biggest impact on lower-end graphics cards.

 

Yeah, those where the times.. eh, 16 bit color in 2004? Excuse me? I'd say good riddance to old systems holding modern game engines hostage

[motorsep]

Almost nobody does that for an FM, right? Plus, we used to edit AF just by editing the AF, or you use some other dedicated AF editor. There is not much reason that the AF editor is tied into the game engine.

 

Of course there is a reason - there is no way to have same physics in a standalone AF editor (which doesn't exist anyway) as in-game physics. Plus not only you setup ragdolls and other physical skeletal based bodies, but you can also place and adjust those, then save the map.

[SteveL]

I'm not familiar with the built-in editors. When you talk about an AF editor, do you mean the "save ragdolls" facility? We wouldn't remove that of course, even if we did decide it was worthwhile to remove some others. We'd only consider removing stuff that isn't any use to anyone.

[revelator]

Actually doom3 could run on a voodoo2 using the ARB ->note not the ARB2 renderer, there was a demo showing it somewhere on the net.

But since i removed all the older backends this is not possible with revelation.

 

So yup the voodoo cards rocked btw did anyone know that a lot of the devs from 3dfx actually work for nvidia now ?.

[AluminumHaste]

Yes Nvidia bought the rest of Voodoo in an asset sale, hence the use of SLi. Not surprised a lot of people went over to work for Nvidia, those guys were talented.

[revelator]

Feel free to use my code if its not to much work porting the darkmod features to it.

 

The change to EPSILONS was an attempt at fixing a shadow bug vanilla had when using newer msvc compilers eg. > 2010.

Microsoft changed floatiing point values in msvc 2012 to use SSE math instead of FPU math and that change caused the bug where vanillas shadows sometimes dissapeard.

The fix helped but shadows still dont work correctly when compiled with anything newer than msvc 2010.

[revelator]

Aye just a damn shame that management in 3dfx sucked so much :S could have been rather interresting to see where they would have been today.

[SteveL]

Update on soft particles: I spent all evening tearing my hair out trying to work out why my soft particle shader wouldn't work with lamp glares. I wish I'd just come here and asked now! I see it's been solved before, probably many times. There was nothing wrong with the code, it was simply that lamp glares are additive materials, and additive materials ignore the alpha channel. They just add their full color to the background, brightening it. Grrr. *That's* why Sikkpin had separate "alpha" and "rgb" versions of his soft particle shaders. Now I do too. You fade out most transparent materials by reducing the alpha value, but for "blend add" materials you need to reduce the amount of color you're adding instead.

 

It's taken me longer than I thought, but I think I've got all the visuals sorted now, along with the hoped-for one-size-fits-all solution for deciding where to fade the particle and where to paint more. I'll post a diagram with the details to the tracker tomorrow. For now I want to add a few to my test map. I've also attached to the tracker a list of the 97 materials used in our 300-odd particles, with how frequently each is used. We can consider updating the most used/needy materials, and those that we want to apply to existing maps, and either tackle rarer ones later or just let mappers add the shader program to whatever material file.

 

Here're some softened lamp hazes. This one is for Biker The idea of trying to fixing this first came up at a pub table when Biker was demoing his WIP to Sir Taffsalot and me and he demonstrated how one of these lamp hazes was giving him gip and forcing him to move his lamp further out from its alcove.

 

The softened versions kick in at 20 seconds by the way. What you see at first is the originals.

 

http://youtu.be/zU7dK7pUlvY

[Arcturus]

About AF. I had to write articulated figures for horse and a movable saddle, and while in game editor was buggy I can't imagine doing that in a text editor.

[nbohr1more]

I played around with this demo and the previous. I must say that the soft particles are an astounding improvement.

 

It might not be a bad idea to do this to all the glare sprites that have been added to lamps, candles, etc too. I noticed

some pretty severe clipping on one of the glares at the beginning of Penny Dreadful 2.

 

The fixed water shaders aren't working on my Intel GPU for some reason (they don't render at all).

I pretty much chalk that up to "Intel sucks" so I'd like to see how those work on nvidia to confirm my suspicion.

[HMart]

Almost nobody does that for an FM, right? Plus, we used to edit AF just by editing the AF, or you use some other dedicated AF editor. There is not much reason that the AF editor is tied into the game engine.

 

Of course, having real-time in-game editing would be super-cool, but then it should be done right, not in a half-assed half-broken-by-engine-updates way

 

idtech 4 has some nice tools, that you guys lack on the DarkRadiant, and that would help imo, first they have a visual material editor, no need to write materials by hand (but is not hard), this tool is a tad buggy just like the UI editor, and has a tendency to screw up materials if done by hand first, but if the bugs were removed, then it would be very usable, a Ragdool editor or the AF editor like is called and you know about, then theres ones that exist on DarkRadiant and are just tools for quick ingame editing, theres a sound and light editor i especially like the light editor, especially because lights on DarkRadiant don't look 100 percent like they do ingame, you can just walk on the level put a light/sound change parameters and see the result instantly, removing this tools is foolish imo, except the id Radiant of course.

 

I'm not familiar with the built-in editors. When you talk about an AF editor, do you mean the "save ragdolls" facility? We wouldn't remove that of course, even if we did decide it was worthwhile to remove some others. We'd only consider removing stuff that isn't any use to anyone.

 

No he is talking about the ragdoll making tool, that command is to save ragdoll's that you put on the maps to the map files, the AF editor is to make the ragdoll's themselves.

 

About AF. I had to write articulated figures for horse and a movable saddle, and while in game editor was buggy I can't imagine doing that in a text editor.

 

Totally and ragdoll's can be used for more than character bodies, like you said they can be used for a saddle, a chain a flag or banners/drapes like GRIMM used, etc, removing it again would be foolish imo.

Edited October 28, 2014 by HMart

[nbohr1more]

OK, I think this would allow a "customLight" keyword to force the light parser to read the

ARB programs from the material definition allowing unlimited variation of interaction types

within the typical light volumes:

 

if ( backEnd.vLight->lightShader->IsCustomLight() ) {    // custom light defined by material
qglBindProgramARB( GL_VERTEX_PROGRAM_ARB, newStage->vertexProgram );
qglBindProgramARB( GL_FRAGMENT_PROGRAM_ARB, newStage->fragmentProgram );

 

Hmm, I think I'll have to workout an exclusion so the renderer doesn't try to use the shader on the textures in the def before passing it to the light code. Probably in draw_common.

Edited October 28, 2014 by nbohr1more

[SteveL]

I played around with this demo and the previous. I must say that the soft particles are an astounding improvement.

 

It might not be a bad idea to do this to all the glare sprites that have been added to lamps, candles, etc too. I noticed

some pretty severe clipping on one of the glares at the beginning of Penny Dreadful 2.

 

The fixed water shaders aren't working on my Intel GPU for some reason (they don't render at all).

I pretty much chalk that up to "Intel sucks" so I'd like to see how those work on nvidia to confirm my suspicion.

 

Thanks for testing! Yes I'll need to take advice on which materials to connect up to the softener program. I won't do all 97, and it wouldn't be desirable for all anyway. Adding it is easy enough, but I also need to test the handful of particles that use each and check whether the material is used in any other contexts.

 

Re Intel: that ancient laptop I borrowed from my mum last week has Intel on board graphics, so I'll try it and see whether I can fix it. Strange if particles work, which means that depth capture is working, and unfixed water works, which means that current render capture is working, but that the fixed water doesn't. I'll try to find out why.

 

There's been no test on nvidia yet. If anyone has one, please try it. I'll prep a patch for anyone wanting to try it who's not got access to svn.

 

idtech 4 has some nice tools, that you guys lack on the DarkRadiant

 

Thanks for this info, that's really interesting and I had no idea these tools existed. No worries, no one will consider removing anything without properly consulting first!

 

OK, I think this would allow a "customLight" keyword to force the light parser to read the

ARB programs from the material definition allowing unlimited variation of interaction types

within the typical light volumes:

 

What kind of things would we use a programmed light shader for? AO I guess, and maybe some kind of simulated global illumination, but what else? I'm having a failure of imagination :-)

[SteveL]

Hmmm the water works fine for me on this old laptop with on-board Intel GPU, albeit at 6 fps! Which'll make it harder for me to fix your bug nbohr1more. We'll have to have a think about how to diagnose it. I usually start by adding a line to the end of the shader program:

 

MOV result.color.r, 1.0;

 

Then doing reloadARBprograms on the console. That'll turn the shaded surface red if the program is running. Then I try replacing the 1.0 with different variables from the shader program to check they have the values I expect. If I expect a value to be in the range 0..10, then I divide it by 10 and put that in the red channel etc.

 

But it's almost certainly not a code bug since the effects all work fine on my amd card and on this Intel laptop. Any ideas?

[revelator]

Could be gfx drivers i actually had to buy an AMD card because my previous engine ran like a snail on AMD :S AMD does a few things different same with intel, and yeah intel sucks when it comes to gfx cards there cpu's rock though xD.

 

Sadly i sold my nvidia cards so cannot help on that :/ but maybe i can persuade one of my pals to try it out, he has a nvidia card.

[nbohr1more]

For the customLight, beyond cubemap projection you could:

 

Project a "3d texture light map" see example: http://www.humus.name/index.php?page=3D&ID=47

 

(That's next on my wish list.)

 

Add a second falloffImage pairing to the same light volume.

 

Make extremely exotic light animations, flickering, fireflies, even animating the falloff behavior.

 

Add more or fewer bounces to lights ala Maha-x's method.

 

Make lights that accept new image map types like gloss maps and use them in certain areas of your map for better artistic control (a bit tedious).

 

Try out new interaction shaders by simply updating materials, no need to recompile (probably the most practical example, but boring).

[nbohr1more]

Ok here's the other half of the problem, just treat the stage preparation step like it's being passed to

low-spec hardware or to a config where shaders are disabled via a boolean check:

 

draw_common.cpp

 

// completely skip the stage if we don't have the capability
if ( tr.backEndRenderer != BE_ARB2 ) {
continue;
}
if ( r_skipNewAmbient.GetBool() ) {
continue;
   // nbohr1more skip ARB shaders for custom lights so that they are not processed twice
if ( backEnd.vLight->lightShader->IsCustomLight() ) {
continue;
}

Edited October 28, 2014 by nbohr1more

[AluminumHaste]

I pretty much chalk that up to "Intel sucks" so I'd like to see how those work on nvidia to confirm my suspicion.

 

Seems to work fine on my work computers Nvidia GeForce 300 OEM card:

 

http://www.youtube.com/watch?v=ZYA0tGlQHzs&list=UUXtmlLWhOCeBvYKUfbFS2tQ

[Bikerdude]

The difference in the lamp haze is stunning, when flipping the switch the particles are less harsh and far more realistic. I wonder if we could now have a single large fog partcle for outside, as the way it blends against hard surfaces is high up my bling scale.

[Goldwell]

Do we have an ETA on when the next update is due to hit?

[Goldwell]

the way it blends against hard surfaces is high up my bling scale.

 

ROFL "bling scale" I love it!

[SteveL]

Wish I could make vids like you AH! You've done a much better job at showing the good stuff and the flaws.

 

I'll check whether that dustfog material is used in any other non-particle circumstances. I'd vote for simply replacing that material if not, so that existing maps benefit. It's one that mappers couldn't really work around: you either had harsh intersection lines or you didn't fill a room with vapour.

 

Update: the dustfog material ("shotgunpuff") isn't used for anything except particles. I checked all materials, map files, skins, def files, fx, md5 models, prefabs and scripts in the main mod and published maps.

Edited October 28, 2014 by SteveL

[SteveL]

I wonder if we could now have a single large fog partcle for outside, as the way it blends against hard surfaces is high up my bling scale.

 

The tdm dustfog 1..3 all use the same material I think, just with different levels of alpha to make them look thinner or thicker, so if we soften one they'll all soften. Are there others?

 

I'm hoping for suggestions on what particle to try next Not having actually made a map I don't know which are the hardest to get right. First I'll find that lamp glare that nbohr1more mentioned in PD2 and fix it up.