Sprite (Tutorial) - Revision history

Old-Sckool at 01:41, 18 February 2011

2011-02-18T01:41:55Z

← Older revision		Revision as of 01:41, 18 February 2011
Line 718:		Line 718:
	[http://www.digitalmzx.net/faq/sprite.html Saike's Sprite Tutorial] - Slightly out of date with regards to other MZX features.		[http://www.digitalmzx.net/faq/sprite.html Saike's Sprite Tutorial] - Slightly out of date with regards to other MZX features.

	[[Category:MegaZeux]]		[[Category:MegaZeux]][[Category:Tutorial]]
	{{stub}}		{{stub}}

Old-Sckool at 19:33, 7 February 2011

2011-02-07T19:33:08Z

← Older revision		Revision as of 19:33, 7 February 2011
Line 1:		Line 1:
	'''~~Sprites~~''' ~~were introduced~~ to ~~[[MegaZeux]] in version 2.65~~, ~~primarily as a method of making it easier to implement large object representations in~~ the ~~game (for example, [[Engine\|engines]] for handling a multiple character player or enemies)~~. ~~They include many features such as collision detection, easy drawing,~~ and ~~configurable draw order. Despite being designed to make coding easier~~, ~~many [[:Category:MZXers\|MZXers]] avoid their use in favor~~ of ~~more traditional methods such as [[overlay]] buffering~~ and ~~hand~~-~~rolled collision routines~~. ~~This is largely out~~ of ~~a perception that Sprites~~ are ~~difficult~~ to ~~use~~.		Despite the mystery and trepidation that generally surrounds them, '''[[Sprite\|sprites]]''' are not that hard to work with and are designed to be easy to use, with the right program model. Two common and effective models, which can be used together or alone depending on the requirements of the engine, are the '''sprite-layer model''' and the '''sprite-object model'''. The structure of your code will depend on the application and the model being used, but there are some basics to cover first.
	__NOTOC__		__NOTOC__
	<div style="border: 1px solid black; font-size: 1; display: table; padding: 1em">		<div style="border: 1px solid black; font-size: 1; display: table; padding: 1em">
Line 23:		Line 23:
	[[#External Links\|External Links]]		[[#External Links\|External Links]]
	</div>		</div>
	~~==Sprite Tutorial==~~
	Despite the mystery and trepidation that generally surrounds them, sprites are not that hard to work with and are designed to be easy to use, with the right program model. Two common and effective models, which can be used together or alone depending on the requirements of the engine, are the '''sprite-layer model''' and the '''sprite-object model'''. The structure of your code will depend on the application and the model being used, but there are some basics to cover first.
	{{a\|S1}}		{{a\|S1}}
	===The Basics: Drawing Sprites===		===The Basics: Drawing Sprites===

Old-Sckool: moved Sprite to Sprite (Tutorial): Writing a much shorter page for Sprites instead.

2011-01-26T19:37:26Z

moved Sprite to Sprite (Tutorial): Writing a much shorter page for Sprites instead.

← Older revision

Revision as of 19:37, 26 January 2011

Wervyn: /* Exercise 3.1: Creating a status bar */ clarified the meanings of the constant names used here.

2008-12-15T05:36:08Z

Exercise 3.1: Creating a status bar: clarified the meanings of the constant names used here.

← Older revision		Revision as of 05:36, 15 December 2008
Line 402:		Line 402:
	For our first foray into layer sprites, let's do something fairly simple to create, but that epitomizes the most basic purpose of layers: a status bar.		For our first foray into layer sprites, let's do something fairly simple to create, but that epitomizes the most basic purpose of layers: a status bar.
	<ol><li>Before anything else, we need to draw the base template for the status bar. This can be done mostly however you like, but it should at least have locations to draw health, ammo, and collected keys, and the locations and sizes of the places for drawing to these areas should be recorded as constants in the global robot. Here are the constants and sizes I'll be using:<tt>		<ol><li>Before anything else, we need to draw the base template for the status bar. This can be done mostly however you like, but it should at least have locations to draw health, ammo, and collected keys, and the locations and sizes of the places for drawing to these areas should be recorded as constants in the global robot. Here are the constants and sizes I'll be using:<tt>
	: set "lyr_s_x" to 0		: set "lyr_s_x" to 0 ''meaning layer-statusbar-refx''
	: set "lyr_s_y" to 3		: set "lyr_s_y" to 3 ''layer-statusbar-refy''
	: set "lyr_s_w" to 50		: set "lyr_s_w" to 50 ''layer-statusbar-width''
	: set "lyr_s_h" to 2		: set "lyr_s_h" to 2 ''layer-statusbar-height''
	: set "lyr_sh_x" to 10		: set "lyr_sh_x" to 10 ''layer-statusbar-health-refx''
	: set "lyr_sh_y" to 3		: set "lyr_sh_y" to 3 ''layer-statusbar-health-refy''
	: set "lyr_sh_w" to 25		: set "lyr_sh_w" to 25 ''layer-statusbar-health-width''
	: set "lyr_sh_h" to 1		: set "lyr_sh_h" to 1 ''layer-statusbar-health-height''
	: set "lyr_sa_x" to 43		: set "lyr_sa_x" to 43 ''layer-statusbar-ammo-refx''
	: set "lyr_sa_y" to 3		: set "lyr_sa_y" to 3 ''layer-statusbar-ammo-refy''
	: set "lyr_sa_w" to 5		: set "lyr_sa_w" to 5 ''layer-statusbar-ammo-width''
	: set "lyr_sa_h" to 1		: set "lyr_sa_h" to 1 ''layer-statusbar-ammo-height''
	: set "lyr_sk_x" to 8		: set "lyr_sk_x" to 8 ''layer-statusbar-keys-refx''
	: set "lyr_sk_y" to 4		: set "lyr_sk_y" to 4 ''layer-statusbar-keys-refy''
	: set "lyr_sk_w" to 40		: set "lyr_sk_w" to 40 ''layer-statusbar-keys-width''
	: set "lyr_sk_h" to 1</tt>		: set "lyr_sk_h" to 1 ''layer-statusbar-keys-height''</tt>
	The final result should look something like this, 50 characters wide, 2 high, with room for labels and a 2 character margin on each side:		The final result should look something like this, 50 characters wide, 2 high, with room for labels and a 2 character margin on each side:
	<pre style="display:table">\| Health: ========================= Ammo: 00000 \|		<pre style="display:table">\| Health: ========================= Ammo: 00000 \|
Line 456:		Line 456:
	: goto "drawloop"</tt>		: goto "drawloop"</tt>
	Then we need to flesh out each of those subroutines. Health is the easiest to do: we need a bar of filled health as long as the space in the status bar, so draw a line of red 25 characters long next to the other sprites, and re-export sprites.mzm. Make sure to add constants for this:<tt>		Then we need to flesh out each of those subroutines. Health is the easiest to do: we need a bar of filled health as long as the space in the status bar, so draw a line of red 25 characters long next to the other sprites, and re-export sprites.mzm. Make sure to add constants for this:<tt>
	: set "spr_sh_x" to 8		: set "spr_sh_x" to 8 ''meaning sprite-statusbar-health-refx, for the sprite image to copy onto the layer''
	: set "spr_sh_y" to 0</tt>		: set "spr_sh_y" to 0 ''sprite-statusbar-health-refy''</tt>
	To draw the health, we'll simply copy a portion of this bar based on the value of 'health' and 'maxhealth' (you'll have to set maxhealth to something yourself). This leads to:<tt>		To draw the health, we'll simply copy a portion of this bar based on the value of 'health' and 'maxhealth' (you'll have to set maxhealth to something yourself). This leads to:<tt>
	: : "#dohealth"		: : "#dohealth"
Line 516:		Line 516:

	{{a\|E3.2}}		{{a\|E3.2}}

	====Exercise 3.2: Bullets as a layer (framework)====		====Exercise 3.2: Bullets as a layer (framework)====
	Our next exercise is the most complicated individual piece of the engine yet: adding bullets and shooting to the game. There's no easy way to break it into pieces, but it'll really take at least two exercises to fully explain. So I'll do the best I can and break it into a framework phase, where we'll construct the basic skeleton for the code and explain what each part is going to do, and an implementation phase, where we'll implement each of the main subroutines and explain how they work.		Our next exercise is the most complicated individual piece of the engine yet: adding bullets and shooting to the game. There's no easy way to break it into pieces, but it'll really take at least two exercises to fully explain. So I'll do the best I can and break it into a framework phase, where we'll construct the basic skeleton for the code and explain what each part is going to do, and an implementation phase, where we'll implement each of the main subroutines and explain how they work.

Wervyn: /* Exercise 3.4: Interacting with the rest of the game */ Added Exercise

2008-09-17T20:12:17Z

Exercise 3.4: Interacting with the rest of the game: Added Exercise

@@ Line 692: / Line 692: @@
 ====Exercise 3.4: Interacting with the rest of the game====
+After all of that setup, actually integrating the engine into the game is so simple it barely merits an exercise of its own.  In fact I'm considering moving all of this back into the framework exercise, since it would fit there and only take up a couple steps.  But for now, let's just finish this out.
-(To Be Completed)
+<ol><li>The first thing we need is a way to let the player shoot something.  Going with the standard MZX gameplay mechanic, this means the player robot needs to handle spacebar when an arrow key is pressed..  Simply add this line to each of the movement subroutines (#up, #down, etc.):<tt>
 [[Sprite Code Examples#Example 3.4|Example 3.4 Code]]
 ==External Links==
 [http://www.digitalmzx.net/faq/sprite.html Saike's Sprite Tutorial] - Slightly out of date with regards to other MZX features.

Wervyn: /* Exercise 3.3: Bullets as a layer (implementation) */ Added Exercise

2008-09-17T07:25:56Z

Exercise 3.3: Bullets as a layer (implementation): Added Exercise

Show changes

Wervyn: /* Exercise 3.2: Bullets as a layer (framework) */ Implementation consistency, oops.

2008-09-16T05:46:01Z

Exercise 3.2: Bullets as a layer (framework): Implementation consistency, oops.

← Older revision		Revision as of 05:46, 16 September 2008
Line 523:		Line 523:
	: gotoxy "local" 0</tt>		: gotoxy "local" 0</tt>
	We need a separator to prevent this code from happening more than once, and have the code after it happen every time the board loads:<tt>		We need a separator to prevent this code from happening more than once, and have the code after it happen every time the board loads:<tt>
			: restore "justentered" 1</tt>
	: \| "justentered"		: \| "justentered"
	~~: restore "justentered" 1</tt>~~
	And we need some basic sprite initialization and placement:<tt>		And we need some basic sprite initialization and placement:<tt>
	: set "playerbullets" to "local"		: set "playerbullets" to "local"

Wervyn: /* Exercise 3.2: Bullets as a layer (framework) */ Added Exercise

2008-09-15T20:21:59Z

Exercise 3.2: Bullets as a layer (framework): Added Exercise

@@ Line 517: / Line 517: @@
 {{a|E3.2}}
 ====Exercise 3.2: Bullets as a layer (framework)====
+Our next exercise is the most complicated individual piece of the engine yet: adding bullets and shooting to the game.  There's no easy way to break it into pieces, but it'll really take at least two exercises to fully explain.  So I'll do the best I can and break it into a framework phase, where we'll construct the basic skeleton for the code and explain what each part is going to do, and an implementation phase, where we'll implement each of the main subroutines and explain how they work.
-(To Be Completed)
+<ol><li>First things first, we need our basic sprite handler robot preamble.  You've written this thing several times already, but let's go over it again.  We need a one-time execution section that sets a counter based on the robot id, renames the robot based on it, and moves the robot to the robot bank (this part is not strictly necessary but we'll do it anyway):<tt>
 [[Sprite Code Examples#Example 3.2|Example 3.2 Code]]
 {{a|E3.3}}
 ====Exercise 3.3: Bullets as a layer (implementation)====

Wervyn: Stubbing the remaining examples in section 3

2008-09-05T13:01:56Z

Stubbing the remaining examples in section 3

← Older revision		Revision as of 13:01, 5 September 2008
Line 1:		Line 1:
	'''Sprites''' were introduced to [[MegaZeux]] in version 2.65, primarily as a method of making it easier to implement large object representations in the game (for example, [[Engine\|engines]] for handling a multiple character player or enemies). They include many features such as collision detection, easy drawing, and configurable draw order. Despite being designed to make coding easier, many [[:Category:MZXers\|MZXers]] avoid their use in favor of more traditional methods such as [[overlay]] buffering and hand-rolled collision routines. This is largely out of a perception that Sprites are difficult to use.		'''Sprites''' were introduced to [[MegaZeux]] in version 2.65, primarily as a method of making it easier to implement large object representations in the game (for example, [[Engine\|engines]] for handling a multiple character player or enemies). They include many features such as collision detection, easy drawing, and configurable draw order. Despite being designed to make coding easier, many [[:Category:MZXers\|MZXers]] avoid their use in favor of more traditional methods such as [[overlay]] buffering and hand-rolled collision routines. This is largely out of a perception that Sprites are difficult to use.
	__NOTOC__ ~~__NOEDITSECTION__~~		__NOTOC__
	<div style="border: 1px solid black; font-size: 1; display: table; padding: 1em">		<div style="border: 1px solid black; font-size: 1; display: table; padding: 1em">
	<center>'''Contents'''</center>		<center>'''Contents'''</center>
Line 17:		Line 17:
	:[[#S3\|3 The Sprite-Layer Model: Working With Layers]]		:[[#S3\|3 The Sprite-Layer Model: Working With Layers]]
	::[[#E3.1\|Exercise 3.1: Creating a status bar]]		::[[#E3.1\|Exercise 3.1: Creating a status bar]]
	::[[#E3.2\|Exercise 3.2: ~~Implementing bullets~~ as a layer]]		::[[#E3.2\|Exercise 3.2: Bullets as a layer (framework)]]
			::[[#E3.3\|Exercise 3.3: Bullets as a layer (implementation)]]
			::[[#E3.4\|Exercise 3.4: Interacting with the rest of the game]]

	[[#External Links\|External Links]]		[[#External Links\|External Links]]
	</div>		</div>
Line 513:		Line 516:

	{{a\|E3.2}}		{{a\|E3.2}}
	====Exercise 3.2: ~~Implementing bullets~~ as a layer====		====Exercise 3.2: Bullets as a layer (framework)====
	(~~More to come~~...)
			(To Be Completed)

			[[Sprite Code Examples#Example 3.2\|Example 3.2 Code]]

			{{a\|E3.3}}
			====Exercise 3.3: Bullets as a layer (implementation)====

			(To Be Completed)

			[[Sprite Code Examples#Example 3.3\|Example 3.3 Code]]

			{{a\|E3.4}}
			====Exercise 3.4: Interacting with the rest of the game====

			(To Be Completed)

			[[Sprite Code Examples#Example 3.4\|Example 3.4 Code]]

			(more to come)
	==External Links==		==External Links==
	[http://www.digitalmzx.net/faq/sprite.html Saike's Sprite Tutorial] - Slightly out of date with regards to other MZX features.		[http://www.digitalmzx.net/faq/sprite.html Saike's Sprite Tutorial] - Slightly out of date with regards to other MZX features.

Wervyn: Made some mistakes, forgot a couple things. Last edit I promise.

2008-09-02T17:54:35Z

Made some mistakes, forgot a couple things. Last edit I promise.

← Older revision		Revision as of 17:54, 2 September 2008
Line 461:		Line 461:
	<li>Now for the ammo. The easiest way to read this out of a counter and onto the vlayer is to convert the counter into a string. MZX will do this for you without having to write a conversion routine. We would like to write that string directly to the vlayer, but unfortunately MZX doesn't support that operation in a convenient way right now (though it may in the future). We could write it to some off-screen space on the overlay and then copy it, but depending on how you set up the board scrolling in the last section, you may not have any off-screen space. So we'll just have to loop through the string.<tt>		<li>Now for the ammo. The easiest way to read this out of a counter and onto the vlayer is to convert the counter into a string. MZX will do this for you without having to write a conversion routine. We would like to write that string directly to the vlayer, but unfortunately MZX doesn't support that operation in a convenient way right now (though it may in the future). We could write it to some off-screen space on the overlay and then copy it, but depending on how you set up the board scrolling in the last section, you may not have any off-screen space. So we'll just have to loop through the string.<tt>
	: : "#doammo"		: : "#doammo"
	: set "$ammo" to "ammo"		: set "$ammo" to "&ammo&"
			: . "Ampersands are required, so that we don't just draw 'ammo' on the screen."
	: loop start		: loop start
	: set "vch('lyr_sa_x'+'loopcount'),('lyr_sa_y')" to "$ammo.&loopcount&"		: set "vch('lyr_sa_x'+'loopcount'),('lyr_sa_y')" to "$ammo.&loopcount&"
Line 490:		Line 491:
	: set "local3" to 0		: set "local3" to 0
	: if "('spr&playersprite&_y'-'scrolledy')" >= "('vh'-'spr_p_h'/2)" then "drawnext"		: if "('spr&playersprite&_y'-'scrolledy')" >= "('vh'-'spr_p_h'/2)" then "drawnext"
	: set "local3" to "('vh'-'~~spr_p_h~~')"		: set "local3" to "('vh'-'lyr_s_h')"
	: : "drawnext"		: : "drawnext"
	: put c?? Sprite "local" at "local2" "local3"		: put c?? Sprite "local" at "local2" "local3"
Line 505:		Line 506:
	: : "keyenter"		: : "keyenter"
	: restore "keyenter" 1		: restore "keyenter" 1
	: goto "drawloop"</tt></li></ol>		: goto "drawloop"</tt>
	That does it for our status bar. You'll want to add in some test code and make use of the counter debugger to see that the various elements are reporting their numbers correctly, ~~of course~~.		Since the status bar is now replacing the default enter menu, make sure to have the global robot turn that off by setting 'enter_menu' to 0.</li></ol>
			That does it for our status bar. You'll want to add in some test code and make use of the counter debugger to see that the various elements are reporting their numbers correctly, but you can take this robot and drop it on every screen on which you want to have a status bar.

	[[Sprite Code Examples#Example 3.1\|Example 3.1 Code]]		[[Sprite Code Examples#Example 3.1\|Example 3.1 Code]]