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 2479d 5h terminx /polymer/eduke32/eduke32.vcxproj.filters Fix Mapster32 sector copying  
4749 2530d 2h terminx /polymer/eduke32/eduke32.vcxproj.filters WIP refactor of SDL interface. DONT_BUILD.  
4720 2550d 8h terminx /polymer/eduke32/eduke32.vcxproj.filters Remove references to nonexistent enet_mmulti.h from Visual Studio project. DONT_BUILD.  
4615 2583d 10h terminx /polymer/eduke32/eduke32.vcxproj.filters Add new headers to VS project  
4534 2669d 14h terminx /polymer/eduke32/eduke32.vcxproj.filters Add sdl_inc.h to VS project  
4387 2775d 5h 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 2775d 5h terminx /polymer/eduke32/eduke32.vcxproj.filters Some basic changes for Android support. DONT_BUILD.  
4316 2815d 3h hendricks266 /polymer/eduke32/eduke32.vcxproj.filters Replace QuickLZ with LZ4.  
4037 2984d 15h 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 2988d 16h 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 3069d 7h hendricks266 /polymer/eduke32/eduke32.vcxproj.filters Dynamicsoundremap.  
3762 3086d 12h terminx /polymer/eduke32/eduke32.vcxproj.filters Remove deleted md4 library related files from the Visual Studio project  
3758 3086d 12h terminx /polymer/eduke32/eduke32.vcxproj.filters WIP texture cache refactoring  
3298 3236d 10h 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 3265d 21h terminx /polymer/eduke32/eduke32.vcxproj.filters Remove the xdelta3 files from the VS2010 project, too  
3184 3266d 21h terminx /polymer/eduke32/eduke32.vcxproj.filters Add nedmalloc.h to the VS2010 project files  
3166 3267d 0h helixhorned /polymer/eduke32/eduke32.vcxproj.filters Split r3159..r3161, part 1: Makefile and MSVC project file changes.  
3165 3267d 0h 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 3267d 15h 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 3298d 14h 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