SMIDP2lib for SDCC - Revision history

Mr lou at 16:42, 20 December 2011

2011-12-20T16:42:08Z

Mr lou at 16:10, 20 December 2011

2011-12-20T16:10:55Z

Mr lou at 16:08, 20 December 2011

2011-12-20T16:08:28Z

Gryzor at 16:01, 20 December 2011

2011-12-20T16:01:25Z

Gryzor at 16:00, 20 December 2011

2011-12-20T16:00:58Z

Devilmarkus at 15:41, 20 December 2011

2011-12-20T15:41:28Z

Devilmarkus at 15:40, 20 December 2011

2011-12-20T15:40:18Z

Devilmarkus at 15:39, 20 December 2011

2011-12-20T15:39:38Z

Devilmarkus at 15:38, 20 December 2011

2011-12-20T15:38:06Z

Devilmarkus at 15:36, 20 December 2011

2011-12-20T15:36:28Z

@@ Line 38: / Line 38: @@
 === 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 ===
@@ Line 55: / Line 55: @@
 ==== 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.
 <pre>
@@ Line 72: / Line 76: @@
 sMIDP2lib_color:
 	DB &01	; Initial start value
-−
 </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.
-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 319*199 to 240*320, 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:
@@ Line 149: / Line 156: @@
 ''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() ===
 ''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) ===
@@ Line 218: / Line 225: @@
 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.
 </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.
@@ Line 324: / Line 331: @@
 === 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.
-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.

← 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.

@@ 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 ==

← 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''

← 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''

← 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.

← 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" ===