[Bf-committers] Some possible small problems with makesdna

André Pinto andresusanopinto at gmail.com
Thu Mar 27 23:44:41 CET 2008


Greetings
Sometime ago my blender (compiled from svn) started to act strange when
importing files..
The problem was that in rev 14202 the struct RenderData had an attribute
modified from short to int and the handling of files started to act
strangely.
I tried to find the problem.. and it turned out that a fresh compile would
solve the problem.


When trying to figure out what was going wrong I found some small/tiny
things that now I describe (in case you are interested):

1) source/blender/maksdna/dna.c isn't being updated correctly by
dependencies

2) When the attribute RenderData.scemode was modified from short to int..
there was some parts of the code that still assume it to be short

Index: source/blender/python/api2_2x/sceneRender.c
===================================================================
--- source/blender/python/api2_2x/sceneRender.c (revision 14264)
+++ source/blender/python/api2_2x/sceneRender.c (working copy)
@@ -2156,7 +2156,7 @@
                return EXPP_ReturnIntError( PyExc_ValueError,
                                "unexpected bits set in argument" );

-       self->renderContext->scemode = (short)value;
+       self->renderContext->scemode = value;
        EXPP_allqueue( REDRAWBUTSSCENE, 0 );

        return 0;


3)
I noticed that most bitsets in blender structs use a signed type
(short/int).
I think this might be a "problem" if they are later resized.
Since it becomes unpredictable to know how old data will be expanded.
I recall that in signed data types the MostSignificantBit will be expanded.

Its not a serious "problem" but maybe fields that are supposed to be bitsets
should be declared as unsigned and that make things more consistent.


//P.S.
I'm not sure if this is the right place to send this.. maybe it should go on
bugtracker (I'm not sure :S)

André
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20080327/4c14921e/attachment.htm 


More information about the Bf-committers mailing list