Re: [Bf-committers] Node system for game logic
> Message: 6 > Date: Fri, 27 May 2011 23:57:42 +0400 > From: Sergey Kurdakov >>A compilation of a covered work with other separate and independent >>works > > it applies only if it is separate products are put together - such that > engine uses only data, > produced by you hive-system and not any code. > if it is 'linked' - such that there is a code connection (python or not) - > GPL does not allow to run together. > So exactly "Adding GameKit bindings" is prohibited by GPL for non GPL code > if only these binding are not using > network interface or pipes > ( but still even in this case GPL might apply - if it can be proved that the > game cannot run > without GPL component - so that it cannot be replaced with something else). > > LGPL, though, might be OK in this case. Hi Sergey and LetterRip, I think there is a misunderstanding here. Obviously, GameKit runs fine without the hive system. Also, even with GameKit bindings, the hive system would run fine without GameKit, as long as there is another backend available (e.g Panda3D). Therefore, bundling them together would be an aggregate, not a derived product. The hive system wouldn't "infect" the GameKit with a GPL license. I see no reason why GameKit bindings would be forbidden by the GPL. A game that *uses* the hivesystem or any other GPL component would become GPL, but this has nothing to do with GameKit. > From: Tom M > Subject: Re: [Bf-committers] Node system for game logic > To: bf-blender developers > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > On Fri, May 27, 2011 at 11:27 AM, Sjoerd de Vries wrote: > >> I don't believe that the GPL would be viral in this context. > > MS, Sony, Nintendo, and Apple (they are slightly more flexible) > basically have forbidden any open source code that is not one of > > 1) BSD, Zlib, MIT, Apache > > LGPL/GPL simply are not allowed. For the purpose of this discussion > it doesn't matter to the developer whether the code is viral, he > simply cannot use the code at all if he wants to develop for > Wii/DS/Xbox 360/PS3/PSP/iOS. > > LetterRip I am not sure if this is relevant. On how many of those console systems does Python actually work? I am not principally against closed-source applications that use the hive system, but that is another discussion completely. I think you don't need to worry: bundling GameKit with some GPL components should not "infect" GameKit, it would only affect those games that actually use (link with) those GPL components. cheers Sjoerd ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Final FFMPEG compatibility fix (hopefully)
Hi Peter, I am maintaining daily builds of blender for Ubuntu in a PPA at Launchpad. Sorry to be the odd man out here, but I still have problems building blender on Ubuntu Oneiric, which uses libav 0.7~beta2 according to the package overview in Launchpad [1]. libavcodec/version.h states: #define LIBAVCODEC_VERSION_MAJOR 53 #define LIBAVCODEC_VERSION_MINOR 3 #define LIBAVCODEC_VERSION_MICRO 0 The builds fail with following error message: /build/buildd/blender-2.57.1+svn36973~oneiric1/source/blender/blenkernel/intern/writeffmpeg.c: In function 'ffmpeg_property_add': /build/buildd/blender-2.57.1+svn36973~oneiric1/source/blender/blenkernel/intern/writeffmpeg.c:1056:9: error: incompatible types when assigning to type 'int' from type 'const union ' /build/buildd/blender-2.57.1+svn36973~oneiric1/source/blender/blenkernel/intern/writeffmpeg.c:1061:9: error: incompatible types when assigning to type 'float' from type 'const union ' You can see a full buildlog at [2]. Cheers, Ralf [1] http://packages.ubuntu.com/oneiric/ffmpeg [2] https://launchpadlibrarian.net/72565355/buildlog_ubuntu-oneiric-amd64.blender_2.57.1%2Bsvn36973~oneiric1_FAILEDTOBUILD.txt.gz 2011/5/28 Dalai Felinto : > Thanks Peter, it all working now (windows 32 and 64). > > 2011/5/27 Peter Schlaile > >> Hi, >> >> just have commited the final compatibility fix for ffmpeg using a seperate >> header file that handles all the version cruft. (located in >> intern/ffmpeg/ffmpeg_compat.h ) >> >> What makes it very nice: you can now write your code using the latest >> API version of ffmpeg GIT and can still be sure, that it will compile on >> older versions. (without those nasty #ifdefs all over the place.) >> >> You still have to check though, when you use interface functions, that >> where *not* used within the rest of the code and add compatibility macros >> to ffmpeg_compat.h appropriately. >> >> I hope, build doesn't break anymore. >> >> If it doesn't work out, please send me an email. (And: if you do >> so, tell me the exact ffmpeg version you are using, otherwise, I can't >> check!) >> >> Cheers, >> Peter >> >> P.S.: Sorry for the inconvenience, should have solved that the first time >> this way. >> >> >> Peter Schlaile >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Node system for game logic
Statically linking of games against the Hives logic system is the whole point of discussion. Gamekit exclusively uses permissive licenses, such as BSD, MIT, zlib etc, so if you insist on (l)gpl, your logic system is less attractive for BGE too, because BGE devs want to move towards BSD or dual BSD/(l)gpl. What is your problem with BSD license? Thanks, Erwin Sent from my iPhone On May 28, 2011, at 8:03 PM, Sjoerd de Vries wrote: >> Message: 6 >> Date: Fri, 27 May 2011 23:57:42 +0400 >> From: Sergey Kurdakov >>> A compilation of a covered work with other separate and independent >>> works >> >> it applies only if it is separate products are put together - such that >> engine uses only data, >> produced by you hive-system and not any code. >> if it is 'linked' - such that there is a code connection (python or not) - >> GPL does not allow to run together. >> So exactly "Adding GameKit bindings" is prohibited by GPL for non GPL code >> if only these binding are not using >> network interface or pipes >> ( but still even in this case GPL might apply - if it can be proved that the >> game cannot run >> without GPL component - so that it cannot be replaced with something else). >> >> LGPL, though, might be OK in this case. > > Hi Sergey and LetterRip, > > I think there is a misunderstanding here. > Obviously, GameKit runs fine without the hive system. > Also, even with GameKit bindings, the hive system would run fine > without GameKit, as long as there is another backend available (e.g > Panda3D). > Therefore, bundling them together would be an aggregate, not a derived > product. The hive system wouldn't "infect" the GameKit with a GPL > license. I see no reason why GameKit bindings would be forbidden by > the GPL. > > A game that *uses* the hivesystem or any other GPL component would > become GPL, but this has nothing to do with GameKit. > >> From: Tom M >> Subject: Re: [Bf-committers] Node system for game logic >> To: bf-blender developers >> Message-ID: >> Content-Type: text/plain; charset=ISO-8859-1 >> >> On Fri, May 27, 2011 at 11:27 AM, Sjoerd de Vries wrote: >> >>> I don't believe that the GPL would be viral in this context. >> >> MS, Sony, Nintendo, and Apple (they are slightly more flexible) >> basically have forbidden any open source code that is not one of >> >> 1) BSD, Zlib, MIT, Apache >> >> LGPL/GPL simply are not allowed. For the purpose of this discussion >> it doesn't matter to the developer whether the code is viral, he >> simply cannot use the code at all if he wants to develop for >> Wii/DS/Xbox 360/PS3/PSP/iOS. >> >> LetterRip > > I am not sure if this is relevant. On how many of those console > systems does Python actually work? > > I am not principally against closed-source applications that use the > hive system, but that is another discussion completely. > > I think you don't need to worry: bundling GameKit with some GPL > components should not "infect" GameKit, it would only affect those > games that actually use (link with) those GPL components. > > cheers > > Sjoerd > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Node system for game logic
Hi Sjoerd, so if you want games based on hive system to be GPL - then there is no problem with your GPL position. It is just - there are far too fewer games with GPL license ( maybe three orders of magnitude), than all games, and those successful GPL games do live OK without hive. so, unlike Blender - which could be used to create models, your system will have quite narrow use. And of cause, it is your choice. But then, even with Blender gamedev ecosystem - you could not expect much interest. GPL games are developed for fun and not because there is a good system to use, commercial or quasi commercial developers ( free or demo games etc ) - do search for efficient solutions. as for LGPL/BSD discussion then even GameKit depens on LGPL Orgre3D and other LGPL libs, so any additional LGPL lib will not change much ( even if GameKit is licensed BSD - it already has LGPL libs being included ) Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Node system for game logic
Gamekit relies on zero (l)gpl libs. Ogre uses the MIT license. Sent from my iPhone On May 28, 2011, at 9:28 PM, Sergey Kurdakov wrote: > Hi Sjoerd, > > so if you want games based on hive system to be GPL - then > there is no problem with your GPL position. > > It is just - there are far too fewer games with GPL license ( maybe three > orders of magnitude), than all games, > and those successful GPL games do live OK without hive. > > so, unlike Blender - which could be used to create models, your system will > have > quite narrow use. And of cause, it is your choice. > > But then, even with Blender gamedev ecosystem - you could not expect much > interest. > GPL games are developed for fun and not because there is a good system to > use, commercial or > quasi commercial developers ( free or demo games etc ) - do search for > efficient solutions. > > > > as for LGPL/BSD discussion > then even GameKit depens on LGPL Orgre3D and other LGPL libs, > so any additional LGPL lib will not change much ( even if GameKit is > licensed BSD > - it already has LGPL libs being included ) > > Regards > Sergey > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Node system for game logic
Hi Erwin >Ogre uses the MIT license. unfortunately someone misinformed you http://www.ogre3d.org/licensing Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Node system for game logic
Hi All, some info to put together from initial idea to have nodal logic http://wiki.blender.org/index.php/Dev:Source/GameEngine/NodalLogic >Python access to game engine features is incomplete; you cannot get away from using some logic bricks, possibly >inefficiently, if you want to create a 'only python' application. http://blenderartists.org/forum/showthread.php?216269-Dev-BGE-Components-Branch-Created resolves it. then on >Logic brick access to game engine features is incomplete; you cannot get away from using some Python code if you want to >implement a complex logic. the problem is that is hardly resolvable in general, though there are different attempts. http://webdocs.cs.ualberta.ca/~script/ ( no code but there is AI editor which generates ingame code btw this is a way to go - the generated code from any stand alone node system will be free from any restrictions ( because it is produced result ) ) http://msdl.cs.mcgill.ca/projects/projects/AToM3/ just as initial proposal - starts from modeling general systems ( similar systems usually save their results in high level language such as Modelica ( which in turn can be translated to python or c/c++). so - first objection (from NodalLogic proposal ) which was risen ** - that game system of Blender cannot live without blocks - is resolvable, the general solution to program games in graphics - has many attempts - but no satisfactory solution - still it is always possible to translate anything which was developed with blocks to code, which then, can be integrated into any game. Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] GE still slow in rev 36978
Hi all, this commit by Brecht SVN commit: /data/svn/bf-blender [36952] trunk/blender/source/gameengine/ BlenderRoutines/BL_KetsjiEmbedStart.cpp: Attempted fix for #27482: game engine running slow due to revision 36698 doesn't fix the issue for me, the GE is still very slow in revision 36978, but only in camera view. With the 3d viewport camera the speed is normal. Should I add to bug #27482 or open a new one? I'm on Linux 64 Bit. Thanks, Sanne ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Node system for game logic
Hi Erwin. my bad. yes all components of GameKit are non lgpl or gpl. and Orgre from ver 1.7 is also MIT but still if it is possible to render game logic in blocks - it is possible to write code exporter. so if the system is actually that good - to overcome it's GPl nature is not difficult Regards Sergey On Sat, May 28, 2011 at 4:58 PM, Sergey Kurdakov wrote: > Hi Erwin > > > >Ogre uses the MIT license. > > unfortunately someone misinformed you > http://www.ogre3d.org/licensing > > Regards > Sergey > > > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Final FFMPEG compatibility fix (hopefully)
Hi, please try again with latest SVN. Cheers, Peter > I am maintaining daily builds of blender for Ubuntu in a PPA at Launchpad. > Sorry to be the odd man out here, but I still have problems building > blender on Ubuntu Oneiric, which uses libav 0.7~beta2 according to the > package overview in Launchpad [1]. > > libavcodec/version.h states: > > #define LIBAVCODEC_VERSION_MAJOR 53 > #define LIBAVCODEC_VERSION_MINOR 3 > #define LIBAVCODEC_VERSION_MICRO 0 > > The builds fail with following error message: > > /build/buildd/blender-2.57.1+svn36973~oneiric1/source/blender/blenkernel/intern/writeffmpeg.c: > In function 'ffmpeg_property_add': > /build/buildd/blender-2.57.1+svn36973~oneiric1/source/blender/blenkernel/intern/writeffmpeg.c:1056:9: > error: incompatible types when assigning to type 'int' from type > 'const union ' > /build/buildd/blender-2.57.1+svn36973~oneiric1/source/blender/blenkernel/intern/writeffmpeg.c:1061:9: > error: incompatible types when assigning to type 'float' from type > 'const union ' > > You can see a full buildlog at [2]. > > Cheers, > Ralf > > [1] http://packages.ubuntu.com/oneiric/ffmpeg > [2] > https://launchpadlibrarian.net/72565355/buildlog_ubuntu-oneiric-amd64.blender_2.57.1%2Bsvn36973~oneiric1_FAILEDTOBUILD.txt.gz > > 2011/5/28 Dalai Felinto : >> Thanks Peter, it all working now (windows 32 and 64). >> >> 2011/5/27 Peter Schlaile >> >>> Hi, >>> >>> just have commited the final compatibility fix for ffmpeg using a seperate >>> header file that handles all the version cruft. (located in >>> intern/ffmpeg/ffmpeg_compat.h ) >>> >>> What makes it very nice: you can now write your code using the latest >>> API version of ffmpeg GIT and can still be sure, that it will compile on >>> older versions. (without those nasty #ifdefs all over the place.) >>> >>> You still have to check though, when you use interface functions, that >>> where *not* used within the rest of the code and add compatibility macros >>> to ffmpeg_compat.h appropriately. >>> >>> I hope, build doesn't break anymore. >>> >>> If it doesn't work out, please send me an email. (And: if you do >>> so, tell me the exact ffmpeg version you are using, otherwise, I can't >>> check!) >>> >>> Cheers, >>> Peter >>> >>> P.S.: Sorry for the inconvenience, should have solved that the first time >>> ? ? ? this way. >>> >>> >>> Peter Schlaile >>> >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Node system for game logic
Hi, Speeking of gamekit, it has a node logic system MIT lisenced. You can take a look at that if you want, it is C++ with some basic Lua bindings. Having a code generator that generates code from node tree is definitely possible but more complicated than simply evaluating a tree. There is code that does that (GPL unfortunately) to compile the material node tree to GLSL code for viewport and game engine. Xavier 2011/5/28 Sergey Kurdakov : > Hi Erwin. > > my bad. > > yes all components of GameKit are non lgpl or gpl. > > and Orgre from ver 1.7 is also MIT > > but still > > if it is possible to render game logic in blocks - it is possible to write > code exporter. > so if the system is actually that good - to overcome it's GPl nature is not > difficult > > Regards > Sergey > > On Sat, May 28, 2011 at 4:58 PM, Sergey Kurdakov > wrote: > >> Hi Erwin >> >> >> >Ogre uses the MIT license. >> >> unfortunately someone misinformed you >> http://www.ogre3d.org/licensing >> >> Regards >> Sergey >> >> >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Final FFMPEG compatibility fix (hopefully)
New builds just went through. Thank you Peter. Cheers, Ralf 2011/5/28 Peter Schlaile : > Hi, > > please try again with latest SVN. > > Cheers, > Peter > >> I am maintaining daily builds of blender for Ubuntu in a PPA at Launchpad. >> Sorry to be the odd man out here, but I still have problems building >> blender on Ubuntu Oneiric, which uses libav 0.7~beta2 according to the >> package overview in Launchpad [1]. >> >> libavcodec/version.h states: >> >> #define LIBAVCODEC_VERSION_MAJOR 53 >> #define LIBAVCODEC_VERSION_MINOR 3 >> #define LIBAVCODEC_VERSION_MICRO 0 >> >> The builds fail with following error message: >> >> /build/buildd/blender-2.57.1+svn36973~oneiric1/source/blender/blenkernel/intern/writeffmpeg.c: >> In function 'ffmpeg_property_add': >> /build/buildd/blender-2.57.1+svn36973~oneiric1/source/blender/blenkernel/intern/writeffmpeg.c:1056:9: >> error: incompatible types when assigning to type 'int' from type >> 'const union ' >> /build/buildd/blender-2.57.1+svn36973~oneiric1/source/blender/blenkernel/intern/writeffmpeg.c:1061:9: >> error: incompatible types when assigning to type 'float' from type >> 'const union ' >> >> You can see a full buildlog at [2]. >> >> Cheers, >> Ralf >> >> [1] http://packages.ubuntu.com/oneiric/ffmpeg >> [2] >> https://launchpadlibrarian.net/72565355/buildlog_ubuntu-oneiric-amd64.blender_2.57.1%2Bsvn36973~oneiric1_FAILEDTOBUILD.txt.gz >> >> 2011/5/28 Dalai Felinto : >>> Thanks Peter, it all working now (windows 32 and 64). >>> >>> 2011/5/27 Peter Schlaile >>> Hi, just have commited the final compatibility fix for ffmpeg using a seperate header file that handles all the version cruft. (located in intern/ffmpeg/ffmpeg_compat.h ) What makes it very nice: you can now write your code using the latest API version of ffmpeg GIT and can still be sure, that it will compile on older versions. (without those nasty #ifdefs all over the place.) You still have to check though, when you use interface functions, that where *not* used within the rest of the code and add compatibility macros to ffmpeg_compat.h appropriately. I hope, build doesn't break anymore. If it doesn't work out, please send me an email. (And: if you do so, tell me the exact ffmpeg version you are using, otherwise, I can't check!) Cheers, Peter P.S.: Sorry for the inconvenience, should have solved that the first time ? ? ? this way. Peter Schlaile ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers >>> ___ >>> Bf-committers mailing list >>> Bf-committers@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Node system for game logic
Hi, it looks like design questions of GameKit should somehow be considered separately. currently, as it is mentioned >with some basic Lua >bindings. GameKit has no python system, but lua one. also while hive system has some merits - it is not the only approach, I like this one http://sourceforge.net/apps/mediawiki/delta3d-extras/index.php?title=DtEntityfor example ( based on series of articles http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ so this system is really designed with games in mind - not just connect objects - maybe I missed something - but hive system is just overuse of python capabilities to bring objects together but if it can streamline game creation still to be seen ) so which system to use and how still is a question to be discussed. But the narrow part of the story is interface to program games ( there are tools out there such as GameMaker - but it adds nothing special over current Blender capabilities ). If there is working system on interface front to program games without coding - and this main question is resolved - then other questions can be resolved. now the point is if without interface hive system fits into Blender Game engine and if it has potential to fulfill NodeLogic proposal or NodeLogic can be coded with the use of Moguri system + some ideas from http://sourceforge.net/apps/mediawiki/delta3d-extras/index.php?title=DtEntity). as we seen - Ogre was re licensed - but before it proved to be viable system in a first place Regards Sergey On Sat, May 28, 2011 at 6:32 PM, Xavier Thomas wrote: > Hi, > > Speeking of gamekit, it has a node logic system MIT lisenced. You can > take a look at that if you want, it is C++ with some basic Lua > bindings. > > Having a code generator that generates code from node tree is > definitely possible but more complicated than simply evaluating a > tree. There is code that does that (GPL unfortunately) to compile the > material node tree to GLSL code for viewport and game engine. > > Xavier > > > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Node system for game logic
Hi Sjoerd, Thanks for sharing the hive system. I've started to read the documentation and so far I'm impressed by what you have done. I already have a good idea of the system but I still have to figure out how you have achieved all the goals that I stated in my proposal. At some point I will contact you when I know enough to not waste your time with stupid questions. As far as licensing is concerned, I would prefer if you go to a BSD-style license but you should in any case take a firm and definitive position quickly to cut short what seems to be an endless discussion on licensing again ;-) Regards, Benoit > > Message: 1 > Date: Thu, 26 May 2011 14:55:19 +0200 > From: Sjoerd de Vries > Subject: [Bf-committers] Node system for game logic > To: bf-committers@blender.org > Message-ID: > Content-Type: text/plain; charset=ISO-8859-1 > > Hi everyone, > > I would like to present to you the hive system, a working > node system for game logic (and other things). > > It implements the complete list of goals of Benoit's Nodal > Logic proposal: > http://wiki.blender.org/index.php/Dev:Source/GameEngine/NodalLogic > Some of the design decisions are different, but the hive > system contains all of his features. > > The source code is available under GPL: > > http://launchpad.net/hivesystem > > It also has a GUI for editing hivemaps (node graphs). It is > basic and quirky but it works. This makes it possible for > non-programmers to create and modify game logic. I have made > a screencast that demonstrates this for a simple 3D scene: > > http://launchpad.net/hivesystem/trunk/0.7/+download/screencast.swf > > New nodes and hives can easily be built in Python. However, > the coding style is different from normal Python scripts. I > have written a long manual with many examples. If anything is > unclear, please tell me. > > The main limitation is that there are no bindings yet to the > BGE, only to Panda3D. It still needs to be ported to > Python3.2, and I am not very familiar with the BGE source > code. Also, a lot of important nodes (sound, physics, mouse > picking, networking) are still missing. > > I am looking forward to join forces with Benoit and Sven, and > with anyone else who is interested. Any feedback is welcome! > > cheers > > Sjoerd > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Final FFMPEG compatibility fix (hopefully)
Hm, build is successful but at runtime I get error "The procedure entry point RegisterDragDrop could not be located in the dynamic link library avcodec-52.dll" On 28 May 2011 02:08, Dalai Felinto wrote: > Thanks Peter, it all working now (windows 32 and 64). > > 2011/5/27 Peter Schlaile > >> Hi, >> >> just have commited the final compatibility fix for ffmpeg using a seperate >> header file that handles all the version cruft. (located in >> intern/ffmpeg/ffmpeg_compat.h ) >> >> What makes it very nice: you can now write your code using the latest >> API version of ffmpeg GIT and can still be sure, that it will compile on >> older versions. (without those nasty #ifdefs all over the place.) >> >> You still have to check though, when you use interface functions, that >> where *not* used within the rest of the code and add compatibility macros >> to ffmpeg_compat.h appropriately. >> >> I hope, build doesn't break anymore. >> >> If it doesn't work out, please send me an email. (And: if you do >> so, tell me the exact ffmpeg version you are using, otherwise, I can't >> check!) >> >> Cheers, >> Peter >> >> P.S.: Sorry for the inconvenience, should have solved that the first time >> this way. >> >> >> Peter Schlaile >> >> ___ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Node system for game logic
The proposal at http://wiki.blender.org/index.php/Dev:Source/GameEngine/NodalLogic is huge, great ideas, but maybe its overkill. Nodes are cool, better than what we have now, but i think "Scratch-style" logic blocks would be simple and even more clear. http://scratch.mit.edu/ One issue i see is there are many changes at the C level that need to be made to leverage the current node interface. Why not take a pure python approach, and use ctypes where needed? If the UI is going to be general and compatible with other engines like Panada3d, etc.. it really should use a standard GUI toolkit like Qt or Gtk. -brett --- On Sat, 5/28/11, Benoit Bolsee wrote: > From: Benoit Bolsee > Subject: Re: [Bf-committers] Node system for game logic > To: bf-committers@blender.org > Date: Saturday, 28 May, 2011, 9:49 AM > Hi Sjoerd, > > Thanks for sharing the hive system. I've started to read > the > documentation and so far I'm impressed by what you have > done. I already > have a good idea of the system but I still have to figure > out how you > have achieved all the goals that I stated in my proposal. > At some point > I will contact you when I know enough to not waste your > time with stupid > questions. > > As far as licensing is concerned, I would prefer if you go > to a > BSD-style license but you should in any case take a firm > and definitive > position quickly to cut short what seems to be an endless > discussion on > licensing again ;-) > > Regards, > Benoit > > > > > Message: 1 > > Date: Thu, 26 May 2011 14:55:19 +0200 > > From: Sjoerd de Vries > > Subject: [Bf-committers] Node system for game logic > > To: bf-committers@blender.org > > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Hi everyone, > > > > I would like to present to you the hive system, a > working > > node system for game logic (and other things). > > > > It implements the complete list of goals of Benoit's > Nodal > > Logic proposal: > > http://wiki.blender.org/index.php/Dev:Source/GameEngine/NodalLogic > > Some of the design decisions are different, but the > hive > > system contains all of his features. > > > > The source code is available under GPL: > > > > http://launchpad.net/hivesystem > > > > It also has a GUI for editing hivemaps (node graphs). > It is > > basic and quirky but it works. This makes it possible > for > > non-programmers to create and modify game logic. I > have made > > a screencast that demonstrates this for a simple 3D > scene: > > > > http://launchpad.net/hivesystem/trunk/0.7/+download/screencast.swf > > > > New nodes and hives can easily be built in Python. > However, > > the coding style is different from normal Python > scripts. I > > have written a long manual with many examples. If > anything is > > unclear, please tell me. > > > > The main limitation is that there are no bindings yet > to the > > BGE, only to Panda3D. It still needs to be ported to > > Python3.2, and I am not very familiar with the BGE > source > > code. Also, a lot of important nodes (sound, physics, > mouse > > picking, networking) are still missing. > > > > I am looking forward to join forces with Benoit and > Sven, and > > with anyone else who is interested. Any feedback is > welcome! > > > > cheers > > > > Sjoerd > > > > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Smart nodes aren't so smart
This behavior of nodes making connections automatically, can we just get rid of it pretty please? nice intention but it doesn't work :) cheers Daniel Salazar 3Developer.com ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Node system for game logic
Hi, just to complete series of links for components idea: https://github.com/caseman/grease is a python component system tutorials are here: https://github.com/caseman/grease/tree/master/doc/tutorial while targeting quite different aspects of design - still initial intention from http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/ >No programmer required for designers to modify game logic are possible to implement more attempts to implement the same pattern: http://www.gamadu.com/artemis/ https://github.com/tdavies/Ember http://flohofwoe.blogspot.com/2007/11/nebula3s-application-layer-provides.html and code http://code.google.com/p/nebula3/ Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] GE still slow in rev 36978
Hello Sanne, Please add a new bug report. Cheers, Mitchell On Sat, May 28, 2011 at 6:44 AM, Sanne wrote: > Hi all, > > this commit by Brecht > > SVN commit: /data/svn/bf-blender [36952] trunk/blender/source/gameengine/ > BlenderRoutines/BL_KetsjiEmbedStart.cpp: Attempted fix for #27482: game > engine running slow due to revision 36698 > > doesn't fix the issue for me, the GE is still very slow in revision 36978, but > only in camera view. With the 3d viewport camera the speed is normal. Should > I add to bug #27482 or open a new one? > > I'm on Linux 64 Bit. > > Thanks, > Sanne > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] [bf-committers][Patch]Fix Bug [#27510] Color key hue flipping error (compo node)
Thanks, Patch is here http://projects.blender.org/tracker/index.php?func=detail&aid=27514&group_id=9&atid=127 inspired by Campbell Barton, This is my first patch for Blender, Thank you all Jianming Guo ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Final FFMPEG compatibility fix (hopefully)
> Hm, build is successful but at runtime I get error "The procedure > entry point RegisterDragDrop could not be located in the dynamic link > library avcodec-52.dll" looks like you are on your own here. (Check your build environment, things look *seriously* broken, since RegisterDragDrop is some OLE32.DLL function according to google. Since I don't have a Windows box around, maybe others could help. But: if anyone can help you, he/she most probably will need a little bit more information on your build environment. Such things as Win32/Win64/ffmpeg version used, compiler used etc. etc.) Cheers, Peter Peter Schlaile ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Final FFMPEG compatibility fix (hopefully)
It's fixed, Nazg-gul has already tracked down same error on x86, so it wasn't a big problem to catch this one on x64. On 29 May 2011 00:35, Peter Schlaile wrote: >> Hm, build is successful but at runtime I get error "The procedure >> entry point RegisterDragDrop could not be located in the dynamic link >> library avcodec-52.dll" > > looks like you are on your own here. (Check your build environment, things > look *seriously* broken, since RegisterDragDrop is some OLE32.DLL function > according to google. Since I don't have a Windows box around, maybe others > could help. But: if anyone can help you, he/she most probably will need > a little bit more information on your build environment. Such things as > Win32/Win64/ffmpeg version used, compiler used etc. etc.) > > Cheers, > Peter > > > Peter Schlaile > > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
