Jump to content
The Dark Mod Forums

Tels

Member
  • Posts

    14984
  • Joined

  • Last visited

  • Days Won

    23

Everything posted by Tels

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.
  9. 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.
  10. 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?
  11. Testing...
  12. On revelators. The 2.03 SVN compiles just fine on my box and I also test it.
  13. 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.
  14. 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. 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.
  15. It could be simply that the patch was upside down, release the particles donwards, which then raise again. Have you tried flipping it?
  16. 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.
  17. 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).
  18. 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
  19. $ ./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
  20. $ ./thedarkmod.x86 ./thedarkmod.x86: error while loading shared libraries: libGLEW.so.1.10: cannot open shared object file: No such file or directory
  21. 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.
  22. Well, then we just wait until you finished the porting. We are all quite busy here with other stuff.
  23. $ 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
  24. Getting close: I have the following: 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.
  25. Doesn't build:
×
×
  • Create New...