[Soc-2010-dev] Status Report (GE API)

[neXyon]

> Hi Joerg,
>    

Hi Dalai!

> What version of blender/svn are you testing YoFrankie with?
> I just tested with your updated yofrankie branch + blendersvn and
> still runs pretty bad here (Frankie doesn't land, it doesn't find the
> level files in my computer, and some missing logic bricks [1]). I
> tried to test with your branch but there is an error on CMake that
> stop me from building on linux (maybe a svn merge with trunk could
> bring the fix for that).
>    

My branch is out of date and it just got merges from trunk. I'm waiting 
for theeth to recreate the branch so that I can start blender 
development clean, so I'm using trunk at the moment. The fix for frankie 
not being able to run hasn't been committed yet, will do that when I 
start working on blender in the clean branch.

Apart from that I know about three bugs at the time of writing:

1) There are problems with the animations being loaded on file 
transitions (eg. stub => menu or menu => level), that's the reason why 
frankie doesn't seem to land for you. He does, but the animation doesn't 
run. If you load the file and start it directly, you have no problems.
2) Level scripts. Scripts that are in blend files are not working yet, 
because I haven't ported them yet, already talked to Campbell what to do.
3) (minor) If frankie carries something, the walking animation is not 
played.

I haven't had a closer look at the menu yet, so didn't know about the 
missing bricks yet, but when I tried the menu file I also saw that the 
bird was missing. Let's call the menu problems bug number 4 I know of. ;-)

What do you mean by not finding the level files? Is there an error when 
you run into the level sign, or what happens? I have no problems there.

> Also:
> rev. 103: Changed all degrees to radians.
> I understand that the hardcoded radians angles is intended for
> performance reason, but is this really necessary?
> I would expect the compiled class (.pyc) to pre-convert things such as
> math.radians(90.0) or math.pi * 0.5 to the final value.
>    

Python doesn't do constant folding, so it does not pre-convert this. I 
asked Campbell here on what to do before changing those things and the 
advantage of using the hardcoded radians is apart from the (minor) 
performance gain, that we don't have to import math. And it's the least 
change to the code, as constants just got converted to other (less 
readable, that's what the comments are for, but still) constants.

> By the way, is there a way to integrate gsoc's yofrankie branch
> commits with blender-cvs mailing list?
>    

Campbell said there's a seperate mailing list, but there's a server 
problem an admin has to look into, he will forward this.

One thing I wanted to ask you is about vector.reflect(); You fixed the 
function according to [1] and later commits. So that changes from 2.4x 
to 2.5. Did you document that any further? I'm asking because I will 
include that in the migration guide, but I'm not sure what to write to 
migrate that code using reflect. For yf I had to use the negative vector 
in 2.5 compared to the one I got in 2.4x.

> Regards,
> Dalai
>    

Regards,
Jörg

[1] http://www.mail-archive.com/bf-blender-cvs@blender.org/msg08738.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/soc-2010-dev/attachments/20100607/78808082/attachment.htm