KAZESUI'S PROFILE

How did you reach the conclusion that "call event" uses 0.0167sec for overhead?

When I put up 3 events, 1 event to be called with a counter which added 1 for each call, a pp event which triggers if a switch is true and repeatedly calls the first event in a label loop, and a third event activated upon action, which turns switch on, waits for 1.0 sec and then turns switch off.

if what you said with 0.0167sec overhead for the command call event is true, then it should have been impossible for that counter to reach 150000 within that 1 second, yet it does.

the zelda tech demo is not the GB style one, it's a snes style one, but using the same way of travelling between maps as the gbc version due to simplicity reasons for handling the pixel style I suppose. This is the only panning ever done using the pan lock style btw.

anyway here's the tech demo:
Penguin's Zelda tech demo

It's clearly possible, and yes, it's fairly complicated.
What's normally done, is that the hero sprite is left transparent, and you use a picture to represent the hero instead, which you move around by adding or subtracting from some variables containing the coordinates for the picture, and where you use events to toggle between several pictures to animate the hero.

Among the many problems of doing this, is that you now need to use eventing to determine what tiles are passable, alternative ways of interacting with objects, like NPC's, and so on. Also, if you want the screen to scroll as it normally does, you'll have to calculate how much to push back the sprite when you pan the view, or you'll have to confine yourself to 20x15 maps (or pan lock it, and only show 20x15 at the time).

It's not just complicated, but it's also a lot of work. This is probably why you rarily see any rm2k3 games utilizing this apart from small games, or tech demos.

if this still doesn't scare you, you could take a look at the first level of Befuddle quest 5, which is a platformer with pixel movement in rm2k3. If you have questions about the code there, I can probably help you.
I also have an old Zelda tech demo lying around if you want to take a look at it. Can't help you as much with its code though, since I didn't make it.

author=calunio
Best way to learn how to sprite is:

1 - Open MS Paint.
2 - Zoom 8x.
3 - Edit.

After you're skilled with editing:

1 - Open MS Paint
2 - Zoom 8x.
3 - Draw.

Sadly, this is also my way of doing it.
It hasn't made me very skilled at editing, but it has made me skilled at MS paint

author=alterego
I don't know, why don't you try to change that "wait 0.7" command for a "wait until movement" or something like that, and give the engine time to do what is supposed to do...

just adding that "proceed with movement" might work well for debugging, but probably shouldn't be used as a final solution for an ABS game, since it will wait with execution of further code until ALL move events on the map are done executing.

as for the main problem, we can still only speculate in what the problem might be. If you want a more spesific solution, you'll probably have to make a test map where you can replicate the problem and upload the project somewhere, so that someone can look more closely at it, given that it's not too complex.