Mr Lange

We attempted our own rings for Overture. It was a messy experiment. The shading on your bottom example is clean, but it's also rather matte and doesn't exactly portray a metallic surface, even if bright. The chrome shading as seen in the demo was an attempt but it didn't work for several reasons. We're aware it's not too good. We've completely remade the rings now, and they look much better.

MMF2 is stifling and painful to work with and Worlds has become so overly complicated that combined with MMF2's limitations it makes development far too grueling and frustrating, and some things are a living hell to accomplish. There will be more on the new engine soon, stick around. Thanks for the positive feedback fellas.

Fixed that for you.

Merry Christmas SFGHQ and United.

superdarksonic10... I have some bad news...

The loop points are measured in milliseconds. You'll need to find the place you want, and whatever time that is in seconds, move the decimal point over three places. You can find exact times with various sound editing programs such as Audacity. Here's an example, I'm using Sound Forge here. It doesn't have to be perfect, but the closer it is to where it should be, the better the loop will sound. A good place to loop Sunrise Gate is at exactly 5.135 seconds. We regard only three digits after the decimal point to convert that to milliseconds. Thus, 5.135 seconds becomes 5135 milliseconds for our loop start point. You can also see the loop end point is 99388, which would be 99.388 seconds. It's important to note that MMF2 doesn't handle this perfectly and it may be slightly off. Testing this can be tedious because it may require tweaking the numbers a little bit and playing through the whole song repeatedly until it sounds right. I sped this up by capturing the game's audio and using a sound editor to measure the gap between loops. This can be annoying. You have to make sure there's at least one of every object you need left in the map. This is why it's a good idea to import every object you need, set everything aside somewhere outside the map, and copy them as you go. That way, if you need to duplicate the level and start fresh with the same set of objects, you can do so while preserving the objects you need. It's also a good idea to keep things specific to your level in a folder in the objects panel. If you haven't set everything aside, you can at least select each object from the panel and copy one of each to set aside so you can safely clear the map. If you haven't done either and you've already gone ahead and made your level, it's on you to sort everything out. Remember to do at least one of those things from now on; set one copy of each object aside somewhere, and/or keep everything in a folder. This is a little tricky if you're new to MMF2 and Worlds. You need to create a "Background System Box" object, best added to the bottom layer. Select this object, then in the properties panel, go to the qualifiers tab, click edit, then add "Generic 10" to the object's qualifiers. Then go to the Worlds engine code, and open the groups: General methods > Startup Events > Parallax Setup You'll see a set of instructions, and below that a Start of Frame event. Here, add code that sets alterable values D and E for your Background System Box object. D is horizontal scroll rate and E is vertical scroll rate. 1 is fully fixed to the camera, 0 is fully foreground. As such, distant objects will be values closer to 1, such as 0.8, 0.9, etc. Hope this helps you so far.

(reposted from Retro) I looked this up. No wonder, families are only available in the full version. I'm still using the demo. Attributes are not redundant with behaviors. They worked similar to families, but the difference is, they allowed objects of different types to be grouped, attributes are read only in that you can't apply code to them, only run checks. Also, objects in families all have to share the same private variables. Objects grouped by attributes are independent. You cannot read from objects that share behaviors, they're not grouped as a readable object. So, having families and no attributes is better than nothing, but attributes were still an important feature.

I wanted to save this image for a more elaborate topic in the future, but to hell with it. This is why Sonic games are no longer good Sonic games. The "legacy" diagram is what made Sonic games what they were. It's what set them not just apart, but ABOVE every other platformer. Without that, you don't have a Sonic game, you just have a platformer; no matter how many slope-looking things and rings and animal characters you cram into it. The games have been gradually reducing more and more to the "modern" diagram on this chart, and Lost World finally achieved it along with making more bad design choices on top of it. This is not about "purity". The Advance games lost some of the gameplay depth, Rush even more so, but they were still good Sonic games. It doesn't have to be perfect, even though ideally it should be very close or the same as the Genesis games. Or hell, find ways to improve that formula. But, not only have they not been improving the formula, they've been making it worse, and worse, and worse. We're not afraid of "change" or them "trying something new". We're pissed off that their "trying something new" always comes with more compromises and once again fails to address the glaring flaws that were left behind by their previous attempt to reboot the gameplay. And of course, they continue to avoid the two big formulas that were really good and did phenomenally well; the Genesis formula and the Adventure formula. Trying a new formula won't work if they only use 10% of the ingredients they used to have. Generations was moving in the right direction, then they promptly discard all of that as if they had no idea what they were onto. The jump from Generations to Lost World shows they really have no idea what they're doing. Don't even get me started on Sonic 4. I'll go into this in the future with a more thorough explanation, I'm hoping to make a video on it as well. The problem with Sonic is not the fans. It's not some obscure detail. It's not one isolated issue like too many unused characters. The real split in the fanbase are those who can see the difference illustrated above, and those who can't. Those who can are either awaiting, or have given up on, Sonic's return to form as a game series, preferably with the same rich and beautiful aesthetics that walked hand in hand with it. Those who can't are squabbling over the more stupid features irrelevant to what makes a Sonic game, such as whether or not Silver should be canon or why Black Knight didn't get a sequel. They're engrossed more in the lore or the themes than the games themselves, because they can't recognize what a Sonic game is. To them, Sonic games are just a container for all the ridiculous ideas Sega craps out, and they're only fans of those ideas. This is why they're quick to refute the difference in quality between old and new games, accuse 90s fans of being "blinded by nostalgia", and will blame any problems the franchise has on the fanbase, voice actors, and other such nonsense.

Recently discovered C2 doesn't have the family nor the attribute system that CC had, which makes it nearly useless. How could they go this far and try to make a commercial version of Construct, then neglect these critically important features? Back to CC it is then.

The physics are a problem in that engine, yes, but the main problem he pointed out was how terribly unoptimized it is. Testing the html5 build runs very slowly and inconsistently. Even if you ironed out all the physics so it worked as well as Worlds, the huge bottleneck will still be there, if not made worse. This problem does have to do with collision detection.

Sonic Construct Worlds was a good effort by Candescence, but it's not nearly adequate enough to make a Sonic game with. A Construct 2 Sonic engine is looking to be too difficult to accomplish because Construct 2 lacks pixel based collision detection and its only alternative are customizable six point polygon shapes, which is not a viable method. Construct Classic on the other hand does have pixel based collision detection. StreakThunderstorm created an incomplete Sonic engine for Construct Classic. It only features core physics, basic moves, sprite animations, sounds, and springs. So, while it is adequate to work from, it's quite raw and you'd have to create everything else yourself. If you'd like to try, here's the last version: https://www.dropbox.com/s/pt51atpbhn545uw/SonicConstruct%20v10.rar?dl=0 Construct's built in movement behaviors do not have anything close to Sonic physics out of the box. You'd have to work it all out on your own. If you want to try that, I'd start here: http://info.sonicretro.org/Sonic_Physics_Guide You may want to wait, however. There may just be a Construct Sonic engine in the works...

Because I stopped giving much a shit about the insults Sega keeps shitting out and calling Sonic games. There are still several truly great Sonic games that I love and some fans keeping the spirit alive, and we're creating actually good Sonic games in the absence of Sega's competence. The rest of the fanbase can maul each other and Sega and Dimps and "Sonic Team" can keep hammering themselves into oblivion for all I care. If there was anything left of "official" Sonic, it died with Sonic 4.

You have a definitive shipping chart. Debate is over. Go home.

I'm not telling. Nope.

Actually I've had it for a while now. Don't ask.