FullScreen sporadic crashes - Alternatives?

Hi!

So - Some background of my project before I come down to my ->real<- questions…

I’m developing games as Applets and they involve quite a lot of graphics / sprites. I’ve made a 2D-gameengine that supports scrollingbackgrounds in parallax layers and stuff like that and this all comes down to some basic performance issues:

I 'm working in 640x480 at 25 fps which is why I’ve converted into Java FullScreenMode which gives my the performance that I need… However I’m worried for my plattform independency

I also get an error where my browser shuts down and leave a .log file on the desktop saying something about VolatileImage contents lost…

Concluding:

I would really like some pointers about how to gain maximum performance when handling sprite-animations. I use fullscreenmode but perhaps that is overkill?

Has anyone seen and/or solved the VolatileImage crash bug that I encounter sporadically when using FullScreenMode?

Thanx!
/Markus

Hm if u run as an applet, the SecurityManager will not permit switching to FullscreenMode.

I use Fullscreen mode only in Applications.

What kind of rendering/painting do u use ?
What kind of double/triple/quad buffering do u use ?
how many threads are running ( except system threads )

Don’t worry about the security aspects;) It’s a rather special applet that I launch from a local Java client which initialize by altering the java.policy to allow fullScreenMode from Applets so I got it covered…

But you have a point - The only reason for my to enter Fullscreenmode is the gained frame-rate. If I only could increase my performance in a normal “html-embedded” applet, I’d prefer that.

My games are, in a pure rendering perspective, nothing else but sprites moving across the screen. I have NOT looked into Volatile Images but maybe I have to do that…?

As of now - I’ve developed my gameengine with one animationthread with the basic move(), paint() approach using a rendering strategy like:

  fullScreenWindow.createBufferStrategy(2);
  strategy = fullScreenWindow.getBufferStrategy();

  ...

  Graphics g = strategy.getDrawGraphics();

I’ve tried to follow the examples given by Sun on their webpage :slight_smile:

The thing is that I actually would like to skip the fullscreen mode since it is a bit buggy and makes my IE crash once in while (leaving a .log file on the desktop blaming an ‘external error’ in VolatileImage or something like that…

If I tried to make a conclusion of what I want:

What is the most effective / optimal way to perform Image animations i resolutions 640x480 with 20 images floating around on a big background in at least 20 fps?

Thanx for you input
/Markus

In pure Test mode ( only buffer flipping with background clearing i get )

Windowed Mode Desktop with 4 Buffers in a 1152 x 864 ( 100Hz ) i get 800fps ( because no vsync )

with nearly 400 sprites on screen my fps is 180

In Fullscreen 640 x 480 16Bit (150hz) i get 100fps with same sprites.

I use Bitmapfonts instead of normals fonts ( big increase in rendering getGlyph is too slow )

Use automated Images thoose will be accelerated, which means the jdk will detect after 2 redraws this image hasent changed and will be copied on the VRAM of the graphics card.

you can create a automated image with

createCompatibleImage ( at the Moment only transparent images NOT TRANSLUSCENT IMAGES are supported )

search for automated images and u will find some more hints about it, this should speed up your code

Wow… And I actually mean that :wink:

Could you show me that testcode? If I understand you correctly, the tests you describe with 180 fps is in FullScreenmode, right?

The automated images that you speak of - Are they VolatileImages? I find it a bit strange that I get errors in my VolatileImage when I don’t use VolatileImages… Maybe the Fullscreenmode automatically uses Volatile?

Do you know how this works?

You also speak about 4 buffers which makes me wonder - How does the number of buffers impact on the rendering speed / animation quality? Shouldn’t it be enough with just one offscreen buffer?

As you probably understand - I’m no Graphical guru but I consider myself to be a good learner and a good programmer so I’d would really appruchiate if you would take the time to explain these things for me…

Thanx big-time!

/Markus (and btw. english is not :o my first language :-[ )

i can show u piece of code


        // now create hw accelerated transparent image ( ARGB )
        image = gc.createCompatibleImage(width, height, Transparency.BITMASK);
        BufferedImage aBufferedImage = (BufferedImage)image;

modify aBufferedImage , paint inside or do something else with it.

this piece of code is part of my image loader code, i have special image loader code, i encode my images in a special format

image is a Image and can be used for drawImage

the 180fps is in windowed mode with around 400 sprites ( each character is one sprite )

so when i draw a piece of text like " Hello World" i have 10 sprites, each char is a managed image.

Its up to u how many BackBuffers u use, its limited by hardware ( by VRAM ), java will handle the Buffer flips and everything around it, you simply call flip and thats it

So - I take that you don’t know about VolatileImages?

Since IE crashes from time to time blaming the VolatileImage class, I assume that this class is used automatically since I am in fullscreenmode… Would you recon it’s a good assumption?

Therefore I thought that I should try to use VolatileImage since that would allow me to check for contentsLost(), validate() methods eventhough I don’t know HOW I should go about and do it.

I currently just use Images that I preload with a MediaTracker and render with drawImage(…). I get the getCompatibleImage part but still wonder what happened to all this stuff about VolatileImages…

Hmmm!

Anyway - I’m really thankful for your time but I would really like to verify one last thing :wink:

  • Could you show me how your basic animation thread looks like?

I currently do simthing like this and I would really appruchiate if you looked at it for a minute…


while (animationThread != null)
{
  try
  {
    start = System.currentTimeMillis();

    animate(...);

    Graphics g = strategy.getDrawGraphics();

    if (!strategy.contentsLost())
    {
      g.setColor(backgroundColor);
      g.fillRect(0, 0, fullScreenWindow.getWidth(), fullScreenWindow.getHeight());

      paint(g);

      strategy.show();
      g.dispose();
    }

    stop = System.currentTimeMillis();
    sleep = sleepInterval - (stop - start);

    if (sleep > 0)
      Thread.sleep(sleep);
  }
  catch (Exception e) {e.printStackTrace();}
}

Is this the way that it should be done?

Again - Thanx!
/Markus

IIRC, fullscreen mode uses VolatileImages for its back and front buffers, so if your crashes are complaining about volatile image contents lost it could be the fullscreen implementation failing. I wouldn’t worry about it too much, you only need to worry about .contentsLost() etc. if you’re directly using the volatile image class, which it doesn’t sound like you are. Fullscreen has always been buggy from what i’ve tried, about the only thing you can do is make sure you provide a windowed mode as a fallback.

Ok, so FullScreenExclusive makes it’s own implementation of VolatileImage… Sounds reasonable but sad since it does not work well enough!

Could the crashbug be avoided by using VolatileImages directly (whihc I don’t do at the moment)? It could perhaps give me the opportunity to catch the exceptions that FullScreenExclusive don’t?

Anyway - MGodehardt, you say that you get 180fps in “windowmode” and forgive me for asking but as I understand it, windowmode is still a frame that you use in combination with a BufferStrategy, GraphicalEnvironment and all that, right? Whihc means that I might have some problems since I develop Applets… Of course I can use a frame but it wouldn’t look great. But I suppose I could set it to maximum screensize, undecorated without using the fullscreenmode…

I’d still like to se Your version of an animationthread since I don’t feel 100% confidence in my own. Framesync is yet another question but I’ll bring that up when I get the fps up in “windowmode”, if windowmode is what I supspect it is?

/Markus

i am sorry but i cant post any longer my render / game physics code, its copyright protected and part of a commercial project.

your code looks fine, but why do you call your render func paint ? call it render, and be 100% sure u disabled active painting.

paint() and update() SHOULD BE USED AND SHOULD BE DISABLED THRU setIgnoreRepaint(true)

The method u and we use is called active rendering.

try to run your program as an application and look if the same problems occur, if not your java plugin is buggy and not your code.

One hint look in the forums, i saw use currentTimeMillis, this function has a resolution of 50ms under Win9x based Systems, means u can measure 100ms intervalls and this would end in 10FPS.

Look for high performance timers.

Thanx!

I understand that you can’t post your code - Eventhough it’s a petty but what the heck… :slight_smile:

I just spent a couple of hours reading through these forums and I realize that I don’t know nearly enough… In my simplified world I use an animationThread that moves and renders until my game is finished. All images are read using Toolkit.getImage and a Mediatracker and my extreamly poor framesync is based on currentTimeMillies()…

After having laughed at myself for almost an hour (reading different threads in this forum and realizeing how far off I am) I must say that I’m enthousiastic (hard work to spell) 'couse I now understand that Java CAN be used to perform profesional HQ- games / animations…

So - I just keep reading and learning and we’ll see where I end up! I would really appruchiate some kind of “This is the way / basic thoughts of making a pro 2d-game” but I guess that a complete solution can only be made in one way - practise :wink:

Thans for your time and assistance - you’ve helped alot and now its time to dig in and read some more!

/Markus

1.) for games i like this loading method:

static BufferedImage javax.imageio.read(URL input)

it blocks till the image has finished loading. so just call it and once it returns you have a ready-to-use buffered image; no hassle with mediatracker.

2.) most of the time it should be a good idea to use automatic images (aka managed images) for the actual rendering. they are the ones you get from getComptibleImage() (copy the buffered image from step 1 into it)

afaik they use the “best available image type possible” so usually volatile image. the idea is that they do all the managing behind the scenes, so you dont have to check for contentslost() and stuff like that as you would have to with volatile images.

afaik it keeps a copy of the image in vram and one in ram
so it can copy it back in case of contentslost()

3.) im not really an expert here so somebody else has to
elaborate the details on this :slight_smile: :

if you do a lot of transforms and/or translucency, buffered image could be better because these operations arent hardware accelerated and therefore dome in ram which would mean a lot of copying between ram and vram or somthing like that. ???

implement your own image loading code, sun encourage you to do this in games, you can have over 100 tiles in 10kb

for isometric tiles u can use special rle code and zip compression, alot of pixels are not used ( transparent ), and a gif compressor will not detect this, gif has overhead.

It took one month for me until i had a working encoder for all my graphics ( sprites, anim, statics, tiles, etc…) and a working loader, its hard work

5 days a week 8 hours makes 40 hours times 4

so i spend 200 hours to get it working, its not a ah i program this quick and dirty and end up in a big mess

Well - Why not?

Is there som basic information out there with tutorials for how to start building your own image loader? You say that sun encourage this but I can’t find where they do that and how they recomend you to start…

Any tips? :wink:

/Markus

use my code above where i create transparent managed image ( aka auto image )

set Pixel with this code


aBufferedImage.setRGB(xpos, ypos, pixelData);

where pixeldata is a int which is 0xAARRGGBB ( hexadecimal representation )

AA=0x00 means transparent, AA=0xFF means visible, no other values are allowed

and RGB is red, green, blue value

its up to you, how you implement a image encoder, if u are a experienced C/C++ programmer its easy. I did this 20 years ago, if not you should try to fetch some good books about imaging, u can also go to university and study it.

Thats the real programming, inventing something new, be creative, it may take months or years until your game is ready, thats the real hard piece of it.