LarkSS

I assumed that even if it's not requested often, that the desire to have a helper with you was common among a lot of fangamers here, heh. Sadly to say though that feature would take too long for me to implement into Delta 1.3, nor would I want to deal with 2 concurrent engines in Delta's current state. D2's reworked engine structure will allow for multiple players to be handled pretty much seamlessly, so I'll be holding off on helpers until D2 reaches completion.

I'd suggest that if we split ourselves apart, we should also have a centralized area where anyone can build/gather shared supplies/etc. It would also be nice to set up transportation routes, power lines, and even network paths between the lands. As for hosting I can't help with that. When I set up a server previously it was for a small number of friends, so there was no problem with me turning on the server on-demand. I'm the kind that turns off all computers before sleeping every night. I don't have the most stable connection anyway to be honest.

I was thinking of the Technic Pack as I wrote my post but couldn't remember the name. I add my vote for its usage too; wouldn't even care about anything else. I combat your monopoly with solar panels thank you very much.

Good information Gamerdude, that I rarely see people worrying about when coding things in MMF2. Just like with standard programming languages that support lazy condition checking (as in only test what is needed), MMF2 also stops checking conditions if one turns out to be false. As you stated, collision checks are very expensive, ESPECIALLY if you use the collision mask pixel test. You generally want to keep those conditions last to avoid them if possible, but there is a significance to the rest of the condition order too. Any condition that you know will me false more often than another should be on top as that will falsify the event more often for quicker processing. Take this for example: If Ground = 1; If SpeedX <> 0; ::Do stuff:: That condition order is best because there is roughly a 50-50 chance in a standard platformer that you will be on the ground, but it is EXTREMELY likely that you will actually be moving. I also find that it is good practice to keep input conditions on the very top. @Gamerdude (specifically): If you really want to optimize your performance I'd look into getting rid of the need for out-of-view collision checks. If you put all objects that use BG collision into a common qualifier, you can toggle a flag based on whether they are within camera view or not. Then, you can disable movements if an object is out-of-view. For moving badniks you can disable slope handling if they are out-of-view and do a quick snap-on routine as soon as they are near again so you don't see them glitching in any way. It may not be a very convenient change but you should see large performance gains on older machines. Something else I'd recommend (that you may already do) is to disable fine collisions for any BG or object that doesn't need per-pixel collision testing. MMF2 does not determine if a BG/object is 100% solid and wastefully does a per-pixel collision check if you kept fine collisions on. Disabling this when possible is very beneficial if you want to keep collisions out-of-view active.

Hey everyone! I just thought it would be best if I clarified this ahead of time. Due to the depth of what's planned for Delta being changed drastically, I'll be releasing a build of Delta soon as 1.3 with all current additions, including the input manager, but NOT the level designer. Now would be a good time to put in a request for a small feature you'd want to see in Delta! For a short period of time I will support this release of 1.3 for bug fix purposes, but afterwards I will solely focus on the major reiteration currently code-named Delta 2.0. D2 will not be available for many months to come, and due to being highly experimental it will be closed-source until it's use with select projects have sufficiently proved to me that it is ready for public release. I do plan however to begin updating this topic with occasional milestone updates during the reiteration phase so you guys can stay updated as well as provide input while development occurs. Without going into detail (as concepts are still under brainstorm), D2's goals will be accuracy, efficiency, stability, flexibility, and collaboration. I wouldn't advise anyone to halt their current projects in anticipation for D2, and no it will not focus on cloning the Genesis Sonic engine; regardless, I hope you guys look forward to it in the future!

If you guys set up the ComputerCraft SMP mod, I'd most likely join the band wagon too. I installed it on a server I set up a few months back and it worked very nicely, especially when I started an FTP server so the other players could edit their LUA scripts in their favorite text editors. Nothing like going on a coding frenzy after mining/building for awhile. It's especially good when combined with RedPower 2 (extra world materials, colored circuits, machinery, etc), but it's a bit more complicated to get working in SMP.

Tell me about it. Vsync naturally caps to the screen refresh rate (its function after-all is to sync with the vertical refresh of the display) but in MMF2 it caps the framerate to 30 or lower on some machines which is out-right terrible. HOWEVER on other machines it fixes a frame-drop issue providing a gorgeously smooth 60 frames per second. I wish they would have fixed their vsync code by now, but alas...

Please don't discuss piracy on the forums, even if you are not discussing you methods of acquiring a pirated copy. If you use MMF2 a lot you should look into obtaining a legit copy; you do not need the expensive Developer version to fangame. In regards to the rendering problem, I have seen my share of odd issues. For me having vsync on is usually the major cause, but for others they just need to update their DirectX runtime. Also, updating your HWA build is very important due to Yves doing lots of HWA optimizations and compatibility fixes.

You could always use the Ultimate Fullscreen extension which will just add black bars to non-widescreen resolutions to preserve aspect ratio.

Funny, I thought the boulder chase was scripted because I just held right until the boss and took absolutely no damage (still cool though!). I'll probably give my own personal review later when I play it more than 2 times through. For now I need to do what I can to get Zero's SAGE face on.

Resse's Puffs. Also a Raisin Bran + Frosted Flakes combo always makes a good bowl.

I'm having problems downloading this. Using your main link I get, "This webpage is not available," and using the mirror link I get, "This file is currently set to private." Are you just previewing the website for now? (Very nice artwork and design btw.) Edit: Downloading from here is working fine!

You could always try the Fur Fighters' route of multiple characters in a level, aka specific objects that force you to be a certain character, but only if you decide to use it. (try youtubing it if you don't know what I'm talking about)

None as of now. It's been on hiatus for awhile and needs to go through some major changes before its next release. All I can say is don't expect 1.3 to be around for SAGE.

@TailsSena: I personally have a tendency to name things in meaningful ways that make it easier for others to see my code and know what's going on. For example: iterate.[objectname] "iterate." is 8 characters already, and object names consisting of 4 characters or more is in no way uncommon. If Clickteam was smart and converted the names into unique identifiers during build time, this wouldn't be a problem whatsoever. But alas... Edit: I figured it might be helpful if I uploaded my version of DW's original optimization example. This has a few more methods including the ForEach group iteration technique as well as an optimized method of handling arrays for even more performance from the generic pick method (only reason it's slightly faster than the ForEach technique). http://larkss.thisisourcorner.net/files/optimization.zip Edit2: I've updated my family system for those who may have downloaded it for the family technique rather than to see how the optimized process can be used. It builds family trees considerably faster now and also fixes an issue with porting. (MMF2 sucks with qualifiers/event order, and I had to split an event in two to make sure it works properly in different applications.) I also updated the notes to point out something important that must be done or else your family tree will not start construction. http://larkss.thisisourcorner.net/files/FamiliesV2.zip

Double posting due to new content. Please let me know if this isn't approved of here. (I don't like how editing doesn't update the time stamps for the thread.) --- My second iteration of the family system is done, using the good ole' Doomsday Zone boss to showcase it. It is in stress test mode, so everything will be running as fast as possible. Please read Notes.txt if you have any concerns about how to use and modify this system. MAKE SURE FOREACH IS UPDATED! http://larkss.thisisourcorner.net/files/FamiliesV2.zip

@Serephim: That was my reaction when I gave a test out of curiosity. >_> Keep in mind though when I say 20%, that's with everything else being light-weight processing in comparison. In the worlds engine, your performance boost wouldn't be as great, but it would most likely be noticeable ESPECIALLY if you bundle loops into groups that you toggle only when needed. Edit: I finally got the system in a stable state. When doing a direct comparison between my current implementation and the old method that's commonly used, my FPS is soared from 240 to 920, nearly 400% faster than before. I will upload my code sometime tomorrow I suppose; I just need to replace the current graphics with something I can show publicly.

I just thought I'd verify that yes, fastloop management in MMF2 is horrible and you can see huge performance improvements if you stuff your loops into groups and only activate the group for the specific loop you want to execute. Ridiculous. Something else worth mentioning is that in general, you should name things as minimally as possible, ESPECIALLY fastloops. The longer the string, the slower your game will be. I have found that converting loop names from 12 character to 3 character strings that run on average 150 times per frame increases performance by 20%... @TailsSena: What is the main issue with your Photo Viewer app? If it is not related to optimization, you could PM me if you'd like to keep this thread clean.

I'm effectively rezzing an old thread, but there really is no need to make a new thread for this and it's best if the things discussed here are kept in mind by fellow MMF2'ers anyway... --- So I've been toying with MMF2 again lately for assistance purposes since offering to make a new community engine in a better game-building resource is just out of the question for my intents and purposes. Outside of the ridiculousness of how MMF2 works, it has always been notorious for its poor performance with a lot of basic operations. The greatest threat of all to performance has been discussed here infact; object iteration *shutter*. Although the concept of object iteration is simple once grasped, applying it in MMF2 is no joke, ESPECIALLY if you don't want to kick your high framerates in the nads. The purpose of this post is to shed some of my recent discoveries on my quest of acceptable performance in an age-old program. First of all, DW's generic pick object discovery is a great one, but in my opinion it is not the best way to go about object iteration. The problem is manual management of an array per object-iteration. This can be a nightmare simply put, as you fumble in the Z dimension so you can have 2-dimensional arrays per group of iterated objects. The generic pick object condition is also just that, generic. For someone new diving into your code, they must trace back to where the fixed value references are pointing to unless the developer remembered to be courteous and lay out some necessary comments. But hey, great performance right? Definitely! But I have found an alternative method that is much more promising... Tests with the ForEach extension showed that while it is faster to process and easier to use than standard spread value tactics, it is not comparable to the generic pick object method. However, ForEach has an under-the-wraps feature allowing group iteration. Surprisingly, this produces a result with almost the EXACT SAME PERFORMANCE! I theorize this is because when you add objects to a group, it builds a list with their references, and iteration through the group goes through the references within the extension and then selects the desired object with the same method of the generic pick condition. This is wonderful because groups can be named whatever you want, and the ForEach extension contains the meat and potatoes of the operation for you. To work with this, just add the objects you want to iterate through into a unique group using the ForEach extension (the "Groups" category). Do NOT add based on fixed value as this feature seems to be broken. When all is added and ready to go, iterate through your group using "Start ForEach loop for group...". The ForEach object will iterate through all objects in the group, in the order that they were added in. If you have multiple types of objects, you can use the "on loop for object" condition for each object you want to test, and it'll trigger that event when it comes across the object in the group. If your loop relies on order, just set up the group in the order you want and you've effectively eliminated the need for sub-loops and extra conditions! Here are the rules to using ForEach properly for a happy day: Update the extension! Do not add or remove objects based on fixed value. The order in which you add objects is important. You MUST remove any object from the group that is destroyed. Duplicate objects can exist in the group, as long as each existance is unique and separated by a "spacer" object (explained below). 1 Recursion works given you work around its brokenness (explained below). 2 1. For whatever reason, trying to add the same type of object twice into the same group even if each are unique instances fails, UNLESS if another type of object is added inbetween. This counts for adding based on qualifier too, EVEN IF BOTH OBJECTS ARE DIFFERENT TYPES. To fix this, just add a "spacer" (read useless object) inbetween. This allows the group to be created properly, and since duplicate additions are removed there is close to zilch performance loss from having this object in the group. 2. Recursion in MMF2 is broken in general. Thankfully it works, but loop indexes are not preserved. If you are recursively running loops which iterate multiple times and having them resume is 100% important, you must manually track the indexes within an array. Recursive ForEach loops must be maintained in this same fashion. Also, due to extension implementation, ForEach cannot preserve event order when running a recursive loop. To run a ForEach loop inside of another ForEach loop, break the first loop with a built-in loop, and have that loop run your second ForEach loop. I know, a big pain, but it's the only work-around and the Clickteam community failed to wrap their heads around how this is a problem. --- I am currently working this system into a family system I made awhile back. When implementation is done, I will release the code here so curious eyes can take a glance. To give a visualization, I can currently have 12 "machines" with 6 parts each running at over 900FPS on a 3GHz machine, while each machine has joint elasticity applied for fictional physics feedback. Yay.

DW, Damizean has used collision masks since the early releases of Worlds (collisions for moving rings). I've only ever used it as a simple way for an object to check collisions around it without using a bunch of sensors (the pushable objects in Worlds for example), until I figured out an easy way to set up sensors for multiple objects, which I then trashed collision masks because they're not very flexible nor much of a speed up in my testing. Azu and Serephim, there is no way for a collision mask to detect another object. The only real work around is to use a multiple object sensor system instead. IIRC I submitted an example that uses a somewhat automated process to make the task easy, though it lacks the object iteration optimization DW discussed earlier.

The easiest solution would have to be to use the Mode7 object. Take a look at some examples of it in action, then pass it a water texture and align it to your water level. For correct layering purposes you may want to use two Mode7 objects, one behind the foreground and another in front, so that you get the visualization of you actually passing through the water when going low enough.

I don't see the point in comparing Stencyl to Construct, or saying that an optional coding interface is a turn-off. It seems like a great way for inexperienced coders or programmers looking to make a quick game to design something. Construct on the other hand is in a league all of its own, and obviously if you were serious about game designing but didn't care to start from the ground up you'd want to go the Construct 2 way (which looks great by the way and I'm even considering purchasing). Thanks for the share Damizean; this looks great and I think my little brother will love to try it. Hopefully their proposed Android and HTML5 support comes sometime in the near future.

Which is kind of sad because at one point I had a build with the gravity angle fully functioning (gravity in any direction) that Damizean sent me, but lost it since then.

Happy Birthday Streak.

My thoughts exactly. Anyway to all, we will release information about the future of the project as things develop. For awhile though, things will be pretty quiet. We have a lot of work to do...