Tels
-
Posts
14984 -
Joined
-
Last visited
-
Days Won
23
Posts posted by Tels
-
-
It's just the picture and model that I chose making it look opaque. The drawnings are transparent, but the colour builds up if you have several layers of shadow volume to look through. I agree it'd probably work better if the colour got reduced a bit. I'll try tweaking it up and down while I'm experimenting.
The sikk version looks transparent no matter how many layers you have because it saturates the blue channel but leaves the others alone. That's not an improvement, because you can't see any detail... in the pic above for example, the two prongs of the generator look like a single shadow. In the engine-coloured one you can see the layers.
Yeah, I got this from your post, but I didn't see that there were so many shadows making it opaque due to the many layers. But maybe you can still tweak it a bit, even a single shadow doesn't need to be that strong in the color.
I can now see in my test map that some shadows are drawn using different routines. I have a mixture of red and yellow shadows. The red ones are "turboshadows" whatever that might mean. I plan to find out this morning...
Please post the findings
And thanx for the work! -
I added the missing line.
If you are visualizing shadow volumes it's helpful to set r_useDepthBoundsTest to 0 too, otherwise the engine will cull away parts of the shadow volume (a performance optimisation).
One small thing: maybe you can multiple the engine color by 0.5 or 0.7 - in sikkmod they are transparent, while the engine colored once seem almost solid. It might be better visuals when they are not that solid.
But you might want to test if that is actually an improvement, its hard to tell from static images.
Good work, tho!
-
greebo has committed new static libraries for linux, but they are version-sensitive. If you are using an old os build, you might have to compile your own.
Is therer anywhere any documentation about this? How to compile static versions, how to update them etc?
-
I guess that actually replacing boost 100% is tough, because it brings a few often-used features, and some of the "only used once" features are rather complex, like traversing a directory recursively. It's not that we couldn't replicate that, but doing so in a correct, cross-platform manner is certainly not something done in 5 minutes.
Btw, the patch in the first post actually works, so I guess we could apply that as the first baby step
Anyway, the biggest issue I see right now is the error in Linux:
dlopen '/home/te/games/tdm/gamex86.so' failed: /home/te/games/tdm/gamex86.so: undefined symbol: _ZN5boost10filesystem6detail9copy_fileERKNS0_4pathES4_NS1_11copy_optionEPNS_6system10error_codeE
It looks to me the boost include files where recently updated (a few days/weeks ago), but the .a files in linux/boost/lib/ are from August. Maybe this is the reason? (I freely admit I'm a bit confused on how to exactly tackle this problem).
-
This is already in place.
Seen it a few seconds later during svn updated, but your clever sorting of strings threw me off
-
Speaking of cleanup: While looking for the boost includes, I noticed that we have quite a mess here. Some of the files include the lobraries from .cpp files, others include them from the .h files (which is the right place IMO).
That again makes it harder to follow the source and see what is done and where. That's a general issue, tho, and not only for the boost libraries. But I guess since these were added later, the inconsistencies here are greater than for includes that have been there from the dawn of time on
-
Started a thread where we can collect the boost info and issues: http://forums.thedarkmod.com/topic/16753-tdm-and-the-boost-library
-
This thread is for technical issues about boost, as well as discussion on which parts we actually need or could replace, or if we actually want/can to get rid of boost.
Here are a few starters:
The file game/ModMenu.cpp includes boost, but doesn't actually use it anywhere, so the patch below works:
Index: game/ModMenu.cpp =================================================================== --- game/ModMenu.cpp (revision 6346) +++ game/ModMenu.cpp (working copy) @@ -22,7 +22,6 @@ static bool versioned = RegisterVersionedFile("$Id$"); #include <string> -#include <boost/filesystem.hpp> #include "ModMenu.h" #include "Shop/Shop.h" @@ -42,8 +41,6 @@ _modTop(0) {} -namespace fs = boost::filesystem; - // Handle mainmenu commands void CModMenu::HandleCommands(const idStr& cmd, idUserInterface* gui) {Some functions use boost-specific objects, but then just use them like regular strings. I guess it is easier to pass in arguments that way, but instead of casting the object to char inside the function, this could also well be done by the calling place. Here are a few examples:
- IniFile::ConstructFromFile
- IniFile::ExportToFile
These two above are the only places where boost is used in IniFile.
-
Ah, idLib defines a Max() function (note capital M), and it's used in a lot fo places so we should use that.
D'oh! I searched for max, MAX, and Max in Math, but I somehow must have overlooked Max() in idlib. My mistake
The other fix is, unless you already applied it:
Index: sys/scons/SConscript.game =================================================================== --- sys/scons/SConscript.game (revision 6344) +++ sys/scons/SConscript.game (working copy) @@ -55,6 +55,7 @@ PlayerView.cpp \ Projectile.cpp \ Pvs.cpp \ + SearchManager.cpp \ SecurityCamera.cpp \ SmokeParticles.cpp \ Sound.cpp \ @@ -248,6 +249,7 @@ ai/Tasks/FleeTask.cpp \ ai/Tasks/FollowActorTask.cpp \ ai/Tasks/GreetingBarkTask.cpp \ +ai/Tasks/GuardSpotTask.cpp \ ai/Tasks/HandleDoorTask.cpp \ ai/Tasks/HandleElevatorTask.cpp \ ai/Tasks/IdleAnimationTask.cpp \Regarding boost, I'll have to investigate what exactly the problem is. Is there a chance we can get rid of a few boost libraries easily? Boost::fillesystem seem to be used only in about 3 places (plus a lot in the tdm_updater).
-
All right. The changes above (scons and max()) are good, but then:
dlopen 'xyz/games/tdm/gamex86.so' failed: xyz/games/tdm/gamex86.so: undefined symbol: _ZN5boost10filesystem6detail9copy_fileERKNS0_4pathES4_NS1_11copy_optionEPNS_6system10error_codeE
This seems to take on quite a bit longer...
-
Doesn't compile so far:
game/SearchManager.cpp: In member function ‘bool CSearchManager::JoinSearch(int, idAI*)’: game/SearchManager.cpp:663: error: ‘max’ was not declared in this scope
There is no max() in C or C++, so I guess MS added their own. idlib doesn't have one, either. Here is a workaround, still avoiding to compute the sqrt() twice:
Index: game/SearchManager.cpp =================================================================== --- game/SearchManager.cpp (revision 6342) +++ game/SearchManager.cpp (working copy) @@ -660,7 +660,8 @@ float yRad = searchSize.y/2.0f; // outerRadius defines the search perimeter, where observers will stand - outerRadius = max(SEARCH_MIN_OBS_DISTANCE,idMath::Sqrt(xRad*xRad + yRad*yRad)); + outerRadius = idMath::Sqrt(xRad*xRad + yRad*yRad); + outerRadius = outerRadius > SEARCH_MIN_OBS_DISTANCE ? outerRadius : SEARCH_MIN_OBS_DISTANCE; innerRadius = 0; // no active searching if (!ai->IsAfraid()) // armed AI becomes a guard {I'l try again
-
Thats' right, you can't test the current revision with released assets. A lot has been added for 2.03.
I usually tested the new 2.03 builds and they worked quite good with the 2.02 assests - but of course I did only cursory testing and only played one FM.
But is it possible to test the softparticles in a small mission, which would you recommend, how do I enabled/disable them? I just want to see if it works and give you direct feedback.
-
Let me know if I need to patch something for 2.03 to enable it to compile on Linux. I don't understand scons setup.
I'll do, as soon as it is compiled again. Just found another mission file.
In general, new .cpp files must be added to the lists in sys/scons/SConscript.game for the Scons build to link correctly.
-
Ok then removal of all backends beside ARB2 in next commit
Need to investigate a crash after i reverted nbor1more's test code, seems i overlooked something after i fiddled with it.
And don't forget to take out the never-used glasswarp
Btw, I wonder if this is the problem with GLEW on my system:
# greebo: Use custom compiled GLEW devIL and libjpeg in Linux
Your branch added GLEW in the above comment (compared to stock TDM), but it's only a comment. Maybe it is missing some actual scons magic?
Edit. There is a file SConscript.gl, but it is never referenced.
-
There's nothing there that I can see that is significantly different than regular smoke. I recall we had to remove smoke from the torches guards carried specifically because the smoke followed the emitter and looked bad.
Yeah, I had the same problem with the sparks, and also the "trails" on the arrows. I wonder how I solved that, or if I really solved it.
-
That's not the case. With world gravity on, the particles move straight up regardless of the orientation of the emitter, but they still move as the emitter moves.
I presume trailing smoke in projectiles uses the "aimed" orientation.
Ah, that could be the case. Sorry for the confusion.
(We really should have a better documentation on the wiki for the particle system. All the different keywords with pictures showing their effect.)
Edit:
Here is what I used back then: I don't see "aimed" in there, either:
// For the gas arrow while flying particle tels_gasarrow_trail { { count 35 material textures/particles/smokepuff time 0.700 cycles 0.000 deadTime 0.000 bunching 1.000 distribution rect 1.000 1.000 1.000 direction cone "0.000" orientation view speed "13.000" to "21.000" size "3.000" to "6.000" aspect "1.000" randomDistribution 1 boundsExpansion 0.000 fadeIn 0.150 fadeOut 1.000 fadeIndex 0.000 color 0.030 0.070 0.020 1.000 fadeColor 0.000 0.000 0.000 0.000 offset 0.000 0.000 0.000 gravity world -0.5 } } -
No, it fails again with the same error. I guess a new file has been added and it wasn't added to the scons list?
Edit: Yeah, I think it needs to be added to "sys/scons/SConscript.game"
Like so:
te@te:~/src/darkmod_src$ svn diff sys/scons/SConscript.game Index: sys/scons/SConscript.game =================================================================== --- sys/scons/SConscript.game (revision 6342) +++ sys/scons/SConscript.game (working copy) @@ -248,6 +248,7 @@ ai/Tasks/FleeTask.cpp \ ai/Tasks/FollowActorTask.cpp \ ai/Tasks/GreetingBarkTask.cpp \ +ai/Tasks/GuardSpotTask.cpp \ ai/Tasks/HandleDoorTask.cpp \ ai/Tasks/HandleElevatorTask.cpp \ ai/Tasks/IdleAnimationTask.cpp \
It will take 18 min to test if it compiles&links again.
Speaking of missing assets, does that mean I can't test the current revision with the 2.02 stock assets?
-
It's probably an asset problem. The latest build refers to assets that haven't been released :-/
The missing symbol means that the linker build a DLL that doesn't match the executable, assets have not yet been loaded at this stage. So either I jumbled the build, or did not put the correct .so in the directory. Techncially the build overrides these, always. But lately I toyed with relevators branch and this might have accidently overwritten the tdm_game.pk4 file.
I'll recompile and test again.
-
Thanks, I'll go look for your code (and for anything that uses the separate origin). I'm interested to know what possibilities we have for particles nowe that I've mapped out pretty much every line of code, so I plan to read up on how other games use them too.
The add-on is here:
http://bloodgate.com/mirrors/tdm/pub/add-ons/tels_tdm_black_light.pk4
Just found out that the add-on is a bit broken due to changes in the TDM particles and entities, but the definitions might still be useful.
-
That doesn't change anything.
Are we talking about the same thing? The way I read the last posts (the thread is a bit jumbled) that Steve added a WorldAxis keyword. That aligns the axis of the particle to the world.
However, the "gravity" thing is for the movement (not the orientation!) of the particle. Steve said that particles always move with the emitter, e.g. when you move the emitter during the lifetime of the particle, the particle is "dragged" alogn with the moving emitter. With "world aligned" gravity, the particle stays where it was emitted and is only affected by the gravity value.
E.g. for a flame or sparks you want the particle be "bound" to the emitter of during the lifetime of the particle, for smoke you want it to trail.
Or did I confuse two things here?
-
Hm:
gamex86 - No SO found in EXE path gamex86 - Found SO in pak file with timestamp of 1417810470 - /home/te/games/tdm/tdm_game02.pk4/gamex86.so gamex86 - SO in pak file is newer, extracting to darkmod path /home/te/games/tdm/tdm_game02.pk4/gamex86.so copy gamex86.so to /home/te/games/tdm/gamex86.so gamex86 - Correction of file modification time successful dlopen '/home/te/games/tdm/gamex86.so' failed: /home/te/games/tdm/gamex86.so: undefined symbol: _ZTIN2ai13GuardSpotTaskE Regenerated world, staticAllocCount = 0. Shutting down sound hardware ----------- Alsa Shutdown ------------ close pcm dlclose -------------------------------------- idRenderSystem::Shutdown() I18NLocal: Shutdown. Sys_Error: couldn't load game dynamic library About to exit with code 1
-
Hm, do we really still firm under "Doom III Mod"? Yeha, techncially, we started as a D3 mod, but TDM is now standalone since 2 releases and for over one year. So, what is the moddb policy about such things? Is TDM even able to get voted on as "mod of the year"?
Anyway, I did cast my vote in favor of it
-
Revision #6340 compiles on my old Kubuntu box, I'm gonna do a testrun in a few minutes. Thank you, Steve
-
Tbh I thought you guys had already removed the decrepit non-arb2 stuff from the engine. That's one reason why I want to try out gpu skinning in your branch rather than in the trunk -- it won't be practical to implement it or work around it for older GPUs, so any benefits would be ruled out. And I think TDM effectively removed support for non-ARB2-capable hardware years ago -- no-one without an arb2 card has been able to see water for the last several years, for example -- although yes we'll need to have a discussion and make a good case to the community before removing the code from the engine forever. I've only been around TDM for a year but I've seen a few discussions on this kind of question. We'll have a much better chance of persuading the community at large that advancements are worth the cost of dropping support for elderly machines if we have a few carrots to hold out
So (personal opinion only) I think we should go on and try implementing some goodies that require hardware from the last decade I'd just like to throw out some food for thought here: We shouldn't give too much weight to people who only theoretically argue for "but the people with the old hardware can't play TDM!". The "can't see water" is proving this. If the support is already broken, and nobody bloody noticed it in the last few years (!), then we don't need to keep it around, regardless on what armchair engine users theorize about
The TDM engine is already way too complex and underdocumented, keeping old, but broken features might be more hassle then ripping them out, f.i. when someone wants to figure out something and then has all the broken code to confuse them. There is a cost in maintainance and we are lacking in personal resources everywhere.
[Resolved in TDM 2.08] TDM and the boost library
in The Dark Mod
Posted
Good news: the new libraries work on my system.