Does the spherical coordinates for normal mapping work? Do you have to do point sampling?
Not saying it doesn't work, cause I haven't tried it, but wouldn't bi linear interpolation cause some odd artifacts, since it would take the long route around the sphere if say you had coordinate -1 next to coordinate 1.
Full Build Times Debug:
1) 24.65 1) 12.47
2) 25.16 2) 12.11
3) 24.80 3) 11.76
Full rebuilds are much faster under header only, and this is with /MP(multithreaded builds) enabled(8 cores) which favors having extra .cpp to split up the work
Partial Rebuild Release:
1)16.18 <-- changed 1 line in 1 cpp
2)25.81 <-- changed 1 line in random .h
3) 13.66 <--- changed 1 line in a different cpp
Can't do partial rebuilds with header only, but full rebuilds with header only are comparable to partial rebuilds with CPP's time wise. Partial rebuilds heavily depend on exactly what was changed
Partial Rebuild Debug
1) 19.06 <-- changed random header by 1 line
2) 3.32 <-- changed a line in 1 cpp
3) 16.62 <-- changed a line in another random .h
The code was all originally written using .cpp/.h combo as traditional C++. To switch to header only I just copied the contents of each .cpp under the contents of the .h and then removed the .cpp from the project.
After I had finished this I only had one compiler error which resulted from two objects which both made use of each other. One by value and one by reference.
I fixed this by splitting the class which used the other by reference into two headers, the .h as it had already existed, and contents of its .cpp moved into a .hpp and included in a header called "circular.hpp" which is then included in the one and only .cpp(main.cpp).
+ could probably also just rename all .cpp to .hpp and add them to circular.hpp or some such which is included in main.cpp, but this keeps those extra files around...
I had expected it to decrease the size of the .exe(or at least change it) since I've heard of other people doing similar things to create more optimized builds, and of course people crying about template bloat. That didn't happen though.
Built times are better in many cases, slower in others. I could see the header only approach not working so well with a giant project as it pretty much results in constant time builds which grow linearly with the # of files.
Of course changing a header in a giant C++ project can result in a nightmare rebuild...
Perhaps the best way would be header only, but split into multiple projects, so that not everything must always be remade?
Overall Header Only:
+faster worst case build times(changing a header)
+simpler build process
+can place code right in the class itself, like in most modern languages
+less files to deal with
+less worrying about forward declaring to avoid excess header includes and PIMPL pattern
+only one translation unit so warnings/errors in headers are seen once(less spam)
+can write functions in header without being forced to "inline" them (normally this results in multiple definitions error but with only one translation unit, no such problem)
+on older compilers that don't have link time code gen, should be more optimal?
-best case build times are slower(changing cpp)
-might not scale too well? not sure here, might be easy to work around this with multiple projects
I think I am going to start doing this with all of my code, and port my existing code over to this approach..
Does anyone have any experience with this, or know of any problems I missed with this approach?
Not sure how much I believe that comment. I've downloaded and tested various so-called fast allocators(Nedmalloc etc.) claiming that they outperform microsofts, and every time I actually tested it, the MS allocator was the fastest.
The OS seemed to matter somewhat here, as MS allocator under XP didn't always win, but under Vista/Windows 7 it fairly well destroyed the others(I believe the default under Vista+ is low frag).