MIDP 3 started

Motorola has submitted JSR 271: MIDP 3. If you have any game-related wishes for MIDP 3, get ready to start pushing for them! The list of stuff in the JSR already includes lots which would help game developers. One target is to “Enable richer and higher performance games”.

Would it be a good idea to use these forums to gather game developers’ wishes? I could pass them on to my company’s expert group members; however it might be better if game developers had an independent voice on the expert group.

The most important feature would be drawing scaled images. Having a variation of drawImage() scale the image to fit inside a specified rectangle, just like in the J2SE edition. Obviously this would have to be very fast, with a strong emphasis on being implemented as low-level as possible (perhaps hold a gun to their head!). It must also support transparency and avoid using any heap. If this were done properly then it would be the single most useful game-related feature of them all. Of course, in reality, each implementation would do it differently and none of them would get it right. :’(

And the following would be welcomed too:-

  • Arbitrary image rotations/transforms.
  • A palletised version of drawRGB()/drawPixels().
  • The ability to create mutable images with transparency.
  • Anti-aliased drawing.
  • More fonts.

And now for the ‘moon on a stick’ wishlist:-

  • Guaranteed midi sound support (with no prefetch delays).
  • Guaranteed semitransparent pixel support.
  • System.disableGC(), enableGC(), forGodSakeDoItNowGC().

actually - I just need more heap, jarsize and an actually working network stack.

Oh and ofcourse the most important one. A new Technology Compatibility Kit that FAILS all devices which don’t behave properly - never gonna happen, but would really make porting soooo much easier :slight_smile:

Arbitrary scaling is really needed. I created one method in my MicroGo game to scale source images (mutable or immutable) into an immutable image.

Comments? 8)

/**
* Changes the image to a new size
* @author Yu You
* Copyright 2005.
* PM me at: yuyou_@hotmail.com
*
* @param originalImage,
* or null
* @param width
* @param height
* @return Image the new Image. Never be null.
*/
public static Image resize(Image originalImage, int width, int height) {
//if (height <= 0 || width <= 0)
//throw new Exception(“ERROR_INVALID_ARGUMENT”);
if (originalImage == null)
return Image.createImage(height, width);
int orig_h = originalImage.getHeight();
int orig_w = originalImage.getWidth();
if (orig_w == width && orig_h == height)
return originalImage;
int[] orig = new int[orig_h * orig_w];
originalImage.getRGB(orig, 0, orig_w, 0, 0, orig_w, orig_h);
int index;
int[] newbuffer = new int[height * width];
int loc, oldloc = 0;
//long before = System.currentTimeMillis();
for (int i = 0; i < height; i++) {
for (int j = 0; j < width; j++) {
loc = i * width + j;
index = (int) (i * orig_h / height) * orig_w
+ (int) (j * orig_w / width);
//System.arraycopy(orig,index,newbuffer,loc,1);
newbuffer[loc] = orig[index];
}
}
//System.out.println(“time:”+(System.currentTimeMillis()-before));
Image newImage = Image.createRGBImage(newbuffer, width, height, true);
orig = null;
newbuffer = null;
System.gc(); //
return newImage;
}

MIDP 3 is currently being discussed on Sun’s KVM-INTEREST group, with some overlap to here too.

You can be sure that the expert group members read KVM-INTEREST.

[quote]Oh and ofcourse the most important one. A new Technology Compatibility Kit that FAILS all devices which don’t behave properly - never gonna happen, but would really make porting soooo much easier :slight_smile:
[/quote]
That would be good enough for me.

yuyou: Thats a good piece of code. It could be useful for rescaling images before the game starts. I think that due to the restrictions in MIDP, the transparent pixels would be lost, but I don’t see any way around that. (Edit: on second thoughts, the tranparent pixels would be kept intact; so ignore that)

david: It’s amazing. kvm-interest has suddenly sprung back into life after being almost dormant for several months.

I fully agree with the TCK comments. We can only hope.

There is nothing stopping you doing the image resize before the png data is ever constructed into an Image object.

The only downside is the zlib and IDAT chunk CRCs would have to be reconstructed each time you manipulated the image data.

Manipulating png data and recalculating it’s CRC is uber-hardcore. I like it. :wink:

I see a lot of requests for scaling and rotation. Has anyone tried to use JSR-184’s immediate mode for this?

shmoove

I did, and I agree, I don’t see urgent needs related to scaling and rotating.
I think what jsr 184 offers is enough, It fills all my needs so far

Franck

That’s what I thought. Even though I never played around with JSR-184 it immediately came to my mind that it could be used to implement certain effects for 2D games (I’m still not sure how popular 3D will get on phones, despite all the hype it gets). For me, a JSR-75 phone is all I need for now. Another MIDP spec will just fragment the market even more. I don’t think we need another spec for now.

shmoove

Yep I have used JSR-184 to do image scaling. I guess it depends on what you are trying to achieve but nothing ever seems straight-forward with M3G. Ideally all of your game content would be drawn using 3D co-ordinates as there is little point in trying to persuade M3G to draw a textured object at a predestined 2D screen location due to the number of factors involved. And Sprite3D can be incredibly slow on the current devices. Don’t get be wrong, M3G has great reasonable potential for 3D games, but personally I try to avoid it for 2D content. Perhaps when M3G devices become faster, more stable and more widespread will I change that view.

Image scaling and rotations is something that should have been in the original MIDP spec from the beginning. MIDP3 has the opportunity to put that right. MIDP2 took at least 2 years, so I’m hoping to see the first MIDP3 device in 2007 with amazing image scaling capabilities. ;D

I hope they include standard codes for SoftKeys and Clear, although many phones use the same of Nokia, its need to make code more portable.