Subversion Repositories eduke32


Go to most recent revision | Show changed files | Details | Compare with Previous | Blame | RSS feed

Filtering Options

Rev Age Author Path Log message Diff
4909 2385d 11h terminx /polymer/eduke32/eduke32.vcxproj.filters Fix Mapster32 sector copying  
4749 2436d 7h terminx /polymer/eduke32/eduke32.vcxproj.filters WIP refactor of SDL interface. DONT_BUILD.  
4720 2456d 14h terminx /polymer/eduke32/eduke32.vcxproj.filters Remove references to nonexistent enet_mmulti.h from Visual Studio project. DONT_BUILD.  
4615 2489d 15h terminx /polymer/eduke32/eduke32.vcxproj.filters Add new headers to VS project  
4534 2575d 19h terminx /polymer/eduke32/eduke32.vcxproj.filters Add sdl_inc.h to VS project  
4387 2681d 10h terminx /polymer/eduke32/eduke32.vcxproj.filters Add xxHash (, a faster alternative to CRC32, and implement it in a few places. This is around 20-30% faster than CRC32 for me (it's also implemented into the "fileinfo" console command, so you can test for yourselves). I didn't have time to gather up all of the files supported by the startup window so this isn't used there yet. Additionally, this is by the same author as the LZ4 compression library we already use.  
4386 2681d 10h terminx /polymer/eduke32/eduke32.vcxproj.filters Some basic changes for Android support. DONT_BUILD.  
4316 2721d 9h hendricks266 /polymer/eduke32/eduke32.vcxproj.filters Replace QuickLZ with LZ4.  
4037 2890d 21h terminx /polymer/eduke32/eduke32.vcxproj.filters Add Lunatic stuff to the Visual Studio project. This is just the file view in the IDE, not Lunatic compilation with MSVC! DONT_BUILD.  
4027 2894d 22h terminx /polymer/eduke32/eduke32.vcxproj.filters Rip out all traces of nedmalloc. Sorry, XP users--it's time to upgrade to something newer than an OS from 2001 if this affects you.  
3834 2975d 13h hendricks266 /polymer/eduke32/eduke32.vcxproj.filters Dynamicsoundremap.  
3762 2992d 17h terminx /polymer/eduke32/eduke32.vcxproj.filters Remove deleted md4 library related files from the Visual Studio project  
3758 2992d 17h terminx /polymer/eduke32/eduke32.vcxproj.filters WIP texture cache refactoring  
3298 3142d 15h terminx /polymer/eduke32/eduke32.vcxproj.filters Sort some of the more recently added source and header files so they're in the right sections in the VS2010 project  
3194 3172d 3h terminx /polymer/eduke32/eduke32.vcxproj.filters Remove the xdelta3 files from the VS2010 project, too  
3184 3173d 3h terminx /polymer/eduke32/eduke32.vcxproj.filters Add nedmalloc.h to the VS2010 project files  
3166 3173d 5h helixhorned /polymer/eduke32/eduke32.vcxproj.filters Split r3159..r3161, part 1: Makefile and MSVC project file changes.  
3165 3173d 5h helixhorned /polymer/eduke32/eduke32.vcxproj.filters Revert "Fix the warnings when building with C++, add MSVC C++ build support."

This reverts r3159..r3161.

(Handled so that r3163's changes are kept applied.)
3159 3173d 20h terminx /polymer/eduke32/eduke32.vcxproj.filters Fix the warnings when building with C++, add MSVC C++ build support. This also changes the internal type of lotags, hitags and cstat type fields to uint16_t instead of int16_t to clean up some dubious behavior wherein the code was using a value of 32768 as a flag in these fields for certain types of things, like invisible sprites (using the value as if it was uint16_t) where it was elsewhere checking if the value was < 0 (using the value as if it was int16_t). This change may break a few specific effects if any part of the relevant code was missed when looking for areas that needed to be addressed.

I think there's also a fix for the CON precache system breakage in here (lost it in my local tree when I started getting the C++ build working in MSVC, sorry!)
3086 3204d 19h terminx /polymer/eduke32/eduke32.vcxproj.filters Remove built-in copy of nedmalloc and update nedmalloc.dll. Note that the built-in copy of nedmalloc hasn't been updated or enabled in a really long time as modern system allocators (Windows 7 and Linux 3.x at least) are no longer consistently beat by nedmalloc (but nor are they consistently faster). So, the dll remains for users of Windows XP because it may still improve performance there (while not likely degrading it on Vista/7).  

Show All