Is it possible to create a fade effect in MIDP2? I have a screen showings stuff with LayerManager. Then I need to change to another screen (like the player entering a city). The screen would then fade out, and fade in inside the city.
Theoretically it would be possible using Image.getRGB and Image.createRGBImage (names from memory: no JavaDoc on this PC). But you’d need to create a new image for each step of the fade, which is probably prohibitive.
What you’d need is a new method something like:
graphics.drawImage(myImage, x, y, alpha);
This might be a good thing to ask for from MIDP 3. Why not ask for it on KVM-INTEREST? They’re gathering MIDP 3 requirements there right now.
While it would be nice to see full alpha support in MIDP3, you can do a cross-fade in MIDP2 without much trouble at all.
Graphics::drawRGB(int[] rgbData, int offset, int scanlength, int x, int y, int width, int height, boolean processAlpha)
Not bad. I really should put the JavaDocs on that PC at home.
Abuse: have you actually used this technique? Seems like you’d have to modify the alpha value of each pixel in your RGB array for every step of the fade. Does that run fast enough for smooth fades, on real phones?
From my experience, the drawRGB method needs to be sped up by a number of magnitudes before it can really be used (for fullscreen fades). Something that I have done for fullscreen fade in and outs is as follows:
-
Create an image out of RGBA values - make sure that its width fills the whole screen, but make sure its height is no more than 27 pixels. You can’t create immutable images with arrays larger than 4096 length.
-
Save the image data into an immutable image for use later.
-
Go back to step 1, but increment the opacity value.
-
The result - you end up with an array of small immutable images which are relatively fast to draw.
Now, when you wish to do a fade, just fill the screen with 8 of the currently selected immutable images. Your logic code will progress the array counter to select the next more or less opaque image in 100 milliseconds or whatever.
Works for me.
Regards,
Ribot
nope, I havn’t done it myself, but I’m quite sure it’d be fast enough.
I was actually thinking of just fading between the 2 images rgb values, the alpha would play no part in it.
Sounds ike a handset issue???
“Sounds ike a handset issue” - it affects all recent MIDP2.0 series 60 phones. 
I’ll try the drawRGB to see how it performs. Anyway, I’ll just be sure to create other types of “fades”, like striping out, squaring out etc.
How about using setClip to only draw small 2x2pixel or 4x4 pixel sections of the image in random order over a specific amount of time into an offscreen bitmap. Keep track of which ones have been drawn so far and then over time the complete image will appear to fade in.
Wood
Fading can be done very cheaply on Nokia devices just by using DirectGraphics.fillPolygon(). Simply paint your graphics as normal but afterwards draw a rectangle (using fillPolygon) to cover the entire screen. This is drawn using an ARGB color so by slowly modifying the alpha component every frame you can fade the polygon in or out. This is a nice and cheap trick - but sadly it only works with the proprietary Nokia API.
[quote]Fading can be done very cheaply on Nokia devices just by using DirectGraphics.fillPolygon(). Simply paint your graphics as normal but afterwards draw a rectangle (using fillPolygon) to cover the entire screen. This is drawn using an ARGB color so by slowly modifying the alpha component every frame you can fade the polygon in or out. This is a nice and cheap trick - but sadly it only works with the proprietary Nokia API.
[/quote]
I believe the poster was after a cross fade between 2 images, not a fade to color.
Yes that’s right, sorry, it will only fade between the polygon color (eg. blackness) and whatever is being drawn underneath. Admittedly it is rather limited, especially as it requires the Nokia API, but it can be a simple and cheap alternative if you don’t mind it fading-out to black. Once the black polygon is fully opaque you can switch the graphics underneath before fading back in to slowly reveal the new screen.
Oh dear!
I should have said that the screen would fade to BLACK, and then fade in inside the city. Falken gave me the solution. Thx. Maybe we should ask for gamma support in kvm-interest? So fading to black would be easy, just decreasing the gamma until the screen is completely balcked out. Then, add gamma gradualy until is returns to its default value.
Nice to know the solution! How did you find the performance of the fillPolygon method? If you don’t mind, what devices have you tested on and what gap in time and alpha have you found good for a smooth fade?
[quote]Maybe we should ask for gamma support in kvm-interest?
[/quote]
I think you should. It’s already on my list of things to bring up with our Expert Group members; what I have in mind is:
graphics.drawImage(image, x, y, anchor, alpha);
Then you could vary the alpha with each redraw to do a corss-fade. Another thing on my list is:
graphics.setARGBColor(r, g, b, alpha);
graphics.setARGBColor(argb); // 0xaarrggbb
That’s already in the Nokia UI API, so clearly easily implementable at least for Nokia ;). And that would allow you (by setting colour to 0xaa000000 and filling a rectangle) to do the fade to/from black.
MIDP 2.0’s support for transparency in PNGs states that you either support alpha fully, or treat anything other than full transparency as fully opaque. I’d like to propose the same principle for the possible wider transparency support MIDP 3.0 (e.g. the methods above) so that it wouldn’t be too much of a burden for the least powerful phones. Otherwise the manufacturers might have to veto the whole thing. Would that be acceptable to you lot?
Why limit alpha’ed drawing to drawImage?
An alpha global to a Graphics context would be alot more useful. (alpha’ed fillRects, and drawLines for example)
/*
* @param value Valid range of values 0 to 255
*/
setAlpha(int value)
You’d get alpha’d fillRects and alpha’d drawLines from that setARGBColour method, by setting the current colour to a colour with the right alpha component.
I agree that a setAlpha instead could then be taken to apply to drawImage as well, removing the need for a new drawImage method with an alpha parameter. Either would be fine. But I like the idea of emphasizing the concept of colour naturally having an alpha component.