🔒 Locked

[java] Applets and images

Started by Kanzetsu Dec 5, 2001 at 5:31 PM 6 replies 350+ views

Original Post

Dec 5, 2001 at 5:31 PM

I''m currently trying to implement a small game engine, which probably will be used for tile-based games. The game will be applet based. What I really can''t get a grip on is how to handle images. Image? BufferedImage? VolatileImage? Raster? WritableRaster? etc etc. Which one should I use? Since I''m interested in making a Mario-style game, I need to have some sort of transparency (full translucency is not really that imported, just per-pixel "visible"/"not visible"). How do I do this, and what classes should I use? What makes it even harder for me to decide is because of the different versions of Java browsers use. Netscape uses 1.3, so no problem there, but IE is still at 1.1. I know that I can activate 1.3 by changing the CODEBASE attribute of the APPLET tag, but will I still be able to access more than one of my own classes? A lot of questions, but to summarize: I want to display images (sprites) in an applet, with transparency, at a reasonable speed. How? // Kanzetsu

WayfarerX

Dec 5, 2001 at 5:35 PM

If you want to stay in an applet then stick with normal Images in 1.1. Not only will this work on newer VMs, but you'll save all the lazy IE users from having to download the plugin.
If you can ditch the Applet environment then I would say go for the new VolitileImage in 1.4. I haven't really played with it yet, but it will probably be blazing fast (with video card, of course).
BufferedImages are good for when you need to change the data inside the image directly (this is where the WritableRaster comes in).

As for the transparency, all of the Image classes support it. Do do what you're talking about (color keying), just save your images as transparent gifs.

"So crucify the ego, before it's far too late. To leave behind this place so negative and blind and cynical, and you will come to find that we are all one mind. Capable of all that's imagined and all conceivable."
- Tool
------------------------------

Edited by - wayfarerx on December 5, 2001 6:36:22 PM

Kanzetsu

Author

Kanzetsu

Dec 5, 2001 at 6:06 PM

Hmm, OK, thanks for the info.

I've come across several applet pages where the authors have set CODEBASE to some cab-file over at sun.com, allowing IE users to run 1.3 (and perhaps 1.4?) applets. If I put all my own classes, images etc inside a jar archive, will this work?

UPDATE: I now noticed that this CODEBASE attribute belonged to an OBJECT tag and not APPLET. Apparantely it was, like you said, about plug-ins.

Edited by - Kanzetsu on December 5, 2001 7:16:38 PM

Kanzetsu

Author

Kanzetsu

Dec 5, 2001 at 6:46 PM

OK, I did a quick check (I''m off to bed any minute now), and I''m still a bit confused about copying my transparent images into the frame buffer. If I use Graphics.drawImage, all that happens is that the "transparent" pixels are drawn in a specified color?

// Kanzetsu

Kanzetsu

Author

Kanzetsu

Dec 6, 2001 at 4:42 PM

So, I've got an applet up and running. But - when trying to fill the whole screen with graphics, e.g. filling the screen with tiles, my applet slows down considerably. I'm using Images. I've set up a back buffer and use the drawImage method to draw my sprites, tiles, background image etc onto it. The view then steps in and copies the buffer using drawImage. It works, but the speed is far from acceptable.

Any suggestions on how to speed up the rendering?

// Kanzetsu

Edited by - Kanzetsu on December 6, 2001 5:43:01 PM

CaptainJester

101

CaptainJester

Dec 7, 2001 at 10:16 AM

Unfortunately that is the drawback of using Java. It is slow. You could try posting your drawing code and someone might be able to help you optimize it.

---
Make it work.
Make it right.
Make it fast.

Jim_Ross

Dec 7, 2001 at 10:51 AM

Try developing your program as an application first, then port it to an applet. You can pretty much swap a JFrame for an Applet, and then go fix an compilation errors. It''s easier to debug, you will know if a slowdown is due to browser stuff or your code, easier to test... endless benefits, don''t have to wait for jar file to d/l, don''t have to use the applet runner which behaves like no actual browser.

smokingSkull

Dec 11, 2001 at 5:20 PM

If performance is still a problem, you may want to use threads for some of your other graphics classes (ie other than the one that dumps the stuff on the screen) and synchronising the method calls where necessary. I''m not sure if this is applicable in your applet, but it may help by allowing different anims etc. to run synchronously.

smokingSkull

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.