Jump to content
The Dark Mod Forums

Tels

Member
  • Posts

    14984
  • Joined

  • Last visited

  • Days Won

    23

Posts posted by Tels

  1. I've looked at the map and talked with Biker and also thought a bit about the limits.

     

    The entity limit is posing a real problem - even for a medium-sized map like Bikers (I wouldn't call it large in TDM terms, in Thief terms it's of course massive).

     

    Although Biker might have found a emp. workaround with the bottles, the limit might still be reached and the map isn't even finished. The real problem is that the engine treats almost everything as its own entity, even tho you might need it only for simple reasons like "define the position easily in DR". A "full" entity has of course advantages, like you can toggle it on or of, query it, run scripts on it, have scripts refer to it etc. But in some cases it is superflous. Here are a few examples:

    • lights + models. Some of our streetlamps are a light with a visual model (1 entity). Biker often used a light + a model and here the entity def is just a reference to a model. But not in all cases can you combine these two.
    • light haze. These are all particle emitters with a single haze particle. So in some cases you have light + model + haze (3 entities)
    • static models. These are basically just a "place the model x at position xyz" references. The might not need an entity after loading the map anymore. But the engine makes no distinction.
    • location separators (esp. the ones that just set the sound on a portal): I'm not sure if the engine removes them after loading anyway, but if not, that might be something to look into. Larger maps can easily have a few dozend of these and all they basically do is set some parameters on the visportal they touch.
    • Door handles are their own entity, so a standard door is already 2 or 3 entities.
    • It looks like the map uses scritped scenes with blue rooms with entities (I might be wrong,tho). But that also means you have a few hundred entities that are kept after frame #1 and no longer serve a purpose.

    Looking at the map, there are almost no single places where you have a massive amount of entities and thus could save a few hundreds in one place (except the wine bottles). Instead its literally dozends of different entities for different things in almost every corner. Sounds, locations, lights, AI paths, haze, moveables, movers and so on.

     

    I see a few possibilities here:

    1. Remove unnec. entities after map loading. This might be difficult, because some script could refer to any entity, and then it must be kept. But likely candidates are portal info, difficulty info, shop info, starting inventory (I believe these are already removed). Another difficulty is that removing the entity might not be enough, the entity must not even be spawned - otherwise it uses up one entity slot during frame #1 and the map would still reach the limit. Might not gain enough.
    2. Build more light+model entities, and make the mapper use them. Educating mappers seems to be the issue here. Might not gain enough.
    3. Add the ability of a "haze" to lights. Lights already have the ability to display a model (and a different when off), adding the haze has the advantage that the haze particle could also be turned on/off with the light, a possibility currently not available. Needs a lot of coding support, mappers need to be aware and might not gain enough.
    4. Double the entity limit. Probably the easiers solution. We also should look into the engine code and see if we can identify places where the code loops through all entities and change these to a "loop only through entities of type X". This means also we need to keep a second list(tree) of entities sorted by type. One of these bottlenecks where (are) the trigger_touch, but I'm sure other code places want to look at all lights, and instead inspect every entity until they found all the lights. f.i.This would gain enough to allow bigger maps for a while.
    5. Other complicated schemes involve SEED, more intelligent engine management of entities (combine them in the back, automaticaly), but they are all complicated to code, and depending on the type of map, won't help. I'm pretty sure the next map will be even bigger and involve 10000 moveables and we are back at the beginning again.

     

    Edit:

     

    The new "blend light" to simulate dropshadows make the situation for 3. worse, they spawn one additional entity for each moveable candle. That change could even theoretically break large maps by adding entities and pushing it over the limit. I think having a better renderer that automatically creates soft shadows and ambient occlusion and light haze would also solve this issue because these elements would not need an entity.

  2. You are fixing these things before I even can look at them. And not sure what "m4" is, but now it runs to this point :)

     

     

     

    g++ -o build/release/core/framework/DeclFX.o -c -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 -Winvalid-pch -D__DOOM_DLL__ -Iframework -Ibuild/release/core/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. framework/DeclFX.cpp
    scons: building `build/release/core/glimp/sys/linux/glimp_dlopen.cpp' because it doesn't exist
    cd sys/linux && m4 -E < glimp_dlopen.cpp.m4 > /home/te/src/tdm_experimental/The-Darkmod-Experimental/src/build/release/core/glimp/sys/linux/glimp_dlopen.cpp
    m4:stdin:36: undefined macro `f363_ret'
    m4:stdin:48: undefined macro `f363_ret'
    m4:stdin:105: undefined macro `f363_ret'
    scons: *** [build/release/core/glimp/sys/linux/glimp_dlopen.cpp] Error 1
    scons: building terminated because of errors.
    

     

     

  3. hopefully final changes to get the linux build going again.

    Added missing glew initializer to linux specific code.

    split up qgl headers in os specific versions.

     

    Im unable to locate the opengl lib flags -lGL anywhere in scons or otherwise so i suspect it uses autodepend, but if you get any linker errors let me know.

     

    Unfortunately not:

     

    g++ -o build/release/core/framework/Session_menu.o -c -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 -Winvalid-pch -D__DOOM_DLL__ -Iframework -Ibuild/release/core/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. framework/Session_menu.cpp
    build/release/core/glimp/sys/gllog/gl_extensions.cpp:15: warning: missing braces around initializer for ‘glExtName_t’
    build/release/core/glimp/sys/gllog/gl_extensions.cpp:19: error: ‘GLExtension_t’ does not name a type
    build/release/core/glimp/sys/gllog/gl_extensions.cpp:17: warning: ‘void StubFunction()’ defined but not used
    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/core/glimp/sys/gllog/gl_extensions.o] Error 1
    scons: building terminated because of errors
    

     

    I might take a look tomorrow and see if I can fix it.

  4. He's quite complimentary.

     

    Haven't watched the second video, but he has every right to be. St Lucia is just a beautyful map, and the mod is just a wonderful piece of work. If you watch that video, there aren't really many things that an AAA game title would have over it - except the marketing department, maybe :) It always amazes me how much we packed into that map and mod and what a wonderful result came out of the hard work. All people involved can't be thanked enough.

  5. There is currently an ongoing LP of both Thief 4 and The Dark Mod, made by Bobbin Threadbare from Something Awful. The thread is, unfortunately, hidden beyond the paywall, but the movies are available on YT.

     

    As of today, he managed to cover Tears of St. Lucia and Mandrasola.

     

    He has a really soothing voice, I nearly fell asleep during the briefing -_- He'd be really great for voice overs, tho. And knows the right phrases, too "It's not about the money, but the experience" :D

     

    Just wish the St Lucia playthrough would have been the first playthrough. It's a great showcase, but I'd really liked to know how he played it the first time.

  6. Ok created replacement functions for linux and other unix based OS that do not have these, changes have been comitted.

     

    Thanx. It progresses a lot further now:

     

     

     

    scons: building `build/release/core/glimp/sys/gllog/gl_extensions.o' because it doesn't exist
    g++ -o build/release/core/glimp/sys/gllog/gl_extensions.o -c -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 -DGLIMP -Ibuild/release/core/glimp/sys/scons -Isys/scons -Iglimp/sys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. -I. build/release/core/glimp/sys/gllog/gl_extensions.cpp
    build/release/core/glimp/sys/gllog/gl_extensions.cpp:15: warning: missing braces around initializer for ‘glExtName_t’
    build/release/core/glimp/sys/gllog/gl_extensions.cpp:19: error: ‘GLExtension_t’ does not name a type
    build/release/core/glimp/sys/gllog/gl_extensions.cpp:17: warning: ‘void StubFunction()’ defined but not used
    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/core/glimp/sys/gllog/gl_extensions.o] Error 1
    scons: building terminated because of errors.
    

     

     

  7. Is there a way to merge models like that without learning to use a specific modelling program like Blender? Biker made his prefab in DR. I've tried making a couple of models in DR too in the past, but like Biker I found I'd generated massive ase files, 100s of times bigger than the map file where I built the model (and which must have held just as much information).

     

    http://wiki.thedarkm...tching_entities

     

    Works at run time, with dynamic allocation of models up to the limit, and recompiles the merged model when LOD stages change (or never).

     

    You aren't even limited to the same model or entity type.

  8. Is that a performance increase from the changes or from the change of location in the screen shot? Sorry to be a nag, but would it be possible to get a side by side of the same location, just for easier comparison? :) It's hard to get a feel from the different locations.

     

    At least it proves it compiles and runs - let's ship it :D :D

  9. No it compiles a bit, and then stops here:

     

     

     

    scons: building `build/release/game/idlib/Heap.os' because it doesn't exist
    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 -I. idlib/Heap.cpp
    idlib/Heap.cpp: In member function ‘void* idHeap::Allocate16(dword)’:
    idlib/Heap.cpp:393: warning: suggest parentheses around ‘+’ in operand of ‘&’
    idlib/Heap.cpp: In function ‘void* Mem_Alloc16(int)’:
    idlib/Heap.cpp:1169: error: ‘_aligned_malloc’ was not declared in this scope
    idlib/Heap.cpp: In function ‘void Mem_Free16(void*)’:
    idlib/Heap.cpp:1190: error: ‘_aligned_free’ was not declared in this scope
    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.
    

     

     

  10. The patch for the Linux include was not properly applied, here is it again:

     

    diff --git a/src/sys/win32/win_qgl.h b/src/sys/win32/win_qgl.h
    index f26907a..a27f56e 100644
    --- a/src/sys/win32/win_qgl.h
    +++ b/src/sys/win32/win_qgl.h
    @@ -38,8 +38,8 @@ If you have questions concerning this license or the applicable additional terms
    #include "glew.h"
    #include "wglew.h"			 // windows OpenGL extensions
    #elif defined( __linux__ )
    -#include "glew.h"
    -#include "glxew.h"			 // linux OpenGL extensions
    +#include "glew/glew.h"
    +#include "glew/glxew.h"				// linux OpenGL extensions
    #endif
    
    //
    

     

    Now it fails with:

     

     

     

    In file included from game/../idlib/../idlib/Lib.h:163,
    			 from game/../idlib/precompiled.h:112,
    			 from game/precompiled_game.h:28:
    game/../idlib/../idlib/math/Matrix.h: In member function ‘idMatX& idMatX::SwapRows(int, int)’:
    game/../idlib/../idlib/math/Matrix.h:2438: error: ‘ALIGNPTR’ was not declared in this scope
    game/../idlib/../idlib/math/Matrix.h:2438: error: ‘ALIGNPTR’ was not declared in this scope
    game/../idlib/../idlib/math/Matrix.h:2438: error: declaration of ‘<typeprefixerror>ALIGNPTR’
    game/../idlib/../idlib/math/Matrix.h:2438: error: conflicts with previous declaration ‘<typeprefixerror>ALIGNPTR’
    In file included from game/../idlib/../idlib/Lib.h:172,
    			 from game/../idlib/precompiled.h:112,
    			 from game/precompiled_game.h:28:
    game/../idlib/../idlib/math/Curve.h: In member function ‘float idCurve<type>::RombergIntegral(float, float, int) const’:
    game/../idlib/../idlib/math/Curve.h:199: warning: there are no arguments to ‘ALIGNPTR’ that depend on a template parameter, so a declaration of ‘ALIGNPTR’ must be available
    game/../idlib/../idlib/math/Curve.h:199: warning: there are no arguments to ‘ALIGNPTR’ that depend on a template parameter, so a declaration of ‘ALIGNPTR’ must be available
    game/../idlib/../idlib/math/Curve.h:200: warning: there are no arguments to ‘ALIGNPTR’ that depend on a template parameter, so a declaration of ‘ALIGNPTR’ must be available
    game/../idlib/../idlib/math/Curve.h:200: warning: there are no arguments to ‘ALIGNPTR’ that depend on a template parameter, so a declaration of ‘ALIGNPTR’ must be available
    game/../idlib/../idlib/math/Curve.h: In member function ‘float idCurve<type>::GetTimeForLength(float, float) const’:
    

     

     

     

    No idea why. Because ALIGNPTR is only defined for Win32, but used everywhere. Haven't tried to fix it, tho.

     

    -----

    Btw, how do I do an "svn update" with git? I couldn't get this to work,not even after reading the man page...

  11. The branch fails to compile on Linux (after the include fix):

     

    game/../idlib/../idlib/math/Curve.h: In member function ‘type idCurve_BSpline<type>::GetCurrentSecondDerivative(float) const [with type = idVec3]’:
    game/../idlib/../idlib/math/Curve.h:1891: sorry, unimplemented: inlining failed in call to ‘float idCurve_BSpline<type>::Basis(int, int, float) const [with type = idVec3]’: recursive inlining
    game/../idlib/../idlib/math/Curve.h:1902: sorry, unimplemented: called from here
    game/../idlib/../idlib/math/Curve.h:1891: sorry, unimplemented: inlining failed in call to ‘float idCurve_BSpline<type>::Basis(int, int, float) const [with type = idVec3]’: recursive inlining
    game/../idlib/../idlib/math/Curve.h:1907: sorry, unimplemented: called from here
    game/../idlib/../idlib/math/Curve.h:1891: sorry, unimplemented: inlining failed in call to ‘float idCurve_BSpline<type>::Basis(int, int, float) const [with type = idVec3]’: recursive inlining
    game/../idlib/../idlib/math/Curve.h:1902: sorry, unimplemented: called from here
    game/../idlib/../idlib/math/Curve.h:1891: sorry, unimplemented: inlining failed in call to ‘float idCurve_BSpline<type>::Basis(int, int, float) const [with type = idVec3]’: recursive inlining
    

     

    The last lines are then repeated a few hundred times.

  12. Does not compile:

     

     

     

    scons: building `game/precompiled_game.h.gch' because it doesn't exist
    g++ -o game/precompiled_game.h.gch -x c++-header -c -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -fpermissive -fvisibility=hidden -m32 -O3 -march=pentium3 -ffast-math -fno-unsafe-math-optimizations -fomit-frame-pointer -fno-strict-aliasing -Wno-deprecated -Winvalid-pch -fPIC -DGAME_DLL -Igame -Ibuild/release/game/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. game/precompiled_game.h
    In file included from game/../idlib/precompiled.h:109,
    			 from game/precompiled_game.h:28:
    game/../idlib/../sys/win32/win_qgl.h:41:19: error: glxew.h: No such file or directory
    scons: building `build/release/game/game/randomizer/userintf.os' because it doesn't exist
    g++ -o build/release/game/game/randomizer/userintf.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 -fno-strict-aliasing -Wno-deprecated -Winvalid-pch -fPIC -DGAME_DLL -Igame -Ibuild/release/game/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. game/randomizer/userintf.cpp
    scons: building `build/release/game/idlib/Base64.os' because it doesn't exist
    g++ -o build/release/game/idlib/Base64.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 -I. idlib/Base64.cpp
    In file included from idlib/precompiled.h:109,
    			 from idlib/Base64.cpp:1:
    idlib/../sys/win32/win_qgl.h:41:19: error: glxew.h: No such file or directory
    scons: *** [game/precompiled_game.h.gch] Error 1
    scons: *** [build/release/game/idlib/Base64.os] Error 1
    scons: building terminated because of errors.
    

     

     

     

    Solved this particular issue with that patch:

     

    te@te:~/src/tdm_experimental/The-Darkmod-Experimental/src$ git diff sys/win32/win_qgl.h
    diff --git a/src/sys/win32/win_qgl.h b/src/sys/win32/win_qgl.h
    index 55875a5..8f078d4 100644
    --- a/src/sys/win32/win_qgl.h
    +++ b/src/sys/win32/win_qgl.h
    @@ -38,7 +38,8 @@ If you have questions concerning this license or the applicable additional terms
    #include "glew.h"
    #include "wglew.h"			 // windows OpenGL extensions
    #elif defined( __linux__ )
    -#include "glxew.h"
    +#include "glew/glew.h"
    +#include "glew/glxew.h"
    #endif
    
    //
    
    

     

    We probably should start a new thread for this.

    • Like 1
  13.  

    Does not compile:

     

     

     

    scons: building `game/precompiled_game.h.gch' because it doesn't exist
    g++ -o game/precompiled_game.h.gch -x c++-header -c -pipe -Wall -Wno-unknown-pragmas -fmessage-length=0 -fpermissive -fvisibility=hidden -m32 -O3 -march=pentium3 -ffast-math -fno-unsafe-math-optimizations -fomit-frame-pointer -fno-strict-aliasing -Wno-deprecated -Winvalid-pch -fPIC -DGAME_DLL -Igame -Ibuild/release/game/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. game/precompiled_game.h
    In file included from game/../idlib/precompiled.h:109,
    			 from game/precompiled_game.h:28:
    game/../idlib/../sys/win32/win_qgl.h:41:19: error: glxew.h: No such file or directory
    scons: building `build/release/game/game/randomizer/userintf.os' because it doesn't exist
    g++ -o build/release/game/game/randomizer/userintf.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 -fno-strict-aliasing -Wno-deprecated -Winvalid-pch -fPIC -DGAME_DLL -Igame -Ibuild/release/game/sys/scons -Isys/scons -Iinclude -Iinclude/zlib -Iinclude/minizip -Iinclude/libjpeg -Iinclude/devil -I. game/randomizer/userintf.cpp
    scons: building `build/release/game/idlib/Base64.os' because it doesn't exist
    g++ -o build/release/game/idlib/Base64.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 -I. idlib/Base64.cpp
    In file included from idlib/precompiled.h:109,
    			 from idlib/Base64.cpp:1:
    idlib/../sys/win32/win_qgl.h:41:19: error: glxew.h: No such file or directory
    scons: *** [game/precompiled_game.h.gch] Error 1
    scons: *** [build/release/game/idlib/Base64.os] Error 1
    scons: building terminated because of errors.
    

     

     

  14. Sure anything you dont want from dhewm3 ? changing to SDL would break my GLEW port so im not sure how i should react to that part, besides i prefer using native OpenGL and no other part of the engine

    really needs anything special since all the libraries used in it are allready crossplatform. Changing to use cmake would be a great leap though and we get rid of a lot of deprecated stuff in the process :).

    Nothing agains scons its a great build system but it can be a little clunky at times and cmake works for all OS so its really a no brainer.

    All devs who want to have access to my git repository to make direct changes are welcome to chime in :) the more of us the faster it goes.

     

    A change away from scons would be real good. But apart from a few fruitles tries, we have nothing to show for yet.

  15. That would do it if it's portable enough, but I'd suggest for now we leave the function dormant. We'd have to recalibrate the entire thing to make it useful. The current set up only does anything if you have less than 256mb!

     

    But -2Gb is less than 256Mb :)

     

    I'd say fix it right, and use a long (int64) so it can hold more then 2 Gbyte. Also, code like this makes me cringe:

     

    if (retSize < 0) {
     return retSize = -retSize;
    }
    return abs(retSize);
    

     

    If the variable is less then 0, you make it positive, fair enough. But why "abs()" in the other case? It is already positive... Plus, there a wholly needless if there. A much simpler approach is:

     

    return abs(retSize); 

     

    And be done with it :)

     

    Edit: If a size of >4Gbyte (or 3, for 32 bit processed) is causing problems in other parts of the engine, the right way is to use 64bit to query the value, then limit it to a safe value (and output both on the console).

  16. So how is qgl_enforce.h getting included?

    That #define explains the error messages. I knew there were no explicit calls to any use_qgl* functions in that function, but it's using macros to swap out the functon names.

    Will it compile if you rename qgl_enforce.h? Probably not but then you should get an include error which'll tell you where it's being included erroneously.

     

     

    NB that's a function declaration from the original engine code. We added one param. I agree completely that more-const is better than less-const, but it's a question of good style rather than code correctness in this spot as they're built-ins passed by value, so there are no possible side-effects. In this spot I'd prioritise the rules that say (1) you align new code to the surrounding code, hence the one new param matches the existing ones, and (2) you don't change what ain't broken when you already have a huge testing to-do list!

    That said, it *is* confusing that two of the parameters get modified by another function that looks like it won't modify them. That one's my pet hate: seeing values passed to a function to be modified by non-const reference instead of a non-const pointer, which means there's no clue whatsoever for the reader that the values will get modified. In our defence, that's existing code.

     

    Yeah, I agree with the "dont fix whats broken"; but OTOH, the code never gets better if we only add in the old style. To our defense, we do have at least 3 different styles and the mess isn't getting much better. (Large cleanup efforts are not really a priority given the resources).

     

    Still I'd wish we could stop spending so much time looking at the code just because it has these traps :)

     

    ps I'm not using the royal 'we' here :) "We" and "our" means revelator and I, we collaborated on getting that (exsiting) function working.

     

    I think we all sit in the same boat :)

  17. Hmm do these errors pop up anywhere else in the build ? the use_qglsomething only exist in qgl_enforce.h and since its not even included anywhere i have a hard time figuring out why the compiler complains about these functions :blink: there not only used in image_load.cpp.

     

    If you could do me a favour try compiling the one from my github, you will probably have to get the glew package for your linux distro, im curious to see if it builds ok on linux.

     

    Could you please remind me how to checkout from git? I guess it stil has a linuxBuild.sh I can then run?

     

    If the file is not used at all, we should delete it promptly, it only wastes human resources figuring out :)

     

    Actually: renderer/qgl.h line 537 or so:

     

    // make sure the code is correctly using qgl everywhere
    // don't enable that when building glimp itself obviously..
    #if !defined( GLIMP )
       #include "../sys/linux/qgl_enforce.h"
    #endif
    
    

  18. LOL, blimey they are on another bloody planet with those prices.

     

    Did a quick google search and found Ryan Air €98 return, plus the train from the Airport at €30 you could sleep over in my spare room etc. Thats a good deal cheaper and quicker than going via Brussels.

     

    Tha train from the Airport is €30 now? Wow, it used to be 5 pound or so - well, ok, that was before the war :D

     

    Yeah, Ryan Air plus train on your side plus train on my side amounts to about 150 € 200 € back-and-forth all in all. Not bad, but still quit heavy for a beer :ph34r: In that case I'd rather have a long weekend to see a bit more of London.

×
×
  • Create New...