* Big code cleanup and re-organisation, cleaner drawing
* Button alignment now enabled for default theme
* Sliders tweaked and improved
* Tooltip shadow cleaned up
Todo: Alignment looks pretty, but at this stage, what it *means* is not clear or consistent. Need to work out some UI guidelines for when to and when not to use the alignment code.
Summary: standardized imageformat functions(make function names similar, and
parameters in same order where relavant), small code cleanups, and
added a description of how to add an image format to blender.
Kent
Specifics:
merged png_decode.c and png_encode.c to png.c and cleaned function calls.
fixed some spacing in IMB_imbuf_types.h
casting cleanups:
intern/amiga.c
intern/ham.c
intern/iris.c
Modified switch statements to have a default type to insure values are set:
intern/antialias.c
Initalization of some vars and make types similar.
intern/bitplanes.c
cleaned function calls, and changed if else to if's with return:
intern/jpeg.c
added {}'s in multidemensional arrays.
intern/matrix.h
Made a little cleaner to read, and matched above changes.
intern/readimage.c
intern/writeimage.c
somehow this was mixed up, or forgotten to fix when endian issues were
solved in the past (1998)...
To check: red color should be 30% grey, blue 10%. This was switched,
making B&W images look unnatural.
error... Jesterking report helped me finding the mistake! We found out
that pressing F12 while rendering is in progress, crashes...
Hi Yamyam,
I beg you to forgive me! Totally misread the report... the error was only
in pressing F12 *during* rendering, it even restarts a render then. This
happens always, no matter what is being rendered.
I found the code for renderwindow doesn't use queues to store events, like
in the rest of Blender, but immediately executes incoming events. This
means you can even press ZKEY (zoom) or F11 (hide) while rendering.
In CVS I've committed a patch that checks if Blender renders, before
allowing to execute the F12 event. Also now blocked is F3 (!) during render.
The other options (zoom, push window) still work.
-Ton-
option "Area" in paint buttons set.
Apparently reevan forgot to check on some old vertexpaint globals
hanging around, preventing the routine from sampling the backbuffer.
Now weightpaint works identical to vertexpaint for 'area' or 'no area'.
previous fix for Transform Panel...
the convention that 3d window has to leave in 2d ortho mode also applies
on backbuffer now, which left painting routine confused.
A single call to persp(PERSP_VIEW) fixes this.
There's a bug left with local axis constraints, but it's only a minor annoyance and fixing it would take more time that I can give (finals at the U you know...)
Also deleted some vestige of an old feature that was disabled.
VertexPaint or FaceSelect mode on.
The error was caused by not resetting to 2d buttons matrix after drawing
the color codes for selection in backbuffer.
have been fixed now we know it.
pressing CTRL+1,2,3,4 was meant to set subdivision levels, but it read
the active pointer without it checking for NULL... tsk!
when removing header from buttons window, the previewrender didnt show
or crashes.
was caused by relying to an evil global pointer 'lockpoin' which was only
set in headerbuttons...
was too small to display the number in it (amount of vertices). Also the
range can be too large to make the slider display useful info.
direct reason: mesh with 1 vertex made the slider draw corrupt.
when you set halo, and star, then disable halo, the texface flag was set.
this is because both values use the same bit in the flag <blush>
solved by clearing the 'star' flag when you disable halo.
Not perfect, but at least it looks OK. :)
- no start 4 split anymore, split 3d win in 3rd screen instead
- print of name active object in 3d window
- added a theme in the file, for manual demo
- no scrub/sync set
- removed text files
- auto save on (per 5 minutes)
- no standard osa rendering
- and i might have forgotten some
All for getting a manual compatible version. but the 4 split in start for
2.30 release caused quite some annoyed reactions.
this is safe initialization only.
based at report from madprof.. he had a 2.30 file without this
data correctly initialized... but how it happens? tuhopuu files?
anyhoo, we might think of splitting do_versions in 2 parts:
1. do_versions initialization of old variables that changed
like physics properties that need to be scaled or so
2. do_init for newly created variables that are not allowed to be zero,
this can safely be done for each file
