source? I'd actually be interested in messing with the engine a little now. Maybe work on a surface system for the torch or something.
Like 4Sword said it is the top attachment. It is the rar-file because it contains both a GM7 and a GM8 version.
Also, not sure if this is a bug but if you roll onto the ice your movement speed either doesn't decrease fast enough or at all;
Yeah, the speed does not change at all. It does not accelerate nor decelerate. I have been looking at it in MC, but I can not really discern the behavior. Sometimes Link seems to accelerate on ice and sometimes not. Can't really find out what. I'm missing something obvious. Might have to tweak the ice movement parameters also.
and also if you do that onto ice and then try and move in the opposite direction you are sometimes able to do that really quickly.
That is a feature of MC as well. It all depends on your initial speed before rolling.
It was also cool that you were able to get the bow walking sprites to be more efficient in terms of image dimension, but there is probably a better way to handle moving with an item such that the item's "shaking" doesn't have to be done in the image but rather some sort of displacement based on Link's image_index. Then again I haven't really looked into the plausibility of that; e.g. whether or not the bow is always in the same position when Link is on a certain image_index.
Yeah cropping the images was a pain in the ass. Not that it is difficult, but it was a lot work. Walking animations with items can also be reduced to a single frame for the item, that is a fact. And you can alter it by giving the x and y an offset for each frame. But like with the cropping you've got the problem with lining the item up with Link.
And my monitor has a pretty high resolution, thus lining things up on pixel accuracy is damn hard. I think I felt my eyes popping once from the staring.
For example with the bow it has to be aligned with Link's front hand. When moving left GM frame 2, 3 and 6 need an y-offset of +1. When going down this is frame 2 and 6. But what I need to know is what GM does during draw_sprite(). Does it increase the image_index and then renders the image to the backbuffer, or does it render the image to the backbuffer and then increase the image_index. If I know that, I can decrease the walking frames for items.
The same also counts for walking with the Lantern. Ah well, sometimes you need to work on something else before you can improve your earlier work.
The lantern starting transition could be a bit quicker.
Yeah, I had the image_speed set to 0.05, to check the lining up of the lantern in every frame. After that an image_speed of 0.25 looked pretty quick. I think MC's usual speed is 0.33. I will change it. Also note that after loading there is a moment where the fire of the lantern is ignited. I didn't program the particle effect, but I did make the transition stage.
There was an addition I was working on which divided parWall into parWall and parCorn which would give some efficiency; in that corners don't have to be large objects (could be 16 x 16) and that if checking for parWall was done first corner-cutting would also only be done if there was no "walls" around the corners.
Yeah, saw that earlier. At this moment it looked best to do it this way. But I just checked with MC and I noticed a huge mistake. The igniting of the torch has an additional Link animation and is activated from a larger distance. So I still have to work on it. Beginning with ripping the ignition animation.
The any key stuff might be able to be sped up if if-else if statements are used, but otherwise the idea of doing it that way is a pretty good way to handle the event.
if-else is definitely more efficient. But I have to say that I only learned GameMaker in a few weeks over the last summer. I do not know the complete ins and outs of gamemaker yet. I didn't know when I use the <Any key> it would also generate multiple key events in a single cycle, when multiple buttons are pressed at the same time. When multiple key events are generated, then it is best to change it to if-else because it is real dumb to evaluate each button in every key event.
