Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (495)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Side Scrolling Problem  (Read 7066 times)
0 Members and 1 Guest are viewing this topic.
Offline TheAnalogKid

JGO Coder


Projects: 2



« Posted 2002-10-21 14:51:24 »

Hello everyone,

I'm working on a class this is responsible to manage 2D side scrolling using a map format generated by the map editor Mappy.

I've downloaded a provided source code to perform side scrolling in Java BUT it is really slow!  :-/

I've wrote a simple test class that uses it.  In this test class I set the mode in 640x480x32 with full screen exclusive mode.  The program blits tiles on the entire screen with tiles of size 16x16.

Unfortunaly I get only 43 fps but from my point of view I should get near 75 fps (a preview program provided with the map editor acheives this rate).  I mean, I run the test on an Athlon 1.4 gigaherts with a GeForce 2 32 megs of VRAM.

I think there is real problem here.

The tile images I blit are suppose to be accelerated because I create them using GraphicsConfiguration.createCompatibleImage(w, h)
and with
GraphicsConfiguration.createCompatibleImage(w, h, Transparency.BITMASK)

Am I doing something wrong?

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #1 - Posted 2002-10-22 02:48:42 »

Is the code rendering _to_ those images on each frame?
If so, the images aren't being accelerated, as we accelerate them after a few copies from the image have been made w/o the image being modified.

Also, have you tried to increase the tile size?

There is a way to find out if your tile images are accelerated: run your app with tracing turned on:
 java -Dsun.java2d.trace=log YourApp

(run it with -Dsun.java2d.trace=help for more info on the tracing facility)
It'll spit out the information on which rendering primitives are being used. If you see lots of lines like this
 sun.awt.windows.Win32BlitLoops::Blit(),
then we're using ddraw for rendering your image to the screen/backbuffer, and thus your images are accelerated.

Note that it'll print out lots of info, so you might want to use
-Dsun.java2d.trace=count , so it'll print out only the number of times each primitive was used when the app exits.

Also, are you using BufferStrategy and flipping?
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #2 - Posted 2002-10-22 11:23:16 »

I create the tile images only one time just before starting performing the scroll.

I've done a simple test yesterday to see if the tile images are accelerated by replacing them with on tile image loaded from file using Toolkit.getImage() and suddenly the test ran at 75 fps.  Strange isn't it?   Shocked

I think that the context I create the tile images is not appropriate which make them not accelerated.  I create a Frame, I do setUndecorated(true) then setIgnoreRepaint(true) and after that I use a BufferStrategy on that frame to perform page flipping (I verified the use of page flipping with the BufferCapabilities)

Maybe because I create image tiles with a frame that was instantiated before changing the display mode make them unaccelerated???

I'm gone try the trace option to see what happens.

Thanks trembovetski for your help.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #3 - Posted 2002-10-22 11:30:39 »

Quote
I create the tile images only one time just before starting performing the scroll.

I've done a simple test yesterday to see if the tile images are accelerated by replacing them with on tile image loaded from file using Toolkit.getImage() and suddenly the test ran at 75 fps.  Strange isn't it?   Shocked

I think that the context I create the tile images is not appropriate which make them not accelerated.  I create a Frame, I do setUndecorated(true) then setIgnoreRepaint(true) and after that I use a BufferStrategy on that frame to perform page flipping (I verified the use of page flipping with the BufferCapabilities)

Maybe because I create image tiles with a frame that was instantiated before changing the display mode make them unaccelerated???

I'm gone try the trace option to see what happens.

Thanks trembovetski for your help.


Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #4 - Posted 2002-10-23 01:49:49 »

The "state" of the frame doesn't affect acceleration of the images. The only requirement is that it should be realized, that is, either shown, or realized by calling pack() method.

I'd be interested in seeing the tracing output.
Offline Micke

Senior Newbie




Yada-yada


« Reply #5 - Posted 2002-10-23 03:02:32 »

But doesn't the fact the the display is, say 16bpp, and you createCompatible, switch to 32bpp and the compatible image is no longer compatible? Maybe the "accelerated" version is, and the transformation into it only is a bit heavier due to the conversion...

Sometimes when I load images quickly after switching to FS Excl and changed DSP-mode, the code runs *a lot* slower than last time (I exit and rerun and voila! It's snappy again!) I'll try a few runs with the trace turned on and see if I can spot a difference when it starts up in this dreaded slo-mo

/M
Offline Micke

Senior Newbie




Yada-yada


« Reply #6 - Posted 2002-10-23 03:36:38 »

I got a whole bunch of differences when I removed the sleep after switching DisplayMode (It seems I've seen the problem before, since I put that sleep in). I do not, however, use multiple buffers for now, but instead a VolatileImage as backbuffer which is blit onto the screen.
With the startup delay (fastmode) I see alot of sun.awt.windows.Win32BlitLoops::Blit
Without the startup delay (slowmode) I see alot of sun.java2d.loops.Blit::Blit

Is this sleep-after-you-switch-display-mode recommended?

/M
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #7 - Posted 2002-10-23 08:20:40 »

BTW, did anybody try to exploit a JScrollPane for a scrolling game?

Up to my experience, JScrollPane is quite clever concerning minimal redraws an such.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #8 - Posted 2002-10-23 15:38:17 »

Thanks a lot guys for all your tips but I still have this performance problem.  I've tried the trace option and it displays a lot of sun.awt.windows.Win32BlitLoops::Blit() which means that my tile images are accelerated.  But again if I replace those images by a tile image loaded from file, the performance is correct.  Here is the portion code that creates the tile images (sorry for the formatting):


       List imageBlockList = new ArrayList();
       Image imageBlock;
       Graphics gfx;
       for (intIndex = 0; intIndex < m_intNoOfImages; intIndex++) {
           imageBlock = component.createImage(m_intBlockWidth, m_intBlockHeight);
           gfx = imageBlock.getGraphics();
           
           intBlockIndex = m_intBlockWidth * m_intBlockHeight * intIndex;

           // read in Image data
           readStream(stream, bytBGFX, 0, bytBGFX.length);

           // Note: LSB doesn't apply in graphics
           intColIndex = 0;
           intImageY = -1;
           for (intY = 0 ; intY < m_intBlockHeight; intY++) {
               intImageY++;
               for (intX = 0 ; intX < m_intBlockWidth; intX++) {

                   // grab the colour of the pixel
                   switch (m_intColourDepth) {
                   case 8:
                       intRed             = ((int) (m_bytColourMap[(((int) bytBGFX[intColIndex])&0xFF) * 3 + 0])) & 0xFF;
                       intGreen      = ((int) (m_bytColourMap[(((int) bytBGFX[intColIndex])&0xFF) * 3 + 1])) & 0xFF;
                       intBlue       = ((int) (m_bytColourMap[(((int) bytBGFX[intColIndex])&0xFF) * 3 + 2])) & 0xFF;
                       break;
                   case 15:
                       intRed             =  (((int) bytBGFX[intColIndex * 2 + 0]) & 0x7C) << 1;
                       intGreen       = ((((int) bytBGFX[intColIndex * 2 + 0]  & 0x03) << 3) | (((int) bytBGFX[intColIndex * 2 + 1]) >> 5)) << 3;
                       intBlue       =  (((int) bytBGFX[intColIndex * 2 + 1]) & 0x1F) << 3;
                       break;
                   case 16:
                       intRed             =  (((int) bytBGFX[intColIndex * 2 + 0]) & 0xF8);
                       intGreen       = ((((int) bytBGFX[intColIndex * 2 + 0]  & 0x07) << 3) | (((int) bytBGFX[intColIndex * 2 + 1]) >> 5)) << 2;
                       intBlue       =  (((int) bytBGFX[intColIndex * 2 + 1]) & 0x1F) << 3;
                       break;
                   case 24:
                       intRed             =   ((int) bytBGFX[intColIndex * 3 + 0]) & 0xFF;
                       intGreen       =   ((int) bytBGFX[intColIndex * 3 + 1]) & 0xFF;
                       intBlue       =   ((int) bytBGFX[intColIndex * 3 + 2]) & 0xFF;
                       break;
                   case 32:
                       intRed             =   ((int) bytBGFX[intColIndex * 4 + 1]) & 0xFF; // need & 0xFF to keep the int's posative
                       intGreen      =   ((int) bytBGFX[intColIndex * 4 + 2]) & 0xFF;
                       intBlue       =   ((int) bytBGFX[intColIndex * 4 + 3]) & 0xFF;
                       break;
                   default:
                       intRed             = 0;
                       intGreen       = 0;
                       intBlue       = 0;
                       break;
                   }

                   gfx.setColor(new Color(intRed, intGreen, intBlue));
                   gfx.drawLine(intX, intImageY, intX, intImageY);

                   // build up pixel information of the transparent image
                   if (m_intColourDepth == 8) {
                       if (((int) bytBGFX[intColIndex]) == m_intTransparentColour) {
                           intColour = 0;
                       } else {
                           intColour = (255 << 24) | (intRed << 16) | (intGreen << 8) | intBlue;
                       }
                   } else {
                       if (((intRed << 16) | (intGreen << 8) | intBlue) == m_intTransparentColour) {
                           intColour = 0;
                       } else {
                           intColour = (255 << 24) | (intRed << 16) | (intGreen << 8) | intBlue;
                       }
                   }
                   intImageSource[intBlockIndex + intColIndex] = intColour;

                   intColIndex++;
               }
           }
           
           imageBlockList.add(imageBlock);
           gfx.dispose();
       }
       
       imgOpaqueBlocks = (Image[]) imageBlockList.toArray(new Image[imageBlockList.size()]);




Maybe someone could see something wrong?

Also I use JDK 1.4.1 (not 1.4.1_01)

Offline Seb

Senior Newbie




import com.acme.Bomb;


« Reply #9 - Posted 2002-10-27 08:35:12 »

Hi, I noticed you're using createCompatibleImage(), you should use createCompatibleVolatileImage(), only then can you be relatively assured the image is accelerated.

Here's a side scrolling thingy I wrote. Compare the speeds. In my tests there were definite performance improvements.

Some comments on this code. The display mode is hardcoded. It's not checking for available display modes before doing the switch, so you should know beforehand what's supported by your system. you can change it in the constructor, reference name 'fullScreenMode'. alt-enter to switch into full screen.

Don't take this code as the correct way to run a rendering loop though. I hacked it up today. The correct way should turn off paint events.

Well, hope it helps,
Seb


import java.awt.*;
import java.awt.image.*;
import java.awt.event.*;

public class GraphicsTest2 extends Frame implements KeyListener {
final static int WIDTH = 640, HEIGHT = 480;
     Map map;
     int offset;
     String sync = "SEMAFORO";
     GraphicsEnvironment ge;
     GraphicsDevice gd;
     DisplayMode normalMode, fullScreenMode;
     boolean fullScreen;

     public GraphicsTest2() {
           ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
           gd = ge.getDefaultScreenDevice();
           normalMode = gd.getDisplayMode();
           fullScreenMode = new DisplayMode( WIDTH, HEIGHT, 32, DisplayMode.REFRESH_RATE_UNKNOWN );
           fullScreen = false;

           setUndecorated( true );

           map = new GraphicsTest2.Map();
//            map.setGraphicsConfiguration( gd.getDefaultConfiguration() );
           offset = 0;

           setBounds( 0, 0, WIDTH, HEIGHT );
           addKeyListener( this );
           setVisible( true );
     }

     public void paint( Graphics g ) {
           synchronized ( sync ) {
                 GraphicsConfiguration gc = ( (Graphics2D) g ).getDeviceConfiguration();
                 for ( int y = 0; y < (HEIGHT >> 4); y++ ) {
                       for (int x = 0; x < (WIDTH >> 4); x++ ) {
                             g.drawImage( map.getTile( gc, x, y ), ( (x<<4)+offset)%WIDTH, y<<4, null );
//                              g.drawImage( map.tiles[ map.bitmap
  • [y] ], ( (x<<4)+offset)%640, y<<4, null );
                           }
                     }
               }
         }
       public void update( Graphics g ) {
           paint(g);
       }

         public void setFullScreen( boolean yes ) {
               if ( yes && ! fullScreen ) {
                     gd.setFullScreenWindow( this );
                     gd.setDisplayMode( fullScreenMode );
                     fullScreen = true;
               } else if ( !yes && fullScreen ) {
                     gd.setDisplayMode( normalMode );
                     gd.setFullScreenWindow( null );
                     fullScreen = false;
               }
         }
         public boolean getFullScreen() {
               return fullScreen;
         }
         public void keyTyped( KeyEvent ke ) {
         }
         public void keyPressed( KeyEvent ke ) {
               if ( ke.getKeyCode() == KeyEvent.VK_ENTER && ke.isAltDown() ) {
                     setFullScreen( !getFullScreen() );
               }
               if ( ke.getKeyCode() == KeyEvent.VK_ESCAPE ) {
                     setFullScreen( false );
                     System.exit( 0 );
               }
         }
         public void keyReleased( KeyEvent ke ) {
         }

         public void setOffset( int i ) {
               synchronized ( sync ) {
                     offset = i;
               }
         }
         public Object getSync() {
               return sync;
         }

         public static void main( String[] args ) {
               GraphicsTest2 window = new GraphicsTest2();
               while( true ) {
                     for ( int j = 0; j< 640; j++ ) {
                           synchronized ( window.getSync() ) {
                                 window.setOffset( j );
                           }
                           window.repaint();
                     }
               }
         }

         class Map {
               static final int MAX_TILES = 128;
               byte[][] bitmap;
               Image[] tiles;
               VolatileImage[] volatiles;

               public Map() {
                     createTiles();
                     volatiles = new VolatileImage[MAX_TILES];
                     System.out.println( "Map constructor done." );
                     createMap();
               }
               public final Image getTile( GraphicsConfiguration gc, int x, int y ) {
                     int tileId = bitmap
  • [y];
                     VolatileImage img = volatiles[ tileId ];
                     if ( img == null ) {
                           volatiles[ tileId ] = img = gc.createCompatibleVolatileImage( 16, 16 );
                           renderVolatile( img, tiles[ tileId ] );
                     } else {
                           int returnCode = img.validate( gc );
                           if ( returnCode == VolatileImage.IMAGE_INCOMPATIBLE ) {
                                 img.flush();
                                 volatiles[ tileId ] = img = gc.createCompatibleVolatileImage( 16, 16 );
                                 renderVolatile( img, tiles[ tileId ] );
                           } else if ( returnCode == VolatileImage.IMAGE_RESTORED ) {
                                 renderVolatile( img, tiles[ tileId ] );
                           }
                     }
                     return img;
               }
               private final void renderVolatile( VolatileImage vImg, Image img ) {
                     Graphics2D g = vImg.createGraphics();
                     g.drawImage( img, 0, 0, null );
               }
               private void createMap() {
                     System.out.println( "Creating map bytemap..." );
                     bitmap = new byte[64][48];
                     for ( int y = 0; y < 48; y++ ) {
                           for (int x = 0; x < 64; x++ ) {
                                 bitmap
  • [y] = (byte) ( (x*y) % 128 );
                           }
                     }
               }
               private void createTiles() {
                     System.out.println( "Creating tiles..." );
                     tiles = new Image[MAX_TILES];
                     Font f = new Font( "SansSerif", Font.PLAIN, 16 );
                     for ( int i = 0; i < 128; i++ ) {
                           BufferedImage img = new BufferedImage( 16, 16, BufferedImage.TYPE_INT_RGB );
                           Graphics2D g = img.createGraphics();
                           g.drawString( Integer.toString( i, 16 ), 0, 14 );
                           tiles = img;
                     }
               }
         }
    }
    [/pre]

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Seb

Senior Newbie




import com.acme.Bomb;


« Reply #10 - Posted 2002-10-29 01:24:10 »

I just wanted to add something. When drawing the tiles using VolatileImages always check if the Image is still valid, if not rerender it. (see my code. function getTile() )

This can happen on Windows when switching display modes.

Seb.

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #11 - Posted 2002-10-29 11:09:19 »

Thanks a lot Seb for your time!

I still didn't had time to complete trying your solution but it seems very well!

I'm wondering why you must code yourself the caching of Image through VolatileImage while it is suppose to be implemented when using Image created from component.createImage() or GraphicsConfiguration.createCompatibleImage()?

Any Idea Jeff, Chris?

Offline Seb

Senior Newbie




import com.acme.Bomb;


« Reply #12 - Posted 2002-10-29 13:57:37 »

Hello again,

Here are some performance numbers I got from running a modified version. In this version I use a direct rendering loop, and I call setIgnoreRepaint(true). This way I could get some timings.

All the tests were done at 640x480x32 full-screen.

I got around 78fps on a Duron 900 runing in a pc-chips 810 motherboard (this is a very low end motherboard with a SiS chipset and SiS integrated graphics sharing the RAM with the cpu, in otherwords, no dedicated vRam).

On an Athlon 1.3GHz (actual clock speed, not the model name) I get 128fps on the same motherboard.

Now there are still some issues I believe. I still have to check my code just in case I'm doing something wroung, but in my 600MHz P3 with a geForce 2 MX I must get something like 10 fps!! There might be some compatibility issues with the drivers, although as I said, it could be my fault. I have to check the code.

I also got around 35 fps on a toshiba 300Mhz laptop.

Seb.

Offline Seb

Senior Newbie




import com.acme.Bomb;


« Reply #13 - Posted 2002-10-29 14:13:33 »

As far as Component.createImage(...) is concerned, I found no documentation indicating it returns VolatileImages. What's more, the only documented ways I found a developer can create an accelerated image is requesting one explicitly through the createCompatibleVolatileImage(...) methods.

Seb

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #14 - Posted 2002-10-29 14:42:56 »

Seb,

see document AWT Images written by Jeff.  Il all explain the acceleration of images using createImage and createCompatibleImage.

If you don't have a copy of this document then see documentation at http://java.sun.com/products/java-media/2D/perf_graphics.html

Offline Seb

Senior Newbie




import com.acme.Bomb;


« Reply #15 - Posted 2002-10-29 15:44:24 »

I just did. This is what I found:
Quote

For Beta 3, Shared Memory Extension is used on Solaris and Linux in the local display environment, resulting in better performance when rendering to the screen and to the images. When DGA is not available, toolkit images and images created with Component.createImage or GraphicsConfiguration.createCompatibleImage are stored in pixmaps instead of system memory, enabling faster copies to the screen using X protocol requests. You can override this behavior with the pmoffscreen runtime flag, described in the section Runtime Flag For Solaris and Linux .


It seems to me that this is referring only to the unix family of O. Systems, specifically Solaris and Linux.

Regarding creatImage images:
Quote

When creating an image whose data is copied to the screen, you should create the image with the same depth and type of the screen. This way, no pixel format conversion between the image and the screen is necessary before copying the image. To create such an image, use either Component.createImage or GraphicsConfiguration.createCompatibleImage, or use a BufferedImage created with the ColorModel of the screen. The pre-defined types of BufferedImage have their own color models.


This means to me that compatible image is faster than your average image only because there is no pixel transformation applied when copying. But it doesn't mention about storage in vRam.

I also found this, which is quite suggestive since it's rather odd that createImage would call createVolatileImage which would call createImage again. Of course its not impossible, just awkward:
Quote

-Dsun.java2d.ddoffscreen=false
Setting this flag to false turns off DirectDraw offscreen surfaces acceleration by forcing all createVolatileImage calls to become createImage calls, and disables hidden acceleration performed on surfaces created with createImage


And out of my own personal experience with the code I posted before, when method getTile is modified to return BufferedImages created with createCompatibleImage(...), the result is faster than using some generic image format, but not as fast as using VolatileImage.

Seb.

Offline Jeff

JGO Coder




Got any cats?


« Reply #16 - Posted 2002-10-29 16:12:45 »

Hopefully we will have "Understanding AWT Images" back up on the board soon.

I wrote it, with Chet's guidance, and it answer smsot of these questions for the current VMs.

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Seb

Senior Newbie




import com.acme.Bomb;


« Reply #17 - Posted 2002-10-29 20:09:22 »

Ok, after your comments I did some more testing. I ran both tests on different machines and you're right, direct handling of VolatileImages is apparently not necessary, at least on most machines.

On the one where I wrote the little test originally there is a performance difference between both implementations, as there is on the geForce 2 MX machine, but there is no difference in the machines with the SiS chipset.

So, there still is a difference on some machines, but having tested this, I would do the same thing your doing, use createComatibleImage() since it caused less problems on the geForce, although performance was only slighly better, around 12 fps, compared to 128 fps on the athlon/sis configuration! Shocked

Oh well, the problem might be related to the fact that I hardcode the DisplayMode, I don't get it from a list of available modes. I'll see.

Seb.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #18 - Posted 2002-10-30 04:53:55 »

there's a number of reasons which may affect performance on certain configurations. Like, for  example, the amount of available vram. Or the fact that, say, your sprites are all accelerated (i.e, in vram), but your back-buffer is not, for some reason.

It also depends on the operations you perform on the back-buffer - if you do any of compositing, antialiasing and such, it could be punted to system memory.

Try running your app with
-Dsun.java2d.ddforcevram=true parameter and see if it helps.

I'd suggest to try to create a simple test which just copies different types of images to the backbuffer (or screen), and see which one is faster under which circumstances.

Jeff's article indeed has answers to some of your questions, so hopefully it'll be back soon.

Offline Seb

Senior Newbie




import com.acme.Bomb;


« Reply #19 - Posted 2002-11-02 06:07:45 »

I found what was causing the bad performance on my pentium 3/geForce2mx/w2k configuration. As I commented before I am getting 128 fps on another system while I got 10fps in this one.

The problem was due to Direct3D use in Java2D. I turned it off with -Dsun.java2d.d3d=false and immediatelly got 25fps on the geForce. Not a great improvement but the redraws are a lot smoother now.

It's also interesting to note, this system has another PCI display adapter (Matrox Millenium II - no 3D acceleration) besides the primary AGP. I got a frame rate improvemnt on both adapters after turning off direct3D.

Seb.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #20 - Posted 2002-11-03 02:44:16 »

Does the problem persist when you disable the Matrox board in Display properties, and run java with d3d on GF2mx?

I have almost exact configuration as my home system (P3 750, GF2MX, W2k), and I haven't seen problems like you describe (I havent' run your app, though =)

Offline TheAnalogKid

JGO Coder


Projects: 2



« Reply #21 - Posted 2002-11-04 14:47:08 »

Grin  Hey guys!  It works now!

Thanks Seb about the flag sun.java2d.d3d=false, it fixed my performance problem.  Like you, I'm running the test with Win2K and a GeForce 2 MX.  Is this a java bug or a graghics card bug?  Strange.

Now my test runs at 85 fps in 640x480x32, 85 hertzs but I'm sure it could surpass this rate.


Thanks everybody for your support!  Smiley

Jerome

Offline Seb

Senior Newbie




import com.acme.Bomb;


« Reply #22 - Posted 2002-11-06 00:23:33 »

I disabled the matrox, I still get bad performance if Java2D uses Direct3D.

I have to add though that I didn't reboot the computer with the Matrox disabled, that could conceivably modify the operating environment and fix the problem. I'll try this at a later time when this machine can be taken offline.

Seb

Offline Seb

Senior Newbie




import com.acme.Bomb;


« Reply #23 - Posted 2002-11-10 12:05:48 »

Old thread, new info...

Since I posted the last message I upgraded my computer. My new setup is Windows XP on a Duron 1200. I'm still using both the geForce and the Matrox. Both are using microsoft drivers this time, last time I was using the original nVidia and matrox drivers.

What's curious is that I'm still having bad performance if I don't disable Direct3D on Java2D

So it appears the problem is not a driver issue. It seems to be either with the card itself, or Java2D's use of Direct3D.

Seb.

Offline trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #24 - Posted 2002-11-11 04:58:12 »

Thanks for the update.
We actually have other people complaining about similar problems with this setup, so we're looking into what's going on..
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Dwinin (28 views)
2014-09-12 09:08:26

Norakomi (57 views)
2014-09-10 13:57:51

TehJavaDev (74 views)
2014-09-10 06:39:09

Tekkerue (38 views)
2014-09-09 02:24:56

mitcheeb (57 views)
2014-09-08 06:06:29

BurntPizza (45 views)
2014-09-07 01:13:42

Longarmx (28 views)
2014-09-07 01:12:14

Longarmx (34 views)
2014-09-07 01:11:22

Longarmx (35 views)
2014-09-07 01:10:19

mitcheeb (40 views)
2014-09-04 23:08:59
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!