Posts by MattEsch

I'm aware this is supposed to go in the bugbox, but it is currently down.

Suppose I wish to do a pixel-perfect upscale of a game (say 1px is rendered as 3px) I can do this ok in software and Direct3D 8, but there is a rendering bug in Direct3D 9. Something about the upscaling seems to stretch the image. Interestingly I noticed that this upscaling bug also happens for sub-applications but not when scaling sprites.

I've attached a simple reproduction to illustrate the issue. I have yet to come up with a suitable workaround.

Quote

- What are some ways to reduce CPU/MB usage in MMF2 that I may not know about?

Delete objects that you aren't using. Turn on box collisions where possible (will remove any collision masks you don't need). Render as much as you can using display lists, as this will reduce the render call overhead. Ensure you are rendering on the trigger and nowhere else.

Quote

- If you're knowledgeable with OpenGL Base, is there a way to create a sort of "fog" effect that will reduce the rendering range and still look decent? (I know how to reduce the rendering range but it just cuts off and that hardly looks presentable)

I thought there was a fog object which turns on the fog in the OpenGL standard pipeline. Could be wrong.

Quote

- Is there a way to prevent MMF2 from crashing when I try and load large Milkshape Models (.ms3d files ) into the internal storage of the "OpenGL MS3D" object? ( This issue is why I haven't added player models for enemies )

This must be a bug in the extension, but fusion does allow you to add binary files to the executable under View > Data Elements > Binary Data. You can try loading these at runtime.

Quote

- Is there a way to horizontally flip objects with the MS3D object? I can't flip it in actual Milkshape or it screws up the animations

Can't help you there. Horizonal flip needs you to apply the right matrix, and I presume that the milkshape extension doesn't allow custom vertex shaders or something equivalent to that.

Quote

- Is there a way to add a skybox (like clouds or something)? The blue clear color I have now is very bland and wouldn't go over well in a full game. (I am using the "OpenGL clear control object for color and depth buffers by the way)

Skybox is normally rendered by rendering a properly rotated small box around the camera, clearing the z buffer, and then rendering your scene on top.

---

OpenGL through fusion is difficult. Using a scripting tool will probably reduce some of the call overhead, but really just doing horrible fixed pipeline OpenGL as shown in the basic NeHe tutorials is not sufficient for even moderately sized scenes. Ideally you would model the scene in fusion and have a renderer take care of all of the low level calls. It's easier to optimise that and batch rendering performance is significant. Also the drivers can be pretty bad on some machines for OpenGL, making the issue worse. It's fun to experiment, but I am not sure about the quality of the final solution.

Please login to see this attachment.

Fusion is taking the integer value when you set the x position, so it appears that the objects move faster when they have a positive x position, and slower when they have a negative x position. For example, suppose the object is at position 10 and you subtract 1.2, the position becomes 8.8, but because the integer value is taken, it ends up in position 8, moving 2 pixels. Suppose the object is then at position -10 and you again subtract 1.2, the position is now -11.2, and because the integer value is taken, it ends up in position 11, moving only 1 pixel.

You should store the float position you want the object to be in a variable on the object, subtract the runSpeed from that variable and then set the position of the object to the value of that variable

Can you try doing these things in low poly mode suitable for games?

The question I really have is how do you want to model this? You're talking about an "infinite" scene so it's hard to see how you want to define such a scene with MMF. If there's a lot of objects you would also need some kind of scene graph to help filter the objects quickly.

I am as curious as you are. The demo has never supported extensions to my knowledge.

The demo does not support extensions. You can purchase MMF 2 through the site. Please login to see this link. You can pay by credit card or through paypal.

Just pull the latest version of EDIF off github. There's a visual studio project file for the template. Duplicate the template directory, name it something sensible, and that's all you need. There are no other dependencies. If you can write JavaScript there's no reason why you shouldn't be able to master this part.

- With regards to the bug, I figure the problem is not featured in the code snippet you have shown me. Send me your latest and I will diagnose it properly if you can't fix it.

---- Actually thinking about it, I suspect you just called ACT_setApiSettings, so "this.rh" is undefined. I can't see where you have defined the function, but I am confident that it is not defined on the object you want to refer to as "this". Or if it is you have called it incorrectly anyway. In your handleAction function you will want to use yourObject.ACT_setApiSettings.call(this), if you intend to refer to "this.rh" from within that function.

Personally I think a new Box2D extension should be developed in sync for all runtimes using the latest box2d api. It would actually be nice if it was a movement that could be applied to objects. Movement extensions seem like a pretty neglected feature at the moment, but they would greatly simplify physics.

Personally I think this method for including extensions could be improved. I don't like having to edit more than 1 file, and imo I shouldn't need to edit even 1 file. It makes installing extensions a pain and I don't really know how Francois envisages this will work when this meets userland (as editing source code isn't acceptable). I'm keen to see it changed. I have made my opinions regarding globals known as well. I just think a module loader is needed like the require keyword in nodejs and all of these problems are solved.

We don't have a dummy mfx with dynamic properties (yet) and it would be some effort to write it. The only option you have at the moment is downloading EDIF and updating Edittime.cpp (to define, get and set the properties) and the EDITDATA structure in Common.h for storing the values.

It works fine for me. Added the files in the same structure you have them. These are the changes I needed to make to get your extension running:

Extension.js

if (this.name=="Dropbox")
    return new CRunDropbox();

RuntimeDev.js

document.write('<script src="'+document.srcPath+'Dropbox.js"></script>');

Ahh problems

Ok so, you took the EDIF template I gave you (yes this is still valid), you added the dummy actions to the JSON file and then created a corresponding JavaScript implementation. (Make sure you are using the latest JavaScript SDK). I can't tell you exactly why it's not working. If you want to PM me your code I can take a look to see what's actually happening.

Just be sure that you edit the extension inside the MMF program files directory, and that when you build the project you do a FULL REBUILD. If you don't, the extension and newly modified dev files will not be copied to the output directory.

I agree (and understand what you're saying) about the edit-time properties. I believe it ought to be possible to have edit-time properties configured with a JSON file as well, but as it stands, no such thing exists. You would need to favour runtime actions instead, which is a pain in some cases, but it's the fastest way to get your extension up and running.

As far as my extension not working goes, it was built with an old SDK. I've not managed to check it since the latest updates but I will try it as soon as I get the chance.

Sorry for taking so long to reply.

Calculating shifts is a bit complicated. Ignore that stuff. The best thing to do is to define 2 values, the down shift and the left shift. The down shift in a hexagon grid is half the height, and the left shift is calculated as 1/4 of the width (this is the amount you have to shift an adjacent hexagon to the left so that the 2 diagonal edges will meet). It's better to do define these values statically so you can tweak it for pixel perfection and you don't have to keep recomputing it.

Please login to see this attachment.

For a flat edge you might do something like:

onloop "tile ypos" > start loop "tile xpos"

onloop "tile xpos" > create tile
+ set tile x to (3 * tile size*loop index xpos)/2
+ set tile y to (tile size*[2sqrt(3)]*loop index ypos) + ([sqrt(3)] * tile size * (loop index xpos mod 2))

Where tile size is the width of the hexagon from point to point (the radius).

You can replace [2sqrt(3)] and [sqrt(3)] with 3.46410 and 1.73205

It depends on the orientation of your hexagons. Do you want straight horizonal edge \_/ or do you want a straight vertical edge?

Java is the only other option that runs on linux, but due to low interest in this runtime it seems that it's not very well supported. I wholeheartedly promote Anaconda if you want a windows/mac/linux option that's fast and stable. I think it's the best option you've got.

DistantJ, I am not scaling quick backdrops, I am just repeating them. I like to know that my 32 x 32 tiles are repeated by an exact multiple of 32. I have a 32 x 32 grid. To make sure they are an exact multiple I have to start multiplying 32's in my head. I just think that resizing should snap to, that's all.

I think everyone has missed the point of my complaint here. I am not looking to solve these problems for myself, because I am competent enough to do that. I am just saying that you can't expect me to recommend this product to an important target audience when it works like this and there are competitors which are far easier to use. That's the crux of the complaint here. The user interface is 100% what MMF is about. You might get caught up with ideas about runtimes or whatever, but there are hundreds of game engines out there which will give you cross platform support.

MMF is not simply a graphical coding interface to a runtime, though it is one important element. I could develop a competing solution to graphical coding in a month or so. I don't expect a vibrant community of young game developers to take any interest in it though.

Jacob, basically I think you're right in saying that the frame editor is adequate for most people. It was adequate, I just think the goalposts are moving with the introduction of runtimes as they demand a new approach due to performance constraints. The mobile runtimes needs the user to take a particular approach if they don't want to be disappointed with the results and the editor should not be at odds with this task. You can't have all of your active objects flying around with collision masks. You can't keep recomputing collision masks on rotation for all of those rotating actives. Collisions should therefore be off by default. You need to use as few objects as possible.

The frame editor is not adequate for developing a 2.5D solution for MMF2. I could write an external editor, but external editors disrupt the flow of the development, they don't allow you to mix other objects easily.

The frame editor just needs to be better, it needs to be extensible it needs to make sense. You absolutely must have per instance values. Who wants to setup a complex object model for each varying property and then try to remember which one is which? You wouldn't defend a frame editor that made you create a new object type for each new position would you? (Which is effectively the case when your third dimension is a property). Why then is it acceptable to fix all the other properties, except for at runtime?

To solve this problem for 3D games I was actually using the layer to infer the third dimension, as you can also put objects in their own layer.

I guess the worst thing about all this is that trying to make an observation from the viewpoint of the potential customer is like stepping into a steaming pile of dog turd.

Quote from DistantJ

MMF2 is amazing, as are the exporters. If you want full freedom or control you should learn a code language.

I'm a professional software developer, so I do have full freedom, but I enjoy working with people who are not as technically skilled.

Quote from DistantJ

The instances of an object such as quick backdrop just work differently in MMF, for good reason.

What's that then? You forgot to mention what the good reason is.

Quote

It's no slower to right click and select "clone" than it is to drag an instance from the sidebar. It's just a style of creation that you need to learn if you use this software.

Except you have to factor in the time it takes me to organise that mess of an object list with (buggy) folders. It is slower if you want a well structured app. Also the resizing of those clones will not be simple if you have a grid to fit to (which is very likely if you're using motifs). I wouldn't drag instances from the sidebar anyway, I ctrl drag an instance on the page, size it quickly using the snap to grid for guidance, and I have no new object type to clutter my object list.

Quote from DistantJ

Alterable Values are integers, yes, but you could easily just set it to 100*your desired value and then divide when referring to the value. Again it's difficult to do this when its a straightforward editor like this, since in coding you need to specify whether a value will be an integer, float or double, and this software is mainly aimed at people who don't even know what those three things are.

Alterable values can store floats at runtime so the are NOT integers, and I would argue that an integer-only field is actually more confusing than floats only. JavaScript provides a very simple solution, a single Number type (which is in fact a double). I say float but I mean I just want to be able to type in any number, and the concept of types doesn't even have to feature in the discussion. I'd say it's pretty confusing to type in 3.5 as an alterable value, and for it to appear as 3 only after the object lost and regained focus.

Let me make this clear, I'm not complaining that a product I bought doesn't perform to my expectations. It performs far better than when I bought it. Really I can only expect it to perform in the state that I bought it. But this is not about my expectations on the product I have bought, it's more about my expectations on the product that are being (or due to be) released and that I should consider buying, i.e. the exporters. I am basically saying I am not buying any of your new products until they meet my expectations and right now they don't.

Surely providing resources that show how easy it is to make games would promote sales of the mobile runtimes, but I found out that it isn't really that easy to make mobile games with high performance, despite the quality of the exporter themselves. The steps you need to take to be efficient are too difficult to implement with the current editor. One of those efficiency measures is to use quick backdrop motifs, and even that really basic choice is difficult to implement with the current level editor. I see this as an important short-term advantage that will make sales, but I guess no one agrees with me here.

I just think if you're going to invest time in exporters (at the expense of working on MMF3) you should at least consider making changes to the product as a whole to promote the best return on that investment. I see things that would give me much more confidence in recommending these exporters.