![[de]](/mwf/flags/de.png "Germany")
is there a svn-repos for openclonk?
it would be easier for to implement additional code
what for a compiler/IDE is used?
i am working with GCC(mingw) and Code::Blocks ('cause it's free and it's for linux, too)
it would be easier for to implement additional code
what for a compiler/IDE is used?
i am working with GCC(mingw) and Code::Blocks ('cause it's free and it's for linux, too)
![[es]](/mwf/flags/es.png "Spain")
As the engine source is not open source yet, no. See here. But it could be worth a thought to use a repos for the objects and scenarios already. On the other hands, regarding the objects and scenarios we are just not in any object creation stage yet, in my opinion.I think for the time being, we can create small OpenClonk related projects on the Clonk Forge.
Do we have any starting code yet?
Else i suggest to start with an ogl+sdl template on Code::Blocks GCC win+linux
i think it's better to use opensvn to not get into webspace problems.
Else i suggest to start with an ogl+sdl template on Code::Blocks GCC win+linux
i think it's better to use opensvn to not get into webspace problems.
The existing Clonk source will be open "soon". That will be the code base.
OC uses the CREngine. But Matthes wanted to have a game which is different of CR before the code will be freed, so the source will be avaible in some weeks or so. In OpenSource development a SVN is anyway indispensable.
>source will be avaible in some weeks or so
I would be careful with assumption like these.
but i think we can start from scratch only using some helper-source from cr like lobby, c4groups, irc-chat etc.
that would be a real revolution^^
that would be a real revolution^^
>In OpenSource development a SVN is anyway indispensable.
Or just another version control system.
OpenClonk will use a distributed version control system. It's not yet decided which one. The most likely candidates are Bazaar, Git and Mercurial.The compiler requirements are the same as for CR at the moment, but we'll gladly accept patches to make the code more portable.
It would be cool, if OpenClonk could be compiled using GCC 4.3 :)
Yeah, I know. You can compile it if you use -std=gnu++0x, but the result crashes because of g++ bug 39126. I fear we'll have to wait until C++ 0x support is no longer experimental. Or rewrite large chunks of the engine. Or cheat using const_cast.
yes- that's what we need!
clonk revolution!!!
let's make a free opensource clonk engine.
clonk revolution!!!
let's make a free opensource clonk engine.
Well, any ideas? Creating temporary objects and immediately passing them as non const references to functions is quite useful. Okay, some of the biggest users like the defcore.txt and scenario.txt are probably going to be replaced anyway, but that still leaves configuration and network.
You said something about the ActMap a few days ago. I would like to know how the syntax for replaced act maps (and defcores etc) looks like. Did you implement something already?About that in general, this might be a bit off topic now: OpenClonk has to be documented too, for sure. I think it would be better to switch to a wiki (either Isilkors or on openclonk.org) for documenting. How do you see that - do you think this is a good idea? What are the opinions of the other developers?
A wiki is a bit to large, and the system is not real fast. Are there any better-fitting systems? Something designed for a documentation?
Yes. I reused the Javascript syntax for Object literals for now, but we'll have to discuss that when the code is public. It'll certainly need changes, and I hope somebody else will have a fantastic solution to some of the remaining problems.And I think the same considerations for the documentation apply as they did in the rwd-days: It's quite convenient to use the same tools for documentation and source code control. I think we should rather consider moving the documentation directly into the source. But for tutorials and such a wiki is probably more suited.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill
