I agree with this. Legacy support killed MMF2. But I think you guys know that.

This is a silly question and fair in the future, but would it be possible to import 1.0 caps 'to the best of 2.0's abilities'?

I wouldn't mind importing something thats totally broken and then fixing it -- compared to say, working completely from scratch.

Yeah, the timescale event is just to emulate LOZ style scrolling. It's not critical but it matches the style.

I love the 1 event solution, David. That was way simpler then what I thought was necessary.

Thats actually normal. That happened in IWBTG as well I used big platforms like that because MMF2 tended to fail hard at detecting. Construct allows me to do a much thinner platform, so thats not particularly an issue. a 1 or 2 pixel beam will be quite fine.

As for the platforming issues with the edge, that seems a tad bit weird to me.Once I tested it I adapted right away. There might be a hair bit of an input lag on jumping for some reason? I'll have to look into that further.

Edit: Simple answer just came to me. The original cap ran at fix framed 50 fps. This runs at whatever FPS (probably 60). Technically speaking you have a 20% larger window for 'jumping at the last minute'. Like how if the game ran at 30 FPS, you'd have twice as much time to hit the button as someone playing at 60.

Granted in practice I just press jump a hair earlier now it seems. Also, Tte thing that always throws most people off is the kids hitbox is relatively narrow. compared to his boxy build..

I whipped together a little zelda scrolling example. I'm betting someone could bust this down into 2 events instead of 5... Heck, now that I think of it, I bet someone could even make this 1 event. While I'd like to see that out of curiousity, here it is, in all 5 events of granduer. 1 and 2 event would really push the bounds of 'human readable'.

I had to make this for a friend. so I figured I'd share.

http://kayin.pyoko.org/zeldascrolling.cap

heh, cool. My brother and I can't get past Dracula in the first game. And I think there is moving platform support now. Also, what's the red line detector at the bottom of the guy for?

Well I'm in to that whole custom movement thing, especially back in my MMF2 days (where you basically HAD to, to get something nice done). So thats a floor detector... Though I believe now I could check instead by using 'collision at offset', but this started as a pure code port. In fact, with custom collision masks I can probably turn the kids 3 objects into one -- but I think 2 is fine, just in case I need to do anything that would require them being split.

Yo kayin welcome back

~Sol

Thanks, boss!

Anyways, I got I v-sync build up. platform logic runs at 150 ticks, 3 times the original speed. This is the same solution was using for Brave Earth. So a v-synced, time deltaed game that is 100% pixel perfect.

For things like some enemies and events, I'm probably just going to use normal time delta.

http://kayin.pyoko.org/iwbtgconstruct3.exe

Next thing to do is to simplify some code and then add moving platform support and wall jumping... and then for some NEW stuff.

Also whats this custom movement behavior? I haven't found any real description of it on the site and it sounds like the type of thing thats targeted to me. I don't think I'd use something like that for IWBTG (which I want to of course feel like IWBTG still, so the closer to the original code, the better), but it might be useful for Brave Earth when the feature enters a stable build.

Since Brave Earth is going to take forever, I decided to mess with some side projects. One of them will be an IWBTG mini sequel with some newer gameplay elements. But the first order of business is to make the old platforming engine work.

http://kayin.pyoko.org/iwbtgconstruct2.exe

I think the animation time is off (I almost know for sure it is), and theres no moving platform support yet, nor wall jumping, but it, according to my crazy IWBTG experts who know the game way better than I do, is pretty much 'damned accurate'.

What amazes me is how much neater the code came out in construct, since I didn't need so much redundant code. Right now it's also accurate in the sense that it is 50fps and fixed frame. Obviously not at all desirable in the long run. I'll be trying to implement my older delta time setup for high accuracy time delta movement. I'll keep this thread updated!

Mostly wanted to say hi again. It's been awhile! I might not have been posting but I've been checking in occasionally. Problem is I've been doing more animation then coding, recently.

Alright, that still sounds nice. Yeah, the detectors solutions are fine, but built in integration with the object would be nice. Ah well, something I can easily live without! Thanks for the answer.

Hey kids! Long time, long time!

[quote:295k2rpu] Another new neat feature which probably won't make 0.99, but will follow shortly after, are custom collision masks, which can be drawn via the picture editor.

This makes me very interested and I'm extremely curious as to what this entails and might have some feature requests based on how close or different it is to my expectations.

So I'm a big fighting game guy, to the point where I'm using aspects in it for the game I''ve been working on, so custom collision masks make me automatically think of fighting game hit boxes. Granted, I know the intended basic functionality (just defining a simplier shape for a complex object), I was wondering if the feature would have more advanced functionality?

What I was imagining was to ability to have collision "layers" on an object have have the abilitity to add as many as you need (terrain collision box, enemy collision box, head collision box, attacking hit boxes, ETC) and be able to adjust them per-frame. This may be way more complicated than planned or only useful to people like me (who can get by with multiple objects for collision), but the concept sounds neat and useful to me if taken to that sort of level.

If this sounds good and more than your intended functionality, I'll submit a decent feature request. If it sounds silly and to complicated, I won't bog up the tracker. I am very curious to hear how much functionality the feature will have though.

Thanks!

This sounds really interesting. Sadly I don't think I can preempt any shortcomings without say, trying to implement it. It'd be nice to get some of the advantages of behavior with a custom movement engine though!

I like that solution. I got lots of old backup caps that I'd like to retrain access to.

I'd be 'effected' but what would happen? I assume the events would just be gone? I really don't care, but technically something will happen!