next »

[_Tommo_]

so, the time has come to introduce the stuff I'm usually rambling about in Technical..

the... wait for it...
Dojo Framework!
Tutorial & API Reference, random screenshots
and even the source of a jam game
IRC channel: irc.freenode.org /join #dojocpp

Dojo is a 2D and 3D engine that I've wrote in C++ the past years, following an approach at the opposite to the classic "engine guy": I've only added those features that proved themselves needed for a real feature in a real games/experiments.
This resulted in what I think is a quite complete and efficient to use C++ engine, trying to expose the power of the language rather than its flaws.

Features:

• C++ and open source: the engine itself and all of its dependencies are free and open-source, because devs should be able to choose what they use.
• Cross platform: runs on potentially anything except Windows Phone, has ports for Windows, OSX, iOS, Android and Linux.
• High level: even if it runs on OpenGL like SFML or SDL, it doesn't require to know OpenGL; and all of the objects such as Sprites and Sounds are managed and garbage-collected.
• Structured Resource pipeline: most of the Resources' properties are deduced straight from the filesystem, so the code required to manage them is minimal, eg: to create an animation, just name the frames "frame_1.png" "frame_2.png" "frame_3.png".
• Gameplay logic: contains much of that gameplay stuff that everyone always has to code from scratch, namely Hierarchic States and Events, helping to divide "framework" and "game" code.
• Sane serialization format: dojo is integrated with a JSON-like data definition language that is used from everything from font definition to save states... parsing files manually is sooo 90'!
• Multilanguage: Strings, TextAreas and the format above, all support the whole Unicode; and localized resources are automagically loaded from "foo/en", "foo/it", "foo/se" etc folder depending on the detected region.
• Fast rendering: it contains no trace of immediate or even worse software (uuh) rendering, and draws everything via an optimized VBO+VAO path.
• And utilities because why not: glm math is integrated, along with Perlin noise, a Mersenne twister, A* and a std::string extension that is actually decent.

What is missing
Dojo is still very much alpha... and the downside of my approach is that things that I never needed are not there.
Obviously that might change!
some include:

• Shaders: added!
  
  • Editors: I think that editors to be effective have to be tied as closely as possible to a given game, so I always implemented them in the game itself to avoid restricting what I can do with the engine, just like many other engines did.
  • Skinned meshes: they are huuuuuuuge!
  • Android: it is mostly there thanks to a daring contributor!
  
  Anyway, I think it has become mature enough to be useful to someone to make quick games or something, so I'm leaving this here!
  I'll be happy to hear critics, suggestions and everything
  
  Oh, if you didn't notice, here's an hint: there's tons of documentation in the links at the top!

[InfiniteStateMachine]

Looks good. Following on BB

One question. In your description you mention an animation being a series of png images. Does the engine merge these into a larger atlas in memory to reduce draw calls?

[_Tommo_]

Looks good. Following on BB

One question. In your description you mention an animation being a series of png images. Does the engine merge these into a larger atlas in memory to reduce draw calls?

Thanks

Nope, it doesn't, but you can!
Providing an image sequence is the "quick prototipying" format for the animations; you can use an atlas by providing an .atlasinfo description file to define the frames in an image, just like in the sample

[eigenbom]

Wow, cool stuff dude.

[_Tommo_]

Thanks guys
The Mac port was actually broken until today, because I switched to C++11 + some refactoring, and it needed some work... but rejoice, it works now!

I'll make the tutorial tomorrow, trying to be as general as possible because XCode is godawful crap and it isn't easy to give simple directions which always work... stay tuned!

Also, the Android port is complete and we're proceeding to backport it into the trunk asap... we switched from PocoZip to plain zzip though, so after the merge it will require some updates to the projects.

btw: I'm planning to have stable version releases like any normal software eventually, but I prefer to not freeze interface/libraries for now as it's still quite young.

[Average Software]

Your SAFE_DELETE macro is actually the precise opposite.

The only pointer value that is guaranteed to be safe to delete is NULL.  The fact that a pointer that is pointer is not NULL does not mean that it is safe to delete.  It could be uninitialized, dangling, etc.

I can see this being the source of a lot of errors.

[_Tommo_]

Your SAFE_DELETE macro is actually the precise opposite.

The only pointer value that is guaranteed to be safe to delete is NULL.  The fact that a pointer that is pointer is not NULL does not mean that it is safe to delete.  It could be uninitialized, dangling, etc.

I can see this being the source of a lot of errors.

heh, that's true in a way, but actually I found out that when I ended up deleting a NULL it was always due to a bug somewhere.
So, I know that delete can safely be passed NULL pointers, but to me it makes no sense, so I've removed that behaviour

[pinaster]

what a good job we have here 

[_Tommo_]

Looks cool! 

 I haven't tried it yet, though, because I don't know how to set up the Xcode project. Could you post a tutorial on that? 

Here's the tutorial, fresh from the presses: Building with XCode.

It still needs a bit of fixing for iOS, though.

[_Tommo_]

Just passing here to say that we've fixed the iOS port AND we finally merged the Android port into the trunk

And yeah, more docs are still planned!

[eclectocrat]

Just passing here to say that we've fixed the iOS port AND we finally merged the Android port into the trunk

And yeah, more docs are still planned!

Very cool, colour me interested.

[_Tommo_]

Thanks

Today I've made the effort to document each single assertion(!) with an error message plus some info (they were more than 300), hopefully now it should be possible to understand what happened without digging in the code!
Should be especially useful when you use dojo as a lib+header instead of compiling it each time from source, and anyway it's a very neat way to document the code.

Now I'd really "need" someone to use it, it is hard to mantain the code and the ports if someone isn't using them constantly.. so many bugs go unnoticed

[Serapth]

I would HIGHLY... so HIGHLY I used ALLCAPS, consider renaming it.

Dojo is the name of a very successful JavaScript framework, as well known in JavaScript circles as say... SDL or Havok in game developer circles.

It will make your project very hard to find for people Googling for example.

[_Tommo_]

Yeah I know (now at least)... but when I started it as a small game about ninjas the namespace was Dojo and it stuck.
I know now that I should rename it, but TBH I like the name, and until now I had no plans about it
And right now it has another major problem with searchability, as it's only on bitbucket: in fact this thread comes up higher than the official repo in all the searches I tried
So, yep, stumbling on it from google looks like impossible right now...
I will consider renaming for sure if/when I decide to "market" it better with a site, a forum, a twitter, etc.

But I make engines because I hate this stuff, why, WHY you have to "PR" everything you make today?

[Serapth]

It's stupid you have to think about this stuff, but frankly if you want discoverability you do.  That's why you should always try to make your name as unique as possible.

This is one of those big things that is going to hinder RIM's gameplay sdk for example, also make searching for help with LOVE a right pain in the ass.

If you don't ultimately care about people stumbling upon your project, or don't see it getting big, no worries.  But then, most people dont really see how big things are going to get, until they get big.

[_Tommo_]

(it's been a while, but)

yeah, I think you're right, it's just... I don't feel like changing the name of the thing!
I guess that at first I will go for a site that specifies quite well that it is a GAME thing (google is able to tell things apart pretty well nowadays) so that gaming, or C++ queries will find it pretty well.
And thennnn... if it still doesn't show up in google's "three results", I'll have to change the name

btw, I'm working on a branch to move to OpenGLES 2.0 (shaders! full 3D!), and to add generic collisions.

Until now I've left out collisions on purpose, because I couldn't really abstract something from the games/experiments I made...
a shooter, a platformer, a turn based RTS and a roguelike have basically nothing in common in terms of game physics, but I'm still tired of reinventing the collision wheel each time.
Apart from dropping box2D in it, I was wondering if anyone tried to design a collision system that's simple but generic too

[Cloudiest Nights]

I have no idea how to do any coding with C++, so I went and started downloading Visual Studio 2012. Let's see if I can learn this language 

[_Tommo_]

So, shaders!



They currently work only on PC though, but the long-term plan is to phase out the FF pipeline and make a shader-based renderer!

A Linux version is also in the works thanks to a contributor, and we have an experimental Android one

Also:
if you have quick questions or you just can't figure how to setup the damn thing, you can (more often than not) find me on this new IRC channel:

irc.freenode.net
#dojocpp

IRC is old but gold

[eigenbom]

ooh pretty!

[Dr. Cooldude]

Can't believe I haven't been following this. Looks neat!