201 Topic by Nistur

(45 replies, posted in Showcase)

So, I've finally got something to show for the particles. It's FAR from complete yet, but at least it's something.
I don't think I can embed youtube videos here, so I'll just link them.
Firstly, textured particles.
http://www.youtube.com/watch?v=i20skmd_zi0

Next, untextured particles, but creating an interesting trail.
http://www.youtube.com/watch?v=dYdSG9Z2alI

What it's doing right now is rendering, I believe no more than 1000 particles, usually quite a few less, as point sprites. This means that it's very limited in what they can do (no change in size based on age for example, no rotations,...) but they're fast. I haven't got any empirical evidence, but I think, even with my rudimentary update, any bottleneck will be that, rather than the rendering. They also have "gravity". Unfortunately, Maratis doesn't currently expose the gravity, something I'll probably change, so it's a hard coded number, but that makes very little difference. The particles have a random spread, up to a value defined in the editor, so can make circular explosions (as in the untextured video) or a more targetted spray.

What is still to be done:

  • A lot.

  • Different blend types (Additive being the most important)

  • Exposed particle sizes to the editor.

  • Non-Point sprite particles:

  • Particle growth/decay

  • Rotation

  • Physics:

  • Using Maratis scene gravity

  • Sphere collision with particles

  • Sphere collision with (some) world objects

  • AABB collision with world objects

Other ideas:

  • Attractors?

Go to forum: Showcase

202 Reply by Nistur

(12 replies, posted in General)

Ok, first of all, I've not been able to compile with python3, I've had to use python2, but you've already figured that much out.

Secondly, scons requires Visual Studio (or, at very least, Visual C++ Express) in order to do the compiling. You can download it for free at:
http://www.microsoft.com/visualstudio/e … pp-express
It would appear that this is probably the problem (No installed VCs)

Go to forum: General

203 Reply by Nistur

(10 replies, posted in Gossip)

have a good time. My stepbrother went recently and had a great time. I am very jealous tongue

Hopefully Vegas and I will be able to keep on top of things for you :h

Go to forum: Gossip

204 Reply by Nistur

(10 replies, posted in Gossip)

I should be online most days, so I will do what I can to answer questions. If Vega's already a mod, I won't intrude upon that priviledge wink

Go to forum: Gossip

205 Reply by Nistur

(2 replies, posted in Gossip)

I thought it might be worth putting down a few examples for other people to consider. I wish I could devote time and commit to developing all of them, but hopefully if we throw some ideas around, someone will see something that they like and put their name in for something.

I don't mean for there to be any pressure at all, in fact, it's probably just as worthwhile people saying "I would really like to see a plugin with X" than saying that they will look into one or another of them. That way, there can be a discussion about what things can work and what are entirely infeasible.

I have a few things I would like to start off with RE. the plugins. The first is, something that Anael mentioned is that iOS wouldn't support plugins as they can't have dynamic libraries. I think it would be beneficial to decide early on a framework by which we can have both static and dynamic libraries as plugins. Secondly, something I recently stumbled across that people might find interesting. Volumes Of Fun are a dutch indie game dev studio, but they've made a voxel engine library which might be nice to plug into Maratis. People like voxels tongue Also, slightly more unrealistic, but I would love one of these headsets. I think it would be great to have a brain controlled Maratis game wink One final thing which I think Maratis would really benefit from, but is probably too heavy for the main game engine is a more comprehensive plugin manager, handling updates and "installing" plugins to game projects.

Anyway, hope to get some more feedback, and hope we can get the plugin system submitted and running soon so we can start making some great plugins to go with this great engine smile

Go to forum: Gossip

206 Reply by Nistur

(13 replies, posted in Engine)

That's great then, I will try to document the things I've had a hand in working with this week and maybe try to get some code snippets in there as examples.  I should have some time to get at least that done smile

Go to forum: Engine

207 Reply by Nistur

(150 replies, posted in Engine)

That's awesome! Now the whole game can be packaged up nicely tongue

I think there are some more things I would like to add at some point, as I said before, specifying the tea key for publishing and loading would be nice. Also, I'm not entirely sure I've done this, but I might: It might be a good idea at some point to check whether multiple packages do actually work. They're not needed in some games, but if you have a couple of smaller packages, you could more easily provide updates without having to replace _all_ the data wink either by layering packages on top, or just replacing older packages for newer ones.

Go to forum: Engine

208 Reply by Nistur

(13 replies, posted in Engine)

Thanks, I will try that later today. Unfortunately I haven't been able to do much today, I did, however, start writing a bit on the wiki, I have begun to fill out the API on the MFile interface. Before I continued, I wanted to check whether what I had done was acceptable. The start is here.

Go to forum: Engine

209 Reply by Nistur

(3 replies, posted in Editor)

I just had a quick look, that has fixed the problem, thanks smile

Go to forum: Editor

210 Reply by Nistur

(13 replies, posted in Engine)

That would be great! Just point me at it when it's done and I'll start writing tongue

Go to forum: Engine

211 Topic by Nistur

(3 replies, posted in Editor)

For some reason, whenever I press any non-character key in Maratis editor under Linux (eg, Enter, Shift, Ctrl...), if I have a variable selected, it will put the character ÿ. I am currently using the svn build, I'm not sure whether this will happen on the precompiled version. Off the top of my head, it seems like a default value for keys it doesn't recognise. If Maratis had wide character support, I know there's a difference between how Windows and Linux treat wide characters, but that's probably not the issue.

I am just about to start cooking, so I can't look into this right away, but I'll try to this evening some time if noone comes up with a magical solution beforehand.

Go to forum: Editor

212 Reply by Nistur

(13 replies, posted in Engine)

Oh, that's alright then, if it doesn't work for now, I can work around it using just a string, can easily be replaced later.

I would like to use this again to bring up the possibility of a wiki with API reference. I am willing to host it myself if that makes things easier. I would be happy to contribute with what I have discovered, including sample code.

Go to forum: Engine

213 Topic by Nistur

(13 replies, posted in Engine)

I'm slowly trying to get this particle system working. I've confirmed that it compiles and runs nicely on both Windows and Linux (yay!) and I've started looking at texturing, however, I can't seem to work out how the M_VARIABLE_TEXTURE_REF works.

I have got a MTextureRef as a member, I've initialised it with m_Texture(0, "", false) as I would assume this would make an empty reference. I have then passed this variable back to the editor within getVariable, however, all I get is a section in the editor which says Texture, but won't let me do anything. Is M_VARIABLE_TEXTURE_REF just read only? Will I have to read a string and then load the texture from that?

As always, I'm still looking into this issue, so I might reply to myself in a bit with a "Eureka" tongue

Go to forum: Engine

214 Reply by Nistur

(5 replies, posted in Engine)

Thanks, That will make things a lot nicer.

Go to forum: Engine

215 Reply by Nistur

(5 replies, posted in Engine)

That seems to have fixed it. It also seems that one of the computers I was having it tested on didn't have the VC++2010 runtime installed on it, so I was having different results with an older version, which was using the prebuilt binaries (VC8 I assume) and the ones I built.

This is quite helpful. Just checking, can we get, from a game/plugin whether it will be using the fixed renderer? So we can display a plugin.

Go to forum: Engine

216 Topic by Nistur

(5 replies, posted in Engine)

This is a bit of a strange one, Maratis Editor seems to run fine with OpenGL 1.4, whereas Maratis Player (or when you run the game from within the editor) just displays a blue screen.

I realise that OpenGL 1.4 is ooooooold now and the solution would be "get updated drivers/graphics card which supports newer OpenGL" but I was just wondering, What is it that's stopping the "game" from rendering normally, whereas the 3D view within the editor renders fine. Is it possible to force a switch to a "low def mode" for 1.4 cards? Games themselves can implement some sort of popup or message of some form saying "Game is not optimised for this graphics card so may not display as expected".

I just think that, if this can be sorted, at least in some way, it can only improve Maratis. Plus next week I will be away from my PC with my netbook which only has a i945 GPU, so if I could persuade this to work, I can be more productive wink

Go to forum: Engine

217 Reply by Nistur

(10 replies, posted in Engine)

Hmmm, that might be why I found it difficult to find documentation on it. I'm currently still busy with some of the particle functunality so I have no immediate need right now. I don't mind adding them myself either.

Go to forum: Engine

218 Reply by Nistur

(10 replies, posted in Engine)

I will probably end up drawing some particles as quads or tri lists, in order to allow for rotations, which I don't think point sprites can support. But I like the idea of being able to potentially have more particles for cheaper in some situations. A simple flag should take care of that I think.

Anyway, thanks. I'll see what I can do about that. Hopefully it will be that simple wink

Edit: On second thoughts, I'm not sure whether we want to put glEnable(GL_POINT_SPRITE) in init, potentially people might want to be able to draw points without sprites? Not sure... I'll put it there for now anyway

Go to forum: Engine

219 Reply by Nistur

(10 replies, posted in Engine)

So, I've started writing my own particle system now. It's coming along pretty well. I have everything fairly neatly working together.

So that's not a problem. The issue now is that I'm using M_PRIMITIVE_POINTS, which gets me nice, 1px sized dots. Not entirely useful for a particle system. It would seem that OpenGL, at least has an extension allows you to glEnable(GL_POINT_SPRITE). It's currently not exposed in Maratis. I was wondering whether there is a reason for this, before I look into potentially adding this to the renderer.

Go to forum: Engine

220 Reply by Nistur

(10 replies, posted in Engine)

I will take a look, but pos3Ofs is 0, and pos is the first member of the struct, so it looks sensible.

I've cast ptr to what it's meant to be (from reading the code) and it definitely looks like the array isn't corrupt. I guess it's just the fact that all the data's packed together.
http://nistur.com/maratis/particles.png

I guess I'll have to repack all the positions. Ahh well.

Heh, it seems that the particles are kept in a std::vector, and it gets uses &list.begin() as the start to the array and then &(list.begin() + 1) - &list.begin() as the stride. That would explain why it was coming out as 144 rather than 136, the sizeof(PAPI::Particle_t). I think that's enough, I'm going to give up on this particle system, maybe look for another one to replace it, but probably just write my own.

Go to forum: Engine

221 Reply by Nistur

(10 replies, posted in Engine)

Thank you, I will try that. As may be obvious at this point, I'm getting quite confused at this point with this library. I'm seriously considering starting again from scratch tongue

It seems to be that the array it gives back in ptr is the array of particle structs, which have all the information within them you could need. The idea is that you just use that array, pull out the bits you want each time and stride over the rest of the information. This seems insane, to send all this information to the GPU for rendering, when it would never need the mass of the specific particle, or it's age. I just did a quick check and sizeof(PAPI::Particle_t) comes up as 136. At the moment, I'm just trying to use the colour and position, that's 24 bytes per particle we need to send, I think right now it will actually send 136*2, right?

I should also point out that it's currently using the rendering code from the Particle Systems API example, just with GL calls translated to MGui renderer calls. Can't wait to get rid of points and put alpha images there...

Go to forum: Engine

222 Reply by Nistur

(47 replies, posted in Tutorials/Examples)

No code in this one, just an overview of how to go about tidying the code and making a more pleasant development environment, along with instructions of how to start a debugging session simply.
Tutorial 9 is up.

Go to forum: Tutorials/Examples

223 Topic by Nistur

(10 replies, posted in Engine)

I've been having a play around with this particle system. I'm slowly getting somewhere, however it's currently crashing after a while. It seems to be possibly that it might be a buffer overrun or something. Just a few questions.

Firstly, is drawArray a synchronous call or does it get batched up? If that's the problem then that would potentially be the problem as I don't think the arrays I'm giving it are necessarily going to live that long. Secondly, there shouldn't be any theoretical maximum to the size of the array, should there? It's currently trying to draw 500 particles and complaining.

I think I'm going to have to do some serious rewriting on this particle system to get it to do anything sensible, "just for fun" I decided to render only 1 particle, but update 10,000 of them and the framerate dropped to a slideshow. Now, most particle systems shouldn't need that many particles, but potentially, over an entire scene, that's not an overly obscene amount.

Also, I'm not entirely sure if this is normal, but when I "GetParticlePointer" then it returns one giant array with all the information about the particle stored in it, with offsets to each of the different information within each particle. Much as this would be incredibly useful if the particle calculations are to be moved to the GPU, I think sending all of this in a giant array may be overkill for rendering.

        cnt = m_Context.GetParticlePointer(ptr, flstride, pos3Ofs, posB3Ofs,
            size3Ofs, vel3Ofs, velB3Ofs, color3Ofs, alpha1Ofs, age1Ofs,
            up3Ofs, rvel3Ofs, upB3Ofs, mass1Ofs, data1Ofs);
        if(cnt < 1) return;
        
        render->enableColorArray();
        render->setColorPointer(M_FLOAT, int(flstride) * sizeof(float), ptr + color3Ofs);
        
        render->enableVertexArray();
        render->setVertexPointer(M_FLOAT, int(flstride) * sizeof(float), ptr + pos3Ofs);
        
        render->drawArray(M_PRIMITIVE_POINTS, 0, cnt);
        render->disableVertexArray();
        render->disableColorArray();

Is this correct or am I making a stupid mistake somewhere? I will try and look for answers myself too smile

Go to forum: Engine

224 Reply by Nistur

(16 replies, posted in Showcase)

It's great to hear that you've been checking my website. I've got to say that writing the tutorials has got me to learn quite a bit about how Maratis works. I've started working on the particle system again this morning. Already debugging the crash so I know why it breaks.

With regards to you extending what I have done, if you want to make any additions that you think would be helpful to other readers, I would appreciate the contribution wink

Go to forum: Showcase

225 Reply by Nistur

(16 replies, posted in Showcase)

What I meant was just how the API was structured. With love, there is love.graphics and love.keyboard etc... rather than everything being a global function. It makes it quite easy, when looking through documentation, or even through the code itself, to have a good idea what you're looking for and what you're expecting to find. I don't want to sound like I'm picking at Maratis in particular, it's quite common from what I've seen. I was just saying that I think it would be nice to break up the functionality a bit.

I have no particular dislike for SCONS, I find it a little overengineered quite often, but it does it's job, and usually does it well. I can see why people might dislike it though.

Also, I just thought I would make a small anouncement here. I hope you don't feel like I'm hijacking your thread. I've got the rest of this week and next week free. I had holidays I needed to take. I should therefore have significantly more time to work on the whole particle stuff so hopefully soon I can demo that and I'll probably use my own game and finally show some screenshots of it.

Go to forum: Showcase