Search options (Page 11 of 18)

Are you running the release, or building from svn?

I have Ubuntu on one of my machines at home, I can try and take a look, but I don't remember a segfault when running on Archlinux at all...

Ok, so, I guess first of all, the features I needed from my engine were quite simple, I wanted the highest flexibility in terms of platform as possible. There was one issue here, much as mobile gaming can now be quite lucrative and can get a decent amount of attention... I am not sure if I'm allowed to do mobile games, specifically iOS games, due to my contract at work. I don't think it would cause an issue unless I started making a lot of money out of the game, but because of this I was focusing on desktop OSs with posibility to branch into consoles at a later date if needed.

Secondly, I wanted some flexibility with the engine itself. I have no issue working with closed source proprietary software when it's needed however, previous experiences with such systems have made me prefer an open system where I could change things if I really need to (instead of getting the reply, "sorry, you can't do that with X" on forums/IRC)

Lastly, I needed a community. With my game being a personal project, I don't (currently) have other programmers to bounce ideas off, or help decypher source code and APIs. It doesn't matter so much that the code and APIs are clear and documented (although it's always nice) but more that if I am incredibly stumped with an issue, I could post and say "hey, how would you do Y, I've tried it in the following ways" and get an answer this decade. Again, had bad experiences with other projects.

So, next up is what engines I considered. Well, first up was UDK. A great all-round package. Has some very impressive results and it's relatively cheap for indie development. However it fell down on one point for me. I'm a Linux user. I've done various talks about playing games on Linux and developing games for Linux. Much as I know the linux gamer market share is pretty abysmal, I would feel wrong not contributing to the games available for Linux. Since Epic no longer support Linux, this was out.

Second was the open source id Tech 4 (iodoom3) Again, had great results, far more than I could possibly need. Also, it contains Carmack-code... which adds a certain something to it The issue with this was, mainly, the license. Now, I have nothing against GPL at all, in fact, I think it's a great thing, but it is a little constrictive for indie game development. I fully intend to release my game source at some point, but would be more difficult to get any compensation for the development (I'm currently out of pocket after commissioning artwork)

I didn't bother to look at OGRE again. I used it for a group project at university. OGRE itself is well documented. Has a thriving community. More than good enough for the job. The issue with OGRE is also something you could consider a strength... the plugins. There are plugins for anything and everything. They are all... hmmm... how to put this nicely... well... some of them are crap. We found that after trying to use 2 plugins (which were little more than wrappers for external libraries) we would have saved time to integrate the libraries directly. They're usually half written to solve a specific problem for one person and then released as a generic solution. By the time you've found the issues, you've wasted a lot of time.

I briefly considered Unity, but it has the same issue as UDK in that it doesn't support Linux. Also a few other pet dislikes with Unity, but largely irrelevant.

After coming to these conclusions, I spent a while looking at what other options were available (do I sound too picky yet?) I found Crystal Space and, like you, found it to be a bit of a headache to get anything working, so I decided it wasn't worth it. I had a look at the Sauerbraten engine but decided that repurposing a first person shooter engine for my third person adventure game would be more work than was worth it. XNA had the issue with Linux support.

Then I found Maratis. After sounding so overly critical about other engines, I don't want to make it seem like Maratis is the solution to all my problems, it has quite a few downfalls. However, the main thing that led me to say yes to Maratis is that, the first thing I did was email Anael to ask a couple of questions. He replied quickly in a friendly manner and was helpful and competant. After that I sat on the forums a bit, firstly just reading and seeing the frequency of posts, the content of them, and later, responses to my posts. Again, I found the forum, although not exactly busy, to be reasonably active and helpful. The issues with Maratis that I came up with are firstly the lack of proper publishing support, something I ended up contributing to and the lack of extensibility in the engine. Now, I don't want this to sound wrong at all (incidently "Anael's Wrath" sounds like a good title for a video game... ) Maratis hasn't got a lot of bells and whistles. It does a job and it does it pretty well, but there's nothing extra. Also, the design of Maratis is sort of geared towards a small, sleek engine. Bulking it out with the plethora of features that can be found in something like UDK would for one, probably reduce the average code quality, but also increase the complexity of Maratis. You could technically put any extension work you wanted into the game plugin DLL, or standalone game project executable if that's what you wanted but that doesn't lend toward generalised solutions and reusable code. Anael then mentioned that he actually had a plugin system, but it was removed from the release. Of course, if the plugins were enabled again, it might lead to a situation similar to what I found with OGRE, where there are many sub-par plugins. However I think it's the right path to attempt, and I think Anael does too (I'm not putting any words into his mouth here )

I think this deserves a tl;dr... so here it is:
tl;dr: UDK - no Linux support,
iodoom3 - GPL too constrictive,
Unity - no linux support,
OGRE - *shudder*
Maratis - not as "complete" but active, open and friendly

I had this dilema at Christmas. I originally was intending to roll my own engine last year (got a good deal of the way through it too) but I realised I couldn't handle gameplay coding as well, on top of a full time programming job. This little brain can only take so much programming If it helps your decision at all, I can explain the research I did and reasons etc for me choosing Maratis over other more pedigree engines.

Right, I've finally had time during my lunch break to get this working properly. I have it loading the shader from a file and I have it (theoretically) reloading when I press spacebar. It's a bit flakey for some reason, and I don't like the fact that I have to give an absolute path for the shader filenames. Can I change M_fopen to look for files relative to MaratisPlayer, then the mproj, then global maybe?

Anyway, I'm now pulling apart the drawTexturedQuad code and I'll probably put this into a PostRenderManager type thing and stick it into the tutorial The thing I don't understand though, how is the texture being passed to the shader? From what I can see, it's sending an empty texture, I assume it probably filles it with whichever texture has been passed to bindTexture. What's the easiest way to get the depth buffer passed in too?

Hmmm, I can see why that's done then. I guess I can include the MDevILLoader then. Unless you would prefer registering a data loader inside MGui too. Thankfully MDataLoader is in MCore, so that shouldn't be too much of an issue. Generally speaking, MEngine can then setup the MGui image data loader to the same as what it uses.

Anyway, I'm no sure exactly when I'll get time to look at this. I might have time tonight, but it's quite possible I'll be busy again.

lqez: Great to hear from you. NPK has been a pleasure to work with. I've yet to find any issues with it. I would request that maybe there could be a little more documentation (as with everything) If there's any way I could help with that, I can try I don't pretend to know how libnpk works inside out, but I can do my best

I guess when I find out, I will add it to the tutorial then too

I've been far busier than I anticipated. I finally managed to spec out a little of the next stage, I'd like to have some feedback on the plans I have so far, especially from anyone with any experience making an FPS in Maratis as to what features I'm likely to need. To be honest, much as my name is in the credits of an FPS game I wouldn't presume to know what might be needed in setting one up from scratch in Maratis.

I have, however, been trying to acquire an environment from my friend Umar, which would probably be licensed CC BY-NC-ND. So at least the game should look pretty

Nice, where did you find that?

Ok, to begin with, the version numbering, yes, maybe something like

// in some plugin
bool StartPlugin(unsigned int maratisVersion)
{
    if(maratisVersion != s_pluginRequirement)
        return false;
//...
    return true;
}

But also, it might be worth allowing for plugin version numbers. I'm not sure if it should be in the same method, maybe filling a version number reference. Not entirely sure. Anyway, then you can have plugins dependant on specific versions of other plugins.

I will have a look at MGui and see whether I can pinpoint any specific memory issues, I think it's worth making dynamic as it's something that plugins will almost definitely want to take advantage of.

The issue with using the MGame::draw virtual is that we can only have one game, which should be implemented inside the game.dll. If there are other plugins, they can't really add to this. I was considering maybe something like registering something in the MPlugin to update and draw. Some plugins can then ignore it when not needed. Not sure.

MRenderingContext looks like exactly what I was looking for. I was intending to integrate Love2d more fully and remove GL calls and replace them with engine specific ones, so MRenderingContext calls should be able to do the job nicely. Quite a bit of work, but worth it in the end, I think. Anyway, I'll keep poking and see what I come up with.

Thanks for the reply

I've been very busy with various things, but I've been slowly progressing with the profiler. Just a bit fed up with putting tags throughout the Maratis code Time consuming and boring. Almost done though.

Anyway, a couple more things I wanted to ask about. Firstly, the plugins, for ones that aren't game.dll, what do you think about a version number system, so we can add dependencies and ensure they've got the correct features. I can add that to the stuff I've been working on, if it's approved.
Secondly, in terms of drawing things, for MGui things, I should be able to just access MGui if I build it to a dll, right? And I can create a child window? Or should I try to work it into the existing UI layout? This might cause problems though if there are multiple plugins which add their own UI stuff.
Finally, and still on drawing things. What should I do if I want to draw things directly? Would just using GL calls work do you think? In particular, I'm considering integrating the Löve2d engine into a separate plugin which I can then use for a data driven UI solution.