Tels
-
Posts
14984 -
Joined
-
Last visited
-
Days Won
23
Posts posted by Tels
-
-
Looking at my special particles from Black Light, I believe to make a particle to "trail", you use:
gravity world -2.000
instead of just "gravity -2.000".
I'm not sure if all particles should have "world" in there, too. My fire arrow explosion, f.i. doesn't have it, while the "smoke trail" has it. But technically, you could shoot a firearrow at a moving object, and then the explosion would not move with the object. This is an unusual thing, tho.
To get back to the original question (not sure if this is now resolved with the change from Steve, or not):
If the candle smoke is just the torch smoke, then it should be possible to improve it by:
- making it smaller, use different particles
- use "trailing particles", so they trail correctly while you move the candle during extinguishing it
However, the particles will still be just an approximation, we do not have "physical particles", so they will stil smoke through a solid object etc.
- making it smaller, use different particles
-
I can only think of 2 ways to handle it:
Option #1 would be to amend the tdm_light_holder script object so that when it changes particle from flame to smoke or vice versa, it rotates the light entity upright. That should take care of it, but it'd be a one-shot fix so if the player then turned or dropped the smoking candle on its side the smoke would turn too.
Then again the particle system has never been set up to support leaving a trail in the air. If the player waves a smoking candle round, the whole particle effect will go with the candle. (Actually, is this true? If it is, that would mean we can't we do steam-train effects by moving a func emitter... I've not noticed any code that would support leaving behind a trail so perhaps we can't).
Is this actually true? I remember that I tweaked the "firesparks" for my advanced torch particles so that if an AI carries a torch, the smoke+flints do not go straight up, but instead "trail". The same is done for the smoke trailing the firearrow.
If you are interested, I could dig up what I did tweak.
-
Yes.... I've not tested it but there's code to let you specify model, model_1, model_2 etc along with offset_1 offset_2
I'm probably responsible for this, as I added it back when I wanted SEED to be able to combine multiple emitters into one entity. But I never extended it to multi-models in general, and also the specification of the emitters is very clumsy (manually adding the offsets is not fun).
Technically, however, multiple models per entity should be easy, instead of just presenting the "one and only" model to the renderer (and saving its renderhandle), present multiple models to the renderer and store (and save/load) all render handles.
Basically just extending the scalar var into an array.
-
I would think for indies using idTech 4 / BFG engine, having ability to shove in more entities on the level without increasing upper limit would be a good thing
I also doubt that average indie will manage to make scenes with millions of world clutter objects.Well, I already tried it:
http://forums.thedarkmod.com/topic/12107-announcement-seed-system/page__view__findpost__p__243243
The models are cloned dynamically, then combined into larger models automatically. On LOD changes, the model is recompiled.
-
might be missing the x86 version or if you got it something might have acted up in the package installer ? try sudo apt-get -f install without any packages to let apt-get try to autocorrect problems.
No, the linker looks into "/usr/lib" - but on a 64bit system there is the 64bit variant there. The 32bit variant is in /usr/lib32/ - and so I think that scons just has not the right path or setting for this library.
For other libraries, the right version is in /usr/lib32/, too and this works. Just not for GLEW.
-
Make patches that'll make a difference to players.
I'm sorry, but my limited time does not permit me to do major work, and since creating patches from a "not being able to commit or branch" SVN tree is easily twice the work, this further hampers my ability to contribute. And since I can't commit even the most simple typo in a comment....
So, you have to take what I produce. Or, if you are not interested in such changes anymore, just tell me, and I'll find other interesting things todo.
Edit: And to expand on that: If not even the simply patches are cross-checked and commited, I'm not convinced any other major changes "making a difference to the players" will be commited either. So I'm very vary to spend time on things that then will be ignored. For instance the language patch, I don't think it has been applied. That work was done weeks ago and I'm just waiting for it to get applied so I can continue with it. Sorry, but I don't want to waste neither my nor your time.
-
Relevator, here is a patch to remove GLASSWARP:
http://swift-mazes.com/pub/tdm-patches/tels_patch_k_remove_glasswarp_2014-10-04.txt
The patch was discussed at lenght and we don't need GLASSWARP at all. Not sure if it was already applied to TDM.
-
It still doesn't link the game executable:
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../libGLEW.so when searching for -lGLEW /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../libGLEW.a when searching for -lGLEW /usr/bin/ld: skipping incompatible /usr/lib/libGLEW.so when searching for -lGLEW /usr/bin/ld: skipping incompatible /usr/lib/libGLEW.a when searching for -lGLEW
The reason here is that I'm on a 64bit system, but we are buildind a 32 bit executable, so it must use /usr/lib32/ and only /usr/lib/ as fallback. I wonder why this works for other libraries, but not GLEW.
-
Here is a small patch quietening a compiler warning and cleaning up some left-over from doom cruft:
http://swift-mazes.com/pub/tdm-patches/tels_patch_o_cleanup_2014-11-23.txt
I believe the following patches have not yet been applied:
http://swift-mazes.c..._2014-10-04.txt
http://swift-mazes.c..._2014-10-04.txt
What can I do to make this go faster?
-
Testing...
-
Guys thanks for doing this, we have garnered a few more players because they can play on linux.
Is this linux build based on the current 2.03 SVN or Revelators branch build..?
On revelators. The 2.03 SVN compiles just fine on my box and I also test it.
-
After looking through the code, SEED combines entitie's rendermodels after they have been spawned. So it's not usable right away due to:
- combining the rendermodel (this would actually work for func_statics, but might stutter if they have LOD stages)
- only doing so after-spawn.
We need to build a multi-model entity (this probably needs a new entity class) and add the rendermodels to it for each entity that we don't want to spawn.
Edit: A bit more info:
CStaticMulti is the class that contains one rendermodel and multiple clipmodels. Back then I could combine rendermodels, but not clipmodels. But I think the performance is better with multiple clipmodels due to each of them having a small idBounds instead one large.
Anyway, this class can easily be extended to have multiple rendermodles, I think. In the worst case we might have to use the ModelManager and add the visible models of func_statics together to one rendermodel.
The challange is to do this before spawning the entities - SEED currently kicks in after all have been spawned.
The "SEED can overcome the entity limit" is based on the generation of entities, where we don't spawn the entities but instead generate from procedural and image-map rules.
- combining the rendermodel (this would actually work for func_statics, but might stutter if they have LOD stages)
-
What looks best right now would be if we can assign multiple (different) models to one entity like you were speculating on above. Do any of your existing model management techniques work that way? Can we present multiple render entities or render models from a single entity, each with its own origin and orientation?
Yes, I belive that already works in the engine. But not sure. (Techncially there is no reason why it shouldn't work. After all, the renderer doesn't care wether 1 or x models are presented by the same entity to it.
If so we could add a spawnarg "inert" for func_statics, and get the game to combine all "inert" statics in each visleaf into one entity.
I'm not quite sure if SEED (which would be the logical place to do that) can already do it. It can definitely combine multiple models into "1 entity+1 model".
Since it already contains all the logic what to combine and what not (do not cross visleaf, keep the distance, same type and so on), it should technically be able to do that. I'm just unsure if the path "1 entity + multiple models" is implemented. If not, I think it would be quite easy, back then we didn't have the engine source, but now the sky is the limit
(I know I already implemented "multiple emitters per one entity" so multiple particles (which are just "fany models" anyway) works.
Edit: SEED is the class that handles "multiple models, multiple entities", the ModelManager is the low-level class that cobines multiple rendermodels into one.
Technically, to combine multiple func_statics, you draw a SEED entity in DR and then link the func_statics as targets to it. But I think we could automate it, spawn a SEED entity, and add targets to it. Of course, care must be taken that the targets of SEED don't need to spawn. But it could work.
-
It's barely visible in a static image, but there's steam rising above the tub. For some reason, using a deform particle patch interfered with the bath's shadow on the floor below. I'm now using a cluster of manually placed func_emitters instead, and this no longer happens:
It could be simply that the patch was upside down, release the particles donwards, which then raise again. Have you tried flipping it?
-
I've spent a few hours testing "inline" and I've come to the conclusion it's not worth fixing :-(
The problems:
It writes copies of the models into the proc file, so you'll add about 20kb per model to your (unzipped) proc file.
It slows down dmapping exponentially the more models you inline. 200, you won't really notice. 500, add a couple of minutes. 2000, I gave up after an hour and a quarter.
Piling lots of inlined models on top of one another (I did a pyramid of 500 barrels) causes shadow errors.
You have to add a caulk or clip brush because it will draw a FS for you without adding an entity for the model, but it won't make it solid. We could make it write the collsion model too, but that'd double the file bloat.
Oh boy.
So, we are back to either blindly double the entity limit and try to mitigate the effects, like always allocating a temp 16K*4 byte block and running through all entries, by keeping a "highest entity ID in use" variable.
In addition, more "multi entitites" or more usage of the model manager (in an automatic way) could also help.
-
Just a stupid question: Why don't we compile GLEW in, if it is only one file and has so wildy different versions among the different OS people use? Wouldn't that solve the problemwith linking it?
(Sure, we would be stuck with one version, but then, TDM is released frequently and also there is no need to update GLEW inside TDM).
-
I'm using Kubuntu 10.4 (yes, its that old). And libglew1.10-dev isn't available:
$ aptitude search libglew v libglew-dev - c libglew1 - The OpenGL Extension Wrangler - runtime environment i libglew1.5 - The OpenGL Extension Wrangler - runtime environment i libglew1.5-dev - The OpenGL Extension Wrangler - development environment v libglewmx-dev - p libglewmx1.5 - The OpenGL Extension Wrangler - runtime environment p libglewmx1.5-dev - The OpenGL Extension Wrangler - development environment
-
$ ./thedarkmod.x86 ./thedarkmod.x86: error while loading shared libraries: libGLEW.so.1.10: cannot open shared object file: No such file or directory
ldd says this:
$ ldd thedarkmod.x86 ./thedarkmod.x86: /lib32/libm.so.6: version `GLIBC_2.15' not found (required by ./thedarkmod.x86) ./thedarkmod.x86: /lib32/libc.so.6: version `GLIBC_2.15' not found (required by ./thedarkmod.x86) linux-gate.so.1 => (0xf77aa000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7763000) libdl.so.2 => /lib32/libdl.so.2 (0xf775f000) librt.so.1 => /lib32/librt.so.1 (0xf7755000) libpng12.so.0 => /lib32/libpng12.so.0 (0xf7730000) libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7613000) libXext.so.6 => /usr/lib32/libXext.so.6 (0xf7603000) libXxf86vm.so.1 => /usr/lib32/libXxf86vm.so.1 (0xf75fd000) libGL.so.1 => /usr/lib32/nvidia-current/libGL.so.1 (0xf7537000) libGLEW.so.1.10 => not found libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7442000) libm.so.6 => /lib32/libm.so.6 (0xf741c000) libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf73fd000) libc.so.6 => /lib32/libc.so.6 (0xf729a000) /lib/ld-linux.so.2 (0xf77ab000) libz.so.1 => /usr/lib32/libz.so.1 (0xf7284000) libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf726a000) libGLcore.so.1 => /usr/lib32/nvidia-current/libGLcore.so.1 (0xf5c5a000) libnvidia-tls.so.1 => /usr/lib32/nvidia-current/tls/libnvidia-tls.so.1 (0xf5c58000) libXau.so.6 => /usr/lib32/libXau.so.6 (0xf5c54000) libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf5c4d000)But I only got:
$ dir /usr/lib32/libGL libGLEW.so.1.5 libGLEW.so.1.5.0 libGL.so libGLU.so libGLU.so.1 libGLU.so.1.3.070701 $ dir /usr/lib32/libGLEW.so.1.5 lrwxrwxrwx 1 root root 16 2008-12-29 15:27 /usr/lib32/libGLEW.so.1.5 -> libGLEW.so.1.5.0
-
$ ./thedarkmod.x86 ./thedarkmod.x86: error while loading shared libraries: libGLEW.so.1.10: cannot open shared object file: No such file or directory
-
Using Kubuntu, but is a very old one 10.4 I believe. Can't upgrade, the HD is full (root partition to small, my fault back a few years ago) and the PC won't take a larger HD, anyway. It's at the EOL so I'm not gonna ugprade it, but so far hadn't had the time and money to buy a new PC.
Sorry, seems I can't help you here anymore.
-
Well, if you can just look into game code, you can see that BFG's codebase is D3+ROE. Maybe minor differences. Porting game code of TDM to BFG is easier than trying to make modern rendering engine from TDM engine.
Well, then we just wait until you finished the porting. We are all quite busy here with other stuff.
-
1
-
-
need to install the x86 version do sudo apt-get install libglew1.5-dev:i386 and you should hit jackpot
$ sudo apt-get install libglew1.5-dev:i386 Reading package lists... Done Building dependency tree Reading state information... Done E: Couldn't find package libglew1.5-dev:i386
Meh
-
Getting close:
/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../libGLEW.so when searching for -lGLEW /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../libGLEW.a when searching for -lGLEW /usr/bin/ld: skipping incompatible /usr/lib/libGLEW.so when searching for -lGLEW /usr/bin/ld: skipping incompatible /usr/lib/libGLEW.a when searching for -lGLEW /usr/bin/ld: cannot find -lGLEW collect2: ld returned 1 exit status scons: *** [build/release/core/sys/scons/doom] Error 1 scons: building terminated because of errors.
I have the following:
$ whereis libGLEW
libGLEW: /usr/lib/libGLEW.so /usr/lib/libGLEW.a /usr/lib64/libGLEW.so /usr/lib64/libGLEW.a
So may I miss the 32bit packet of libGLEW (I do remember that I had to install some of the to build on my 64bit Linux), or SConstruct has a path missing.
-
Doesn't build:
scons: Cannot explain why `build/release/game/idlib/Heap.os' is being rebuilt: No previous build information found g++ -o build/release/game/idlib/Heap.os -c -fPIC -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -fpermissive -fvisibility=hidden -m32 -O3 -march=pentium3 -ffast-math -fno-unsafe-math-optimizations -fomit-frame-pointer -DXTHREADS -fno-strict-aliasing -Iidlib -Ibuild/release/game/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -Iinclude/glew -I. idlib/Heap.cpp idlib/Heap.cpp: In function ‘void* _aligned_malloc(size_t, size_t)’: idlib/Heap.cpp:34: error: ‘GC_init’ was not declared in this scope idlib/Heap.cpp: In member function ‘void* idHeap::Allocate16(dword)’: idlib/Heap.cpp:349: warning: suggest parentheses around ‘+’ in operand of ‘&’ include/boost/system/error_code.hpp: At global scope: include/boost/system/error_code.hpp:221: warning: ‘boost::system::posix_category’ defined but not used include/boost/system/error_code.hpp:222: warning: ‘boost::system::errno_ecat’ defined but not used include/boost/system/error_code.hpp:223: warning: ‘boost::system::native_ecat’ defined but not used scons: *** [build/release/game/idlib/Heap.os] Error 1 scons: building terminated because of errors.
Revelator's TDM Branch
in The Dark Mod
Posted
Sorry for the long delay, RL interfered.
The latest git pull does still not compile on my system, it misses a compatible libglew. However, I haven't found a package for my old kubuntu yet and had not yet the time to compile it from source.