Age | Commit message (Collapse) | Author |
|
Was annoying to use a different editor for cmake only.
theeth says this should be ok with gsoc and merges from branches.
|
|
* bring back 'player' libtype, after investigation with ideasman.
scons/mingw works nicely, for some reason msvc fails to link still, will look further into it.
|
|
* first working changes to get blenderplayer linking
* blenderplayer/ moved into source/ (CMakeLists.txt changed for that too)
* added externs for bprogname to gp_ghost, so that it links properly
|
|
-r18677:19317
Notes:
* Sequence transform strip uses G.scene global, this is commented
out now, should be fixed.
* Etch-a-ton code was most difficult to merge. The files already in
2.5 got merged, but no new files were added. Calls to these files
are commented out with "XXX etch-a-ton". editarmature.c and
transform_snap.c were complex to merge. Martin, please check?
* Game engine compiles and links again here for scons/make/cmake
(player still fails to link).
|
|
blackpoint, gamma, log.
Allow DPX's with different color channel types to load, even if they are unsupported.
Saving log DPX's is broken, the header will always be written with log off because dpxCreate is called before the image presets are set. However there is no access to image presets before running dpxCreate() so log data is written but the header always sets it off.
Made a fix for this but couldn't test because it seems loading log images is also broken.
Enable verbose DPX output when '-d' debug flag is used.
|
|
|
|
Think global, act local!
The old favorite G.scene gone! Man... that took almost 2 days.
Also removed G.curscreen and G.edbo.
Not everything could get solved; here's some notes.
- modifiers now store current scene in ModifierData. This is not
meant for permanent, but it can probably stick there until we
cleaned the anim system and depsgraph to cope better with
timing issues.
- Game engine G.scene should become an argument for staring it.
Didn't solve this yet.
- Texture nodes should get scene cfra, but the current implementation
is too tightly wrapped to do it easily.
|
|
New priorities for most libs, at least core. This is still for Blender proper, BGE and such still to come.
|
|
svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r12987:17416
Issues:
* GHOST/X11 had conflicting changes. Some code was added in 2.5, which was
later added in trunk also, but reverted partially, specifically revision
16683. I have left out this reversion in the 2.5 branch since I think it is
needed there.
http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=16683
* Scons had various conflicting changes, I decided to go with trunk version
for everything except priorities and some library renaming.
* In creator.c, there were various fixes and fixes for fixes related to the -w
-W and -p options. In 2.5 -w and -W is not coded yet, and -p is done
differently. Since this is changed so much, and I don't think those fixes
would be needed in 2.5, I've left them out.
* Also in creator.c: there was code for a python bugfix where the screen was not
initialized when running with -P. The code that initializes the screen there
I had to disable, that can't work in 2.5 anymore but left it commented as a
reminder.
Further I had to disable some new function calls. using src/ and python/, as
was done already in this branch, disabled function calls:
* bpath.c: error reporting
* BME_conversions.c: editmesh conversion functions.
* SHD_dynamic: disabled almost completely, there is no python/.
* KX_PythonInit.cpp and Ketsji/ build files: Mathutils is not there, disabled.
* text.c: clipboard copy call.
* object.c: OB_SUPPORT_MATERIAL.
* DerivedMesh.c and subsurf_ccg, stipple_quarttone.
Still to be done:
* Go over files and functions that were moved to a different location but could
still use changes that were done in trunk.
|
|
Playanim now works for:
- tiff, cineon, dpx, hdr, exr
Only multilayer not, that's too much for a bugfix. Multilayer is a totally
different image format, handled separately.
ALso removed redundant printing for dpx/cineon.
And fixed crash in cineon when G.scene doesnt exist. Bad bad, should
not be there!
|
|
|
|
|
|
since no additional crashes were reported!
|
|
This commit fix the following problem in the DPX code:
1) The code always assume a depth of 10 bits
2) The code don't check the file type (Log or Linear)
|
|
blocks that were previously missed; and b) greatly increase my
ohloh stats!
|
|
rendering from the sequencer because a float buffer can be generated for some frames but not others depending on their contents.
|
|
reference black, reference white and gamma.
Added 16 bit TIFF saving.
This needs more work to cleanup code and add 16 bit TIFF reading, but
committing it now so it can be tested.
|
|
* some lib renaming
|
|
|
|
Basically I moved -funsigned-char -fno-strict-aliasing
from individual Makefiles to nan_compile.mk defines for CFLAGS and CCFLAGS
Kent
|
|
*printf functions.
|
|
|
|
In my attempts to get cinepaint's cineon code to work with files in memory,
I accidently rewrote something that should have been left as it is. This
causes images whose image buffers didn't start right after the cineon header to
become "shifted" to the left.
The DPX code looks correct, though.
|
|
different platforms will follow soon. This was just tested against current CVS on MSVC 2005 with Verse, QuickTime, OpenEXR, Player all on.
|
|
- commiting fixes for vc8
- updating projects for added files
|
|
not be misconstrued as "working" by myself
|
|
Was missing test for it before turning it into unsigned short.
|
|
* first part of cineon fix commit - after next commit it'll compile also with SCons
|
|
too late... moved it one line up. :)
Still unknown; why doesn't HSV color field not redraw?
|
|
standard for film scanning, 10 bits/channel and logarithmic. DPX is
derived from Cineon as the ANSI/SMPTE industry standard.
DPX supports 16 bits color/channel, linear as well as logarithmic.
Code has been gratefully copied from CinePaint and was integrated in
Blender by Joe Eagar.
According to CinePaint's dev Robin Rowe the DPX code defaults to log
colorspace. Can't find in the code clues yet how to enable/disable that.
However, tests with write/read of DPX seems to show no visible loss by
log conversion code. Might be because it uses the entire 16 bit range...
CinePaint dpx files have been succesfully imported in a Quantel IQ HD/2K
finishing/grading set without problem, so for now I guess we can
use it! :)
Changes in code: added tests for image magic numbers before entering
the actual reading code. Prevents error prints, and makes it faster too.
(Note; this because Blender doesn't check for extensions, but calls
reading functions on every file until one accepts it. :)
|