• 9
• 9
• 10
• 9
• 10
• ### Similar Content

• I am taking an absolute beginner's game development course and we have just finished game jams in small groups. Our current assignment is to get feedback from people working in any aspect of game development. I would very much appreciate any feedback! The game is up on itchi.io (sound warning) https://wobbegong.itch.io/zombie-shooter It's essentially a very basic PvE.
I also have some things I'm wondering about, but you don't necessarily have to answer these.
1. Do you have any tips on working with physics? My group wrestled a bit with Rigidbody physics not totally working the way we wanted to -- jumping ended up kind of floaty and inclines seem to mess up movement. Alternatively... how can I build terrains with depth that won't result in wonky physics?
2. How can I keep up the level of challenge in an interesting way as the player progresses through the waves?
3. What are some of your personal guidelines for creating title screens?
Thank you very much in advance!

• ...if you got time to read and answer i would be happy .

So me and my co try to do a game.
It should be in unity couse my co do everything in this engine.

We got the rpg package from evila for inventor, but it only runs on pc right now.

I like to make a online store for guns in the game and a multiplayer open world that runs on pc, android, mobile, ps4, xbox one.
Somebody told me that you "only" need to program it like so and that its possible in every engine...

So if you are one of the lucky guys who could help me out or programm that, or even if you know a newer better package for maybe unreal which offers that - please let me know now.

• I'm having a weird issue with detecting a collision. I've tried everything I could find online but nothing seems to work. I have a brick object. It has a 2D Collider attached and I have also attached a 2D Rigidbody on it. I also have an EndScreen 2D Collider. The EndScreen 2D collider is tagged with "EndScreen". I am trying to detect when a brick collides with the end screen collider and simply print "game over" in the console.
This is my current code for this part of the program, it is attached to the bricks:
void OnCollisionEnter (Collision2D collision) { if (collision.gameObject.tag == "EndScreen") { Debug.Log("Game over"); } } Several things have happened depending on the set up. If I have the rigidbody 2D set as static, my ball object can still collide with the bricks, but I get no Log message. If I set it to Kinematic or Dynamic, I get absolutely no interaction between the ball and the bricks, and nothing when the bricks pass through the collider. I have tried to set the collider to a trigger and use OnTriggerEnter2D, no change. I have tried to put the rigidbody on the EndScreen object and tried to set it's body type to all 3 settings, no change. The only thing I can think of that I have not done is put the script on the EndScreen object and switch the tag to the bricks. The reason I have not done this is because I will have several types of bricks, some of which will have different tags.

Please tell me somebody can see what I'm doing wrong here, because I'm losing my mind over something I feel should be ridiculously simple. Thanks.

# Unity Help figuring out Megaman's jump curve - PLEASE!

This topic is 755 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi there!
I've been working on a Megaman fangame project on Unity, and for a couple of days now, I've been trying to find out how his jump curve operates on Megaman 5 with no success.
Has anyone here already done this, and would help me out with this info?
I'm figuring everything out by Memory Watching on FCEUX and using NES roms.
The variables I'm currently looking at are:

0360-0377 Y position fraction (that is, Y sub-pixel position (?) )

0378-038F Y position low
0390-03A7 Y position high

03D8-03EF Y speed low
03F0-0407 Y speed high

Here's what I managed to find out:

The gravity is 064.
The Positon Fraction and Y Speed Low Byte increments operate between 0 and 255 (this is actually true for every other delta in the game).
His speed starts at 4.192 pixels, and will decrease by .064 (gravity value) every frame.
If I correctly understood this, whenever his Position Fraction is .192, the ACTUAL distance his sprite moves will drop by 1 pixel. Also, there seems to be some sort of rounding up (For he actually moves 5 pixels when his speed is 4.192, 4 pixels when his speed is 3.128 etc.).
The position fraction actually forms a pattern:
0 64 192 128 128 192 64 0
Problem is, nor the rounding up nor the Position Fraction increments seem to make any sense to me.

What am I missing here? How are these increments and rounding ups being done?

I guess you could say I could just make an approximation and use my own method, and that's OK, but what I'm facing here is a question of honor
It's though seeing something that doesn't appear to make any sense still working out, more so if you're a programmer.

p.s: I already managed to find out everything else - charge timings, walk speed, slide speed, slide time etc. If you have interest on any of these, ask here or in a PM and I'll gladly pass on this information.

##### Share on other sites

I assume you've seen the information used by tool-assisted speedrunners? http://tasvideos.org/GameResources/NES/Rockman.html and http://tasvideos.org/GameResources/NES/Rockman/Data.html#JumpCurve for example?

The actual application of the deltas and rounding are probably just done directly in the code somewhere, it shouldn't matter where or be particularly important as long as you just apply the same rules (e.g., clamp Y speed to -12 when it gets below -12, et cetera).

Yes, I've seen that site already, before asking this actually. It's good for getting the general idea, but I've seen some values which are actually wrong (using FCEUX Memory Watch myself). As I've said, I could do my own method using the general idea (which is what I'll probably end up doing anyway), but the actual Position Fraction incrementation that's being done doesn't make any sense to me, and I was curious about learning how it actually works.

Position fraction is probably representing an actual fraction in the form of (value)/256. This would make it the fractional portion of a fixed precision number, or what you could call a binary fraction.
You're writing position as 4.192, 3.128 - the actual position would be 4+(192/256) = 4.75, 3+(128/256) = 3.5. So it sounds like it's just applying normal rounding. The cheap way to apply this rounding is:

whole += (frac & 0x80) >> 7;

Fixed point numbers were really common before floating point hardware became normal. It's not surprising that an old NES game like Mega Man 5 uses it.

So 64 = .25, 128 = .5, 192 = .75
Gravity is also likely a binary fraction in the same format (is your fraction pattern correct? Seems wrong here).

EDIT:
In your own code, I would just use floats. There's probably no optimization to be had for using fixed point numbers in this case. You're just seeing a quirk of working with old hardware.

The fraction pattern is actually right, and that's what's bugging me, honestly. If it wasn't for those values, I'd get the idea. If it fits you, you could test this on FCEUX. Using a Megaman 5 rom (not Rockman, the RAM positions for the US version are actually different), go to any stage, open the Memory Watch, type in the values I've provided in the OP, drop the emulation speed to something around 1% - 3%, jump, and watch the position fraction address. And see the bizarre pattern form :P

Edited by Philemon Caim

##### Share on other sites

The fraction pattern is actually right, and that's what's bugging me, honestly. If it wasn't for those values, I'd get the idea.

Why don't you post the every position value (high and low, not just the fraction) and maybe I or someone else might see the pattern more clearly. No point in me duplicating the work you've already done just to help you finish, right?

##### Share on other sites

Pretty fair. I'll be somewhat busy today, but by the end of the day I'll format this data into a table and put it here.

EDIT:
Here it is:

Last considerations: Concerning the Position, Speed High and Speed Low only (next I'll talk about the Position fraction), the Speed Low incrementations make sense, I get this (064 is the Gravity). But, what I don't get is... why sometimes it'll consider 128 being the threshold to do a round down (which makes sense, since 256/2 = 128), and why sometimes it won't (see for instance, when his speed is 2.128 while jumping, next frame he'll move 2 pixels, and the next and the next...).

Concerning the Position Fractions, they form a pattern indeed, but it doesn't seem to make any sense whatsoever.

Edited by Philemon Caim

##### Share on other sites

gravity is applied to Y speed, not Y position. The Y speed low value pattern makes sense.
This speed is then subtracted from the Y position - (Y position low -= Y speed high; Y position fraction -= Y speed low).
Y position low and Y position fraction are, together, a normal 16-bit integer in which the lower 8 bits are representative of a fraction of a pixel.
Y speed high and Y speed low are the same - Y speed low is also a fraction of a pixel.

Edited by nfries88