SMIDP2lib for SDCC - Revision history

Mr lou at 16:42, 20 December 2011

2011-12-20T16:42:08Z

← Older revision		Revision as of 16:42, 20 December 2011
Line 38:		Line 38:
	=== ints vs shorts vs chars ===		=== ints vs shorts vs chars ===

	In the description of the methods below, you will notice that all methods take ints. This will not ~~necessarily~~ be the case in sMIDP2lib though. If it ~~improves~~ speed ~~using unsigned shorts or even unsigned chars/bytes~~, ~~then that'll probably~~ be ~~what we'll do instead. For now, each method is described with ints though~~.		In the description of the methods below, you will notice that all methods take ints. This will not be the case in sMIDP2lib though. Since it has been decided to limit the screen resolution to 256x256 pixels in order to gain more speed, all values can be given in unsigned char size.

	=== Memory requirements and handling ===		=== Memory requirements and handling ===
Line 55:		Line 55:
	==== Global values accessible from all assembler routines ====		==== Global values accessible from all assembler routines ====

	There will be 4 assembler values called sMIDP2lib_clipX, sMIDP2lib_clipY, sMIDP2lib_clipWidth and sMIDP2lib_clipHeight. They'll contain the coordinates and dimensions set by setClip(int x, int y, int width, int height) method, so that all other assembler routines can retrieve them. Each of these 4 values will be 1 byte.		* There will be 4 assembler values called sMIDP2lib_clipX, sMIDP2lib_clipY, sMIDP2lib_clipWidth and sMIDP2lib_clipHeight. They'll contain the coordinates and dimensions set by setClip(int x, int y, int width, int height) method, so that all other assembler routines can retrieve them. Each of these 4 values will be 1 byte.

	There will be 1 assembler value called sMIDP2lib_color which contains the current color set by setColor(int color), so that all other assembler routines can retrieve it. This value will be 1 byte.		* There will be 1 assembler value called sMIDP2lib_color which contains the current color set by setColor(int color), so that all other assembler routines can retrieve it. This value will be 1 byte.

			* There will be 1 assembler value called sMIDP2lib_currentBufferScreen which contains the number of the current non-visible buffer-screen. It'll either be 0 or 1. Each buffer-screen naturally has an address. These addresses will always be the same. They will never change. So assembler code can ask which screen is currently the non-visible buffer-screen. Note that the non-visible buffer-screen is the one being drawn to. The other screen is the one currently visible.
			Terminilogy-wise, "buffer-screen" is what we call the screen we're currently drawing to. This screen will always be hidden as long as we're drawing to it. Only when called flushGraphics() will it become visible. "Visible screen" is the current visible screen (which is never touched while it is visible).
			So flushGraphics() will mainly just do a check on which screen is currently the buffer-screen, and then make it visible screen, while making the visible screen the buffer-screen - and then next frame can begin.

	<pre>		<pre>
Line 72:		Line 76:
	sMIDP2lib_color:		sMIDP2lib_color:
	DB &01 ; Initial start value		DB &01 ; Initial start value

			sMIDP2lib_currentBufferScreen:
			DB &00 ; Initial start value
			sMIDP2lib_currentBufferScreenAddress:
			DB &xx,&xx ; I don't know what the initial value will be yet

	</pre>		</pre>

Line 98:		Line 107:
	The ones written ''in italic'' are some of the more heavier methods, and thus some that will most likely be implemented last in this first stage.		The ones written ''in italic'' are some of the more heavier methods, and thus some that will most likely be implemented last in this first stage.

	For all these methods goes, that coordinates (0,0) is located in the upper left corner of the screen. On the CPC, the lower right corner will be coordinate (~~319~~,~~199~~). '''Only MODE 1 will be supported in the first many versions of sMIDP2lib.''' If the project becomes popular, it's likely a MODE 0 version will be produced also.		For all these methods goes, that coordinates (0,0) is located in the upper left corner of the screen. On the CPC, the lower right corner will be coordinate (255,255). '''Only MODE 1 will be supported in the first many versions of sMIDP2lib.''' If the project becomes popular, it's likely a MODE 0 version will be produced also.
	If possible, it might be a good idea to change the resolution of the CPC MODE 1 from 319199 to 240320, since this is the resolution commonly used in J2ME productions. ''Is it possible to get a MODE 1 resolution of 240x320 pixels that'll work with a lib like this?''
	~~Another idea is to use a resolution of 255x255 pixels, if 255 pixels ends up being a limitation of the drawLine() and other methods~~.

	Besides the methods from the MIDP2.0 API, we also need a few additional methods that aren't part of the MIDP2.0 API. These methods are:		Besides the methods from the MIDP2.0 API, we also need a few additional methods that aren't part of the MIDP2.0 API. These methods are:
Line 149:		Line 156:
	''J2ME description: Gets the width in pixels of the displayable area available to the application.''		''J2ME description: Gets the width in pixels of the displayable area available to the application.''

	In sMIDP2lib, this will simply return ~~319~~		In sMIDP2lib, this will simply return 255

	=== Displayable.getHeight() ===		=== Displayable.getHeight() ===
	''J2ME description: Gets the height in pixels of the displayable area available to the application.''		''J2ME description: Gets the height in pixels of the displayable area available to the application.''

	In sMIDP2lib, this will simply return ~~199~~		In sMIDP2lib, this will simply return 255

	=== Image.createImage(String source-filename) ===		=== Image.createImage(String source-filename) ===
Line 218:		Line 225:

	unsigned char[] storedPieceOfBackground = new char[64]; // We only need space for 64 bytes, since that equals 256 pixels.		unsigned char[] storedPieceOfBackground = new char[64]; // We only need space for 64 bytes, since that equals 256 pixels.
	~~sMIDP2lib_bufferscreen~~.getRGB(storedPieceOfBackground, 0, 0, 0, 0, 16 16); // Size is still given in pixels, so the getRGB method needs to take care of the division by 4 and such		sMIDP2lib_bufferScreen.getRGB(storedPieceOfBackground, 0, 0, 0, 0, 16 16); // Size is still given in pixels, so the getRGB method needs to take care of the division by 4 and such
	// We ignore the offset and scanlength. They'll need to be part of the method, but will be ignored.		// We ignore the offset and scanlength. They'll need to be part of the method, but will be ignored.

	</pre>		</pre>

	The variable ~~sMIDP2lib_bufferscreen~~ is a struct containing a pointer to the address of the current buffer-screen, meaning the one we're currently drawing to. (We'll always be drawing to the non-visible screen). When ever flushGraphics() is called, the current non-visible buffer-screen is shown, and the previous visible screen not becomes the buffer-screen. Therefor, the pointer in the ~~sMIDP2lib_bufferscreen~~ struct, will change value when flushGraphics() is called.		The variable sMIDP2lib_bufferScreen is a struct containing a pointer to the address of the current buffer-screen, meaning the one we're currently drawing to. (We'll always be drawing to the non-visible screen). When ever flushGraphics() is called, the current non-visible buffer-screen is shown, and the previous visible screen not becomes the buffer-screen. Therefor, the pointer in the sMIDP2lib_bufferScreen struct, will change value when flushGraphics() is called.

	This is a good solution because we keep the MIDP2.0 API structure, and we aren't creating overhead since the data in the arrays can be overridden again and again.		This is a good solution because we keep the MIDP2.0 API structure, and we aren't creating overhead since the data in the arrays can be overridden again and again.
Line 324:		Line 331:
	=== Double-buffering makes it problematic to "un-draw" ===		=== Double-buffering makes it problematic to "un-draw" ===
	While double-buffering can potentially make things more smooth, it also causes some problems when it updates only parts of the screen.		While double-buffering can potentially make things more smooth, it also causes some problems when it updates only parts of the screen.
	Consider a sprite moving from left to right, an unknown number of pixels each frame, on top of a background. You would then use ~~sMIDP2lib_bufferscreen~~.getRGB() to store the piece of background you're about to draw on, in order to be able to redraw the background in next frame. Let's say the sprite is about to be drawn at (10,0) and it's a 16x16 pixels bit sprite. Then before drawing the sprite, you would call ~~sMIDP2lib_bufferscreen~~.getRGB() to save the 16x16 pixels piece of background, and then draw the sprite and then call flushGraphics().		Consider a sprite moving from left to right, an unknown number of pixels each frame, on top of a background. You would then use sMIDP2lib_bufferScreen.getRGB() to store the piece of background you're about to draw on, in order to be able to redraw the background in next frame. Let's say the sprite is about to be drawn at (10,0) and it's a 16x16 pixels bit sprite. Then before drawing the sprite, you would call sMIDP2lib_bufferScreen.getRGB() to save the 16x16 pixels piece of background, and then draw the sprite and then call flushGraphics().
	Next frame, you will then want to draw that piece of the background again to cover our sprite before drawing the sprite in the next location. But since we switched buffer-screen with the flushGraphics(), we are now drawing on another screen where our sprite is actually placed on another location. Therefor we will most likely not be deleting it properly.		Next frame, you will then want to draw that piece of the background again to cover our sprite before drawing the sprite in the next location. But since we switched buffer-screen with the flushGraphics(), we are now drawing on another screen where our sprite is actually placed on another location. Therefor we will most likely not be deleting it properly.

Mr lou at 16:10, 20 December 2011

2011-12-20T16:10:55Z

← Older revision		Revision as of 16:10, 20 December 2011
Line 48:		Line 48:

	=== RULES DECIDED SO FAR ===		=== RULES DECIDED SO FAR ===

			==== Screen resolution ====

			Has been set to 256x256 for optimal performance.

			==== Global values accessible from all assembler routines ====

	There will be 4 assembler values called sMIDP2lib_clipX, sMIDP2lib_clipY, sMIDP2lib_clipWidth and sMIDP2lib_clipHeight. They'll contain the coordinates and dimensions set by setClip(int x, int y, int width, int height) method, so that all other assembler routines can retrieve them. Each of these 4 values will be 1 byte.		There will be 4 assembler values called sMIDP2lib_clipX, sMIDP2lib_clipY, sMIDP2lib_clipWidth and sMIDP2lib_clipHeight. They'll contain the coordinates and dimensions set by setClip(int x, int y, int width, int height) method, so that all other assembler routines can retrieve them. Each of these 4 values will be 1 byte.

Mr lou at 16:08, 20 December 2011

2011-12-20T16:08:28Z

@@ Line 46: / Line 46: @@
 All loading of image and music into memory must of course be handled in some way. I am far from an expert on this area, but I imagine some kind of iterator, keeping track of where the next available memory is. Therefor we also need some way of freeing memory again, e.g. when we close a Player (for example to load a new tune).
 This is far from worked out at this stage though.
 == Supported Methods ==

Gryzor at 16:01, 20 December 2011

2011-12-20T16:01:25Z

← Older revision		Revision as of 16:01, 20 December 2011
Line 1:		Line 1:
	~~test~~

	''Current version of this page: v0.1''		''Current version of this page: v0.1''

Gryzor at 16:00, 20 December 2011

2011-12-20T16:00:58Z

← Older revision		Revision as of 16:00, 20 December 2011
Line 1:		Line 1:
			test

	''Current version of this page: v0.1''		''Current version of this page: v0.1''

Devilmarkus at 15:41, 20 December 2011

2011-12-20T15:41:28Z

← Older revision		Revision as of 15:41, 20 December 2011
Line 295:		Line 295:
	Currently, there are the following issues to work out a solution for:		Currently, there are the following issues to work out a solution for:
	=== Double-buffering makes it problematic to "un-draw" ===		=== Double-buffering makes it problematic to "un-draw" ===
	While double-buffering can potentially make things more smooth,		While double-buffering can potentially make things more smooth, it also causes some problems when it updates only parts of the screen.

	Consider a sprite moving from left to right, an unknown number of pixels each frame, on top of a background. You would then use sMIDP2lib_bufferscreen.getRGB() to store the piece of background you're about to draw on, in order to be able to redraw the background in next frame. Let's say the sprite is about to be drawn at (10,0) and it's a 16x16 pixels bit sprite. Then before drawing the sprite, you would call sMIDP2lib_bufferscreen.getRGB() to save the 16x16 pixels piece of background, and then draw the sprite and then call flushGraphics().		Consider a sprite moving from left to right, an unknown number of pixels each frame, on top of a background. You would then use sMIDP2lib_bufferscreen.getRGB() to store the piece of background you're about to draw on, in order to be able to redraw the background in next frame. Let's say the sprite is about to be drawn at (10,0) and it's a 16x16 pixels bit sprite. Then before drawing the sprite, you would call sMIDP2lib_bufferscreen.getRGB() to save the 16x16 pixels piece of background, and then draw the sprite and then call flushGraphics().
	Next frame, you will then want to draw that piece of the background again to cover our sprite before drawing the sprite in the next location. But since we switched buffer-screen with the flushGraphics(), we are now drawing on another screen where our sprite is actually placed on another location. Therefor we will most likely not be deleting it properly.		Next frame, you will then want to draw that piece of the background again to cover our sprite before drawing the sprite in the next location. But since we switched buffer-screen with the flushGraphics(), we are now drawing on another screen where our sprite is actually placed on another location. Therefor we will most likely not be deleting it properly.

Devilmarkus at 15:40, 20 December 2011

2011-12-20T15:40:18Z

← Older revision		Revision as of 15:40, 20 December 2011
Line 295:		Line 295:
	Currently, there are the following issues to work out a solution for:		Currently, there are the following issues to work out a solution for:
	=== Double-buffering makes it problematic to "un-draw" ===		=== Double-buffering makes it problematic to "un-draw" ===
			While double-buffering can potentially make things more smooth,

	Consider a sprite moving from left to right, an unknown number of pixels each frame, on top of a background. You would then use sMIDP2lib_bufferscreen.getRGB() to store the piece of background you're about to draw on, in order to be able to redraw the background in next frame. Let's say the sprite is about to be drawn at (10,0) and it's a 16x16 pixels bit sprite. Then before drawing the sprite, you would call sMIDP2lib_bufferscreen.getRGB() to save the 16x16 pixels piece of background, and then draw the sprite and then call flushGraphics().		Consider a sprite moving from left to right, an unknown number of pixels each frame, on top of a background. You would then use sMIDP2lib_bufferscreen.getRGB() to store the piece of background you're about to draw on, in order to be able to redraw the background in next frame. Let's say the sprite is about to be drawn at (10,0) and it's a 16x16 pixels bit sprite. Then before drawing the sprite, you would call sMIDP2lib_bufferscreen.getRGB() to save the 16x16 pixels piece of background, and then draw the sprite and then call flushGraphics().
	Next frame, you will then want to draw that piece of the background again to cover our sprite before drawing the sprite in the next location. But since we switched buffer-screen with the flushGraphics(), we are now drawing on another screen where our sprite is actually placed on another location. Therefor we will most likely not be deleting it properly.		Next frame, you will then want to draw that piece of the background again to cover our sprite before drawing the sprite in the next location. But since we switched buffer-screen with the flushGraphics(), we are now drawing on another screen where our sprite is actually placed on another location. Therefor we will most likely not be deleting it properly.

Devilmarkus at 15:39, 20 December 2011

2011-12-20T15:39:38Z

← Older revision		Revision as of 15:39, 20 December 2011
Line 295:		Line 295:
	Currently, there are the following issues to work out a solution for:		Currently, there are the following issues to work out a solution for:
	=== Double-buffering makes it problematic to "un-draw" ===		=== Double-buffering makes it problematic to "un-draw" ===
			Consider a sprite moving from left to right, an unknown number of pixels each frame, on top of a background. You would then use sMIDP2lib_bufferscreen.getRGB() to store the piece of background you're about to draw on, in order to be able to redraw the background in next frame. Let's say the sprite is about to be drawn at (10,0) and it's a 16x16 pixels bit sprite. Then before drawing the sprite, you would call sMIDP2lib_bufferscreen.getRGB() to save the 16x16 pixels piece of background, and then draw the sprite and then call flushGraphics().
	sMIDP2lib_bufferscreen.getRGB() to store the piece of background you're about to draw on, in order to be able to redraw the background in next frame. Let's say the sprite is about to be drawn at (10,0) and it's a 16x16 pixels bit sprite. Then before drawing the sprite, you would call sMIDP2lib_bufferscreen.getRGB() to save the 16x16 pixels piece of background, and then draw the sprite and then call flushGraphics().
	Next frame, you will then want to draw that piece of the background again to cover our sprite before drawing the sprite in the next location. But since we switched buffer-screen with the flushGraphics(), we are now drawing on another screen where our sprite is actually placed on another location. Therefor we will most likely not be deleting it properly.		Next frame, you will then want to draw that piece of the background again to cover our sprite before drawing the sprite in the next location. But since we switched buffer-screen with the flushGraphics(), we are now drawing on another screen where our sprite is actually placed on another location. Therefor we will most likely not be deleting it properly.

Devilmarkus at 15:38, 20 December 2011

2011-12-20T15:38:06Z

← Older revision		Revision as of 15:38, 20 December 2011
Line 296:		Line 296:
	=== Double-buffering makes it problematic to "un-draw" ===		=== Double-buffering makes it problematic to "un-draw" ===

			sMIDP2lib_bufferscreen.getRGB() to store the piece of background you're about to draw on, in order to be able to redraw the background in next frame. Let's say the sprite is about to be drawn at (10,0) and it's a 16x16 pixels bit sprite. Then before drawing the sprite, you would call sMIDP2lib_bufferscreen.getRGB() to save the 16x16 pixels piece of background, and then draw the sprite and then call flushGraphics().
			Next frame, you will then want to draw that piece of the background again to cover our sprite before drawing the sprite in the next location. But since we switched buffer-screen with the flushGraphics(), we are now drawing on another screen where our sprite is actually placed on another location. Therefor we will most likely not be deleting it properly.

	I don't have any ideas on how to solve this at the moment, other that either skipping the double-buffering part, or breaking the MIDP2.0 API rules. But I hope we'll find a solution.		I don't have any ideas on how to solve this at the moment, other that either skipping the double-buffering part, or breaking the MIDP2.0 API rules. But I hope we'll find a solution.

Devilmarkus at 15:36, 20 December 2011

2011-12-20T15:36:28Z

← Older revision		Revision as of 15:36, 20 December 2011
Line 294:		Line 294:

	Currently, there are the following issues to work out a solution for:		Currently, there are the following issues to work out a solution for:
			=== Double-buffering makes it problematic to "un-draw" ===