wejick / crunch Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/crunch
License: Other
Automatically exported from code.google.com/p/crunch
License: Other
crunch/crnlib v1.04 - Advanced DXTn texture compression library Copyright (C) 2010-2012 Rich Geldreich and Tenacious Software LLC For bugs or support contact Rich Geldreich <[email protected]>. This software uses the ZLIB license, which is located in license.txt. http://opensource.org/licenses/Zlib Portions of this software make use of public domain code originally written by Igor Pavlov (LZMA), RYG (crn_ryg_dxt*), and Sean Barrett (stb_image.c). If you use this software in a product, an acknowledgment in the product documentation would be highly appreciated but is not required. New for v1.04 [11/24/12]: KTX file format, basic ETC1 support, DDS format fixes, simple makefile ------------------------------------------------ Lots of higher level changes to get crnlib into a state where I can carry it forward to support other file and texture compression formats. No major codec-level changes. I've regression tested the codec writing .CRN and RDO .DDS files at various bitrates. Everything seems OK, but with all the changes I made to support KTX and other formats like ETC1 I'm still worried about bugs. New for v1.03 [4/26/12]: crnlib more portable, Linux Port ------------------------------------------------ v1.03 has been ported to Linux. It's still a work in progress. A few features of the command line tool don't work under Linux yet (such as -timestamp), but the core functionality (compression/decompression/transcoding) should work OK. I'm currently testing crnlib/crunch with Codeblocks 10.05 under Ubuntu x86. Overview -------- crnlib is a lossy texture compression library for developers that ship content using the DXT1/5/N or 3DC compressed color/normal map/cubemap mipmapped texture formats. It was written by the same author as the open source LZHAM lossless data compression library: http://code.google.com/p/lzham/ It can compress mipmapped 2D textures, normal maps, and cubemaps to approx. 1-1.25 bits/texel, and normal maps to 1.75-2 bits/texel. The actual bitrate depends on the complexity of the texture itself, the specified quality factor/target bitrate, and ultimately on the desired quality needed for a particular texture. crnlib's differs significantly from other approaches because its compressed texture data format was carefully designed to be quickly transcodable directly to DXTn with no intermediate recompression step. The typical (single threaded) transcode to DXTn rate is generally between 100-250 megatexels/sec. The current library supports PC (Win32/x64) and Xbox 360. Fast random access to individual mipmap levels is supported. crnlib can also generates standard .DDS files at specified quality setting, which results in files that are much more compressible by LZMA/Deflate/etc. compared to files generated by standard DXTn texture tools (see below). This feature allows easy integration into any engine or graphics library that already supports .DDS files. The .CRN file format supports the following core DXTn texture formats: DXT1 (but not DXT1A), DXT5, DXT5A, and DXN/3DC It also supports several popular swizzled variants (several are also supported by AMD's Compressonator): DXT5_XGBR, DXT5_xGxR, DXT5_AGBR, and DXT5_CCxY (experimental luma-chroma YCoCg). Recommended Software -------------------- AMD's Compressonator tool is recommended to view the .DDS files created by the crunch tool and the included example projects: http://developer.amd.com/gpu/compressonator/pages/default.aspx Note: Some of the swizzled DXTn .DDS output formats (such as DXT5_xGBR) read/written by the crunch tool or examples deviate from the DX9 DDS standard, so DXSDK tools such as DXTEX.EXE won't load them at all or they won't be properly displayed. Compression Algorithm Details ----------------------------- The compression process employed in creating both .CRN and clustered .DDS files utilizes a very high quality, scalable DXTn endpoint optimizer capable of processing any number of pixels (instead of the typical hard coded 16), optional adaptive switching between several macroblock sizes/configurations (currently any combination of 4x4, 8x4, 4x8, and 8x8 pixel blocks), endpoint clusterization using top-down cluster analysis, vector quantization (VQ) of the selector indices, and several custom algorithms for compressing the resulting endpoint/selector codebooks and macroblock indices. Multiple feedback passes are performed between the clusterization and VQ steps to optimize quality, and several steps use a brute force refinement approach to improve quality. The majority of compression steps are multithreaded. The .CRN format currently utilizes canonical Huffman coding for speed (similar to Deflate but with much larger tables), but the next major version will also utilize adaptive binary arithmetic coding and higher order context modeling using already developed tech from the my LZHAM compression library. Supported File Formats ---------------------- crnlib supports two compressed texture file formats. The first format (clustered .DDS) is simple to integrate into an existing project (typically, no code changes are required), but it doesn't offer the highest quality/compression ratio that crnlib is capable of. Integrating the second, higher quality custom format (.CRN) requires a few typically straightforward engine modifications to integrate the .CRN->DXTn transcoder header file library into your tools/engine. .DDS crnlib can compress textures to standard DX9-style .DDS files using clustered DXTn compression, which is a subset of the approach used to create .CRN files.(For completeness, crnlib also supports vanilla, block by block DXTn compression too, but that's not very interesting.) Clustered DXTn compressed .DDS files are much more compressible than files created by other libraries/tools. Apart from increased compressibility, the .DDS files generated by this process are completely standard so they should be fairly easy to add to a project with little to no code changes. To actually benefit from clustered DXTn .DDS files, your engine needs to further losslessly compress the .DDS data generated by crnlib using a lossless codec such as zlib, lzo, LZMA, LZHAM, etc. Most likely, your engine does this already. (If not, you definitely should because DXTn compressed textures generally contain a large amount of highly redundant data.) Clustered .DDS files are intended to be the simplest/fastest way to integrate crnlib's tech into a project. .CRN The second, better, option is to compress your textures to .CRN files using crnlib. To read the resulting .CRN data, you must add the .CRN transcoder library (located in the included single file, stand-alone header file library inc/crn_decomp.h) into your application. .CRN files provide noticeably higher quality at the same effective bitrate compared to clustered DXTn compressed .DDS files. Also, .CRN files don't require further lossless compression because they're already highly compressed. .CRN files are a bit more difficult/risky to integrate into a project, but the resulting compression ratio and quality is superior vs. clustered .DDS files. .KTX crnlib and crunch can read/write the .KTX file format in various pixel formats. Rate distortion optimization (clustered DXTc compression) is not yet supported when writing .KTX files. The .KTX file format is just like .DDS, except it's a fairly well specified standard created by the Khronos Group. Unfortunately, almost all of the tools I've found that support .KTX are fairly (to very) buggy, or are limited to only a handful of pixel formats, so there's no guarantee that the .KTX files written by crnlib can be reliably read by other tools. Building the Examples --------------------- This release contains the source code and projects for three simple example projects: crn_examples.2008.sln is a Visual Studio 2008 (VC9) solution file containing projects for Win32 and x64. crnlib itself also builds with VS2005, VS2010, and gcc 4.5.0 (TDM GCC+MinGW). A codeblocks 10.05 workspace and project file is also included, but compiling crnlib this way hasn't been tested much. example1: Demonstrates how to use crnlib's high-level C-helper compression/decompression/transcoding functions in inc/crnlib.h. It's a fairly complete example of crnlib's functionality. example2: Shows how to transcodec .CRN files to .DDS using *only* the functionality in inc/crn_decomp.h. It does not link against against crnlib.lib or depend on it in any way. (Note: The complete source code, approx. 4800 lines, to the CRN transcoder is included in inc/crn_decomp.h.) example2 is intended to show how simple it is to integrate CRN textures into your application. example3: Shows how to use the regular, low-level DXTn block compressor functions in inc/crnlib.h. This functionality is included for completeness. (Your engine or toolchain most likely already has its own DXTn compressor. crnlib's compressor is typically very competitive or superior to most available closed and open source CPU-based compressors.) Creating Compressed Textures from the Command Line (crunch.exe) --------------------------------------------------------------- The simplest way to create compressed textures using crnlib is to integrate the bin\crunch.exe or bin\crunch_x64.exe) command line tool into your texture build toolchain or export process. It can write DXTn compressed 2D/cubemap textures to regular DXTn compressed .DDS, clustered (or reduced entropy) DXTn compressed .DDS, or .CRN files. It can also transcode or decompress files to several standard image formats, such as TGA or BMP. Run crunch.exe with no options for help. The .CRN files created by crunch.exe can be efficiently transcoded to DXTn using the included CRN transcoding library, located in full source form under inc/crn_decomp.h. Here are a few example crunch.exe command lines: 1. Compress blah.tga to blah.dds using normal DXT1 compression: crunch -file blah.tga -fileformat dds -dxt1 2. Compress blah.tga to blah.dds using clustered DXT1 at an effective bitrate of 1.5 bits/texel, display image statistic: crunch -file blah.tga -fileformat dds -dxt1 -bitrate 1.5 -imagestats 3. Compress blah.tga to blah.dds using clustered DXT1 at quality level 100 (from [0,255]), with no mipmaps, display LZMA statistics: crunch -file blah.tga -fileformat dds -dxt1 -quality 100 -mipmode none -lzmastats 3. Compress blah.tga to blah.crn using clustered DXT1 at a bitrate of 1.2 bits/texel, no mipmaps: crunch -file blah.tga -dxt1 -bitrate 1.2 -mipmode none 4. Decompress blah.dds to a .tga file: crunch -file blah.dds -fileformat tga 5. Transcode blah.crn to a .dds file: crunch -file blah.crn 6. Decompress blah.crn, writing each mipmap level to a separate .tga file: crunch -split -file blah.crn -fileformat tga crunch.exe can do a lot more, like rescale/crop images before compression, convert images from one file format to another, compare images, process multiple images, etc. Note: I would have included the full source to crunch.exe, but it still has some low-level dependencies to crnlib internals which I didn't have time to address. This version of crunch.exe has some reduced functionality compared to an earlier eval release. For example, XML file support is not included in this version. Using crnlib ------------ The most flexible and powerful way of using crnlib is to integrate the library into your editor/toolchain/etc. and directly supply it your raw/source texture bits. See the C-style API's and comments in inc/crnlib.h. To compress, you basically fill in a few structs in and call one function: void *crn_compress(const crn_comp_params &comp_params, crn_uint32 &compressed_size, crn_uint32 *pActual_quality_level = NULL, float *pActual_bitrate = NULL); Or, if you want crnlib to also generate mipmaps, you call this function: void *crn_compress(const crn_comp_params &comp_params, const crn_mipmap_params &mip_params, crn_uint32 &compressed_size, crn_uint32 *pActual_quality_level = NULL, float *pActual_bitrate = NULL); You can also transcode/uncompress .DDS/.CRN files to raw 32bpp images using crn_decompress_crn_to_dds() and crn_decompress_dds_to_images(). Internally, crnlib just uses inc/crn_decomp.h to transcode textures to DXTn. If you only need to transcode .CRN format files to raw DXTn bits at runtime (and not compress), you don't actually need to compile or link against crnlib at all. Just include inc/crn_decomp.h, which contains a completely self-contained CRN transcoder in the "crnd" namespace. The crnd_get_texture_info(), crnd_unpack_begin(), crnd_unpack_level(), etc. functions are all you need to efficiently get at the raw DXTn bits, which can be directly supplied to whatever API or GPU you're using. (See example2.) Important note: When compiling under native client, be sure to define the PLATFORM_NACL macro before including the inc/crn_decomp.h header file library. Known Issues/Bugs ----------------- * crnlib currently assumes you'll be further losslessly compressing its output .DDS files using LZMA. However, some engines use weaker codecs such as LZO, zlib, or custom codecs, so crnlib's bitrate measurements will be inaccurate. It should be easy to allow the caller to plug-in custom lossless compressors for bitrate measurement. * Compressing to a desired bitrate can be time consuming, especially when processing large (2k or 4k) images to the .CRN format. There are several high-level optimizations employed when compressing to clustered DXTn .DDS files using multiple trials, but not so for .CRN. * The .CRN compressor does not currently use 3 color (transparent) DXT1 blocks at all, only 4 color blocks. So it doesn't support DXT1A transparency, and its output quality suffers a little due to this limitation. (Note that the clustered DXTn compressor used when writing clustered .DDS files does *not* have this limitation.) * Clustered DXT5/DXT5A compressor is able to group DXT5A blocks into clusters only if they use absolute (black/white) selector indices. This hurts performance at very low bitrates, because too many bits are effectively given to alpha. * DXT3 is not supported when writing .CRN or clustered DXTn DDS files. (DXT3 is supported by crnlib's when compressing to regular DXTn DDS files.) You'll get DXT5 files if you request DXT3. However, DXT3 is supported by the regular DXTn block compressor. (DXT3's 4bpp fixed alpha sucks verses DXT5 alpha blocks, so I don't see this as a bug deal.) * The DXT5_CCXY format uses a simple YCoCg encoding that is workable but hasn't been tuned for max. quality yet. * Clustered (or rate distortion optimized) DXTc compression is only supported when writing to .DDS, not .KTX. Also, only plain block by block compression is supported when writing to ETC1, and .CRN does not support ETC1.
Running the following:
crunch -file btn_colony.dds -fileformat dds -A8R8G8B8 -out test.dds -mipMode
None
on the attached file results in the following error:
crunch: Advanced DXTn Texture Compressor - http://code.google.com/p/crunch
Copyright (c) 2010-2012 Rich Geldreich and Tenacious Software LLC
crnlib version v1.01 x86 Built Apr 15 2012, 18:14:02
Reading source texture: "btn_colony.dds"
Error: Failed reading source file: "btn_colony.dds"
Original issue reported on code.google.com by [email protected]
on 25 Jul 2012 at 6:55
Attachments:
error LNK2005: "bool __cdecl crnd::crnd_validate_file(void const *,unsigned
int,struct crnd::crn_file_info *)"
(?crnd_validate_file@crnd@@YA_NPBXIPAUcrn_file_info@1@@Z) already defined
error LNK2005: "bool __cdecl crnd::crnd_get_texture_info(void const *,unsigned
int,struct crnd::crn_texture_info *)"
(?crnd_get_texture_info@crnd@@YA_NPBXIPAUcrn_texture_info@1@@Z) already defined
and more more more
if I include this file in many cpp
Original issue reported on code.google.com by [email protected]
on 30 Apr 2014 at 12:48
I noticed that in inc/dds_defs.h the sizeof structure DDSURFACEDESC2 is 124
bytes, by calculating that with sizeof(). However, in my DDS tests, where I try
to load a single DDS file, I see a DDS header length of 120 bytes, which does
not match the above mentioned structure.
My loader works, if I calculate fileoffsets with 120 bytes, instead of the
mentioned 124 bytes. Hence, the question is, is the definition of
DDSURFACEDESC2 correct, or should it be instead 120 bytes?
A sample DDS attached in this issue, what I used for testing.
Original issue reported on code.google.com by [email protected]
on 7 Aug 2012 at 11:24
Attachments:
What steps will reproduce the problem?
1. Run crunch_x64.exe /file a.png /out a_x64.crn /quality 255 /mipMode None
/DXT5 /quiet
on attached image
2. crunch.exe /file a.png /out a_x86.crn /quality 255 /mipMode None /DXT5 /quiet
3.
What is the expected output? What do you see instead?
a_x86.crn must be equal to a_x64.crn but it is not. Also a_x64.crn contains a
lot of artifacts but a_x86.crn not.
What version of the product are you using? On what operating system?
the latest trunk version
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 26 Feb 2015 at 1:03
I made a Makefile to build on Linux (meant to be put in /crnlib dir). Attached,
I hope it's useful.
Original issue reported on code.google.com by [email protected]
on 17 Jun 2012 at 12:32
Attachments:
With this and my other patches, particularly issue #13 (on which this has a
hard dependency), it's possible to compile and run crunch on, for example, ARM.
I've had it running, albeit slowly, on my Raspberry Pi.
Original issue reported on code.google.com by [email protected]
on 25 Jan 2013 at 4:11
What steps will reproduce the problem?
1. I have downloaded the latest version (April 2012) and the Makefile of
http://code.google.com/p/crunch/issues/detail?id=1.
2. I went to the crnlib folder and I started make.
What is the expected output? What do you see instead?
It injured me with that words :
julien@julien-H61M-D2H-USB3:~/lib/crunch/crnlib$ make
g++ crn_arealist.cpp -o crn_arealist.o -c
In file included from crn_core.h:90:0,
from crn_arealist.cpp:4:
crn_types.h:15:31: erreur: expected initializer before ‘uint64’
crn_types.h:16:31: erreur: expected initializer before ‘int64’
crn_types.h:24:10: erreur: ‘uint64’ does not name a type
crn_types.h:25:10: erreur: ‘uint64’ does not name a type
crn_types.h:33:10: erreur: ‘int64’ does not name a type
crn_types.h:34:10: erreur: ‘int64’ does not name a type
In file included from crn_core.h:92:0,
from crn_arealist.cpp:4:
crn_traits.h:46:4: erreur: ‘__int64’ was not declared in this scope
crn_traits.h:46:4: erreur: patron de l'argument 1 est invalide
crn_traits.h:47:4: erreur: patron de l'argument 1 est invalide
In file included from crn_core.h:93:0,
from crn_arealist.cpp:4:
crn_mem.h: In function ‘T* crnlib::crnlib_new_array(crnlib::uint32)’:
crn_mem.h:132:7: erreur: ‘uint64’ was not declared in this scope
crn_mem.h:132:14: erreur: expected ‘;’ before ‘total’
crn_mem.h:133:11: erreur: ‘total’ was not declared in this scope
crn_mem.h:138:72: erreur: ‘total’ was not declared in this scope
In file included from crn_core.h:94:0,
from crn_arealist.cpp:4:
crn_math.h: At global scope:
crn_math.h:60:33: erreur: ‘crnlib::math::is_power_of_2’ declared as an
‘inline’ variable
crn_math.h:60:33: erreur: ‘bool crnlib::math::is_power_of_2’ redeclared as
different kind of symbol
crn_math.h:59:19: erreur: previous declaration of ‘bool
crnlib::math::is_power_of_2(crnlib::uint32)’
crn_math.h:60:33: erreur: ‘uint64’ was not declared in this scope
crn_math.h:95:14: erreur: ‘uint64’ does not name a type
crn_math.h:206:14: erreur: ‘uint64’ does not name a type
In file included from crn_core.h:95:0,
from crn_arealist.cpp:4:
crn_utils.h:134:29: erreur: ‘crnlib::utils::write_val’ declared as an
‘inline’ variable
crn_utils.h:134:29: erreur: ‘bool crnlib::utils::write_val’ redeclared as
different kind of symbol
crn_utils.h:133:19: erreur: previous declaration of ‘bool
crnlib::utils::write_val(int, void*&, crnlib::uint&, bool)’
crn_utils.h:134:29: erreur: ‘uint64’ was not declared in this scope
crn_utils.h:134:41: erreur: expected primary-expression before ‘void’
crn_utils.h:134:58: erreur: expected primary-expression before ‘&’ token
crn_utils.h:134:60: erreur: ‘buf_size’ was not declared in this scope
crn_utils.h:134:70: erreur: expected primary-expression before ‘bool’
In file included from crn_core.h:98:0,
from crn_arealist.cpp:4:
crn_win32_timer.h:7:12: erreur: ‘uint64’ does not name a type
crn_win32_timer.h:13:25: erreur: expected ‘)’ before ‘start_ticks’
crn_win32_timer.h:16:18: erreur: ‘timer_ticks’ has not been declared
crn_win32_timer.h:21:7: erreur: ‘uint64’ does not name a type
crn_win32_timer.h:24:14: erreur: ‘timer_ticks’ does not name a type
crn_win32_timer.h:25:14: erreur: ‘timer_ticks’ does not name a type
crn_win32_timer.h:26:35: erreur: ‘timer_ticks’ has not been declared
crn_win32_timer.h:29:14: erreur: ‘uint64’ does not name a type
crn_win32_timer.h:30:14: erreur: ‘uint64’ does not name a type
crn_win32_timer.h:33:7: erreur: ‘uint64’ does not name a type
crn_win32_timer.h:34:7: erreur: ‘uint64’ does not name a type
In file included from crn_core.h:101:0,
from crn_arealist.cpp:4:
crn_dynamic_wstring.h: In destructor
‘crnlib::dynamic_wstring::~dynamic_wstring()’:
crn_dynamic_wstring.h:23:35: erreur: invalid application of ‘sizeof’ to
incomplete type ‘crnlib_assume_failure’
crn_dynamic_wstring.h:23:35: erreur: patron de l'argument 1 est invalide
crn_dynamic_wstring.h:23:83: erreur: invalid type in declaration before ‘;’
token
crn_arealist.cpp: In function ‘void crnlib::area_fatal_error(const char*,
const char*, ...)’:
crn_arealist.cpp:23:46: erreur: ‘_vsnprintf’ was not declared in this scope
make: *** [crn_arealist.o] Erreur 1
What version of the product are you using? On what operating system?
Latest version of crunch (April 2012)
Ubuntu 12.04 32bits
Please provide any additional information below.
Latest version of gcc
Original issue reported on code.google.com by [email protected]
on 3 Nov 2012 at 8:05
I was using crnlib SVN rev 319 for a game jam project
https://github.com/David20321/JamForLeelah and ran into some small issues
compiling a program using crn_decomp.h on Mac OS 10.7.5.
I just had to add some standard library includes: in crn_decomp.h I added
<string.h> for memset and memcpy, and I used dlmalloc.c to get
'malloc_usable_size', since it is apparently not part of the Mac malloc.h. In
crnlib.h I added <stddef.h> to get a definition for NULL. Also as mentioned in
other issues, __is_pod doesn't work with some compilers, so I just defined it
to false.
I have attached a patch file with all the changes I made make it work, but
ideally small parts of the code could be rewritten to not rely on
malloc_usable_size() or __is_pod(), since they are not reliable across
platforms and compilers.
Original issue reported on code.google.com by [email protected]
on 25 Feb 2015 at 11:04
Attachments:
How to do a realtime compression to a DXT1 crn?
Thanks in advance,
Arthur
Original issue reported on code.google.com by [email protected]
on 7 Oct 2012 at 4:43
See patches for details. (Names should be descriptive enough.)
Original issue reported on code.google.com by [email protected]
on 25 Jan 2013 at 4:03
Attachments:
I tried to use relscale option as printed on help option, but crunch didn't
recognize this option.
After digging on the crunch.cpp I found out that the option available is
relrescale not relscale as printed at line 118.
Original issue reported on code.google.com by [email protected]
on 18 Jun 2015 at 4:32
Header dependency tracking, cleaner output.
Original issue reported on code.google.com by [email protected]
on 25 Jan 2013 at 4:01
Attachments:
I would find it very useful if stitching capabilities were added to the crunchD
commandline tool.
With stitching it would be possible to use multiple separate images as manually
generated mipmaps. This is much like what the "stitch" tool from the NVidia DDS
commandline utilities allowed.
As an additional feature request it would be nice if stitching was also
possible for individual channels (R,G,B and A). The idea is that one can build
a texture using channels input from separate greyscale images. This is useful
in cases where the contents of a texture channel should be interpreted
differently (eg. when the alpha channel contains specularity information)
Original issue reported on code.google.com by [email protected]
on 23 Aug 2012 at 3:21
Not really correct on amd64, and breaks things nicely on non-x86.
Original issue reported on code.google.com by [email protected]
on 25 Jan 2013 at 4:05
Attachments:
What steps will reproduce the problem?
1.using makefile downloaded from issues
2.alejandro@desktop:~/crunch-src/crnlib$ make
What is the expected output? What do you see instead?
expected output: linux binary
real output:
alejandro@desktop:~/crunch-src/crnlib$ make
g++ crn_decomp.cpp -o crn_decomp.o -c
In file included from crn_decomp.cpp:6:
../inc/crn_decomp.h: In function ‘void* crnd::crnd_realloc(void*, size_t,
size_t*, bool)’:
../inc/crn_decomp.h:2535: error: cast from ‘void*’ to ‘crnd::ptr_bits’
loses precision
../inc/crn_decomp.h: In function ‘void crnd::crnd_free(void*)’:
../inc/crn_decomp.h:2563: error: cast from ‘void*’ to ‘crnd::ptr_bits’
loses precision
../inc/crn_decomp.h: In function ‘size_t crnd::crnd_msize(void*)’:
../inc/crn_decomp.h:2577: error: cast from ‘void*’ to ‘crnd::ptr_bits’
loses precision
make: *** [crn_decomp.o] Error 1
What version of the product are you using? On what operating system?
last crunch source. OS: linux debian squeeze amd64
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 15 Aug 2012 at 12:46
Here's a patch to fix the compilation on a linux 64bits system. I've compared
the 32 and 64 bits files produced and they have same size. Also, the dds image
looks exactly the same. However, there are some bytes that differ but doesn't
seem to be a major issue though.
Original issue reported on code.google.com by [email protected]
on 3 Dec 2012 at 4:59
To preface this, I rarely write C++ so please review this patch carefully :) I
tested on OSX Lion and checked the build on my CentOS 5.5 box, unfortunately I
don't have a Windows box to test with.
To get this building on OSX a few changes needed to be made due to gcc 4.7's
strictness and OSX's lack of support for some of the pthread functionality.
Also to note, I was using the previously posted Makefile for building.
The highlights of this patch are:
- Converted from unnamed semaphores to named semaphores (OSX doesn't support unnamed).
- Converted sem_timedwait to an alert + sem_wait (sem_timedwait isn't supported on OSX).
- Added a shim for pthread_spinlock (doesn't exist on OSX) that calls into native functions.
- Defined uint64 as unsigned long and int64 as long to get rid of ambiguity errors on OSX.
- Updated function calls in crn_sparse_array to work with gcc 4.7.2's new two-phase lookup rules.
Original issue reported on code.google.com by [email protected]
on 3 Nov 2012 at 8:48
Attachments:
What steps will reproduce the problem?
1. Compile crnlib using GCC 4.2 or Apple LLVM 4.1 (the compilers included with
XCode 4.5.2)
What is the expected output? What do you see instead?
Ideally it would compile without errors, but instead I see errors in
crn_vector.h saying "'T' does not refer to a value" using Apple LLVM 4.1, or
"There are no arguments to '__is_pod' that depend on a template parameter, so a
declaration of '__is_pod' must be available"
What version of the product are you using? On what operating system?
I am using Crunch SVN revision 319 on Mac OS 10.7.5
Please provide any additional information below.
It sounds like boost::type_traits wraps __is_pod in some compiler checks to
find a compatible version, though you probably don't want to add a boost
dependency.
Original issue reported on code.google.com by [email protected]
on 28 Jan 2013 at 8:39
What steps will reproduce the problem?
1. run crunch with this syntax:
alejandro@desktop:~/X-Plane/X-Plane_10$
/mnt/server/xplane/proyects/pol_editor/src-1.2/crunch -file
/home/alejandro/t.png -fileformat dds -dxt3 -mipmode Generate -outdir
/home/alejandro/
What is the expected output? What do you see instead?
expected output: /home/alejandro/t.dds
real output: /home/alejandro/\t.dds
What version of the product are you using? On what operating system?
v1.03 Prerelease - Apr. 26, 2012
OS: Linux debian squeeze amd64
Please provide any additional information below.
Original issue reported on code.google.com by [email protected]
on 15 Aug 2012 at 12:25
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.