Yes, those are the same problems I found. No bugs though, woo!
I want to stand by the idea that there are no freeform slopes in The 2D Metroids (holla atcha boy). They’re not such an integral part of Metroid Prime that we need to put them in here.
There are non-45 slopes though, so a freeform engine is the easiest way to do it.
Ok, once these issues are fixed, we can move on to the next goals.
1: slope ramps (fixed by Saber Mage)
2: Well, it would be easier just not to create any slopes steeper then 45?. That way no code changes are needed for this issue.
3: you’re right on this one, slowdown on slopes isn’t included yet.
So that leaves only issue 3 to be fixed 
Timmeh, freeform slopes have to be supported, they’re necessary for morph ball half-pipes. And they also allow interesting level design.
edit That reminds me, freeform ceilings should be supported by this engine too. I’ll make that a future goal.
you know how tall samus is, right? and you should have some idea of how fast she moves. why don’t you just do some math to see how fast she goes up the steepest slope in the game and calculate what angle that slope has?
SOUNDS LIKE A PIECE OF CAKE
i dunno if this is really related since i only read saber mage’s post.
EDIT: maybe it is, speed at a certain angle.
We can’t just not create slopes steeper than 45 degrees. That’s way too much to ask of our spriters.
And I still disagree on freeform slopes. Keep in mind that Samus will not ever have to walk on halfpipes, since they will only be accessible through morphball.
Even if Samus could reach them, I have an engine in mind that will allow straight lines to function as far as halfpipes are concerned. Let me see if I can demonstrate…
Yeah, asking sprites to make a straight diagonal line is way too much.
Samus walks on halfpipes loads, though <_<
Straight lines as halfpipes? Are you mad?!?!?!?!?
No one said they have to LOOK like straight lines.
why not just make freeform slopes but have the clipping be 45 degrees or whatever?
Which basically means no two pixels of the outer edge of the slope be on top of eachother, right?
I got a decent slope slow-down going, but it acts according to the change in y between two steps/frames. So really, m_hspeed determines the amount of slow-down (how fast you should be going over the slope) because of the code that raises Samus to the top of the slope she is on. The code affects Samus’ x directly, and not m_hspeed.
I’ll post a link to the editable later tonight, but I must depart for work (–
soon.
Remember that her total speed is sqrt(XSpeed^2 + YSpeed^2) and minus a little bit if going uphill. If her X speed doesn’t change when she goes up a hill, it’s like she’s running significantly faster up the hill.
By the time the screen is drawn again, the code affects Samus’ position in a manner that looks like she is going slower, which in terms of her net coordinate changes, she is. I’m not going for perfect physics, as I wasn’t told to, although it might be better to in the long run? shrugs Let’s see what others think? (Lots of question marks?)
Posting a link in a sec.
Keep up the good work, guys. 
I’d love to contribute to this someday when I’m less busy. Great idea, DF.
Thanks, although it would be nice to get some feedback from the others soon xP. Haven’t heard anything for five days. I suppose it is Thanksgiving weekend after all, so I guess 'tis to be expected.
Looking forward to it, Troid
P2D open engine v0.02 (bugfix)
source: http://metroidprime2d.co.uk/open_source/mp…engine_v002.zip
exe: http://metroidprime2d.co.uk/open_source/mp…ne_v002_exe.zip
The 3 issues have been fixed:
- slopes are no longer treated as ramps
- samus can no longer run op slopes steeper then 50?
- samus runs slower on slopes
Time for the next goals:
-
ducking
-
morph ball
-
normal jump (1 jump)
-
space jump (2 jumps)
-
moon jump (infinite jumps)
Ducking & morph ball
When the down key is pressed, samus puts herself into the ducking state. In this state, she cannot move. When pressed left or right, she stands up and runs.
When pressed jump, she puts herself into the standing state, and she jumps. (check for ceiling collisions first)
When pressed up, she stands up again.(check for ceiling collisions first)
When pressed down, she enters the morph ball state. Moving is allowed in this state, but not jumping.
When the jump key is pressed, samus unmorphs into the standing state
when the up key is pressed, samus unmorphs into the ducking state.
The morph ball state is only allowed when the var m_upgrade_morphball is set to true.
When the morph ball rolls on a slope, gravity will have an effect on it, so it will always want to roll down, just like in real life.
jumping
Press the jump key to jump. When moving upwards, and the key is released, the upwards motion is canceled and she moves down. Simple as that.
Space jumps allows one extra jump in mid-air. The key from the original jump has to be released first, only then is a second jump allowed.
Space jump is only allowed when the var m_upgrade_spacejump is set to true.
Moonjump is basicly the same as space jump, but infinite jumps are allowed.
Use the variable m_upgrade_moonjump for this.
The moonjump won’t be used in the real game, its just a handy debug feature (ceiling collision checking)
Ok, who’s up for these tasks? If you have any questions, feel free to ask.
Glad to see that some of my code came in handy, even if just a little bit. It’s obvious who’s the better (or less lazy) scripter here >_>. You really did most of that stuff, in the end.
I’ll try my hand at ducking, and then morph ball once finished. I have a couple questions though:
- Sprites are necessary-ish for ducking, as it is almost solely an aesthetic. It’d also be nice for all programming to get down the sprite/animation triggering as the other programming is done. Sprites are also necessary for morph ball… Did you remember these things when you posted the next goals? 
If you’re wary of open-sourcing the sprites, a viable substitute might be to just supply silhouettes of each sprite, as shape is really all that’s necessary for programming. However a rotating morph ball sprite is kinda necessary, to get it rotating relative to the speed it is moving on the ground. I don’t know - perhaps you were planning on doing some of these things yourself?
- Will the morph ball be a different object than Samus, or will they be one in the same and just switching off scripts and bounding boxes? I’m guessing the latter, but wanted to make sure.
Thanks for putting together that slope angle script as well. No doubt it’ll make the effects of gravity on the morph ball much easier to pull off.
… >_> I like the visual angle-shower, as well. Very useful, yes.
Edit: One more question, about the slope angle script. >_> I apologize if this sounds stupid, but I understand all of it (and am glad I took the time to examine it ) except this. Why do you choose the value +/-2.5 in the arctan2 function’s x parameter? (I realize that it is half of 5, which you use as the hor. distance limit on slope checks.) And why do you only manipulate the slope_x if left, and not if right? I mean, isn’t Samus’ sprite origin in the center of the sprite? If so, then wouldn’t that give a strange offset when checking to the left, and return inconsistent results relative to the right checking?
I’ll try and work on jumping. And as an FYI, MP used some downward motion physics. Meaning that, if you space jumped after falling downward a lot, you wouldn’t jump as high.
EDIT: Ugh, multiple scripts.
It’s one thing to make scripts for repeatedly used functions, but another to just use them to organize events. IMO it’s kind of pointless and gets annoying. Just use multiple “execute code” DnD thingies.
EDIT: Damnit, Pro.
Pro indeed >_>. … >_>.
Anyways. Yeah, personally I wouldn’t usually use seperate scripts just to organize events. I can understand why someone would, and really I don’t think it’ll affect the engine much at all, so I don’t mind. I’m simply thankful that someone had enough initiative to get anything moving along.
DF, I need answers to my questions, and essentially some sprites to use, to begin any work on this. I could start the morph ball, but I don’t know what size to go with.
“Just use multiple “execute code” DnD thingies.”
Please don’t.
About the sprites, use 1 sprite for ducking, 1 for the morph ball. Don’t add animations yet. Right now we’re concentrating on physics and controls. Use super metroid sprites for now.
Animations and p2d samus sprites will be the next goal.
The morph ball is the same object as samus, don’t add a separate object for that.
The bounding boxes for ducking and morph ball sprites are automatically initialized in the samus_init function.
The x and y values in the arctan2 function are both averages. I calculate the y average in the code above. The x average is (0+1+2+3+4+5) / 6, which is 2.5 . With these averages you can calculate the correct angle.
The 3rd argument in the slope angle function is to define if we’re calculating the slope angle on the left or right side of samus, true = left, false = right.
The sprite x-origin is the center indeed. If left is true, I calculate the y average from x-5 to x, if it’s false, I calculate the average from x to x+5.
Hope that helps clear things up
Those downwards motion physics sound nice, if you can implement that, be my guest.
Putting all kinds of scripts in 1 big script is the worst thing you can do… Using seperate files for logic, controls and initialization helps to keep the code organized, manageable and understandable. When the game gets bigger, you’ll know what I mean.
BTW seperate scripts have no impact on the engine, gamemaker compiles it into one big mess anyway…
And please, no DnD… Just no…
Need a pro licence? http://www.google.com