P2d open source engine


Which is what I said. Of course, you could always forcibly teleport something into a solid like when you unburrow a pile of units in StarCraft.


I believe move_contact_solid basically moves the object in given direction until it contacts a solid object, leaving 1 pixel of its bounding box inside the solid. Using move_outside_solid with reversed direction negates that one-pixel overlap. So in most cases, it probably has a miniscule effect, I’d like to think.


Aaaaaaah. Makes sense.

You other guys suck.


Puts lolpenis image back in timmeh’s avatar


I hate you forever for that, by the way.




They’re not monthly, the next goal starts whenever the current one is done.

The engine you send me contains a bug:

  • when you run up a slope and hit a ceiling, samus moves all weird.

Not bugs, but recommendations

  • the slowdownfactor of slopes should be relative to the slope angle, and not be a constant, maybe you could use your slope angle script for this.
  • add some freeform slopes, so we can test those as well.

Otherwise, it works pretty well :slight_smile:

Yea, I know I’m pretty strict, but the movement scripts are a crucial part of the engine, these have to be absolutely bug-free before we move on.


Hehehe yes, yes I know these things :stuck_out_tongue:. I guess I was just being lazy, mostly. But no, I don’t care about the strictness; I understand completely. The more demand, the greater the challenge, and I’d like to think that I enjoy challenges :slight_smile:.

Indeed, that ceiling glitch is really strange… I guess I’ll just have to look into it. If I were to guess, I’d say it’s possibly a conflict of the ceiling/wall-collisions’ move_contact and move_outside_solid function calls, and the ones used for the slopes.

And yeah, the rate of decelleration differing on slopes I realized as well. That one really was just a case of me being lazy.


Tried to fix it myself, now I realize again why I hate gamemaker… The built-in functions and variables are a pain in the ass, there’s just no way to fix this in a proper way.

So if you want to use your own custom gravity, hspeed and vspeed, be my guest, I’m sure the code will be higher quality (and most important of all, bugfree) then with gamemaker functions >_>.


Next time listen to uncle PY first :3


wants to kick uncle PY in the crotch

I’ve made a new version that does not make use of gm’s internal vars. Slope running is included.

P2D open engine v0.02
source: http://metroidprime2d.co.uk/open_source/mp…engine_v002.zip
exe: http://metroidprime2d.co.uk/open_source/mp…ne_v002_exe.zip

I couldn’t find any bugs in this engine, but I want to see this confirmed by other people first before we move on to the next goals.
The next goals will be:

  • ducking
  • morph ball
  • jumping
  • space jumping (1 extra jump)
  • moonjump (for debugging purposes)
    Don’t start on these goals yet, the current engine must be confirmed bug-free first.

Saber Mage, this means I can’t use your slope running code, cuz the entire movement script has changed. If you think you can improve the current engine, or make a better one, feel free to do so :wink:


I know we’re not starting yet, but I’d like to ask my questions before we do. Can you do a space jump if you fall off a ledge, or do you have to jump first? I can’t remember :frowning:


in prime yes, in the sidescrollers, I don’t remember, does that help?


Yeah =P


I don’t think you could in prime 1, that was one of my main annoyances.

SM+ you could do it in the air, one tap to start spinning, one to space jump.


You couldn’t start spinning in mid-air in Super Metroid. I’m hooking up my GameCube right now to see if you could space jump without jumping in Metroid Prime 1.

Nope. Can’t do it in Prime 1.


Oh, my mistake :S

It felt like a needed change (one of the few the gba metroids brought)


Verily! I got excited way back when I saw that you could do it in Metroid Fusion, the same year I started programming. :stuck_out_tongue:


My only thing with the engine is that where the blocks are with gaps, you can run across it without slowing/falling.


Ah, how unexpected, yet swell :stuck_out_tongue:.

Well, the engine is pretty solid. There are only three issues I see/saw):

  • Samus treats the slopes like ramps. Flies off the top of them :stuck_out_tongue:. [EDIT: Fixed.]

Samus can go up slopes steeper than 45-degrees. I believe you said that 45 was to be the limit for Samus when not in morph ball? [EDIT: I really don’t know how well we can detect this. There are so many small differences in freeform slopes that could give undesired results. The easiest way past this would probably be just to make sure that we use obj_block_parents for all of our walls :slight_smile:.]

  • I don’t think there’s any slow-down on the slopes. I could be wrong, but I can’t really tell, and don’t think there is. I’ll check out the code now.