motorsep

eeh, why not to follow some decent standard and use cmake ? I never understood when people find some obscure tool and present it as the ultimate solution. Cmake is de facto standard for cross platform development. Works like a charm on Linux, Windows and OSX. RBDoom 3 BFG uses it, dhewm3 uses it afaik, Blender is switching from scons to cmake.

Thanks! No, no GPU particles. It's not trivial to move particles to GPU, and for the amount of particles we use it doesn't make much sense to move them to GPU yet. I would make more sense to optimized particles, if there is a room for it, on CPU. Demo recording/playback fix, some reload* cvars fixes, dmap writing inlined LOD surfaces into proc file as separate surfaces, and fixing/enhancing tools (since they compile fine with MSVC2013 Community Edition, Qt5 port isn't gonna happen until there is a massive demand in tools for Linux modders) are the next big targets. Moving r_show* rendering from old rendering code to the new shader based one is one long term goal. Faster shadow mapping, having translucent surfaces casting shadows and real-time GI are another long term goals. That is what our renderer road map looks like so far (excluding some mostly purely shader based features).

Thanks, fixed it

What's new with 2.0.2 and 2.0.3 ? Christmas shopping!

Thanks

I decided to put some info up about the engine and IndieDb seemed like a good place to do that Check it out: http://www.indiedb.com/engines/storm-engine-2-working-title

I looked up RoQ docs.. It seems that making a video out of TGAs with alpha would make a mask automatically (built into RoQ file). Gotta test it.

So I guess no one really worked with RoQ videos extensively ?

That may be, but RoQ video needs a flag telling engine what color is transparent (as mask I guess).

I figured I'd link my post here, since I am guessing Crowind might know about RoQ more than I do http://forums.thedarkmod.com/topic/16769-authoring-roq-videos-and-defining-their-properties/

Thanks, but what do you mean by that ^^ ?

Some games fade in player's view (from black) on spawn. I assume it's done to prevent player seeing certain things being spawns and such. So there is a delay between being spawned and seeing the world. I have a few things, particles in particular, that begin emitting at t he same time player is spawned. It doesn't look appropriate as I'd like for particles to be at full capacity when player is spawned. So I figured if I have a delay and the gradual fade in from black on the view, then the issue would be resolved. Is it something engine/game already provides (Doom 3) ? How can I achieve such effect ? Thanks.

I recall RoQ videos can be transparent and such, and can be used as textures in materials. Is there an explanation how to author RoQs with settings/parameters explained (setting transparency for example) and how to properly setup material to use RoQ in GUIs and world/model surfaces ? Thanks.

Moving lights = stationary lights when it comes to performance, assuming they cast no shadows. Stationary lights casting shadows from static meshes (LWO/ASE) and map are _much_ cheaper than shadows cast from moving lights and skeletal geometry. So many moving light + static shadows = ok; many moving lights and dynamic skeletal shadows = death.

Not really close But it makes sense to wait until they fix it for TDM.

I am keeping my fingers crossed, because AMD sucks in all idTech 4 / 5 games :/ By the way, how did you get in touch with AMD about TDM issue? I might need to get with them about our engine performing horribly under Win 8 / 8.1 on some AMD GPUs.

You really don't want to abandon dmap shadows, because performance difference is drastic. Engine will have to calculate silhouettes for _everything_, while with dmap shadows it doesn't calculate anything for prelit shadows.

Afaik not. We had to increase mem allocation besides tweaking those two. However, that could be because RoQ reintegration into BFG engine. idTech 4 might get away with just increasing those.

RoQ2 source code: https://github.com/i...ster/utils/roq2 It would be nice if someone can add cmake support to it and ability to generate solutions for MSVC 2010, 2013 and gcc (for Linux), that can be compiled

Woah, selection and Entity List load up at the speed of light now!!!! Awesome! Thanks greebo!

Go with shadow mapping! Btw, there is shadow mapping code in idTech 4, so might be a good idea to poke at it to get it working again.

RoQ2 for Jedi Academy can make high res RoQ videos, but engine needs to be fixed to support that. RoQ also has to be power of 2, e.g. 1024 x 1024.

That's not large, and low poly. Large is what I made - 130k x 130k units, polycount is what you'd see in modern games. Either way, the issue has been resolved. Although I still think it's beneficial to gameplay to have hub level system.

Tested it with shadow volumes - works the same way as with shadow maps. Well, it's a good reason to be exited anyway I still don't get why there is a notion that BFG vs idTech4 is like CryEngine vs idTech 4. When it comes to game code, it's almost identical to idTech 4. So I am certain that TMD can be ported, little by little to BFG game code. By BFG I mean Storm Engine 2, since it's a way ahead of BFG in terms of bug fixes, modding capacity and such.

It runs well because it's modified Doom 3 BFG engine, not idTech 4, and also because LOD is working, and because shadows are shadow maps, and not volumes, so there is no extra geometry to calculate/render. I have parallel visportals to split the "room" into 4 areas (set up diagonally / / / ) , but no cubes around entities. I can make that video with r_showTris, if I don't forget