101

(11 replies, posted in Engine)

Thank you, that worked great. Here's the beginning of a "dialogue box", this one is particularly smiley. And the stretching in this case is on purpose. Now to hunt for textures

http://img96.imageshack.us/img96/5779/smilekg.png

102

(11 replies, posted in Engine)

((sorry for the delay, I had to wait until my lunch break to actually test it))

No, it's actually rendering nothing at all now smile But I'm quite happy to say that it's probably some of the crazy things I'd tried to get the thing displaying properly before that I haven't un-done yet. I will fiddle more tonight smile

103

(11 replies, posted in Engine)

... I'm sorry... clearly my mind wasn't working well this morning.

Thanks smile

104

(11 replies, posted in Engine)

I'm trying to do some orthographic drawing and everything's looking squashed and in the wrong place. I have no idea what I've managed to set up incorrectly.

Oh, and another thing is that for some reason the setup that I assumed would be right, gave {0,0} at the bottom left (huh?)

unsigned int w, h;
system->getScreenSize(&w, &h);
render->setOrthoView(0, w, h, 0, 0.1, 1);

render->enableVertexArray();
render->enableTexCoordArray();
//...

I did also have render->setViewport(0,0, w, h); in there to test, but it did nothing.
The vertices I'm trying to draw are two quads from {0,0} to {200,200} and {100,100} to {300,300}.

http://img26.imageshack.us/img26/3357/squashed.png

Any ideas?

105

(2 replies, posted in Gossip)

Having had a couple of issues with rendering some videos with Blender to look right, I have had a thought for another potential plugin that shouldn't be _too_ hard to do.

MVideoDirector!

I think, the most basic thing that can be done for this is that we can set up a scene in Maratis with camera pans etc, test it by running the game. We can add a behaviour to the camera which does nothing much, and just has a single boolean for recording... The (custom) MGame instance can then check for this behaviour on the current camera, check the variable, and then either do normal drawing, (and?/)or render to video.

I'm not sure whether there would be any issues with the draw taking too long. I know Maratis logic is locked to 60fps, but we would really need rendering to a stable framerate (well, to be syncronised with logic, so even if a frame takes 1s, it still thinks of it as 1/60)

Anyway, this was just a thought I had, I'm definitely not going to be picking it up now. I just thought I'd mention to see what people thing

106

(12 replies, posted in Engine)

Ok, I will submit that in a bit. I'm just getting a segfault and I'm trying to figure out where it is. It's only when I call a function I specified... But only after it's already returned to lua... So yeah, no idea what's going on with that right now

107

(12 replies, posted in Engine)

you still need to register MScript::function to respond to the calls from lua (otherwise the symbols are all nil). This is only ever done in MScript::init()

Either MScript::init() needs to be called the first time we run the script (rather than when MScript is initialised), or we manually link MScript::function to the function name in MScript::addFunction. As long as we always add to the map, either way should work, if MScript gets restarted, MScript::init() will then re-link any previously added functions. It's just really a case of whether there was a particular reason MScript::init() was being called on construction, or if it's ok to leave it until we run the script.

108

(12 replies, posted in Engine)

I have just confirmed, for my use case, this definitely fixes the problem. Is it ok to submit this?

109

(12 replies, posted in Engine)

It finally occurred to me what's happening.

MScript calls init() on construction, to add all the functions to the lua state. It doesn't call init again unless runScript is called when the script is already running. Therefore, adding functions manually, like I suggested, won't work because it's post-init but pre-run. m_isRunning will be false. The choice then, I think, is either to always call init() on runScript (and not on construction) or to blindly add the function to the lua_State, regardless of whether the script has been initialised, running or whatever. Personally I think the former is best, but I don't know if there was a reason this wasn't done before

110

(12 replies, posted in Engine)

Other people go out on a Friday night, I sit on a train, coding... or trying to...

Anyway, I've investigated this further. I've finally set up my netbook to easily switch between 3 builds of Maratis (stock distribution, svn dev build and MIngEd dev build) so I can now finally build Maratis and not have to manually copy files over...

Not important. What I have found interesting is that init() is called LONG before the game plugin is loaded... so the reason my functions aren't being found is because it's just being added to the map, but not to the lua_State.

my suggested fix is to change this:

void MScript::addFunction(const char* name, int (*function)(void)){
    m_functions[name] = function;
}

to:

void MScript::addFunction(const char* name, int (*function)(void)){
    m_functions[name] = function;
    if(m_IsRunning)
        lua_register(m_state, name, ::function);
}

I think that should probably fix it. Unfortunately, my train journey is almost over, so I don't think I'll have time...

111

(12 replies, posted in Engine)

Nope, that didn't work. It seems to be that at all points where I can realistically put addFunction, it's before the script is initialised

Registering script functions
Starting script
First script update (getBehavior: nil)

The first line is from within the register function that I've been trying to call from various places, the second is from within the script, outside any functions, the last is the first update of the script.

I have no idea why this might be happening, as the MScript setup seems to be that it should add the functions on init(). This is particularly difficult to debug, as I have to build both Maratis, and the game together... I'll see what I can find out

112

(12 replies, posted in Engine)

Behaviours get added automatically with static objects when the plugin is loaded currently, but I'll try adding it to startPlugin later, see if that makes any difference. Thanks

113

(12 replies, posted in Engine)

I have no idea whether this is a bug, or something silly I'm doing.

I have a collection of functions I'm trying to add to lua. As far as I know, I'm registering them correctly:

MEngine* engine = MEngine::getInstance();
MScriptContext* script = engine->getScriptContext();
if(script)
    script->addFunction("broadcastMessage", ScriptBroadcastMessage);

int ScriptBroadcastMessage()
{
    //...
}

I've tried registering the functions on MGame::MGame(), as a static object when the plugin is loaded, and on the first update of MGame. I've checked the value of broadcastMessage from lua on the first update, and on 10th update, and it's always nil.

As I have said, this is probably my fault, but I can't see what I'm doing wrong...

114

(0 replies, posted in Engine)

So, I've been doing a little work here and there. There is something I would like to add to Maratis. The main thing is the extended lua API system which BitPuffin started working on.

Adding multiple npk packages into MPackageManager is incredibly trivial (I think most of the code should actually be there now...) So the nicest way would be to package a small collection of default data into an npk and distributing it with Maratis. This could contain things like assets for error messages too.

Now, when you publish a game, the idea is that we're trying to have a (relatively) small amount of files. Having a Maratis.npk there is one more than needs to be. I think there are two choices here. Potentially, what we could do is extract the entities from the system npk and write them to the project one... or... we can try to embed the npk.

In theory the second one isn't difficult at all. We just have some memory within Maratis (probably MCommon) which contains the npk file. I've written similar systems before with success. I have also recently sent some code to lqez, which he has submitted into the npk repository, which will allow using custom read functions (like our MFile wrappers... if we use them, we could actually theoretically have an npk file within an npk file... hmmm) I think this would be a pretty nice way to include a small amount of default assets.

Now, some pros/cons
+ Doesn't increase the amount of (potentially confusing) files in a Maratis distribution/game
- Requires an extra pre-build step to generate a C file with the data
+ Can be extended to include a couple of other useful things.
- Increasing executable size
+ Unable to break with accidental "upgrade"
- Unable to upgrade post-deployment

Of course there are more. I won't do any work on this at all unless I get a go-ahead. I just thought I'd dump my thoughts on this matter, open a debate, see what happens smile

115

(18 replies, posted in Showcase)

That's cool. I had a lot of fun when I was writing the driving mechanics for a game we did at work. It's nice having things like this with pure numbers you can put in (torque, grip, stearing etc) and can get something actually different out of it.

Never did 3D vehicle collision though, so no flips for me.

Looks amazingly fun to play with smile Keep up the great work smile

Right, I've just submitted this. It compiles and should work, but I haven't had a chance to test it. Basically, I've kept callFunction in there, but all it does is:

if(startCallFunction(name))
    endCallFunction();

with startCallFunction and endCallFunction doing the actual work. In theory, this should do it.

We've already discussed this before, but I thought I'd make a separate thread in a more logical place.

Basically, what's going on is that in order to give parameters to lua, we need to push values in. This is all fine. We can do this. But then we also need to give a number to lua_pcall to tell it how many arguments(so it knows how many to take off the stack). This is also not too much of a problem.

The problem is when we need to push the arguments after we give it a function to look up (so we say, "we have this function, here are the arguments, oh, and by the way, can you call it with 4 arguments?")

I've looked into popping the arguments off the stack, then calling lua_getglobal to find the function, then pushing them back on, but this isn't really realistic for a couple of reasons, firstly, we need to find some way to store them temporarily, and we also need to be able to store them in a general way (so not, for example, convert them into strings, as we lose context)

At this stage, I'm open to suggestions as to how I can patch this. The easiest way I can see is splitting the call into 2 functions (beginCallFunction(...) endCallFunction(...)) and then wrapping them in callFunction if there are no arguments. For arguments, they can be done in between begin and end. Alternatively, we could somehow build a stack ourselves, and pass the stack to callFunction. Finally, can continue down the popping/pushing route I started taking, but that looked pretty painful...

118

(35 replies, posted in News)

That is really cool! Everything's nice and simple smile

119

(18 replies, posted in Showcase)

cool! How are you doing the vehicle handling? One contact point per wheel, one per car? What kind of things have you got to tweak and play around with?

120

(24 replies, posted in Engine)

Hmmm. The issue with the submesh thing is that you can't then have complex models with lods. I was thinking that having a behaviour switching the mesh would allow for that... but I guess the submesh thing would be suitable for most situations.

I don't think the material animation thing is really feasible though, as you would need changeAnimation(obj, "SomeAnim" .. lodlevel) which gets a bit messy...

I will have a look at making a behaviour to switch the submeshes (although, I don't have a model I can test...) If it works, I will put it forward as a potential behaviour to integrate into Maratis. By the way, there are some generic behaviours here that might be good at some point to integrate. They're using my extended behaviour database though, so would need a little modification to get working without it.

121

(24 replies, posted in Engine)

LoD.
Well, don't necessarily need LoD in engine, can easily be implemented in a behaviour (at least, without checking too much, I believe it should be able to be...) but for this, it would need, as a minimum, a ModelRef type for MVariable we can expose in the editor.
I assume it would be possible to switch the model at run time from a behaviour?

122

(18 replies, posted in Showcase)

This looks awesome! Is it all done in lua?

Looking forward to seeing more (video? tongue)

Nistur wrote:

So yeah, it was calling the function... but the lua state didn't realise there were any arguments to get from the stack...

Right. I've finally got around to testing the function calling in the new build (I think maybe we should move this conversation somewhere else...?) I'm now getting an error, trying to call number value or something. Which makes me think that maybe we're pushing onto the stack in the wrong order.

I'm looking at this incredibly long winded webpage (section "Arguments and Return Value")

lua_getglobal(L, "square");                 /* Tell it to run callfuncscript.lua->square() */
    lua_pushnumber(L, 6);                       /* Submit 6 as the argument to square() */
    if (lua_pcall(L, 1, 1, 0))                  /* Run function, !!! NRETURN=1 !!! */
    bail(L, "lua_pcall() failed");

whereas we are having to push first, then getglobal... I'm wondering if there's any nice way around this...

Sorry for the delayed response.

We're over at #Maratis on freenode.
If you haven't got an IRC client installed, you can use a browser one

Sure! If you can jump on IRC we can get you set up smile