Page 4 of 4

Posted: Thu Sep 15, 2005 1:03 am
by Bogey
I hope you dont mind me saying this.



Posted: Thu Sep 15, 2005 4:02 pm
by gorgan_almighty
Wow this is amazing! It can do so much that Sumo can't!! :shock:

But Sumo can also do so much that this can't. Sumo is so widely used that this engine MUST be compatible with it if its going to survive. I suggest You have a go at integrating this into Sumo, to make a Next Generation Sumo (NGS) engine! :D The currently existing sensors, controllers & actuators can be integrated as block types in the pipline. :)

Keith. 8)

Posted: Thu Sep 15, 2005 8:12 pm
by pildanovak
I disagree - Sumo is widely used because it's the only open source engine with an easy to use gui and the possibility to click and runt the game.

But it's functionality and structure is so outdated that building upon it would be probably a mistake. Of course a bacwards compatibility - such as conversion of old files into the new structure would be nice.

Backwards incompatibility

Posted: Thu Sep 15, 2005 11:41 pm
by Bandoler

This is an issue that had to come up sooner or later. I'm not planning to work towards backwards compatibility. The current engine and this project are conceptually diferent. It is true that i could try to build a rendering pipeline that mimics what the current engine does. However any project beyond a minimum size made with the current engine uses a lot of python, and i don't think making a layer to adapt the interface to what i'm doing in this project is possible.
Then there is the logic stuff, which is very different too. I don think it is worth to try to keep compatibility...


Posted: Fri Sep 16, 2005 9:54 am
by gorgan_almighty
I agree that your engine (which really needs a name by the way :P) is very different to Sumo. But most people are working on large projects that have taken them many many hours to get this far, and I'm sure they'd rather stick with Sumo then trash what they've already done so far and move to a different engine entirely. I know people who are still using v2.25 because 2.37a isn't 100% compatible with their main projects.

Merging this project with Sumo may not be practical (and I can understand you wanting to keep it under your control) but it could be developed as a plug-in for Sumo, extending the functionality of Sumo without having to integrate with it.

Keith. 8)

Posted: Sat Oct 08, 2005 11:51 pm
by jellywerker
I say keep it seperate and it cna be added to 2.4, combining a new good game engine with an older erm, crappy one isn't a good idea.

Update from the conference

Posted: Thu Oct 20, 2005 1:54 am
by Bandoler

After the blender conference, the feedback i got of this system and the short discussion on the game engine there, Crystalblend is the official new engine, as you probably know already.

My project is too complicated for normal users, so i'll stop targeting non-developers. I'll go on with the project that finally has a name "crosa", and a web site: , but more oriented to tech users.

There is not much in the new web yet, but it is a matter of time. I'd like to officially close this thread saying thanks to all the people reading it and giving their opinions. I'll be around anyway, posting whenever i have something worth to show (not as often as i was posting in this thread), and my project will still be using blender. However iĺl move a little bit away to not disrupt the new official approach.

I've updated the CVS in SourceForge with a new version using Blender 2.40 alpha, and also the PSP player i showed in the confernce. I'll upload it as a binary too for people that don't want to fight with my code to compile it, and want to test it on the PSP.

Farewell, and thanks again!


Posted: Mon Oct 24, 2005 7:15 am
by Sutabi
The reason I no longer use the game engine is not becuase of its crappy graphics, a good game isn't too much about that, but ability to add addition features that had nothing todo with the graphical side. What you present is definetly what I desire to develop larger scaled applications.

It would be intresting to have modules extendable outside the source, maybe allow .dll/.so

Its intresting to see how much Visual Development oversees programming in general. For example, If I create code for somethig to act a certain way, I then will later have to define that as well as what interacts with it. Your project eliminates dealing with code that could be developed visual anyways, in which most companies would then develope their out style of appliations to part together the engine, but Its a rarity to be able to control the lowest points of what goes into the engine with rapid feed back. Again Blender GE already does this, I am just glad its being continued into this engine. I just wonder when is it going to be a problem when there are certain things blender cannot handle that will cause the develope to force the artist to work with code rather then art. Multuiple UV's is definely an issue, but then either developer will need to use two or more of the same meshes to define UV's or the develope will need to develope another module to allow external data for prasing models with multiple UV.

Maybe I am going off into a tagent, but I know at some point the limit of the engine wont be how it forces more complexity, but if its enough complexity to better development towards the artists sake. Since I see at my standpoint, this require at least a developer and then an artist, and somewhere along the mists a sub developer logics, the mighty verse intergration and now you have not only a more powerful too, but the idea of constant flow, being able to see changes as everyone works ^_^.....

Bah, I just cant wait for a release.

vvvv toolkit, has similar point of view

Posted: Sat Dec 17, 2005 2:27 am
by Wirefall
i look the post and the replies, i think that is an interesting work, game engine in blender does not take the advantages of shaders... :(

i found all teory very similar to the vvvv toolkit... a germany tool

i used that tool only for testing and it's very original proposal like 'always runtime', pipelines, shaders, iterations renderes