I need a way to grab a squared area of a bitmap, to display it on screen. My bitmappedfont is 320x288 big containing images each 25x25 (these are not the actuale sizes ).

I need code/example on how to grab for example the 14th "character" from the bitmap, returning it as a ImageItem. How to do such? Can anyone remember the old-skool horizontal scrolltexts "demo"/intro's on the ole' 8-bit computers (Amiga, Commodore64, Atari)? Such a scroller is my intention.

remember to reset the clip afterwards or (better) before each rendering.

It is also possible to use translations but IIRC there are some devices that are buggy.If you just want to get the demo running on a few devices, then it should be ok to use.

Some things to remember:Never copy an image onto another image. You will lose your transparency.If you are using MIDP2.0 or only Nokia devices you can also use the direct pixel rendering features that also support alpha values.

You need a Graphics object to set the clipping for! (get it from the paint() method of your midlet).Take a look at some of the examples that come with the (free) sun WTK: http://java.sun.com/products/sjwtoolkit/

@pappavis:Well it was pseudo code that you were supposed to make work on your own.

Like SimonH says, you need the graphics object which is passed from the Canvas' paint method.

If you are missing a library? Well if you have not added any libs, then probably.I would suggest you get the WTK emulator and just include the libs from there as IIRC it has all the libs that are really needed.

If you are aiming for lowest common denominator, only include the MIDP1.0 lib.

One more thing. Working on J2ME can be a challenge. Low memory, weak CPUs, slow displays. And when you are working on games or graphical applications such as a demo it is all the more important.So optimise your heart out!

If you have any questions, post them and we will try and help.You can also post/send the code if you like.

This is my first attempt at doing anything with Java. This bedroom-rpogrammer idea is to recreate the ol' 8-/16-bit scrolltext found on AMiGA, Commodre64 etc. but then do it on J2ME.

My code need to more or less do the following;1. Read a text string into an array.2. Associate each letter (element) in the array with an appropriate letter.3. Draw all letters after each other on displayarea (the screen) from left to right.4. Shift all X-positions of the letters a few pixels to left.5. Repeat (3) until the last letter has disappeared to the left side of the screen.

The aforementioned is no problem coz such is running in a window$ BlitzMax .exe already. See earlier post for a screenshot. My problem is step (2) and (3) in the above process. Blitzmax have a neat feature that it handles tiledbitmaps nifty:

The method drawFrame uses the code frm earlier post. If the program code could produce a scrolltext on the emulator it should probably be run on my Samsung E900 as well . My dev environment is Netbeans 5.5 with J2ME kit installed.

@pappavis:Call me slow but why are you using such complicated processes for such a task?

From what I can read (my dutch? is non-existent) you are calling the paint method for each letter?In the paint method you are creating some object and then assigning the values and whatnot..

What you should do is reduce the rendering to it's bare minimum.Create your tiled sprite on app start and then only use it's paint method when you want to draw the letters.

So how I might do it:Use Simons Midlet and Canvas classes* add a Sprite class that handles the rendering of the tiles. this class should get the loaded image and the col- and row count and from that init all data the paint method should get the graphics context, position info and the col/row or an index you then generate col/row from. (then you have a good general purpose sprite class you can reuse)

the paint method could look similar to the example I had pasted.

then when your midlet is running and paint is called you do* loop through the letters and get their image indexes* call the sprite class' paint method and pass it the graphics context, position and index/cell/row information.

Good idea to also reset the clip to the screen size after you call mehods that might change the clip, seeing as there is no reset-clip-method.

@SimonH thanx for the example of SetClip.@Overkill, thanx your idea for sprite works great.

The text scrolls . Using a Spirte class and giving the tilewidth, heigh 32x32 the correct tile ("letter") is indeed take from the tiledmap. However now a problem happens, that the letters are painted on screen causing 'smudging'. Is setClip meant to fix that smudging?

So how I might do it:Use Simons Midlet and Canvas classes* add a Sprite class that handles the rendering of the tiles. this class should get the loaded image and the col- and row count and from that init all data the paint method should get the graphics context, position info and the col/row or an index you then generate col/row from. (then you have a good general purpose sprite class you can reuse)

then when your midlet is running and paint is called you do* loop through the letters and get their image indexes* call the sprite class' paint method and pass it the graphics context, position and index/cell/row information.

Good idea to also reset the clip to the screen size after you call mehods that might change the clip, seeing as there is no reset-clip-method.

Wow, I've never seen that hideous CLASS_NAME and METHOD_NAME style before. What's wrong with using getClass().getName() and using the stack trace that the exception gives you? Both provide more information and since they're automatically generated they don't need to be maintained (and hence aren't likely to drift out of sync).

Oh come on, relax a little bit.Heck stack trances will work on a PC but not on a Mobile, but no one is blasting anyone for that slip up.

Best practice would be to make sure your code works safely without the need for try/catches or throwing around exceptions.Besides try/catches would make an already weak mobile app even slower, it does not really help once the app is on the device.You also do not have anywhere to write the information anyway as there is no console and most do not have any debugging support (and those that do have the least problems)

Worst of all, the emulator is no criteria if the app will run bug-free on the mobile or not.

They do work, but of course on a mobile there's no console! Some of the better devices (Sonys mostly) allow a console on a PC via Bluetooth/IR and most emulators support a console, so it's not all that bad!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org