Sound/Game system status and work. Was: Re: [Bf-committers] 2.36
jbeaurain at istop.com
Wed Jan 5 03:21:18 CET 2005
Just returned from holiday and will soon be ready to start working on
some of the audio stuff as described below ...Except I see someone
(Alexander) already beat me to it and started. I still believe I can be
of some help. Will first need to catch up with everything that I missed
while away though.
A quick look at the "Soundsystem mess" thread shows that the differences
between C and C++ is/was giving you some headaches. I am well versed in
using (and in deciding when to use or stay away from) either of the two
through my work. This is one part of what I believe I can be of help
with to clean up and redesign. Refactoring C++ code can sometimes lead
to having to change multiple places in the code but the same can happen
in C depending on the initial design.
Other than that I see you plan to get rid of OpenAL and do everything
with SDL. I am from an academic background in the field electronic
engineering so I have some experience in physics and math which may (or
may not;) come in handy in coding certain things from scratch if we have
to go this way.
Will keep reading the rest of my unread mail and get back within the
next week or so.
PS: I still think it may be a good idea to start something in the
Blenderwiki so that everybody involved know what is going on and not
reinventing each other's wheels. I find it hard using email threads as
TODO lists, general documentation and design documents. The sound part
of the game engine may not be complex/big enough to justify it's own
wiki topic and I also think the whole game engine can use one there
where people can share what they know and learn about it. I'll try to
get a general framework for the Game Engine (with the minute amount that
I know, maybe Kester can add some valuable info to it) on the Blenderdev
wiki as soon as possible. because I think I'll also want to start
contributing to the whole after we are done with the sound stuff.
Jacques Beaurain wrote:
> I did see the assert and I also added some extra notes in the tracker
> about problems getting debug builds to work (that is why no one uses
> debug builds I guess). It seems some recent changes made this
> impossible (python linking errors).
> Other than that I have been playing around on getting scons to do
> proper debug and release optimized builds on windows (linking to debug
> CRT, doing runtime checks, full optimizations etc.) The SConstruct
> patch attached shows what I am trying at the moment. The problem is
> that solid's extern/solid/SConscript adds extra cflags that conflicts
> with the ones in SConstruct and stops the builds. There has also been
> other places that had /Ox flags appended (also see sconstruct.patch)
> and I also noticed misc. things .
> Interestingly, my initial tests shows that renders with the internal
> renderer speeds up by about 10-20% (Using the free Visual Studio 2003
> toolkit with optimizing compiler) compared to the released 2.35a
> binary by using the compile flags above (the commented ones shows what
> I had to do to obtain a debug build by building release with
> debugging). I did not analyze many scenes with a lot of test runs yet
> though and would like to make sure I iron out all my build problems
> first and then obtain reliable extensive test results. It may even be
> a red herring bacause of changes between the 2.35a branch and now, so
> I guess I should set up a compile from CVS and just change the flags.
> More on this when I return from holidays on January, or the Windows
> guys can try the you can continue with what I have here and try it in
> the mean time.
> I added notes to #1808 about helping out with the sound system. I have
> been looking for an area to contribute and believe I can be of some
> help here. Any direction and thoughts from people who started thinking
> in that direction about this would be helpful. When I get back I'll
> get my thought together and start a wiki or something for the design
> and todo's. Are Ogg Vorbis (codecs) support, separate cd & audio into
> different classes, and loop points with OpenAL the only issues?
> (besides stability)
> PS: does anyone else building on Windows have to change <iostream.h>
> to <iostream> all the time (see patch)?
More information about the Bf-committers