-
Posts
14984 -
Joined
-
Last visited
-
Days Won
23
Everything posted by Tels
-
Good news: the new libraries work on my system.
-
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. Please post the findings And thanx for the work!
-
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!
-
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).
-
[Resolved in TDM 2.03] Testers requested: soft particles
Tels replied to SteveL's topic in The Dark Mod
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
-
[Resolved in TDM 2.03] Testers requested: soft particles
Tels replied to SteveL's topic in The Dark Mod
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.
-
[Resolved in TDM 2.03] Testers requested: soft particles
Tels replied to SteveL's topic in The Dark Mod
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). -
[Resolved in TDM 2.03] Testers requested: soft particles
Tels replied to SteveL's topic in The Dark Mod
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... -
[Resolved in TDM 2.03] Testers requested: soft particles
Tels replied to SteveL's topic in The Dark Mod
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 -
[Resolved in TDM 2.03] Testers requested: soft particles
Tels replied to SteveL's topic in The Dark Mod
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. -
[Resolved in TDM 2.03] Testers requested: soft particles
Tels replied to SteveL's topic in The Dark Mod
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. -
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.
-
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.
-
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 } }
-
[Resolved in TDM 2.03] Testers requested: soft particles
Tels replied to SteveL's topic in The Dark Mod
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? -
[Resolved in TDM 2.03] Testers requested: soft particles
Tels replied to SteveL's topic in The Dark Mod
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. -
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.
-
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?
-
[Resolved in TDM 2.03] Testers requested: soft particles
Tels replied to SteveL's topic in The Dark Mod
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
-
[Resolved in TDM 2.03] Testers requested: soft particles
Tels replied to SteveL's topic in The Dark Mod
Revision #6340 compiles on my old Kubuntu box, I'm gonna do a testrun in a few minutes. Thank you, Steve -
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.