Jump to content
The Dark Mod Forums

Tels

Member
 View Profile  See their activity

  • Posts

    14984

  • Joined

  • Last visited

  • Days Won

    23

 Content Type 

Posts posted by Tels

  1. Any UK taffers up for a light drink on the 26th?

    in Off-Topic

    Posted · Edited by Tels

    What about eurotunnel..?

     

    Deutsche Bahn is unable to tell me what the price will be (Einmal mit Profis arbeiten...). I guess it will be a lot more expensive, using theThalis. But I have no idea, actually.

     

    Edit. Thalys.com gives me a quote of about 360€ from Cologne <=> London. Plus the local railfare that would be near 400€

  2. TDM Engine Development Page

    in The Dark Mod

    Posted

    Actually, the file sys/linux/qgl_enforce.h looks bogus to me. It contains a few hundred empty lines, than hundreds of redefines, but I can't find anywhere what they refer to, not even google.

     

    Even if we keep it, the 1400 or so empty lines should be removed from the top.

  3. TDM Engine Development Page

    in The Dark Mod

    Posted

    And again sorry for clarity, is this the 2.03 trunk, or the 2.02 trunk with my particle patch applied? Probably both though unless I screwed up the patch.

     

    Sorry, should have been more verbose:

     

    $ update
Path: .
URL: https://svn.thedarkmod.com/svn/darkmod_src/trunk
Repository Root: https://svn.thedarkmod.com/svn/darkmod_src
Repository UUID: 49c82d7f-2e2a-0410-a16f-ae8f201b507f
Revision: 6144
Node Kind: directory
Schedule: normal
Last Changed Author: stevel
Last Changed Rev: 6143
Last Changed Date: 2014-11-15 19:36:41 +0100 (Sat, 15 Nov 2014)

     

    AFAICS the errors come from re-defined names:

     

    $ ack use_qglReadBuffer

    sys/linux/qgl_enforce.h

    1361:#define glReadBuffer use_qglReadBuffer

     

    Maybe I'm missing a .h file or a dev package is not installed?

  4. TDM Engine Development Page

    in The Dark Mod

    Posted · Edited by Tels

    Is that from our svn trunk or from revelator's branch?

     

    From the main trunk, I haven't switched branches. Revision 6143.

     

    (Oh, and one code review comment: Please use more const in parameters. The new function idImage::CopyDepthbuffer modifies some of its arguments (imageHeight & width, or at least it looks like it does?) but keeps others (x,y) constant. That looks odd and makes it harder to see whats going on :)

  5. TDM Engine Development Page

    in The Dark Mod

    Posted · Edited by Tels

    The Linux build is broken:

     

     

     

    nizip -Iinclude/libjpeg -Iinclude/devil -I. renderer/Image_load.cpp
renderer/Image_load.cpp: In member function ‘void idImage::GenerateImage(const byte*, int, int, textureFilter_t, bool, textureRepeat_t, textureDepth_t)’:
renderer/Image_load.cpp:600: warning: suggest parentheses around ‘&&’ within ‘||’
renderer/Image_load.cpp: In member function ‘bool idImage::CheckPrecompressedImage(bool)’:
renderer/Image_load.cpp:1364: warning: comparison between signed and unsigned integer expressions
renderer/Image_load.cpp: In member function ‘void idImage::PurgeImage()’:
renderer/Image_load.cpp:1659: warning: comparison between signed and unsigned integer expressions
renderer/Image_load.cpp: In member function ‘void idImage::Bind()’:
renderer/Image_load.cpp:1705: warning: comparison between signed and unsigned integer expressions
renderer/Image_load.cpp:1750: warning: comparison between signed and unsigned integer expressions
renderer/Image_load.cpp:1755: warning: comparison between signed and unsigned integer expressions
renderer/Image_load.cpp:1760: warning: comparison between signed and unsigned integer expressions
renderer/Image_load.cpp: In member function ‘void idImage::BindFragment()’:
renderer/Image_load.cpp:1802: warning: comparison between signed and unsigned integer expressions
renderer/Image_load.cpp: In member function ‘void idImage::CopyDepthbuffer(int, int, int, int, bool)’:
renderer/Image_load.cpp:1927: error: ‘use_qglReadBuffer’ was not declared in this scope
renderer/Image_load.cpp:1937: error: ‘use_qglTexImage2D’ was not declared in this scope
renderer/Image_load.cpp:1938: error: ‘use_qglCopyTexSubImage2D’ was not declared in this scope
renderer/Image_load.cpp:1943: error: ‘use_qglCopyTexSubImage2D’ was not declared in this scope
renderer/Image_load.cpp:1945: error: ‘use_qglTexParameterf’ was not declared in this scope
renderer/Image_load.cpp: In member function ‘int idImage::StorageSize() const’:
renderer/Image_load.cpp:2043: warning: comparison between signed and unsigned integer expressions
renderer/Image_load.cpp: At global scope:
renderer/Image_load.cpp:23: warning: ‘versioned’ defined but not used
include/boost/system/error_code.hpp:214: warning: ‘boost::system::posix_category’ defined but not used
include/boost/system/error_code.hpp:215: warning: ‘boost::system::errno_ecat’ defined but not used
include/boost/system/error_code.hpp:216: warning: ‘boost::system::native_ecat’ defined but not used
scons: *** [build/release/core/renderer/Image_load.o] Error 1
renderer/Image_init.cpp: At global scope:
renderer/Image_init.cpp:228: warning: ‘void R_AlphaRampImage(idImage*)’ defined but not used
renderer/Image_init.cpp:381: warning: ‘void R_RGB8Image(idImage*)’ defined but not used
renderer/Image_init.cpp:449: warning: ‘void CreateSquareLight()’ defined but not used
renderer/Image_init.cpp:495: warning: ‘void CreateFlashOff()’ defined but not used
scons: building terminated because of errors.

     

     

  6. Any UK taffers up for a light drink on the 26th?

    in Off-Topic

    Posted · Edited by Tels

    Yeah, briefly :) But 250 € for two flights plus cab is a tad expensive, and "in the middle of the week" is out of the question right away :)

     

    Edit: Oh. Its only 91€ both ways - unless you bring a suitcase, which adds 50€ .. 100 € :o But it would start Tuesday evening and go back on Thursday morning. That means still 1 1/2 day holiday from work.

  8. Springheel's Stuff

    in Art Assets

    Posted · Edited by Tels

    I've been working on some RITs for AI to do....this one is activated by def_attaching a new prop quill, which triggers the following behaviour for sitting AI:

     

    The height works for both regular desks and scribe desks, though it's a bit high for regular tables.

     

    Very cool. It would be a bit better if you could have them "dip" the Quill into ink, tho. As it is, it looks quite repeating.

     

    Edit: Oh, and they write way too fast. Writing on very expensive parchment or leather skin is a slow, careful task, to avoid errors and have a clean image. It's not a fast "lets scribble something with a pen" we are used to nowadays :)

  9. What are current max limits for the following:

    in TDM Editors Guild

    Posted

    If everything else fails, you could also consider splitting the mission into two different maps. It's not a very liked approach, especially since T3, but it is a possibility.

     

    I think the entity count can be brought down a lot by a combination of:

    • comine multiple func_statics into one (with SEED or manual)
    • exprot often-used stuff as ASE model and avoid the func_statics, instead make them a model (ok, this has the same entity count, but it saves memory and loading times)
    • If you useda lot of vinepatches, vegetation etc, it might be worthwhile to create special models for that. Likewise for arches, where you can combine multiple patches into one ASE model.

    Btw:

     

    • Entities - 7779

    • Models - 595

     

    Each model is one entity during runtime, so you probably already crossed the 8192 entity limit.

     

    Technically, we could double it (I think), but blindly doubling the limit will expose other limits in the engine, like the CM limit. ALso, a lot of operations in the engine assume that there is a small number of entities and will be slower (not much,but they will be slower) if you have a lot of entities.

     

    E.g. if the engine wants to get every AI, even if there are only 2 in the map, it will run through the entire entity list. Likewsise trigger_touch entities will compare themselves against every entity, not only the ones that are close and so on. All these things will take a tiny amount of time longer if you double the entity amount. So I'd say try to stay under 8000 for this map.

     

    If you need help, I could have a look.

  11. TDM Engine Development Page

    in The Dark Mod

    Posted

    If using a build from my fork on github, remember that the FPS counter code was replaced by a 64 bit precision counter version from MH :)

    Its much more precise and does not suffer from the sometimes drastic FPS variations the vanilla version had.

     

    That change alone would be great, as I get wildly varying FPS counts on my (old) system.

  12. TDM Engine Development Page

    in The Dark Mod

    Posted

    I'll be committing particles to the trunk for testing within a few hours... tonight or tomorrow. I've got it working nicely in the engine as of tonight, instead of being controlled through material files, so it's ready for testing on existing maps. I just took a run through a few maps and it's all looking good so far :)

     

    Re the builder archer, that a good point. I think we catered for skin switches in AI LOD already, but maybe not model swaps. We might have to disable LOD for any AI whose model has been fiddled with if there's not a cleverer solution.

     

    That would be ther exception, wouldn't it be? In that case I'd say its the mappers "fault" and LOD on such AI will not be available. (and still be available for 99% of the AI out there).

     

    Or is changing the model spawnarg commonplace? It certainly is unorthodox, I'd say. It never occured to me.

  13. TDM Engine Development Page

    in The Dark Mod

    Posted

    Aye and it will be so from the initial checkin :) but since the GLEW port was a rather major change i thought it better to just start from that, the patch just for the glew changes is massive.

    If the devs like i could just hand over the repository to them and they could keep a version of both models, eg one with GLEW and one without but i suspect when they notice the benefits of it that they might prefer this version.

     

    I do think that we'd just add GLEW to TDM - no sense in keeping two versions. But as I said, it's not my job or decision.

  15. TDM Engine Development Page

    in The Dark Mod

    Posted

    I created a fork of the TDM unofficial sources with my current changes here https://github.com/r...od-Experimental

    all devs who want access PM me and ill set you up :).

    My current changes would not fit well with the main fork so i prefer this way as i have cleaned up a lot allready and plan on cleaning up even more of the code.

    This means removing old unused gunk (theres a lot i know that from experience) fixing known bugs which allready are implemented in other engines including my own,

    General optimization etc.

     

    The code was formatted for better readability (tight).

    Untill we can get rid of boost i have updated it to the latest version 1.57.

    GLEW is also latest version and supports upto opengl 4.4.

    MH's VBO code is in.

    MH's precise FPS counter is in.

    MH's fix for Ase models sometime turning up black is in.

    I have fixed a number of places where something was allocated with new[] and deallocated with delete instead of delete[].

    FIxed a few uninitialized variables.

    Fixed a number of things pointed out by PVS Studio.

    Fixed a fix i had done wrong, see above :S sorry i was tired when i did that number, had been up for 26 hours.

     

    I do like the changes, but I think that for TDM, we would need these in small steps, e.g. one diff per item. That way it is easier to see what it changes.

     

    However, don't let me distract you, as I no longer have access to the mod, I can't commit anything, anyway, and all the work will be done by others. Thank you again for your work! :wub:

    • Like 1

  18. OpenGL perf. on AMD/ATi gpu's: WIP fix.

    in TDM Tech Support

    Posted · Edited by Tels

    eeh, I disagree. If that was the case, there would be no QA departments. One person with one specific hardware setup could test it all. However, software is tested on wide variety of hardware. So you don't just take one isolated case and proclaim: "That's it, AMD has issues with drivers because TDM run at 60fps on all Nvidia GPUs just because it does for me on my PC!"

     

     

    I'm with Steve here: If you want to test the GPU, you keep everything else (monitor, CPU, motherboard, memory, HDD) the same and swap the GPU and driver. If it then becomes much slower - you have found a culprit.

     

    Testing on a different PC would not prove anything in this case.

  19. TDM Engine Development Page

    in The Dark Mod

    Posted

    Hehe not unless you want to keep your job ;)

     

    comitted a few more tweaks, and a request to update the boost libray used as the version TDM uses has a problem that was fixed in later versions.

     

    I allready made a new version for revelation though i only use boost in one place atm, i could add that one to the next commit.

     

    I hoped we could get rid of boost. It solves only a few problems that I'm sure we can solve without, but brings the massive downside binding the compiled version to the compatiblity version of the OS. E.g. you can't run a compiled-on-a-new Ubuntu TDM on old Ubuntu, and you can't run the compiled-on-old-ubuntu version on newers, so you have to compile TDM on a semi-old ubuntu to make it available to more users....

    • Like 1

  20. TDM Engine Development Page

    in The Dark Mod

    Posted

    It seems like it would rebuild entire surface, and with render entity, it would only update that particular model (surface). So it seems like it would be faster.

     

    Yeah, that's true. But if it would still render as fast in that case is not known. One would have to implement and try it. But I think the modelmanager is the wrong approach, anyway. The engine (renderer) should deal with that transparently in the backend.

     

    However, back then, we didn't have the source to the renderer, so it was the best that we could do (I do keep repeating myself here :) And now we have the source, but as little or even less manpower.

  21. TDM Engine Development Page

    in The Dark Mod

    Posted

    Btw, something just occurred to me. Doom 3 culls on per-surface basis. If you have one massive surface, and only a little bit of it in the view, afaik engine won't cull it. That might be the reason SEED is slow, if all meshes are combined into one surface. I don't know how SEED works exactly, but it would make sense to combine all of the models into one render entity, not into one surface. Again, it just occurred to me, and I might be in the wrong :)

     

    Well, yeah, back then the ModelGenerator was a giant hack and it hasn't been revisited since then. So it still merges everything into one surface. I'm not sure if merging everything into one renderentity would have been faster.

     

    The "slowness" of the combination isn't during rendering - this is a lot faster than not merging (and also overcomes the render model limit (which was since then raised) and the entity limit.

     

    What is so slow is rebuilding the model when one of the "submodels" change their LOD stage. If none of them ever change, everything is just as fast as always.

  24. TDM Engine Development Page

    in The Dark Mod

    Posted

    I guess, if Revelator wouldn't mind, giving him SVN access and having him make a TDM branch with the changes he recommends might be the best way to go

    since we wouldn't have to keep searching for dependencies in the supplied parts (etc)? Mh's VBO fix was originally isolated to the VertexCache.cpp and VertexCache.h

    blocks (as were Serpentine's changes) so there's no dependency hunting there but if Revelator's code is better then perhaps it's better to get a full fledged branch made?

     

    Yeah, SVN branches are exactly for this type of experimentation. And when revelators work does work, we can just merge the branch back in and more developers can test it.

  25. TDM Engine Development Page

    in The Dark Mod

    Posted · Edited by Tels

    A proper patch to the TDM engine would be a lot more helpful than these random bits of code that can't be just integrated. I don't think we have anyone who would have the time to clean up this mess.

     

    Edit: By mess I mean both the "mess" in the D3 engine, the "d3 engine plus some TDM modificatons" and the new code, which looks quite a bit experimental. The mix of these three is a lot of ugh :)

×
×
  • Create New...