ZFGC
Resources => Coding => Topic started by: 4Sword on July 13, 2009, 02:02:22 am
-
There are probably some errors somewhere and other places that can be optimized. I was using the xor originally in Link's step-event but it was not as effective as cancelling out the keys at the beginning of the event - it just gets a bit complicated looking by how parenthesis need to be placed. Hypothetically, the xor in the functions which receive two opposing keys as arguments could be altered because of the beginning check in the Link step event; because then only one value might be needed.
There's also a good blinking code that is kind of realistic to the game. The problem I had with some of the code though was that if you step onto ice after not stepping onto ice that your move_x should not be at its maximum. It seems simple enough to add in, but trying to test the xprevious yprevious position didn't work for me. Also, when move_x and move_y are not 0, the move factor move_f is set to the square root of 2 even though it isn't always moving so much like that - it's not too important though as the actual value should be a little less than the square root of 2 but still larger than 1.
I do like that I was able to integrate Goodnight's style of movement into this. And also realizing that if something like the x speed was at its maximum that the step_x could be set to 0 if the y speed was 0. Additionally, making sure the step_x and step_y are equal if both x and y speeds are at their maximum makes sure the diagonal movement doesn't get jittery.
I would make it a little more efficient, but I have to bail some straw tomorrow to make some money. The GMK file is in the attachment though.
-
Oh, and I thought that I would ask it here and now since everyone can see this. Can anyone alter the code I provided so that when Link gets onto the ice initially after not being on it that his move_x will either be something like -2 or 2; this is closer to Minish Cap. Anyone have any ideas on how to do or solve this (preferably suggestions which you attempt to test)?
-
I don't have GM7, or I'd take a peek at it, but I feel I should mention-
If you're going for a fidelity engine, I highly suggest having a generalized parent object that houses a draw script for your sprites that has draw_sprite(this.sprite,ceil(x),ceil(y)) (pseudocode; can't remember the arguments off the top of my head. I know theres one for image index too; basically just gotta call to the host's current sprite and image index).
It helps you sync up objects a bit better (removes that jitter lag when forcing another object to follow your players x and y).
I had a decent system for ice movement a while back... I think it's on my fiance's computer. If I can find it I'll post it on here. It was very adaptable.
-
I had thought that it would be possible to get rid of the step_x/step_y based movement in favor of Game Maker's built in movement stuff. Using its direction, speed, hspeed, and vspeed with something like floor(x) or ceil(x) when it moves diagonally, it could give the same effect with the fractional components preserved appropriately. It's easier for me though to not be too dependent on Game Maker's functions so I can understand how the code is fully working.
About drawing sprites, I tried to do something in a previous topic where Link was drawn in pieces to save space in memory for the sprites where Link has a hat and doesn't have a hat. An issue that came up was that I would not be able to utilize Game Maker's Animation End event so I would have to keep track of when the animation ended manually. The key about the Animation End event is that it looks at the sprite_index which is based on one sprite. To use Link pieces with this I would have to make the animated pieces of Link be set to the sprite_index.
Needless to say that got a little confusing and I opted to rather just focus on the mechanics of Link movement that his drawing. I had looked at, I believe, mit's ice or mixtella's example of ice sliding which had some of the mechanics worked out but with more position checks and no real diagonal movement. But yeah, if you ever find that ice movement stuff, it might be useful to see it.
-
About drawing sprites, I tried to do something in a previous topic where Link was drawn in pieces to save space in memory for the sprites where Link has a hat and doesn't have a hat. An issue that came up was that I would not be able to utilize Game Maker's Animation End event so I would have to keep track of when the animation ended manually. The key about the Animation End event is that it looks at the sprite_index which is based on one sprite. To use Link pieces with this I would have to make the animated pieces of Link be set to the sprite_index.
So if I understand it right than you want to make Link do the same animations with and without the hat and still be able to use the animation end event. I would think the Animation End event is dependent on Link's body and not on the hat. So couldn't you separate the body and the hat. You would need a sprite sheet with Link without a cap with all his actions and an extra spritesheet for the hat for drawing the hat over the Link sprite when Link has the hat? You could connect the Animation End event to Link body. But I'm not sure how much it would reduce the Memory cost.
-
Essentially something like Link walking down with and without the hat, the two sprite animations for that have similar components. The idea was not to have redundancy by storing the similarity in memory when it could just be stored once. A problem that arose in a previous topic, maybe not noted in that topic, was that Link standing down compared to Link standing up had different parts which animated. To make it work, some redundancy has to return (the animated sprite for Link down had to contain the eyes) but in trade-off for the ability to classify hat Link and non-hat Link by not having the hat and non-hat.
That is probably a little confusing though in explanation. The Animation End event is based on animation; some of the Link pieces didn't need to animate like Link's standing down feet. For something like Link walking down the speed of the feet would be just cooresponding to the head's animation. The hat on Link isn't just placed on though, without it his hair is spiky.
-
The biggest thing with that is having to write your own animation system for sprites. They're annoying to make :P
-
Well, I believe their is a function on GM (A drag and drop one.) which is Friction, I came across it in a few tutorials at Yoyogames.com by Mark Overmars, when the character stops moving, he/she slides a little bit on the floor, if I remember. Setting it to just 2 doesn't matter, cause it'll make you slide -2 aswell.
The code that could slow retract speed is if(speed < 2) speed = min(2,speed+0.4), but this is for accelerating, instead of deaccelerating, so you'd just have to flip a few things around to get it to gradulally slow down, I use to have this script in one of my games, but I don't remember which ones, sadly.
I believe it was Friction that handled this, but, you can also make Gravity do this aswell. (Highly unrecommended, but it's worth a shot.)
Edit: You could also use that "Able to change direction" variable to your advantage, since when Link is slipping on ice, and you suddenly go down or up, he stays in that same frame for a second then changes direction.
Edit2: Slight mistake on my part.
-
About Edit 1, I am not sure if you are referring to an able_d variable that I might have had in another version of the engine, but looking at the Minish Cap game Link's normal ability to change direction is based on keys held and not movement made. The friction and gravity stuff you mention might also be a little odd with the engine in how it does diagonal movement correction and how the friction changes intensity.
Anyway, thinking about it a bit, the problem with not being able to slow down after just initially getting onto the ice is probably because the ice_slide script is ran when x and xprevious are the same - in that the x hasn't changed yet, Link hasn't moved or attempted to move. Adding a check at the end of the code might fix the issue I was having.
-
I figured out the condition needed to do what I was talking about. Essentially, I was perpetuating a problem I was trying to work around - Game Maker's xprevious/yprevious variables. They reset at the beginning of the step which made using them to do a position check stupid because I was already checking the x/y position (as said, at the beginning of the step they are the same as xprevious/yprevious). So what I did was add prev_x/prev_y. In short:
x/y - position of Link
xprevious/yprevious - what Link's position was at the beginning of the step
prev_x/prev_y - what Link's position was from the previous step
I also altered the code a bit; e.g. checking move_x to be != 0 is dumb when one could just check absv_x > 0. This should finish out the ice movement stuff (although some of it may be altered later to include a boolean for the speed bleed off when stopping - to assist with swimming).
The updated GMK is attached.
Edit: Actually, comparing the Minish Cap to my ice-movement stuff, moving diagonally on ice is faster than non-diagonally. Altering it so that the move_f = 1 when on ice and moving diagonally before checking to see if you hit anything makes it so ice movement is quicker and the effect more closely emulates the Minish Cap that way. Meh, might alter it or not.
-
Looks good but I get the feeling that in MC Link's maximum speed on ice is faster. And Link remains sliding a bit longer.
4Sword a small advice. Use comments in your code. I don't understand everything what your doing, because maybe I would do it different or I don't understand GMK as much as I want to. Especially in the scripts where nondescript arguments are used.
-
The non-diagonal speed maximum on ice seems to be just the same as off ice. Diagonal movement on ice and off seem to be different; as with the edit to my last post, having the move_f movement factor as 1 on ice instead of the square root of 2 allows Link to move faster giving the appearance of the correct affect. Otherwise in terms of how much Link drifts after not moving while on ice, to increase the distance traveled all that has to be done is altering the incrementation in the move_slide script.
I'll add comments into it in the next release, but mostly this is what all the variables are:
prev_x: the x position of Link in the previous step
move_x: defines the interval over which Link moves in terms of x, the -/+ gives the direction you are moving in or drifting towards
maxi_x: maximum x movement speed
step_x: the counter used to determine how much you move in terms of x per step
absv_x: absolute value of move_x, calculated because step_x needs to be based on a positive number to work right.
slip_b: slip boolean: if you are on ice
slip_p: slip previous: if you were previously on ice last step
move_f: move factor: correction if moving diagonally. Non-diagonal movement is just a regular 1 but diagonal movement is based on the square root of 2 which makes you move less diagonally so you don't move faster diagonally than non-diagonally.
The scripts aren't too fancy in that one can figure out what they do by their arguments, but I'll comment that later too. I suppose that would make the engine more useful to people.
-
Update: I think that I got it a little closer in terms of the drifting, but my perception is always a little off due to the way I think. I added in a fixed view so I would be able to work with a larger area all while having a fixed perspective so I could measure distances at a glance.
Also, for those who haven't looked into it at all, here's a screenshot just showing Link walking on ice for no reason:
(http://i8.photobucket.com/albums/a13/4Sword/icemoveshow.png)
The updated file, stuffed to the gills full of commenting, is attached.
-
First of all kudos for the comments in the code.
Second I have tested it and I think the turning is correct now, but the reversing not. When you change from left to right, up to down or vice versa I think you still need to slide a bit further and keep to one place a bit before actually going the other way.
The same goes for starting to walk on ice when standing on ice. Before Link actually moves he has to slip a bit.
-
Look, about the turning direction I am not sure exactly what you mean, all that involves is using a value to get to the other end of the move_x/move_y variable; shrinking this value makes it so you take the turning wider while increasing the value makes it so you take the turning shorter. I don't know I am not seeing what you are saying with respect to that.
About walking on ice after just standing on it, again I do not know what you mean other than currently on ice Link is building up speed until he gets to his maximum on the ice; so that he doesn't move at full speed right away. To slow this down so the buildup looks like more, it also makes it so turning has to be wider than it is in that GMK file.
Edit:
If you could, try altering the values in the move_slide script to values that work better for you. Like, for getting onto the ice after not being on it, you'd have to just change the "return (argument1 - argument0) * (argument3 - 2);" line so that "(argument3 - 2)" is something like "(argument3 - 1)".
The top min/max part is for speed incremenation when moving on ice, the bottom min/max part is for drifting when not holding any keys. I tried it with a .1 and a .0625 which might work better, I don't know.
-
I've been playing with the drift settings. To my opinion I think these are the best:
.2 -> .075.
.065 -> .035
But it is difficult to test without a visible 16x16 grid.
About the turning I meant the following example.
Link is walking over ice at its maximum to the left. You release the left arrow and at the same time press the right arrow. At this moment Link faces the other direction but still slides a bit to the left and slowing down. At the point where Link doesn't move his position the Link animation still makes 4 or 5 steps before Link actually moves to the right.
But I think that is fixed by changing 0.2 in 0.075 or somewhere around that.
On another note, I think it is better to make those 2 friction parameters, which you can add to the script. By doing this the script can be used for other surfaces, like the swimming in water or something else if needed.
UPDATE: To properly see what settings are correct, I tried to make an ice course like you have those in the games. So I implemented the Pit's Link can fall into. They work a bit. On normal ground it works like it should, but on ice Link can change the direction he faces before falling in a pit. After which he is put back on the wrong side. I tried 2 methods. One with the direction Link is facing and one by using the prev_x and prev_y, but it does not work correct on ice. I was thinking maybe I could use move_x, move_y and move_f. Ah well, it is late now, so I'm going to bed.
-
Okay, I added pits and it kind of works. Here is what I did:
Check at the beginning of the step if Link is falling, because it has the highest priority.
if(falling){
//check if falling is done. If not add 1 to the action timer
// else set Link back to the edge he came from.
if(action_timer == 12){
action_timer = 0;
falling = false;
//move to the edge Link had fallen from.
move_to_ledge(x,y, prev_x,prev_y,self);
//move_to_ledge(x,y,direction,self);
prev_x = x;
prev_y = y;
}else{
action_timer += 1;
}
}else{
Okay if Link is not falling, than just do movement code. And at the end of the movement code check if the new position is colliding with a pit. And if so set the correct settings.
//check if the new x and y are colliding with an special object like a Pit
if(position_meeting(x,y,objPit)){
//check if Link should fall. Then set all settings to it.
moving = false;
falling = true;
move_x = 0;
move_y = 0;
action_timer = 0;
inst_id = instance_position(x,y,objPit);
x = inst_id.x+0.5*TILESIZE;
y = inst_id.y+0.5*TILESIZE;
}
The problem is putting Link back on the ledge where he had fallen of. First I tried using the direction link is facing but that gives problems on the ice. So now Link's x and y are set to prev_x and prev_y. There still are some problems.
1) Sometimes it seems as if Link falls twice.
2) If Link walks to left on normal ground the prev_x is updated every step, but the prev_y still has the value from the last time the y position changed. This allows Link to be put back in a wrong position.
I'm still breaking my head over this. And it also isn't completely how MC works, I think.
-
Sorry I saw your edit late and was going to attempt adding in rolling or something; the pit seems like a more natural step though due to most ice situations involving being able to fall into one. The ice course is also nice, gives more variations and scenarios as to what movement can take place.
It is like 3:40 AM though so I cannot really fully review what you did, but on a quick observation of the Minish Cap falling scenarios, I cannot fully remember if falling into a pit is always like this, but in a dungeon, falling into a pit moves Link to the closest 16 x 16 gridspace and then returns him to the start position of the room or the last place of "solid ground".
I like the concept you used where Link's move_x/move_y can be used to move him without the need for keyboard assistance, but I am not too sure of your method with the variable checking and some code placement. The act of falling could be summarized as an "action", the only reason action_timer is in the Step Event is to reset it otherwise its incrementation gets handled in Draw, etc.
In an earlier version of the engine I had included variables like able_x, able_y, and able_d which allowed x movement, y movement, and changing direction. In conjunction with an "action" having able_x/able_y as false would keep Link from moving for the duration of the step; possibly hold_u and the rest could be set like keyboard_check(vk_up) && able_x.
I'll look over it some more when I wake up, but your addition is pretty good, I just have a hunch that it could be simplified.
Edit: and I can't remember if the last GMK I posted had the action or just the action_timer, but generally speaking, an "action" would really just encompass what to draw based on direction and whether or not Link is moving; with things like able_x, able_y and the generics like that used in the Step event such that the step event can be as general as it can be.
-
I have updated my previous post, because I clicked send a bit to fast. I have added my latest version of code.
I'll look over it some more when I wake up, but your addition is pretty good, I just have a hunch that it could be simplified.
I know for certain the code can be simplified. But my first priority is to get it to work like in MC.
For as far as I know it works like this in MC. Once Link falls he is set back to the last visited tile that Link can stand on (not the nearest tile Link can stand on), which would allow Link to be put back on the correct tile after a jump with roc's feather or when he jumps in water from a ledge he can't swim in. If the tile is taken by an enemy or another object in the time that Link fell, Link is set to the nearest available tile from that. Although for dungeons I don't really know, but I need to check the game for that. I will check that later.
On another note: I think it is best to change the moving and falling boolean variables into 1 state variable, which can be used in a single switch statement:
0 - idle/standing still
1 - walking/moving
2 - falling
3 - rolling
4 - flying etc.
And another state variable for the use of items. Like:
0 - nothing
1 - sword charge
2 - bow hold
3 - boomerang hold
4 - gust jar hold, etc.
-
Wow guys, I'd never tried this before. Looks pretty neat, only problem I see is that corner cutting isn't sensible enough. It should be like if you barely touch the corner it sends you in that direction. Makes getting around much easier.
Other than that, good job. :)
Edit: BTW, this is what I mean:
(http://img8.imageshack.us/img8/1269/82113880.png) (http://img8.imageshack.us/i/82113880.png/)
See, it's not sensible enough!
-
Wow guys, I'd never tried this before. Looks pretty neat, only problem I see is that corner cutting isn't sensible enough. It should be like if you barely touch the corner it sends you in that direction. Makes getting around much easier.
Other than that, good job. :)
Edit: BTW, this is what I mean:
(http://img8.imageshack.us/img8/1269/82113880.png) (http://img8.imageshack.us/i/82113880.png/)
See, it's not sensible enough!
Don't trick me like that, I thought that was actually a window I could drag for a sec :P
-
Okay, I have checked out how the falling in pits works in MC.
1) In a dungeon Link gets set back to the entrance from which he entered the room.
2) In the overworld and in caves Link gets set back to the tile he had last touch the ground. For example:
* When walking/running in he is set to the tile adjacent to the pit that Link came from.
* When getting shot by a mushroom Link is set back to the tile from where he grabbed the mushroom.
* When jumping with the roc's cape he is set back to the tile from where Link jumped up into the air.
3) In the overworld/caves when Link falls from the ice, he gets set back to the last tile where Link had normal ground under his feet. In other where he entered the ice. If Link jumps over normal tiles to other ice tiles those normal tiles don't count. Link actually had to touch the ground.
4) The holes don not suck Link in. He actually has to move into the hole on his own.
Now that I know this I can make it a lot better and easier. I just need to save the last normal tile Link was on and put him back there, and add a check for in the dungeon. I'll be making that later.
-
Don't trick me like that, I thought that was actually a window I could drag for a sec
Haha I spent a little bit of time trying to 'close' the window, it kept redirecting me to imageshack.us :P *facepalm*
Now that I know this I can make it a lot better and easier. I just need to save the last normal tile Link was on and put him back there, and add a check for in the dungeon. I'll be making that later.
How can you possibly check if it's a 'normal' tile or not? I would have just made an object that Link teleports to if he falls.
-
Now that I know this I can make it a lot better and easier. I just need to save the last normal tile Link was on and put him back there, and add a check for in the dungeon. I'll be making that later.
How can you possibly check if it's a 'normal' tile or not? I would have just made an object that Link teleports to if he falls.
Actually, it is pretty simple. The special tiles like ice (and later maybe water) have a special effect. So you need something to detect it. In gamemaker it is easy to detect collisions with other objects. If the tile is normal ground than there won't be any object. This is the code I used in the step event:
/*************************************************************************************/
//TODO make it more efficient
//check whether Link is falling in a pit, because it overrides
//all other actions
if(falling){
//check if falling is done. If not add 1 to the action timer
// else set Link back to the edge he came from.
if(action_timer == 12){
action_timer = 0;
falling = false;
//move to the edge Link had fallen from.
move_to_ledge(x,y, grid_x,grid_y,self);
prev_x = x;
prev_y = y;
}else{
action_timer += 1;
}
}else{
/*************************************************************************************/
and...
/*************************************************************************************/
//check if nothing is at the current position and thus standing on normal ground.
if(place_empty(x,y) && !inDungeon){
//TODO This can be more efficient.
grid_x = floor(x/TILESIZE);
grid_y = floor(y/TILESIZE);
}
//check if the new x and y are colliding with an special object like a Pit
if(position_meeting(x,y,objPit)){
//TODO make it more efficient.
//check if Link should fall. Then set all settings to it.
moving = false;
falling = true;
move_x = 0;
move_y = 0;
action_timer = 0;
inst_id = instance_position(x,y,objPit);
x = inst_id.x+0.5*TILESIZE;
y = inst_id.y+0.5*TILESIZE;
}
/*************************************************************************************/
The latest version of my code is attached. The only problem I still can't solve is that it looks as if Link sometimes falls twice.
-
Yeah, I had forgot ice wasn't just a tile, it's an object. xD
*downloads*
Wow that actually works really well. I didn't know we had another good coder in da house! :D Just another guy to bug when I'm stuck, haha! :D Nah dw, I rarely do that. :]
My only complaint now is that the camera view shouldn't abruptly hop to the new position. I don't know if it's like this in MC, but I think it would look better regardless. Make the camera slowly slide to the player.
Also, you should make a counter to count how many frames 'go by' when link falls. Then, after he reaches the last frame, make him reappear.
-
I'm not sure how it's handled in Game Maker, but I would have made an invisible object to act like an alternate shadow for Link. It'd have different collisions, so it'd stop on the "normal" tile when Link moves onto the ice. If Link falls, set his position to the alt shadow. If he gets to another normal tile, set the alt shadow's position to Link. Rinse, lather, repeat.
Of course that's how I'd do it in MMF2. I'm unsure if GM has a different/easier way of handling the job.
-
You mean like making the alternate mask collide with the ice and not follow Link around? Yeah, that's also a practical solution, good thinking. The downside is that you have to create a new object, though.
-
Yeah, I had forgot ice wasn't just a tile, it's an object. xD
*downloads*
Wow that actually works really well. I didn't know we had another good coder in da house! :D Just another guy to bug when I'm stuck, haha! :D Nah dw, I rarely do that. :]
My only complaint now is that the camera view shouldn't abruptly hop to the new position. I don't know if it's like this in MC, but I think it would look better regardless. Make the camera slowly slide to the player.
*Just got my Minish Cap GBA cartridge back.
Just checked it and you are correct. The camera slides to the return position very quick. On short distances it almost seems instantly, but on longer distances you notice the slide.
Also, you should make a counter to count how many frames 'go by' when link falls. Then, after he reaches the last frame, make him reappear.
That is done by the step counter. The falling animation contains 6 frames displayed at and imagespeed of 0.5, so after 12 frames the falling should stop. But 4Sword wanted to place that part in the draw event.
I'm not sure how it's handled in Game Maker, but I would have made an invisible object to act like an alternate shadow for Link. It'd have different collisions, so it'd stop on the "normal" tile when Link moves onto the ice. If Link falls, set his position to the alt shadow. If he gets to another normal tile, set the alt shadow's position to Link. Rinse, lather, repeat.
Of course that's how I'd do it in MMF2. I'm unsure if GM has a different/easier way of handling the job.
Like Darunia said: 'you have to create a new object'. The memory used for one object is far more than just 2 variables. Especially in GM, where an object has standard variables for position, direction, speed, health and of course its bounding box. In the way of code an object is probably also worse, because you need to define it's collision event. Keep it aligned with link or separate. Gamemaker object manager has to manage this object also. In Link you still need to check if you are on normal ground or not and update the x and y position of the shadow (or vice versa). So keeping 2 variables to record the return position is more efficient then creating a new object.
-
About the camera sliding, there was a code that someone did but I cannot recall who did it; it was probably mit because his code is awesome like that. The code for the view thing looks like like:
view_xview[0] = (view_xview[0] * 4 + (x - 120)) / 5;
view_yview[0] = (view_yview[0] * 4 + (y - 80)) / 5;
The code for the view that I had in there was mainly just added as a means to check sliding distance relative to things in a fixed position.
About the corner-cutting, it could be altered probably so that it has the ability to be more sensitive, but meh. The way it works differently from past corner-cutting is it checks to see if it is inside an object's bounding box at its previous position. If it is in that bounding box, then it checks to do the corner-cutting because otherwise all Link is running into is a flat wall. Adding more corner-cutting sensitivity in wouldn't be too difficult.
Creating a new object as an alternate shadow for Link, not sure what you mean by that, but the mask that Link uses works well enough, I'd think.
Also, about getting onto ice, falling in a pit, and returning to previous solid ground or start position, the way in which enters the ice (and how it also checks to see whether or not he had previously been on the ice) allows to have an "entry point" which can easily be determined. It might not need new variables either, just assigning new values to xstart and ystart.
-
Creating a new object as an alternate shadow for Link, not sure what you mean by that, but the mask that Link uses works well enough, I'd think.
What Jeod meant by that was making two shadows: the one you already made which follows Link absolutely everywhere he goes, all the time, and an alternate one which wouldn't be able to enter ice zones, or water, for example. It would stop moving once you collided into these zones and if Link was to fall into a hole, he would be teleported to the alternate mask. If he gets to a new normal tile, though, the alternate mask would teleport to him.
-
I just must have been confused over the fact that it was described as a mask; something more used for active collision testing. Makes more sense as a position; would probably work best with the xstart/ystart variable assignment I talked about in my last post.
-
Okay, I change grid_x to xstart and grid_y to ystart. But I still don't use the x and y position of Link, but the x and y on the grid of the tile.
Second, moved the first piece of code to the draw event.
Third added the camera shift code provided by 4Sword.
new file attached.
-
Using the grid position rather than the direct x/y probably makes more sense to do because otherwise Link would rematerialize right up next and close to the ice. The way Link falls and returns though seems to be pretty good so far. Nice job.
About what is in the draw event, I might tweak it a bit, not too sure as it does a lot of the code well, but mainly the edits would anticipate future changes to the code. And yeah, I'm working on the sensitivity stuff too.
Also, it might be helpful, if we come up with a better way to introduce updates to the code as redownloading GMK files takes up space.
-
Someone needs to invent a way to make patch exe files...
-
Using the grid position rather than the direct x/y probably makes more sense to do because otherwise Link would rematerialize right up next and close to the ice. The way Link falls and returns though seems to be pretty good so far. Nice job.
thnx.
About what is in the draw event, I might tweak it a bit, not too sure as it does a lot of the code well, but mainly the edits would anticipate future changes to the code. And yeah, I'm working on the sensitivity stuff too.
Okay. I do have an idea about increasing efficiency. I would recommend using a FSM with the Link object. Like I said in one of my earlier posts; We should merge the booleans for moving and falling into one variable, because the one cannot be true if the other is true. Using another FSM for the use of items might be required if we don't want to make the first FSM to complex.
Also, it might be helpful, if we come up with a better way to introduce updates to the code as redownloading GMK files takes up space.
Agreed, but I don't think GMK's work very well with SVN. Well one advantage is that normal movement, ice movement and falling in pits are the components that influence Link's other movements. All the other movements are/might be activated by items, but they don't really influence each other (well maybe the use of the sword).
-
Argh, I've been a complete idiot with setting the coordinates for pitfalling.
I had made the code following code:
inst_id = instance_position(x,y,objPit);
x = inst_id.x+0.5*TILESIZE;
y = inst_id.y+0.5*TILESIZE;
It is better to make it like this:
x = (floor(x/TILESIZE)+0.5)*TILESIZE;
y = (floor(y/TILESIZE)+0.5)*TILESIZE;
What an idiot mistake.