Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mysterycoder]

I finished applying for a SourceForge project for WGE.

Name: Wrecked Games Engine
Unix Name: wgengine (wge is taken)
Project Description:
Wrecked Games Engine is a cross-platform 3D game engine written in C++. By having a limited amount of abstraction, the engine is designed to be simple. The game logic is separated and driven by scripts.

Technical Description:
Wrecked Games Engine is a 3D Game Engine written in a straightforward manner using C++. It aims to utilize many existing components such as Ogre3D, OIS, OpenAl-Soft, FMOD, Bullet, and UnitTest++ to reduce development time and keep quality high. Instead of using time-consuming abstractions, though still following good design principles, libraries will be used directly to avoid basically re-implementing our own version of the libraries' apis. There is a clear separation between the game logic and the core engine. All game functionality will be implemented in script, with only a higher-level interface exposed. This functionality can also be accessed via C++. A small test game may be developed alongside this project in order to drive the design and aid in finding shortcomings in the engine.

I know the project description is kinda iffy, but I just want to get the process going. 

[mysterycoder]

Well, the SourceForge project is approved.
Right now wgengine.sourceforge.net just redirects to this forum.

[pjcast]

Cool. I suppose I could upload the SVN dump there. Or, you could just import with what you have. What ever you feel like doing.

[mysterycoder]

Thanks for the offer, but I think I'm going to add the code bit by bit, slowly.
I want to be able to write unit tests for what I can, as well as get the cmake files working really well. 
I'll also check each file and make sure it has proper doxygen markup. 

I've added you as a administrator to the SourceForge project. Hope ya don't mind 


This is my proposed directory structure:
wge -> trunk      ->  WGEMain                -> Include
                                                             Source
                                                             Object  ->   Debug
                                                                              Release
                                                             UnitTest
                             WGETest
                             OpenAlSoundSystem
                             FmodSoundSystem
                             Libraries        (Where all the built libraries go)
                             Dependencies (Light dependencies we maintain)
           branches
           tags

[mysterycoder]

I guess I didn't think about this, should I import the existing svn and then make changes for restructuring folders, adding tests, etc. Or should I build the repository clean, from ground up?

[pjcast]

Depends on how much (if any history) you might want. As for layout, looks fine.

I would make the following suggestions:
* Why cmake? It is a heck of a lot easier to just create native projects (for VC, XCode, and Automake) from my experience. Plus, it adds yet another dependency and extra step.
* I would not put dependencies in SVN. I did it for The Ogre Studio project only because I did not plan to update Ogre and or Mogre very often. Also, because I owned the server and SVN repo - and connection was pretty fast. However, the same is not true for Sourceforge (slow and quota's). So, you can of course have the project structure like that, but should plan to keep binary files like that as regular download (ie like Ogre does).
* Also, don't go crazy with Unit tests. Can be good for some things, but for many Game/Gui apps, a lot cannot be tested with simple Unit tests. Plus, with a small team, will be a lot of work to maintain. So, a few as needed, but don't go crazy

[OvermindDL1]

Actually I like CMake as well.  It can generate all of those native projects which you can keep bundled in for those people that do not have CMake, thus CMake is only necessary for the initial developer and not anyone else that uses the code.

[mysterycoder]

Thanks for the suggestions everyone. 

I think I'm going to have to go with OvermindDL1's suggestion about CMake. This is mainly because I don't have easy access to a Windows system with Visual Studio. Unless someone else will, I feel that using CMake is the only way I can keep the Visual Studio projects up to date. 
Also, it's a lot more fun than AutoTools. 

@pjcast:
I forget how slow the SourceForge svn servers really are. It's definitely a good idea to keep the dependencies separate.
Thanks for the suggestion about the unit tests, I probably would have went a little overboard without your comment. 

[mysterycoder]

Heh that's unfortunate. 

It appears that I can't generate native projects for visual studio using CMake unless I am on Windows.
I suppose I'll just get a Windows installation up and running or run it under Wine.

[OvermindDL1]

I thought it could generate make/project files for anything it supports from any system, they are just text files after all...

[mysterycoder]

Did some quick work on the build system today.
I am using the FindPython feature of CMake to get python as python doesn't use pkg-config.
There's also a cool 3rd party FindBoostPython for Linux.

I've got it building perfectly in VC8 now and I am working on getting to work in an out of source build.
For example instead of:
WGE >> Trunk >> WGEMain >> Debug >> objs
                                      >> Source                       

It uses:
WGE >> Trunk >> WGEMain >> Source
       >> Build  >> WGEMain >> Debug

This is in order to keep the builds cleaner as well as to make building various configurations easier.
My goal is to get the build system as simple as possible, meaning lots of auto configuration. On Linux, it's pretty much a one line "cmake ../trunk" by now.
But in Windows, I'm not so lucky. There's no really easy way to detect boost, so I may have to resort to environment variables or passing extra paths to CMake. Fortunately, after the first setup it should work flawlessly, CMake automatically installs a plugin for Visual Studio that detects any cmake project changes you make and it will rebuild and reload the projects, without having to jump out of Visual Studio.

As for Mac ... I have no idea.

[pjcast]

@mysterycoder

I downloaded the WGE source (complete SVN tree). I'm not sure how to get started with CMake. Is there a specific URL I should download it from? And what command line should I run from which directory? Maybe a batch file is needed?

Also, I don't see any dependencies anywhere. Suppose cause you are no longer on Windows. Would be great if you compile a list of what libraries the latest source's lib needs, versions of those libraries, etc. I'm not how Cmake will find dependencies on Windows. hmm.

[mysterycoder]

@pjcast:
Ah yup, I'll compile a list and I'll certainly get something together for you in terms of compiling.
I should have it done by tomorrow - I'm rebuiling my system right now, replying using lynx
Sorry for the lack of documentation

[mysterycoder]

I've got some preliminary building stuff up at: http://wgengine.sourceforge.net/
I don't have windows installed right now and I've had to do it from memory, so let me know if you have any trouble.
I'll try getting windows on tomorrow and I'll update it then.

Also, I'll add instructions for linux building tonight.

Edit: Linux version is up aswell

[pjcast]

Cool. Thanks for taking a look at updating the instructions.