P2d open source engine

Actually, GM6.1 was created by Mark Overmars himself, before YYG had anything to do with Game Maker. I suppose it might be some kind of bad code (like I would know), but Vista wasn’t around until after Yo Yo Games took over and released GM7. So the original creator of the program is to blame, if anyone :stuck_out_tongue:.

As I said, there are minimal differences between the GML of 6.1 and 7. So would it be alright with everyone if I did scripting and testing in GM7, then sent the code to… Someone? (At least until there’s a v.7 engine?) That shouldn’t be an issue on my part; GM7 opens .gm6 files as simply as it opens .gmk’s.

Yeah, sorry, got my versioning mixed up.

Mark’s shoddy code, then.
There are like, 3 functions new to GM7, so there shouldn’t be much of a problem with just copypasting.

Well, I have yet to encounter any issues.

Ohh I see. I didn’t catch that :stuck_out_tongue:. Thanks for clarifying DF.

Well, I’m going to start doing some work instead of just ogling at this topic <.<
Wish me luck! :smiley:

Augh… Somehow, my coughillegalcough executable of GM7 Pro dissappeared. Beh!

Edit: Yeah, I can’t find it. And so I can’t even run that super simple engine DF provided us with. Gehhhh. Stupid incompatibilities, and big company taking over Game Maker… --;

I’m using GM6. I’ll stop working on it if it goes to GM7 <_<

Anyway, DF, you already did some of the work, and I want to do it a different way than whatever you had in mind. So I’m going to undo a bit =P
Hope you don’t mind.
EDIT: Actually, I thought of a way to do it without deleting anything. Nevermind :astonished:

Alright, nevermind I got Pro back.

I’m amused that you opt to use GM’s built-in solid and gravity features, DF. Personally I wouldn’t recommend it, because while it is pretty reliable, it keeps every and any other object from going through said solid object (even if that other object isn’t solid). That’s been my experience, anyways, but now’s not the time, I’m sure.

So far I’ve created a script that will determine the upward slope of the ground to either side of Samus, inside plausible limits (2 to 1/7). I don’t know how useful it will be, however. I figured it might be handy in calculating how much slower Samus’ running speed should be while she runs up any given slope. If this is retarded and unnecessary and I’ve strayed off-track, please let me know xP.

Edit: Yeah, I’m not doing so well with the slope-running code xP. Not complaining, but the only slope-utilizing platform engines I’ve both seen (editable) and made in GM used their own gravity system. I guess I’ll just have to leave this part up to someone else :stuck_out_tongue:.

In case anyone wants those slope-returning scripts:

[code]//slope_detect
// version 1.0
// author: Saber Mage
// date 11-18-2008
//
//Use this script to return the upward slope of the ground beside Samus.
//Returns 0 if the ground is relatively flat.
//Returns 99 if the ground is too high to walk up.
//
//argument0 - The supposed edge of the ground where Samus collides with it.
//argument1 - The base of the ground - basically the bottom of Samus’ bounding
// ? ? ? ? ? ?box.
//argument2 - The direction in which to check for a slope. (-1 or 1)

//Check vertically. If it is too high to walk up, return 99.
for(i = 0; i < 3; i += 1)
{
if(!collision_point(argument0,argument1-i,obj_block_parent,true,true))
{
break;
}
}
if(i == 3)
{
return 99;
}

//Check horizontally from vertical position. If vertical position is > 1, this usually won’t get any higher than 1.
for(j = 1; j < 8; j += 1)
{
if(collision_point(argument0+j*argument2,argument1,obj_block_parent,true,true))
{
return i/j;
}
}
return 0;[/code]

I apologize for the lack of formatting - it was stripped when copy-pasted.

I know it’s not that useful right now for it to be so extensive, but I wrote it with possibly steeper and less-steep slopes in mind. I also had a variant where I replaced return i/j; with return 1-((i/j)/3); for a return value useful for reducing running speed limits.

I’m working under the assumption that the slopes will be constant values, like they are in all Metroid games. No randomly drawn weirdness, and thus no slope detection, at least not in the way you meant it. =P

So put simply, it’s retarded and unnecessary and I’ve strayed off-track. xP

Hahah. No, it’s actually a good idea in general, and it’s what I recommended for… either CMC or some other dude who was dealing with slopes. He wanted freeform slopes, but they’re naturally more resource intensive, and if you have a standardized tileset, there’re better ways. So not retarded and unnecessary, just not Metroid :stuck_out_tongue:

Also, I ended up trying to convince a horde of transsexuals that I’m not Hitler yesterday, so I didn’t get a bug-free version working. The slopes ended up being more ramps than slopes. ZOOOOOOMMMMMM whee.
I’ll get back to work as soon as I get home (30 minutes).

Are 45-degree angled slopes the only sorts we expect to see in this engine? Or will there also be 22.5-degrees, and maybe others? I would guess there would be less-steep slopes, but just making sure eh.

Edit: Alright, I have a pretty decent slope-run going for me. It seems pretty solid, and doesn’t use the slope calculation script I posted earlier. The biggest issues I can see are that * when decelerating from upward motion on a slope (to a stop), the movement is a bit “bumpy,” and * samus is about 2-3 pixels off the ground when running down slopes (but touches them when she stops running). I can give the code to whoever, or if I should just post it on here, let me know.

Edit-edit: Also Timmeh, it’s true that slopes in 2D Metroid games have been as you say. P2D though, to me, sort of resembles a new animal. Seeing as Metroid Prime utilized some very smooth slopes and curves (especially in its morphball puzzles), I think it’d probably be necessary for P2D to do so as well. Programming for such things though is probably mostly morphball-relevant, and altogether a ways off. That’s just a thought I had as I wrote the above line about not having used that script xP.

Morphball will probably use different slope mechanics altogether. For instance, running over a zigzag path (/////) regularly will ensure that you stick to the ground at all times, but with the morphball, you’ll become airborne at the top of each hill. Also, gravity will affect the morphball differently on a slope, since you don’t roll downhill usually.
So yeah =P

Give the morphball proper physics, there’s no reason not to. MP had them. ish.

Backseat programming ftw? <_<

I’m lazy.

And can’t use gm6 anyway :stuck_out_tongue:

Freeform slopes should be supported with a maximum runnable angle of 45?. Should have mentioned that earlier, sorry :sweat:
Also, when you’re done programming, send the gm6 file to me by mail: destroyerf@gmail.com, or post it here publicly, whatever fits you best.

And I’ll make a gm7 version tomorrow, first thing I’ll do when I come home from work.

And thx to the programmers for the support :wink:

Yeah, you hear that, PY? Thanks to EVERYONE BUT YOU.

MORAL SUPPORT D:

I AM LIKE SANTA D:

Hey, DF, I found a problem/weirdness with your code.
Well, a few things.

if (collision_line(bbox_left,bbox_bottom+1,bbox_right,bbox_bottom+1,obj_block_parent,true,true) && vspeed == 0) { &nbsp; &nbsp;vspeed = 0; &nbsp; &nbsp;gravity = 0; }
Why do you check if vspeed is 0 and then set it to 0? It seems as though you were going to use this to stop Samus when she hit the ground, but then did something else instead and left this in.

Also, when you jump you set gravity to 1. But every step, you have a “gravity = m_gravity;” line. Is the gravity = 1 necessary?

And finally, why is m_gravity a member of samus? Shouldn’t it be a constant?