Jump to content
The Dark Mod Forums

revelator

Development Role
 View Profile  See their activity

  • Posts

    1174

  • Joined

  • Last visited

  • Days Won

    21

 Content Type 

Everything posted by revelator

  1. revelator
    Come to think of it this will probably also affect other parts of the engine if say we use huge high definition textures we would run into problems with the pk4 system not being able to hold the data (actually allready ran into that problem with the HD textures for Doom3) causing the pk4's to not work even though you can open them in 7z or other zip managers. Probably also other places that would begin to experience problems.
  2. revelator
    Mmm could not reply earlier today because the forums seemed to be down, but yeah int pointers would need to be changed to 64 bit size on cards with more memory than 4 gb atleast also the signed vs unsigned comment is valid and needs checking. My small fix only changes the returned negative values into positive ones and does not take into account the growing heaps of memory on modern cards. Also since 64 bit OS are becomming more and more the norm we might need to think about porting the code to 64 bit (dhewm3 patches should prove valuable there).
  3. revelator
    Might have been caused by me since the engine i based this off was allready based on GLEW hence the lack of q before the gl calls, in a fork not yet using GLEW it should have the q prefix. Im actually amazed that it worked without it.
  4. revelator
    small function you can implement at once here, fixes videoram detection. /* ================ Sys_GetVideoRam returns in megabytes This function works but returned negative sizes. Fixed now. ================ */ int Sys_GetVideoRam(void) { #ifdef ID_DEDICATED return 0; #else int retSize = 64; CComPtr<IWbemLocator> spLoc = NULL; HRESULT hr = CoCreateInstance(CLSID_WbemLocator, 0, CLSCTX_SERVER, IID_IWbemLocator, (LPVOID *)&spLoc); if (hr != S_OK || spLoc == NULL) { if (retSize < 0) { return retSize = -retSize; } else { return abs(retSize); } } CComBSTR bstrNamespace(_T("\\\\.\\root\\CIMV2")); CComPtr<IWbemServices> spServices; // Connect to CIM hr = spLoc->ConnectServer(bstrNamespace, NULL, NULL, 0, NULL, 0, 0, &spServices); if (hr != WBEM_S_NO_ERROR) { if (retSize < 0) { return retSize = -retSize; } else { return abs(retSize); } } // Switch the security level to IMPERSONATE so that provider will grant access to system-level objects. hr = CoSetProxyBlanket(spServices, RPC_C_AUTHN_WINNT, RPC_C_AUTHZ_NONE, NULL, RPC_C_AUTHN_LEVEL_CALL, RPC_C_IMP_LEVEL_IMPERSONATE, NULL, EOAC_NONE); if (hr != S_OK) { if (retSize < 0) { return retSize = -retSize; } else { return abs(retSize); } } // Get the vid controller CComPtr<IEnumWbemClassObject> spEnumInst = NULL; hr = spServices->CreateInstanceEnum(CComBSTR("Win32_VideoController"), WBEM_FLAG_SHALLOW, NULL, &spEnumInst); if (hr != WBEM_S_NO_ERROR || spEnumInst == NULL) { if (retSize < 0) { return retSize = -retSize; } else { return abs(retSize); } } ULONG uNumOfInstances = 0; CComPtr<IWbemClassObject> spInstance = NULL; hr = spEnumInst->Next(10000, 1, &spInstance, &uNumOfInstances); if (hr == S_OK && spInstance) { // Get properties from the object CComVariant varSize; hr = spInstance->Get(CComBSTR(_T("AdapterRAM")), 0, &varSize, 0, 0); if (hr == S_OK) { retSize = varSize.intVal / (1024 * 1024); if (retSize == 0) { retSize = 64; } } } if (retSize < 0) { return retSize = -retSize; } return abs(retSize); #endif } This makes auto setting system spec viable again before this fix it still worked but returned negative numbers so if your card had say 2 GB memory it would return -2048 instead of 2048 causing the detection to fail.
  5. revelator
    git clone github address and the m4 defines for using qgl_enforce.h is disabled in scons hence why i was a bit curious as to why it still gets included but yeah did not notice that include in qgl.h it seems to not exist in my unmodified vanilla checkout curious still its bad behaviour as pointed out and the best thing to do would be to kill it untill its dead i also suspect that it would interfer with the new version based on glew since the engine now uses the real gl names instead of the pointers so more work to be done i suspect.
  6. revelator
    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 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.
  7. revelator
    qgl_enforce.h is not used not even on linux its part of the broken gllog and was disabled by id (remnant of idtech 3), the qgl errors seems to be from some missing exports in the linux build hmm. Ill have a look at the ones you posted though im not on linux i might be able to fix them.
  8. revelator
    Ah yes r_framealloc had a hunch that might be the one pushing those huge allocations, was actually not the huge allocations themself that caused the leak see above. Only other engine i seen allocate this much memory was the old tenebrae quake engine which allocated 1 GB at start ouch, but then again it was the first quake1 engine with realtime lighting and bumpmaps so it makes sense.
  9. revelator
    Its an automatic garbadge collector for malloc and friends, mostly used in gcc's java backend. The benefit is that it tracks and if possible applies correction to malloc errors if an error occurs you get a small logfile with information about something being amiss, so it also eases hunting down those kind of problems. i did correct the leak in idlib thanks to this little tool was actually a small mistake where plain malloc was used in a function that needs 16 byte aligned malloc and same for free. The wrappers i wrote use GC as malloc if defined and system malloc if not, in case it puts to much overhead on the engine you can just undefine it but so far it seems to run fine with GC enabled all the time.
  10. revelator
    Comitted the GC wrapper interface to Heap.cpp in idlib changes are comitted on github as well.
  11. revelator
    Aye great work And ok i had a hunch you had a specific reason for putting the code where it is atm, i did do some testing with it in another place which still is before the call to RenderScene but placed into the normal shader loop but without the postprocess sorting, seems to work fine there also but it s a bit crude.
  12. revelator
    /* ================== Mem_Alloc16 ================== */ void *Mem_Alloc16(const int size) { if (!size) { return NULL; } if (!mem_heap) { const int paddedSize = (size + 15) & ~15; #ifdef CRASH_ON_STATIC_ALLOCATION *((int *)0x0) = 1; #endif return _aligned_malloc(paddedSize, 16); } void *mem = mem_heap->Allocate16(size); // make sure the memory is 16 byte aligned assert((((int)mem) & 15) == 0); return mem; } /* ================== Mem_Free16 ================== */ void Mem_Free16(void *ptr) { if (!ptr) { return; } if (!mem_heap) { #ifdef CRASH_ON_STATIC_ALLOCATION *((int *)0x0) = 1; #endif _aligned_free(ptr); return; } // make sure the memory is 16 byte aligned assert((((int)ptr) & 15) == 0); mem_heap->Free16(ptr); } Cant say what changes there might have been in the other engine but heres the fix for Mem_Alloc16 and Mem_Free16
  13. revelator
    That sure looks purty odd though that the particles fail in the subview ? maybe related to depthmasking, i noticed in your code part that you do the depth copy between the subview calls and guessed that you might have a reason for that or maybe just that it was convinient ?.
  14. revelator
    Boehm GC also has a leak detector and i used that to hunt down the leak, funny enough it was the malloc in Mem_Alloc16 after i changed it to use _aligned malloc there seems to be no leaks left Warning though enabling the leakdetector will slow the engine somewhat so only use it for debugging, GC will still print problems if they occur, these will be output to a text file with enginename.gc.log and only if problems occur so its safe to let it run in non debug mode.
  15. revelator
    Aye since its the only place malloc is really used besides 3rd party code, its also engine global so the garbadge collector has access to the entire source game dll's included
  16. revelator
    //=============================================================== // // Boehm GC Wrappers // //=============================================================== /* ================== GC_malloc_wrapper ================== */ ID_INLINE void *GC_malloc_wrapper(size_t required_bytes) { void *p; GC_INIT(); if ((p = (void *)GC_malloc_uncollectable(required_bytes)) == NULL) { return NULL; } return p; } /* ================== GC_free_wrapper ================== */ ID_INLINE void GC_free_wrapper(void *p) { if (p != NULL) { GC_free(p); } } /* ================== GC_aligned_malloc_wrapper Missing from Boehm GC ================== */ ID_INLINE void *GC_aligned_malloc_wrapper(size_t required_bytes, size_t alignment) { void *p1; // original block void **p2; // aligned block int offset = alignment - 1 + sizeof(void *); GC_INIT(); if ((p1 = (void *)GC_malloc_uncollectable(required_bytes + offset)) == NULL) { return NULL; } p2 = (void**)(((size_t)(p1) + offset) & ~(alignment - 1)); p2[-1] = p1; return p2; } /* ================== GC_aligned_malloc_wrapper Missing from Boehm GC ================== */ ID_INLINE void GC_aligned_free_wrapper(void *p) { if (p != NULL) { GC_free(((void**)p)[-1]); } } #define USE_GC_ALLOCATORS #ifdef USE_GC_ALLOCATORS #define GC_MALLOC_WRAPPER(x) GC_malloc_wrapper(x) #define GC_FREE_WRAPPER(x) GC_free_wrapper(x) #define GC_ALIGNED_MALLOC_WRAPPER(x, y) GC_aligned_malloc_wrapper(x, y) #define GC_ALIGNED_FREE_WRAPPER(x) GC_aligned_free_wrapper(x) #else #define GC_MALLOC_WRAPPER(x) malloc(x) #define GC_FREE_WRAPPER(x) free(x) #define GC_ALIGNED_MALLOC_WRAPPER(x, y) _aligned_malloc(x, y) #define GC_ALIGNED_FREE_WRAPPER(x) _aligned_free(x) #endif My current test code in case others might want to try it out, use GC_MALLOC_WRAPPER instead of malloc and GC_FREE_WRAPPER instead of free. the aligned versions are for Mem_Alloc16 and Mem_Free16 (which btw used unaligned malloc so duh).
  17. revelator
    Normally yes, it might not be a huge leak but its still worth checking out it could also be a leak in msvc's own malloc implementation since it uses this to prime the built in memory allocator in case the pointer is empty at start. I did notice it throwing a debugbreak in msize so it seems thats a good place to look.
  18. revelator
    Ok todays work included adding the Boehm garbadge collector to test for memory leaks, to my dismay i actually found that both vanilla darkmod and my own engine seems to leak memory from Mem_Alloc and Mem_Alloc16, Boehm GC unfortunatly could not tell me where in the code the leak is but i noticed that especially Mem_Allloc seems to run through some rather insane data ammounts (allocations of allmost 2 GB Oo) and it does warn about that this may lead to leaks. Bringing the load down could probably save some trouble, but first i need to find out where those large data allocations come from. I Have made code to disable GC if not needed but it does not seem to make the engine run worse and if i can figure out how to make it print the code location for debug calls it would be a nice tool to have (bit like a built in valgrind) .
  19. revelator
    Gonna call it a night its 4.18 in the morning here and im starting to feel like a night owl with these late night coding sessions So night folks
  20. revelator
    Ah ok i was wrong VBO's use GPU memory but can also use system memory if your gfx cards memory is not large enough to hold all the data. Soft shadows are extremely wastefull but should be a bit lighter on resources now that we have access to the engines depthbuffer. SSAO should not be a big resource waste, are you using sikkpins version from sikkmod ? asking because that version is from before we had access to the engines depthbuffer so he had to create a hack to get the depthimage and it was rather hard on resources. edit SSAO can also be a bit resource intensive it seems, but it seems downsampling the ssao image can get rid of a good portion of that allbeit with a bit lower quality of the occlusion factor. Also stumbled upon some new techniques to optimize SSAO called screen space ambient obscurance instead of screen space ambient occlusion. Theres a little info on the unity page http://docs.unity3d.com/Manual/script-SSAOEffect.html
  21. revelator
    r_useArbMapBufferRange can cause problems on some older AMD / ATI cards so good advise if you have one of those new FPS counter averages the FPS so you get the theoretical max FPS your card is capable of with certain effects enabled, also why it does not spike as much. with vsync enabled your card will only show up to and newer (mark newer) ever go above your monitors refresh rate which in most cases is 60 FPS, turn it off and get the unlimited result which can vary a lot but you might get tearing as a result. Not sure if CPU cost would be affected by the VBO code as these are done on the GPU not the CPU, only way to get CPU work down would be moving more of the old stuff to GPU. Read here on how VBO's work http://www.songho.ca/opengl/gl_vbo.html
  22. revelator
    command is the same as for whats different its a 64 bit precision version originally created by MH. Its a lot more accurate and it does not suffer from the wildly variating FPS values the original had.
  23. revelator
    Heres a built with the latest changes for testing http://sourceforge.net/projects/cbadvanced/files/gtkradiant/darkmod.20141115-015433.7z/download Try out the new FPS counter
  24. revelator
    Its a simple function if the darkmod guys want it in the main repository i could just post it here, its pretty much just a question of replacing 1 function with the new one. Also saves them digging through the source to find out where it is else i could upload a build with the new changes for you to test out.
  25. revelator
    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.
×
×
  • Create New...