TDM Engine Development Page

[motorsep]

To be fair, I read this line the other way round: He was trying to say we see the BFG port/engine work as only a toy port and poke to learn, but don't want to use it.

 

Which is a completely different meaning.

 

Bingo!

[OrbWeaver]

I'd consider Flash a dead-end - who knows if Adobe still supports in in 3 years? Maybe then they moved everything to the cloud, or whatever

 

And the sooner it dies, the better. Flash is a deprecated dead-end piece of proprietary garbage that dates from an era when HTML could display little more than coloured text. If someone wants to make a modern replacement for the Doom 3 GUI system they'd be better off using something with a future like HTML5.

[motorsep]

And the sooner it dies, the better. Flash is a deprecated dead-end piece of proprietary garbage that dates from an era when HTML could display little more than coloured text. If someone wants to make a modern replacement for the Doom 3 GUI system they'd be better off using something with a future like HTML5.

 

Are there any good authoring tools for HTML5? I don't know of any. Flash is the only artist friendly package I know of with nice WYSIWYG authoring tools.

 

The idea behind using Flash is simple - get an artist and he would make fully working menus without touching much of a code. Vector elements are scalable, and it's hardware accelerated.

 

With HTML5, or anything else, there is either no good tools, or it requires knowledge of programming. Epic did a good job of course with new GUI system - it's proprietary to the engine and it has sweet tools. But there isn't much stuff like that available in the wild.

[nbohr1more]

Here it is, the OpenTechBFG branch uses CEGUI as the replacement for Flash:

 

https://github.com/O...echEngine/CEGUI

 

Not sure how that compares, but I too am wondering why they chose that over HTML 5?

 

I can only speculate that it was selected since a few notable commercial titles like Torchlight use it.

Edited October 8, 2014 by nbohr1more

[motorsep]

Btw, Flash maybe horrible for web, but otherwise (especially for UI design and prototyping, cartoons, etc.) it's one of the best tools / systems out there.

[revelator]

ah crazy eddies gui, yeah good alternative for a gui, like lua support.

i Remeber it was used in some mmorpg game and it had in game configurable menus like world of warcraft.

[SteveL]

http://glampert.blog...pth-buffer.html

 

found some usefull info here, looks like we have to read the backbuffer ? which left me with a wtf moment, cause someone told me not to read from that.

also it seems really simple compared to my massive function. Also a test shader on that site sadly its in GLSL so not directly useable with vanilla.

Thanks, that's *much* more useful than anything I've been able to find. I'll try it shortly when I get home from work.

 

The shader will be very straightforward to translate into asm. Part of the reason the wrapper is short is that doesn't have the optimization to stop repeated calls to glTexImage2D, but we'll certainly keep that. I tried calling it every frame too. 2fps in my debug build :-)

 

And same here, newer found a lot of good info about ASM shaders :S

It's easy to find info on the functions, but the internet is weirdly silent on the environmental variables that you need. I've found lists of them but finding out what parameters they use or what they do or what ranges they return seems to be a matter of trial and error.

[Tels]

Btw, Flash maybe horrible for web, but otherwise (especially for UI design and prototyping, cartoons, etc.) it's one of the best tools / systems out there.

 

Unless you run Linux, of course...

[Tels]

I understand that. That's why I suggested porting old Doom 3 fullscreen GUI system to BFG.

 

Can't really compare game code programming to engine programming (rendering, etc.; lower level tasks). Game code is just more work, but naturally simpler by nature. So it would really just come down to spending quality time with WinMerge Unless TDM engine rendering part is vastly different than Doom 3.

 

If old GUI is ported back, assets would be all the same by the way. The only things that is different are shaders and fonts, but there is a font tool that comes with RAGE SDK that generates fonts for BFG engine.

 

The code from idTech4 was modified quite a lot in TDM, but I'm not sure how different from vanilla D3 it really is. Or how difficult it would be to port TDM to BFG.

 

And the point is, we don't have anyone working on TDM that has the time (and/or skill) to do this. Even if we wanted

[Tels]

Are there any good authoring tools for HTML5? I don't know of any. Flash is the only artist friendly package I know of with nice WYSIWYG authoring tools.

 

The idea behind using Flash is simple - get an artist and he would make fully working menus without touching much of a code. Vector elements are scalable, and it's hardware accelerated.

 

Yeah, but what they create can then only be modified by another Flash-Savy artist...

 

With HTML5, or anything else, there is either no good tools, or it requires knowledge of programming. Epic did a good job of course with new GUI system - it's proprietary to the engine and it has sweet tools. But there isn't much stuff like that available in the wild.

 

It depends on whether you want to build a kick-ass, totally sweet animated cool new GUI - or if you wanted just to port D3s GUI into HTML 5. The latter doesn't need much authoring tools.

 

Actually, I should research if there isn't a cross-platform HTML 5 (or even 4 + JS would be enough) library that TDM could embed. Then we could just use TTF and Unicode and call the I18N mess a day...

[motorsep]

Unless you run Linux, of course...

 

If the end product is run by a proprietary SWF renderer (like BFG), it will work on Linux too

 

For authoring purposes WINE works as well. Although, majority of artists are on Win/Mac, so it's not really a concern in indie / AAA development.

[motorsep]

The code from idTech4 was modified quite a lot in TDM, but I'm not sure how different from vanilla D3 it really is. Or how difficult it would be to port TDM to BFG.

 

Somehow I thought you guys built on top of existing Doom 3 code, adding new functionality. Did you (TDM team) literally rewrite game code? o.O

[motorsep]

It depends on whether you want to build a kick-ass, totally sweet animated cool new GUI - or if you wanted just to port D3s GUI into HTML 5. The latter doesn't need much authoring tools.

 

That's my worry - hacky development with lacking tools (or general lack of tools) is one of the factors why people don't want to mod Doom 3 derivatives. I'd really care to make better tools in order to attract more people to TMD development.

[New Horizon]

Somehow I thought you guys built on top of existing Doom 3 code, adding new functionality. Did you (TDM team) literally rewrite game code? o.O

 

A bit of both I suspect. The AI are a complete rewrite from the ground up.

[SteveL]

Can't really compare game code programming to engine programming (rendering, etc.; lower level tasks). Game code is just more work, but naturally simpler by nature.

A bit of both I suspect. The AI are a complete rewrite from the ground up.

A minor point, but one I want to mention: engine programming is much less complex than game code. Simulating the messy real world is dreadfully complicated, especially AI. That's what attracted me to learning about rendering after a couple of months working on game code. The renderer front-end is all short geometric functions with simple jobs to do and clean yes/no answers. The back-end is just library calls, you just need to get comfortable with using the reference material. Getting the engine to do stuff efficiently and correctly feels very restful compared with the mind-numbing web of complexity that grayman deals with when getting AI to behave like people, and with engine stuff there's the constant satisfaction of knowing that you finished something after just a few weeks of effort. To me it feels like the difference between solving a sudoku and writing a novel.

[revelator]

Have to agree with steve there, coding in the renderer ranges from trivial to sometimes painfull but gamecode is pure torture.

I once replaced the entire VM in quake with bengt jardrups and spent the next 3 years mining out bugs because of incompatibilities with my engine port urgh, .

The renderer took me about a months work before it was as i wanted it,

getting the game logic going finally worked after a lot of work but its something im not keen on experiencing again.

 

[motorsep]

That's because originally idTech 4 is poorly designed, both engine and game code, according to some of the senior programmers I happened to work with. So much duplication of code. That makes it "harder" to work with. So inherently, any complex system built on that design will result in increased complexity, which otherwise could be much cleaner and simpler.

 

If working with rendering was simpler than the game code, then we'd see a lot more idTech 4 forks with advanced rendering features. Apparently it's other way around, that's why there are none

[SteveL]

Very quick update on depth capture with a vid that's only 7 seconds long because it's way past my bedtime and youtube takes ages to upload. But it's working

 

http://youtu.be/T-EVUiqx_ag

 

The black border round the depth pic is because it's just a floating patch (slightly oversized) with a texture on it that uses the shader you linked above (@revelator). I translated it to asm:

 

!!ARBvp1.0
OPTION ARB_position_invariant;
MOV result.texcoord, vertex.texcoord;
END

!!ARBfp1.0
PARAM clipPlanes = { 0.4, 350.0 };
TEMP  dpth, col, rng;
TEX   dpth, fragment.texcoord, texture[0], 2D;
ADD   rng.x, clipPlanes.y, -clipPlanes.x;
MUL   col.x, dpth.x, rng.x;
ADD   col.x, -col.x, clipPlanes.x;
ADD   col.x, col.x, clipPlanes.y;
RCP   rng.x, col.x;
MUL   col.x, rng.x, clipPlanes.x;
MUL   col.x, col.x, 2.0;
MOV   result.color.r, col.x;
MOV   result.color.g, col.x;
MOV   result.color.b, col.x;
MOV   result.color.a, 1.0;
END

 

 

Regarding the qglReadBuffer( GL_NONE ) question: it works the same with both GL_NONE ad GL_BACK, so I'll leave it at GL_NONE for the reasons you mentioned.

 

Of the three capture methods in the functions, we've been trying out, this one isn't used:

if ( potWidth == imageWidth && potHeight == imageHeight ) {
qglCopyTexImage2D( GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT, x, y, imageWidth, imageHeight, 0 );
}

It's just a short cut for when the player's FOV is a square that's a power of two -- so not very useful.

 

This bit runs once only at map start, because it tests whether the image is too small to hold the screen. It resizes the texture to a power of two that can hold the screen, and then subsequent captures to the texture put the depth component into the RGB channels:

qglTexImage2D( GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT24, potWidth, potHeight, 0, GL_DEPTH_COMPONENT, GL_FLOAT, 0 );
Mem_Free( junk );
qglCopyTexSubImage2D( GL_TEXTURE_2D, 0, 0, 0, x, y, imageWidth, imageHeight );

 

Finally the repeat of "qglCopyTexSubImage2D( GL_TEXTURE_2D, 0, 0, 0, x, y, imageWidth, imageHeight );" in the else block at the bottom is the one that does the business every frame.

 

More experiments tomorrow

 

In case you want to mess with it, here's the shader I used on the patch;

textures/sfx/depth_mat
{
  noShadows
  nonsolid
  {
  blend blend
  maskDepth
  Program stevel_test_depthrender.vfp
  fragmentMap 0 _currentDepth
  }
}

[nbohr1more]

THIS IS AWESOME!!!!!

 

I'm still in shock about how quickly you picked-up ARB assembly...

[grayman]

Yes, I do find that my mind is numb after 4 years of teaching "the children" how to better simulate human behavior. IIRC, one of greebo's parting comments was about how frustrating it had become to deal with the AI.

[motorsep]

Yes, I do find that my mind is numb after 4 years of teaching "the children" how to better simulate human behavior. IIRC, one of greebo's parting comments was about how frustrating it had become to deal with the AI.

 

Is it because of AI in general, or because of how idTech 4 is structured ?

[motorsep]

@SteveL: How are you gonna use depth image in practice ? Fog ?

[nbohr1more]

The depth duffer is an indespensible tool for rendering. He could improve SSAO, do tile-based occlusion evaluation, etc. Almost all of the magic in Sikkmod comes from a hack where he re-renders the whole scene to grab the depth buffer. Here it seems SteveL is rendering the native one at full speed (no re-render hack).

[revelator]

Ill be damned thats some cool work there steve gratz.

Heh seems the fraze old dogs have a harder time learning new tricks fits, i would newer had picked up on ASM shaders that fast iiimposible.

Atleast i was on the right track with the depth copy so i can pat myself on the back also .

[revelator]

final version

 

/*
====================
CopyDepthbuffer
====================
*/
void idImage::CopyDepthbuffer(int x, int y, int imageWidth, int imageHeight, bool useOversizedBuffer) {
this->Bind();
// if the size isn't a power of 2, the image must be increased in size
int potWidth, potHeight;
IMAGE_ROUND_POWER2(imageWidth, potWidth);
IMAGE_ROUND_POWER2(imageHeight, potHeight);
GetDownsize(imageWidth, imageHeight);
GetDownsize(potWidth, potHeight);
// Ensure we are reading from the back buffer: (might be GL_NONE revelator)
glReadBuffer(GL_BACK);
// only resize if the current dimensions can't hold it at all,
// otherwise subview renderings could thrash this
if ((useOversizedBuffer && (uploadWidth < potWidth || uploadHeight < potHeight)) || (!useOversizedBuffer && (uploadWidth != potWidth || uploadHeight != potHeight))) {
 uploadWidth = potWidth;
 uploadHeight = potHeight;
 // This bit runs once only at map start, because it tests whether the image is too small to hold the screen.
 // It resizes the texture to a power of two that can hold the screen,
 // and then subsequent captures to the texture put the depth component into the RGB channels: (steveL)
 glTexImage2D(GL_TEXTURE_2D, 0, GL_DEPTH_COMPONENT24_ARB, potWidth, potHeight, 0, GL_DEPTH_COMPONENT, GL_UNSIGNED_BYTE, NULL);
 glCopyTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, x, y, imageWidth, imageHeight);
}
else {
 // otherwise, just subimage upload it so that drivers can tell we are going to be changing
 // it and don't try and do a texture compression or some other silliness.
 glCopyTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, x, y, imageWidth, imageHeight);
}
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE);
backEnd.c_copyDepthBuffer++;
}

 

if i understood correctly that is