Subroutine X Performance Code Question

[junkatana]

Hello,

I'm new here, and I have some doubt about best way to organize code without sacrificing performance. So I start
organize my code in Subroutines when I call Sprite animations, move sprites, etc, like that:


Declare Sub CharAnimate()
´Animate code here
End Sub


Declare Sub CharMove()

´Movement code here

End Sub



If I organize the code by sub routine and call it, will it get heavy for the code?

I search anothers topics about it, but can't find it.

Please someone help me.

Thanks.

[pico]

I was wondering about this myself. Turns out that when you don't need to pass any arguments it's much faster to use labels.

The following code compiles to 6 instructions:

	gosub CharAnimate
	gosub CharMove
	end

CharAnimate:
	'Animate code here
	return
	
CharMove:
	'Movement code here
	return

The following code compiles to 28 instructions:

	CharAnimate
	CharMove
	end

Declare Sub CharAnimate()
	'Animate code here
End Sub


Declare Sub CharMove()
	'Movement code here
End Sub

[Deleted]

Creating subs and functions can certainly add overhead, which you can see by viewing the ASM output, when called. If you're using subs or functions without any arguments, I would simply do a "gosub linelabel", then add a "return" at the end of the line label code.

Sometimes setting up variables then jumping to a line label can create more overhead rather than using a sub or function with arguments, so it really depends on your usage.

[junkatana]

Dec 28, 2016 9:30:02 GMT -5 @elusive said:

Creating subs and functions can certainly add overhead, which you can see by viewing the ASM output, when called. If you're using subs or functions without any arguments, I would simply do a "gosub linelabel", then add a "return" at the end of the line label code.

Sometimes setting up variables then jumping to a line label can create more overhead rather than using a sub or function with arguments, so it really depends on your usage.

Thank you for that.
Once, I heard that "the beauty of the code is the sacrifice altar of performance". Make more sense now. So where's I can find a good tutorial about this things in this forum? And if my rom run ok on Everdrive, means that will run ok on Cartridge?

[junkatana]

Dec 28, 2016 9:27:56 GMT -5 pico said:

I was wondering about this myself. Turns out that when you don't need to pass any arguments it's much faster to use labels.

The following code compiles to 6 instructions:

	goto CharAnimate
	goto CharMove
	end

CharAnimate:
	'Animate code here
	return
	
CharMove:
	'Movement code here
	return

The following code compiles to 28 instructions:

	CharAnimate
	CharMove
	end

Declare Sub CharAnimate()
	'Animate code here
End Sub


Declare Sub CharMove()
	'Movement code here
End Sub

Thank you. Can you show me a goods tutorials about it?

[Deleted]

The everdrive can hide bugs, but generally yes, if it works on the ED, it'll most likely work just fine on its own dedicated board.

The issue I found was with using the TFM driver, which caused an issue with the timing/bus related, and froze the game after a few seconds. The Everdrive hid this bug.

As for tutorials on this sort of thing, it's more about experience and what your needs are. I would focus on learning the language and hardware, then you'll start seeing where things slow down and when things need faster code.

[pico]

Sorry, my mistake. I accidentally wrote goto instead of gosub in my previous post.

And of course this would be even faster:

CharAnimate:
	'Animate code here
	
CharMove:
	'Movement code here
	
	end

[Deleted]

If you put "End" before "Return", your program will stop

I try to avoid sub routines when possible, though I do use them out of laziness at times as well. Functions can serve more of a useful purpose since you can check the result using conditions, where subroutines you can't (no return value), but if it's a single line of code, you're adding a lot of behind-the-scenes code for almost no reason.

[Deleted]

With classic systems you really have to use GOTO and get good at structuring code yourself. GOSUBS and user functions may look clean but don't help much when you have 83 sprites to track for collisions and still need the screen to scroll decently.


One way I avoid GOSUBS is to organize my code as if it was event driven with begin, main and end sections:


bopha_begin
counter = (counter + 1) AND 255

bopha_main

bopha_end
goto bopha_begin

This helps me avoid GOSUBs and additional GOTOs by putting labels where I'd commonly want to go to (ha!). It also keeps me mindful of the game flow.

[Deleted]

Arg, please use : on your line labels In any other language, that will throw an assignment or unknown routine error.