31 replies to this topic

[Mero]

So I've been working on a global script to allow ffcs to be solid and have the ability to crush link if it pushes him into a solid combo. Only problem at this point is that there is no way to get the four edges of Link's hit box. Any idea on how to go about this?

[Gleeok]

Link->X, Link->Y, Link->X + 16, Link->Y + 16. ...?

[Timelord]

Alucard might have a solution on this one. I think he intends stdCombos to handle things of this nature.

 

My solid FFCs aren't damage, but they are solid in all directions.

 

You shouldn't need a global script though, as dealing damage should be possible within the FFC script. I'm actually less sure about the player being able to move them. Just an if ( ffc moved direction(dir) ) type of statement, that deals damage to the player, and you could include things like if (electrified == true ) for FFCs that change between a normal, and shock state, or if statements that ignore the damage if Link has an item.

 

Assuming you have a way to move FFCs, you might just give the FFC a while (moving) loop, that deals direct damage to Link, if moved in a certain way. Use an int (0 for off, 1,. damage left, 2 damage up, 3 damage left, 4 damage down, 5, damage up/left, 6, damage up/right, 7 damage down/left, 8 damage up/left, 9 damage any dir--you could add additional direction combinations such as 9 damage up/down, 10 damage left/right, 11 damage up/left/right, 12 damage down left right, 13 damage all).

 

Set this as a conditional argument (d1), and the amount of damage as a conditional argument (d2). I'm assuming here that d0 is already used to set something, and that d1 through d7 are unused..

 

That might work, but I;d need to see how you are moving the solid FFC. Your solidity code may be more solid than my own (pun intended)

[Mero]

Without a global script Link jitters because he's Updated during waitdraw() which can only be called in a global script. Only other option is to disable the input preventing Link from walking on it which won't make Link behave like he does with normal solid combos since He walks in place." The crushing effect happens when he is squished between another solidFFC or a solidCombo. The ffcs move on their own. Everything is ran within the global script. A misc index is used to determine if it should treat it as solid or not.

 

edit: another question. How would I check to see if Link intersects a specific edge of the FFC, but not completely inside it since that would should never happen.

Edited by Zecora, 16 April 2014 - 05:09 PM.

[anikom15]

Link->X, Link->Y, Link->X + 16, Link->Y + 16. ...?

Is that Link's hitbox? I thought it was smaller. The approach is the same though. Just test for identical behavior with a non-FFC.

[Gleeok]

I had one written out in but I couldn't find it. So here's a simple version:

float dx = a.x - b.x;
float dy = a.y - b.y;
if (dx > 0) //b is right of a
if (dx < 0) //b is left of a
//etc

[LinktheMaster]

Is that Link's hitbox? I thought it was smaller. The approach is the same though. Just test for identical behavior with a non-FFC.

Depends on which hitbox you're referring to.  When it comes to solidity detection, the hitbox is actually Link->X, Link->Y+8, Link->X+15, Link->Y+15.  Basically it's Link's lower half.  For damage detection, I believe Link's hitbox is 16x16.  It's pretty much just the weapons that vary.  Of course, Gleeok still technically got it wrong since the bottom right of the hitbox is X+15, Y+15.

[Gleeok]

Ah yes, the magical world of ZC.

If you want to draw a square rectangle of 16 pixels do you say '+15'? ...How about a single pixel: '+0"? If you have a grid of 16x16 tiles on the screen forming a tile-map do they all intersect each other?

Is the following rectangle intersection test right or wrong?
if(a.left >= b.right || a.right <= b.left || a.top >= b.bottom || a.bottom <= b.top) //no intersection

It just depends on how you define the rectangle.

[Timelord]

Ah yes, the magical world of ZC.

If you want to draw a square rectangle of 16 pixels do you say '+15'? ...How about a single pixel: '+0"? If you have a grid of 16x16 tiles on the screen forming a tile-map do they all intersect each other?

Is the following rectangle intersection test right or wrong?
if(a.left >= b.right || a.right <= b.left || a.top >= b.bottom || a.bottom <= b.top) //no intersection

It just depends on how you define the rectangle.

Because we all love consistency.

[UninspiredUsername404]

It's because Link's position on the screen (X, Y) is his top left pixel. So his bottom right pixel would be X+15, Y+15 since he's 16*16 pixels.

[anikom15]

Ah yes, the magical world of ZC.

If you want to draw a square rectangle of 16 pixels do you say '+15'? ...How about a single pixel: '+0"? If you have a grid of 16x16 tiles on the screen forming a tile-map do they all intersect each other?

In the case of a framebuffer, yes, yes, no.

[anikom15]

I've implemented solidity for a walking npc, and Link jitters. So there is no way to stop his jittering, eh? Well that's a bugger.

[Gleeok]

I feel compelled to let people know that 16 != 15 just in the off case that they are using this thread as a basis for learning 2D geometry. No matter how silly this sounds. For example, munch on this carpet math:

If you were re-carpeting your floors, would you subtract 1 square foot for every foot of measured width/height? Of course not. You would not have enough carpet.
A 10 ft x 10 ft room would require : 10x10=100 sq. ft of carpet.
If you add that as +9 w, +9 h : 9x9=81 sq. ft. then obviously that is not enough.

Also, just in case anyone is wondering the correct way to get the hitbox is Link->X/Link->HitXOffset/Link->HitWidth and the same for Y. (It's documented!)

I've implemented solidity for a walking npc, and Link jitters. So there is no way to stop his jittering, eh? Well that's a bugger.

Are you using a Waitdraw()? I believe whatever jitter you have should be fixable.

[anikom15]

Gleeok, pixels are not points. They are placed offset their coordinate point, not on the point. Hence a pixel drawn at (0, 0) covers an area of 1 pixel starting at (0, 0), not centered at (0,0). The reason for this is purely convenience. If the graphics system were built to account for centered pixels, it would have to interpolate where to draw pixels (this is what OpenGL does). Consider a 3x3 grid. We will restrict ourselves to special graph paper in which we can only draw lines on the ink, or graph, of the graph paper. First place points on each top-left corner of each square. Then draw two lines from each point, one extending to the right and the other extending downward. You may shade if you like. You'll end up with a square of correct area, nine square units.

Now do the same procedure, placing points in the center of each square of a 3x3 grid. Now, the easiest way to construct our grid, according to the rules, is to shift the points up and to the left by half a unit, thus giving us the same procedure above but with an extra step. Hence, pixels are not measured from their center but from some corner. In most 2D libraries, it is the top-left corner.

Now, let's see why we consider a 3x3 rectangle to be defined as (0, 2), (0, 2) and not (0, 3), (0, 3) like in geometry. Go back to the original square grid we constructed. Looking at the first row from the top, number each point that we placed, starting at 0. You'll have three points, 0, 1, and 2. So when we say (Link->X + 15) px, we are not saying 15 units of length, we are saying the space of 1 and 15 additional pixels, which amounts to 16 units of length, as each pixel, including Link's coordinate pixel, occupies one square unit of space.

I've included a diagram for illustration. I hope you understand it better now. Remember that a pixel is a physical unit of area, not a point.

 

 

Now could you explain how I would use Waitdraw? I'm confused on how it differs from Waitframe. Do I just replace Waitframe with it?

Edited by anikom15, 20 April 2014 - 03:39 AM.

[Mero]

Waitdraw only runs the internal code allowing things to update for this frame up to drawing which is the last thing that happens. If you want to incorporate changes that happen the current frame such as Link's Movement and current Action you'll need make your changes after calling Waitdraw and still call Waitframe at the end of the loop; or at the beginning, since it actually doesn't matter. Just don't do this unless your using a do loop.
 

while(true); //Always cause ZC to freeze with the exclusion of do loops.

Edited by Zecora, 20 April 2014 - 08:59 AM.