1

(1 replies, posted in Engine)

While working on the Android build of Maratis I realized that I yet again had to re-implement, duplicate or stub out the MWindow and related stuff for the new platform. As code duplication is a bad thing and makes maintenance harder than it should be, I decided to instead venture into getting rid of most of our own platform specific code and unify all platforms with SDL2 as it support Windows, Linux, OSX, iOS and Android. The begining of this work is now commited to my development branch on GitHub.

The only platform specific code left in "vanilla" Maratis is MWindow::getTempDirectory, MWindow::getCurrentDirectory, MWindow::setCurrentDirectory, MWindow::setWorkingDirectory and MWindow::execute. While the partials for X11 and WIN32 in C++ is a no-brainer I'm not sure if the equivalent COCOA bit in Objective-C actually can be done that way (as I don't have OSX to test on).

Some of the features of moving to SDL2 is force-feedback and hot-plugable support for joysticks and gamecontroller.

Using the game controller events and semantics makes all joysticks that SDL2 has a mapping for look like an XBox 360 controller to the game engine and makes the buttons and axes on non-XBox controllers map to similar or similarly placed buttons and axes to the user. E.g. the A/B buttons on an X360 Controler is button 0/1 respectively, but on other controllers button 0/1 might be the X/Y button while A/B being 2/3, SDL2 sort all this out and maps them consistently.

So instead of JOY1_BUTTON1, MOTION_X and so on, the semantics has changed to JOY1_BUTTON_A, JOY1_AXIS_LEFTX and so on in Lua. The number of controllers available via Lua has also been upped to four (of course a game can support any number of controllers via the C++ API.) Here is a full list of the available button and axis literals available:

JOY1_BUTTON_A
JOY1_BUTTON_B
JOY1_BUTTON_X
JOY1_BUTTON_Y
JOY1_BUTTON_BACK
JOY1_BUTTON_GUIDE
JOY1_BUTTON_START
JOY1_BUTTON_LEFTSTICK
JOY1_BUTTON_RIGHTSTICK
JOY1_BUTTON_LEFTSHOULDER
JOY1_BUTTON_RIGHTSHOULDER
JOY1_BUTTON_DPADUP
JOY1_BUTTON_DPADDOWN
JOY1_BUTTON_DPADLEFT
JOY1_BUTTON_DPADRIGHT

JOY1_AXIS_LEFTX
JOY1_AXIS_LEFTY
JOY1_AXIS_RIGHTX
JOY1_AXIS_RIGHTY
JOY1_AXIS_TRIGGERLEFT
JOY1_AXIS_TRIGGERRIGHT

Since these are consistent the equivalent set of enums are now available in the C++ API. It is also possible to use the joysticks directly and ignore all the remapping in the C++ API.

With SDL2 mouse motion and button events will be generated by touch devices on e.g. iOS and Android in addition to actual touch events. So the game does not need to be touch aware to work on iOS/Android if it primarily uses the mouse for input. However, there is lot of touch support in SDL2 I have not yet taken advantage of, like multi gestures and dollar gestures.

I am also working on making Maratis more event driven so that systems that produce events (e.g. MWindow) and systems that consume them (e.g. the game, game engine and gui) can be decoupled (it will be up to the consumer subsystem to keep track of state.) This is also a preparation for any future work on adding network support.

SDL2 related things on my todo list:

  • Add force-feedback support.

  • Add multi gesture and dollar gesture support.

  • Refactor MKeyboard and MMouse out from MWindow.

  • Move MWindow (and MWinEvents) from MGui into Common.

  • Ehem... maybe finish the Android build that started it all.

  • Port the iOS build to SDL2

2

(7 replies, posted in General)

anael wrote:

I will try to apply to this : http://sfconservancy.org

Yes, that's a good option. K-3D, a fairly small project I used to contribute to (and gave me a jump start on this C++ thing), was set up through them to be able to accept contributions and run GSoC.

Btw, the CS department at my university use to run their own version summer of code (basically paying students to work on projects they propose as long as the work can be used to show of and in marketing the university) so I hope to have my Maratis application accepted and being able to contribute full time during the summer.

3

(44 replies, posted in Scripting)

I'm currently reading the second edition of "Artificial Intelligence for Games" by Ian Millington and John Funge which I must say is probably one of the best books on the topic of game AI. The authors have a solid background in and understanding of academic AI as well as game and simulation AI and discuss the differences between them.

The book is more or less a catalog of probably every AI technique employed today but also contain a discussion on how and why to choose specific techniques, advice on how not to overcomplicate things (simple AIs can behave remarkably intelligent compared to some more complex ones) with lots of examples from different games. It also discuss all the techniques and their applications in the context of a larger AI framework, basically how they can be combined and communicate in the AI subsystem of a game.

4

(22 replies, posted in General)

Tutorial Doctor wrote:

I just had an idea of creating a starter pack of objects, sounds, fonts, etc for maratis.

When you first get Maratis, you really have nothing to manipulate. So I created a bunch of primitives and put them in the meshs folder. You also have no sounds, nor fonts loaded (I understand copyright stuff with fonts).

I have made some test rooms and some assets for maratis, but I was wondering if anyone would be able to contribute to a Maratis Starter pack.

Of course, we would have to get the scale correct. so that all objects are at the right scale. Anyone interested?
Anyone have any ideas of what essential types of objects (other than primitives) they would like to have in a starter pack?

A good idea would be to do something similar to UDK and their starter kits that are centered around a typical mode or genre of gameplay: FPS starter kit, platformer starter kit, and so on...

5

(7 replies, posted in General)

anael wrote:

Dahnielson : I saw in your github that you made a lot of work on native image loaders and sound loaders, that's awesome smile
Is OpenAL Soft working as expected ?

I haven't had any time to work on Maratis this week and I'm a little bit ashamed to say that I haven't properly tested it. I just integrated, built, ran, saw that it at least didn't segfault and commited it to Github. wink So I can't really say anything about OpenAL Soft yet. The same goes for the Ogg Vorbis loader I implemented just so I could test OpenAL, as I had problem loading sounds using SndFile.

My plan is to also implement a native image loader for DDS files, so S3TC compressed textures can be directly loaded into texture memory, as off-line compression (using e.g. Nvidia Texture Tools) is way better than letting the graphics chip set do it on-line.

I've also been poking around with the idea of implementing a new type of data loader to stream audio and video. At least doing the first one as loading game music completely into memory is a bit waste of memory.

6

(4 replies, posted in General)

Akira_san wrote:

Then i vote for LuaJIT, hope you add it as soon as possible.

I'm working on integrating it as a dependency into my CMake build system version of Maratis. However, I haven't yet figured out how to build it properly except using the Makefiles included in LuaJIT.

7

(2 replies, posted in General)

sunnystormy wrote:

Has there been any movement in this area? What would need to be done in order to get native ARM Linux support for the engine?

I don't think much is needed to be done. I've managed to compile Maratis libs and dependencies using clang targeting ARMv6 and ARMv7 with the Android NDK as it is just an ARM Linux build environment (and nothing Androidy about that part). So I imagine MaratisEditor and MaratisPlayer would build also, possibly change the context from OpenGL to OpenGLES (as such a context is already included).

Think I will get an Rasberry Pi soon to play around with as it is a pure ARM Linux environment running on an ARMv6 with a decent graphic chipset (comparable to the original Xbox).

8

(47 replies, posted in Engine)

sunnystormy wrote:
Dahnielson wrote:

Btw, I'm already working on a port for Android. Just haven't had time to finish it as I've been refactoring some other stuff.

Awesome, man. Let us know when you finish it. I've got a Nexus 7 that I wouldn't mind using for testing. smile

Yep, got an Nexus 7 myself (the old one with Tegra 3) which was my motivation in addition to getting Maratis onto OUYA.

9

(1 replies, posted in General)

And I have been looking into LuaJIT (http://luajit.org/) a JIT compiler for Lua that would speed up the execution of any scripting. Event its interpreter (as iOS forbid generation of executable code on the device) is more efficient than the orginal Lua implementation.

10

(47 replies, posted in Engine)

sunnystormy wrote:

Hey Vegan!

I currently work as an iOS Developer, and I think you can still publish if you're targeting 6.1.

Outside of the iTunes App Store, I don't think there's a distribution channel unless you're willing to cater to Jailbroken iPhones.

Speaking of which, are we considering porting the engine to Android? That would give us an open alternative to Apple. : )

Btw, I'm already working on a port for Android. Just haven't had time to finish it as I've been refactoring some other stuff.

11

(7 replies, posted in General)

anael wrote:

Nice man !

What might be hard to use is OpenAL for the sound, I don't think it's supported natively on Android.
Maybe a third party lib like "OpenAL Soft" will be enough, or it will need a OpenSL sound context to replace the OpenAL one.

Yes, I have been looking into the dependencies. Haven't written any sound context for the Android build yet. But I was thinking of adding OpenAL Soft as a dependency instead if I can get it integrated into the build system (it already uses CMake). It would benefit all the other platforms as well, replacing the aging proprietary binary implementation with a modern open source implementation that offers multiple of backends.

12

(6 replies, posted in General)

While we're on the topic: Changing "maps" to "textures" would make it slightly more intuitive. Sure, I understand that it's short for "texturemaps", but coming from other engines my first thought before looking closely was "why does the project have both a level and a map directory?".

13

(19 replies, posted in Engine)

Sponk wrote:

You could try using Dahnielson's CMake build system. It should be able to create Code::Blocks or VS project files for windows.

https://github.com/dahnielson/

I hope this becomes standard at some point of time wink

Sponk

Just a note of caution: I haven't tested if the CMake generated project on Windows actually builds yet. It's only been tested on Linux (success), OSX/iOS (needs fixing) and Android (success) so far.

14

(7 replies, posted in General)

I'm working on an Android build of Maratis. So far I have been able to at least compile the essential parts for a player with the NDK:

-rw-r--r-- 1 anders anders 9,3M 11 feb 21.05 libbullet.a
-rw-r--r-- 1 anders anders 1,7M 12 feb 11.01 libfreetype.a
-rw-r--r-- 1 anders anders 579K 11 feb 21.05 liblua.a
-rw-r--r-- 1 anders anders 2,1M 11 feb 21.06 libMaratisCommon.a
-rw-r--r-- 1 anders anders 222K 11 feb 21.06 libMaratisOpenGLES.a
-rw-r--r-- 1 anders anders 3,8K 11 feb 21.06 libMaratisWavSound.a
-rwxr-xr-x 1 anders anders 270K 11 feb 21.06 libMCore.so
-rwxr-xr-x 1 anders anders 863K 11 feb 21.06 libMEngine.so
-rw-r--r-- 1 anders anders  70K 11 feb 21.05 libnpk.a
-rw-r--r-- 1 anders anders 270K 11 feb 21.05 libtinyxml.a

Edit: Forgot we needed to provide freetype on Android.

15

(6 replies, posted in General)

sunnystormy wrote:

I apologize if this seems silly.

Is there a way we could change the naming convention for the "meshs" folder so that it's either "mesh" or "meshes"? "Meshs" is not proper English. Was there a reason that name was chosen?

+1

I have been a little bit annoyed by that too... smile

16

(33 replies, posted in General)

anael wrote:

I should look again to be sure, but I didn't find the flags "ASSIMP_BUILD_BOOST_WORKAROUND ASSIMP_BUILD_NO_OWN_ZLIB" anywhere in the xcode project, or I missed it or it didn't get generated ?

Have you tried create a new build directory to run cmake completely fresh in? Yes, I know it's a solution similar to "Have you tried to turn your computer on and off?" wink

If that doesn't work, can you try replacing

ADD_DEFINITIONS(
  -DASSIMP_BUILD_BOOST_WORKAROUND
  -DASSIMP_BUILD_NO_OWN_ZLIB
)

with

SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -DASSIMP_BUILD_BOOST_WORKAROUND -DASSIMP_BUILD_NO_OWN_ZLIB")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DASSIMP_BUILD_BOOST_WORKAROUND -DASSIMP_BUILD_NO_OWN_ZLIB")

and see if the flags are picked up?

17

(33 replies, posted in General)

Btw, I realized that I tried to include the CMake toolchain files the wrong way (when I played around with an Android build). Updated the instructions for iOS:

iOS
---

To generate an Xcode project for building Maratis for iOS, peform the following
steps to create a build directory outside of the source tree:

  mkdir Build
  cd Build
  cmake -G XCode -DCMAKE_TOOLCHAIN_FILE=../Maratis/CMake/Toolchains/iOS.cmake \
     ../Maratis

Assuming the Maratis source directory resides in the same top directory. The
build require that the Xcode generator is used or it will protest with a fatal
error and quit

18

(33 replies, posted in General)

Tutorial Doctor wrote:

I just went to the wiki just now, you changed that Dahnielson? If so, it looks nice!

I think all the pages need a bit of reformatting. I haven't added anything in a while, trying to get stuff to work first.

Good to have you here also.

Yes, I reorganized and styled it a bit to make it clearer. I started to add some templates so that common stuff can be styled much easier at one place and making writing good looking wiki pages much simpler.

19

(33 replies, posted in General)

anael wrote:

The Xcode for mac is generated.
But there is some error when compiling :

STEPFile.h "STEPFile.h:198:64: Use 'template' keyword to treat 'To' as a dependent template name"

That is weird. Can you post the verbose compile console output (gcc -I./ -L./ STEPFileReader.cpp -o STEPFileReader.o bla bla) that SCons and CMake use to compile STEPFileReader.cpp so we can compare them? It would make it easier to fix the error if I could understand what CMake do different from SCons.

anael wrote:

I don't have errors with Assimp when building with Scons, but maybe we don't use the same version, did you update the Assimp lib ?

Maybe missing the flags "ASSIMP_BUILD_BOOST_WORKAROUND ASSIMP_BUILD_NO_OWN_ZLIB" ?

The code is identical to SVN revision 220, I haven't updated anything. The flags ASSIMP_BUILD_BOOST_WORKAROUND and ASSIMP_BUILD_NO_OWN_ZLIB is being defined in 3rdparty/assimp/CMakeLists.txt.

anael wrote:

Additionally (but not related to the previous error), I didn't see the flag :
"M_PACKAGE_WRITABLE" for maratisEditor (not needed for the player)

Yup. That was an ommision by me. It is fixed now.

anael wrote:

I'm also not sure the runpath search path is defined (depending on the dylib installation path) but should be "@rpath"
or "@executable_path/../Frameworks @loader_path/../Frameworks"

I've gone through and tried to fix all rpaths. Don't know if I did them right.

anael wrote:

With the ios option it stops before generating the xcode project :

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
OPENGL_LIBRARY
    linked by target "MaratisApp" in directory /Users/anaelseghezzi/Desktop/Maratis-ios/M/Additional/iOS

Ok, that is the build system not finding OpenGLES, should probably add a separate OPENGLES_LIBRARY variable instead of reusing the OpenGL one so that the error become more obvious. I have now added better checks.

It's a bit frustrating for me not to have access to a Mac so I can catch all these stupid mistakes myself... wink

20

(33 replies, posted in General)

Dahnielson wrote:
Dahnielson wrote:

Stupid mistake of me, will fix it. Think I was a bit tired when I tried to dechiper the project.pbxproj file.

Think I've pushed a fix to github. Hopefully. smile

Try again.

Did my fix take you any further?

On another topic: I'm thinking of trying to support CMakes companion CPack in the build system to generate RPM, deb and gzip distributions of both binaries and source code for Linux, NSIS files for Microsoft Windows and Mac OS X packages.

255 wrote:

I've sent a pull request. If it's ok, I can then do the other pages.

Thanks! However, I left some comments on GitHub on how to improve it and closed it.

I've also edited the wiki pages that already had content on them into Example sections.

255 wrote:

Oh ok Doxygen automatically puts the link when it finds a class name.
But what if in the wiki I've something like this:

all the properties that will be used by the [[MPhysicsContext|physics engine]].

How can I simulate this in the header file?

Simplest solutions is to just write:

all the properties that will be used by MPhysicsContext.

But I guess (haven't tested it yet) you could do:

all the properties that will be used by the \ref MPhysicsContext "physics engine".

From the Doxygen documentation:

Links to classes

All words in the documentation that correspond to a documented class and contain at least one non-lower case character will automatically be replaced by a link to the page containing the documentation of the class. If you want to prevent that a word that corresponds to a documented class is replaced by a link you should put a % in front of the word. To link to an all lower case symbol, use \ref.

\ref <name> ["(text)"]

Creates a reference to a named section, subsection, page or anchor. For HTML documentation the reference command will generate a link to the section. For a section or subsection the title of the section will be used as the text of the link. For an anchor the optional text between quotes will be used or <name> if no text is specified. For  documentation the reference command will generate a section number for sections or the text followed by a page number if <name> refers to an anchor.

255 wrote:

Hi.
There are old information which was input manually e.g. bottom of MOEntity page.
I can easily put the general description of the class before the API list simply moving it before

{{:classMOEntity}}

but what about the old API information like this one:
http://wiki.maratis3d.org/index.php?tit … ties#Ghost
I guess it should be moved on the header files, although in this case you may loose the links inside the text.

The general description of the class as documented in the header file will be on top of the page if it exist.

Move everything that's possible to the header file. However, the descriptiona in the headers should be brief. So any longer discussions that need to interlink to other wiki pages can be added to the wiki page itself at the bottom.

My idea is that the autogenerated API section will be on top of the page. Below it we can add further sections such as "Examples" or "Discussion" (or whatever we choose to call them) with more details.

Last night I looked into the possibility of writing a bot to edit the C++ SDK pages in the wiki using the XML output of Doxygen. After figuring out how to work with the Mediawiki API I managed to more or less spam the Recent changes list at the end of the evening (since then I've been given the "bot" status thus hiding my changes in the normal listing).

How does it work? Well, the C++ SDK documentation has now two parts: the source-code-end and the wiki-end.

Source code
To document the API we need to put comments into all the public header files in the source code that Doxygen can parse.

Start by forking my Maratis repository at GitHub:

  https://github.com/dahnielson/Maratis

Switch to the development branch of your fork:

  https://github.com/dahnielson/Maratis/tree/development

Add comment blocks with triple slashes (///) to header files in the MSDK/MEore/Includes and MSDK/MEngine/Includes directories:

/// This is a description of class Foo.
/// Descriptions can span several lines if you wish.
class Foo
{
    /// This is a description of member function bar.
    void bar();

    /// This is a decription of member function baz.
    /// \param qux   this is description of the qux parameter
    /// \return          this is a description of the return value
    bool baz(int qux);
};

When you are done commit the change and send me a pull-request. BTW, it is possible to edit files of your forked repository directly in your web browser on GitHub.

Wiki
My newly created bot, aptly named Doxybot, parses the XML output that Doxygen generate from the documented source code and post the documentation to a special wiki page for each class. Doxybot uses the ids created by Doxybot as page name for each class, e.g. the class MBehavior become http://wiki.maratis3d.org/index.php?tit … sMBehavior. However that is not a page intended for humans to edit manually as the bot will overwrite any changes to the pages with names prefixed by "class". Instead the bot page is transcluded into the regular page http://wiki.maratis3d.org/index.php?title=MBehavior:

{{:classMBehavior}}

Everything around the transclusion on the regular page can be edited manually as normal for additional documentation.

25

(33 replies, posted in General)

Dahnielson wrote:

Stupid mistake of me, will fix it. Think I was a bit tired when I tried to dechiper the project.pbxproj file.

Think I've pushed a fix to github. Hopefully. smile

Try again.