Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (754)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / Java 2D / Re: Chet's article on the use of images.. on: 2004-08-16 11:17:43
Yep, this wasn't an article on managed images, but more about images in general (a larger and more wholly confusing topic...).  

I was thinking of writing an article dedicated to managed images sometime soon; they've cropped up in the context of most of my blogs and presentations, but perhaps it's time they had their own spotlight.  Thanks for the idea about "un"managed images; I've been mostly focused on how to get people to use managed images so far, not how to defeat the system...

(Note that setAccelerationPriority() is just a stub in the 5.0 release; it sets a hint internally which is thus far ignored.  So this won't get you what you are seeking (image management punting), at least at this point.  We had to get the API in there during this major release, but didn't get a chance to fill in the details yet.  Grabbing the data buffer is the only way to force image "un"management for now...)
2  Game Development / Performance Tuning / Re: Windows tooltips/menus hammer 2D drawing on: 2003-11-12 15:15:04

Glad you found some workarounds.  Note that the flag combo I specified above was intended to be tried _without_ the noddraw flag (which I see you tried as well); when you specify ddraw, we don't do anything at all through directX.  But with the flag combo listed (not including noddraw), we will use ddraw for locking the screen and copying the bits.

The lovely flickering you noticed in your test of these flags is exactly why we started using GDI to copy bits to the screen instead of ddraw; when we lock the screen and copy the pixels, GDI animation loops completely halt and those objects do not get painted to the screen during that lock/unlock period.  This includes the fading menus as well as software cursors (on platforms without hw cursor support, such as most Matrox cards).

Anyway, glad to hear you've found some things to alleviate the situation.  Good luck...
3  Game Development / Performance Tuning / Re: Windows tooltips/menus hammer 2D drawing on: 2003-11-11 18:28:25
interesting phenomena; I hadn't noticed this one before.

From the various descriptions of the problem (including all the flags you tried), it sounds like it's some horrible (and unavoidable?) context-switching bottleneck.  In particular, a tooltip or menu (especially with the translucent menu fade effect of win2k/XP) would be doing heavy GDI rendering.  Meanwhile, Java2D is doing heavy DirectX rendering.  Sometimes, depending on the hardware and driver, the context switch between these libraries can be quite horrible;
a real performance killer.  We have run into similar situations inside of Java2D that we tried to fix (for example, when we used to use ddraw for hor/vert lines and GDI for diagonals it caused serious performance problems just due to the ctxt switching; we now use d3d when we can which seems to help that specific problem immensely).

By using translaccel and ddforcevram, you are telling us that yes, you really want to use DirectX for these operations.  So the images/buffers stay cached in VRAM and we use the ddraw Blt engine or d3d texture engine to copy stuff around in hw.  By using noddraw, you are ensuring that we do not such thing; all images/buffers live in the Java heap and we copy the bits down to the screen over the bus using GDI.  The fact that there is no fps change when noddraw is present implies that our GDI copy coexists happily with the desktop GDI operations (another pointer toward painful context switching).  The fact that you are seeing different behavior on different systems in another indicator that the problem is card/driver-based; perhaps the card on your original system just has a driver that's horribly inefficient at context switching.

Unfortunately, I don't have a fix for you.  Our use of directX allows us to get the great frame rates you are getting by default (300 fps).  But that approach apparently conflicts with basic desktop functionality because of GDI/DX coexistence problems on that configuration (my theory, boldly stated but completely unproven...).  so I think you've already seen your choices clearly; either choose the higher frame rate which can unfortunately hiccup given other occurrences outside the app, or choose the lower non-hw-accelerated framerate that is apparently more desktop-compatible.  Or got into fullscreen mode and avoid the issue.

Some things that occur to me that you can try (more for data-gathering purposes that any real workarounds...):
- Try to force us to use ddraw locking to copy to the screen when ddraw is disabled.  I would expect similar crummy results because we're still forcing context-switching to occur (without the benefit of the higher frame rate of hw acceleration).  To do this, use the flags:
This combo tells us: don't use ddraw for offscreen surface caching (but still use it for other operations), don't use GDI to copy bits down to the framebuffer, do use ddraw to copy bits to the screen.  note that this does not enable translaccel, so your alpha images will be in system memory.
I'm thinking that your framerate would be about equal to (or possibly a little better than) your 150 fps number with noddraw set, but that it would suffer during the tooltip/menu situations.

- Try changing your desktop effects to avoid translucency fades, or anything that smacks of GDI animation.  This could avoid too much GDI/DX thrashing during these operations.

Good luck....

4  Game Development / Performance Tuning / Re: Windows plugin versions on: 2003-10-24 18:19:34
Aha!  I think I have it (a little sample code goes a long way here...)

I got your app running here and I think I know what's going on.  In particular, I know why you're seeing differences between 1.4.0 and 1.4.2 and between ddraw and noddraw.

it's all because of the cursor flicker...

From jdk1.2 up through 1.4.0, we used ddraw when we needed to copy bits from some system memory surface (a non-ddraw/VRAM image) to the screen.  We would lock the screen, copy the bits, and unlock the screen.  This performed better than non-ddraw approaches, but had the side-effect of sometimes causing flashing on the desktop.  this got particularly annoying with win2k and XP, where things like translucent fading menus and non-hw cursors (due to translucent drop shadows and color cursors) would flicker when we did our stuff (because they would disappear during the lock and reappear after we unlocked).

In 1.4.1, we found a way around this problem.  By using GDI, we would (mostly, except for Matrox; I've still seen some cursor flickering artifacts there, but I've seen it with many other apps on those boards as well) avoid the flicker.  And by cleverly arranging the GDI copy routine, we would be able to retain most of the performance of our ddraw copies as well.  I say mostly because it can perform almost as fast as ddraw in some situations, but in others it can be significantly slower (10, 20, 30%, whatever).  But we decided to take that hit for these copies because:
- the flicker was pretty horrid and lots of people were complaining about it
- with the advent of VolatileImage and other images being cached in VRAM and copied using ddraw blits, the amount of screen-lock situations was hugely decreased.

Your app is running into this issue.  I don't know what numbers you are seeing, but when I ran the app on my desktop system here (XP with a Matrox g550 card), I got about 1800 ms for the vanilla app and about 1400 when I re-enabled ddraw screen locking.

(Note: if you want to make this work on your system, the 2 flags to use are:

So I believe that this is the performance difference you are seeing between 1.4 and 142.

The other question here is: why aren't you getting hw-accelerated images?  There are a couple of reasons for this:
1) You are creating ARGB images.  This means that unless you enable d3d translucency (as of 141_02 and 142 via the -Dsun.java2d.translaccel flag) you will never see this type of image hw-accelerated.  Even though the images only contain bitmask-transparent data (from the duke.gif image), we still see them as fully-translucent images and they fall into our translucent-copy routines.
If all you want is transparent-background (vs translucent) images, then either use the image you created to begin with (from the duke.gif image) or call GraphicsConfig.createCompatibleImage(w,h,Transparency.BITMASK)
to get a transparent image.  We should be able to cache that image as a ddraw/VRAM image and accelerate it.

2) Even if you do enable hw acceleration for translucency, you're still out of luck here.  This is because your are copying the images directly to the screen.  D3d has this lovely delusion that it owns the screen.  so now matter what you tell DirectX about a window, the clip region of the desktop, etc., d3d will blast its bits wherever it wants to.  So if we enabled d3d-texture ops to the screen you could, for example, copy your sprites all over any overlapping windows on the desktop.  That didn't seem very professional, so we only enable d3d operations if you tell us to (using the flag) AND if you are copying to an accelerated offscreen image (ala the Swing back buffer).  So in this case, you might want to create a VolatileImage back buffer (or use the BufferStrategy buffer) and draw the sprites to that buffer before then copying the buffer to the screen.  (Just one more caveat: some translucency operations can cause us to punt an offscreen ddraw surface out of vram and mess up this d3d acceleration scheme; if you enable d3d acceleration, also us the -Dsun.java2d.ddforcevram=true flag to tell us to leave the back buffer in vram no matter what).

Make sense?

Good luck,
5  Game Development / Performance Tuning / Re: Windows plugin versions on: 2003-09-15 18:07:35

It does sound like you might be running without ddraw/d3d acceleration on the 1.4.2 version (although I don't know off-hand why that would be).

One way to get more information on what's happening inside java2d is to use the tracing utility.  This is done by using the command-line flag:
   -Dsun.java2d.trace=[log, count, help, out, ...]
Play with this in an application (especially getting the "out" option to work, which spits the output into a file that you specify).  Then specify the flag in the plugin control panel and see what output you get.

What you want is to use the "count" and "out" flags, which will spit the final primitive count into the output file.  You should see things like Win32BlitLoops, Win32DDRenderer, and Win32D3dRenderer.  But if you are not using hw acceleration, then you will not see these class names in the output.

Let us know what you find out.  Also, let us your your system configuration (especially the OS and graphics card).  And a test app would be nice if it gets down to tracking down the problem here.

6  Java Game APIs & Engines / Java 2D / Re: Volatile Image on: 2003-09-12 12:35:08
Thanks for checking out the blog: It's so nice to get noticed!  Smiley

Let me clarify a couple of things about VolatileImages and the issues that were raised on this forum.:

- VolatileImage vs. managed images (aka "automatic images", but I prefer "managed images" because it's more accurate and informative):  There is almost no reason to use VolatileImages instead of managed images for most cases.  The only reasons to use a VolatileImage are:
   - If you want rendering TO the image to be accelerated (managed images have their primary copy in system memory and thus all rendering operations TO that image happen through software routines)
   - If you want to more actively manage the accelerated memory (eg, VRAM).   It's a little easier to tell what's going on with a VolatileImage (in terms of VRAM usage) than with a managed image.
If all you want is a sprite that probably gets accelerated for its copies to the back buffer or screen, managed images are the way to go.  No need to hassle with Volatiles.

- VolatileImage vs. BufferStrategy buffers: If you are using a BufferStrategy, then these are (sorta) managed for you; if one gets lost, then it will automatically be reinstated (we manage all of this with VolatileImages internally, and call validate when necessary).  Note that you still have a contentsLost() method and situation to deal with, but in the case of a back buffer (which gets re-rendered every frame), that's not a big deal since you're just going to wipe it and re-render anyway.

- VolatileImages and translucency:
a) The API: in 1.5, we will (finally) have the ability to create a translucent VolatileImage (currently, you can only get an opaque VImage).
b) contentsLost() and re-compositing VImages problems: I don't see a huge issue here. Image loss is not a common occurrence (unless your game wants to change the display mode every frame to freak out the users.  I can see it now: "Seizure: A game of epileptic proprotions").  So the way to handle any image loss situation is just to re-render the entire frame.  Sure, it costs you a frame's worth of rendering time; but when the display mode changes there are a lot more disturbing things happening on the screen than an momentary drop in your frame rate.

- VolatileImage and automatic revalidation:
The whole reason that we force you to manage these images is that we cannot restore the contents for you.  If we were to keep the primary copy in memory and do an automatic restore (hmmm - sounds like a managed image to me...), then by definition, we would have to do all of the rendering to that primary surface first (since we can lose the VRAM version at any time).  This means that all of that fine rendering would happen through our software loops and you'd lose the benefits of hw acceleration on your rendering-to ops.  "But I don't care about the render-to speed; I only render to my sprites once and then just care about the copy-from speed" - See my point above about managed images; you shouldn't have to use a VolatileImage in this case.

Hopefully this clears things up a bit.  In any case, please check out the follow-on blog, which is basically a series of Q&As on common VolatileImage issues (including some of the points raised here; in fact, I might borrow some of these ideas for more Qs).

And feel free to post replies to the blogs; I think the discussions after the blogs can be even more informative than the original article (check out the ones on BufferedImage on that site; there's some good stuff in the feedback sections).

7  Java Game APIs & Engines / Java 2D / Re: does Java2D support transparency for images? on: 2003-04-24 17:46:07

Just wanted to clarify something about Component.createImage().  When I said earlier that calls to this method will create managed (acceleratable) images, the method I was actually referring to was Component.createImage(w, h), not createImage(ImageProducer).  This latter method will not produce a managed image and has the asynchronous problems you pointed out.  But the createImage(w,h) version is completely synchronous (we create the image at the time that you call the method) and it creates a managed image.  Note that this method does not support the transparency that you would need in a sprite; for that, you have to call GraphicsConfiguration.createCompatibleImage(w, h, Transparency.BITMASK), as mentioned in various posts above.

Sorry for the confusion; there's just too many ways to create images and it's easy to get them all confused, especially with our current managed image approach of only hooking into some of these methods for acceleration (just a quick hack while we work on the long term solution of being able to accelerate any image, no matter how it is created).

8  Java Game APIs & Engines / Java 2D / Re: does Java2D support transparency for images? on: 2003-04-23 15:50:12
I would think that you would get this same error whether you were creating the BufferedImages explicitly (new BufferedImage) or as managed images (createCompatibleImage()); we are essentially doing the same type of thing underneath.  In the managed image case, we may also create a VRAM-cached version of the image, but these cached images do not affect the size of the Java heap.

In any case, if you are having heap-size problems, you might want to increase your heap size when you run Java.  It runs with a default heap size of 64 M on Windows (I believe); maybe try something like:
   java -Xmx128m <class>
or try other values until you get one that works for you.
Also, if you know your heap will grow to that size, then you probably also want to increase the initial heap size to eliminate the performance penalty of the VM growing the heap incrementally:
 java -Xms128m <class>
would start off Java with a heap of 128 megs (I think it starts at 16M by default, but I'm hazy on that detail).

9  Java Game APIs & Engines / Java 2D / Re: does Java2D support transparency for images? on: 2003-04-23 13:33:38
Note that to make the transparent image a "managed image" (sometimes called "automatic image", but "managed" is a more correct and descriptive term...) you currently need to use other API than creating a BufferedImage explicitly.

That is:
 new BufferedImage(...)
will give you just a palin-old BufferedImage, no possibility of acceleration under the hood.  But:
will give you a BufferedImage that we may, depending on various constraints, cache in VRAM and accelerate using the graphics hardware.

Of course, this currently only works for transparent (vs. translucent) images, unless you are using the not-quite-ready-for-prime-time translucency acceleration described by trembovetski in one of these forums.

In some future release, we hope to "manage" all images, no matter how they are created.  But currently, we just hook into specific API calls, such as:
 new ImageIcon().getImage()

10  Java Game APIs & Engines / Java 2D / Re: BufferStrategy and Alt-Tab on: 2003-04-23 13:25:04

Can you post a complete test app that demos the problems you're seeing?  Also, describe exactly what the problem is (crash?  hang?  slowdown?  white-screen of death?).  We fixed major alt-tab fullscreen problems in release 1.4.1_02 and 1.4.2-beta, but I have heard of possible issues related to BufferStrategy and alt-tab.  I have not yet reproduced these problems, so if you have anything easy and tangible that i can work with, that would help me narrow down the problem.

11  Java Game APIs & Engines / Java 2D / Re: volatile image with bitmask transparency? on: 2002-11-13 15:21:53
In answer to your first question, there is unfortunately no way to create a VolatileImage that is non-opaque (translucent or transparent).  This is API that we should introduce in jdk1.5 (a ways off, but I just thought I'd mention it).  The main idea behind the first VolatileImage API was to have the ability to force the back buffer to live in hardware.  Back buffers are usually opaque, so this simple API did the trick.  Now that that functionality is there, we can beef up the Volatile API to include other related operations/formats that people care about.

As to how you work around the issue, you should be able to use createCompatibleImage(w,h,transparent) for any background which will remain static.  Say you have a scrolling starfield (or whatever); you can create this as a compatible image and simply copy from there into your Volatile back buffer.  At some point (usually the second copy), we will recognize this as something that we can do better in hardware and we will create a VRAM version of that compatible image to use from then on.  As long as you are not touching the pixels of the compatible image, we will continue to use the VRAM version of it and you will get native-hardware speeds.

Things to watch for:
- DO NOT grab the Raster or DataBuffer for the compatible image.  If you do this, we give up on accelerating that image because we cannot guarantee that our VRAM version matches the original image (because you can tweak the pixels directly without our knowing).  We will probably introduce some sort of Lock/Unlock API for this in the future, but for now just avoid it if at all possible.
- Accelerating compatible images only works for opaque and transparent images for now.  We're working on translucency acceleration; this should be there in jdk1.5.
- There can be problems with images larger than the screen size (we may not be able to create a VRAM image larger than that size), so if you need a background image larger than this, you'll have to tile it into several images.

Hope that helps.

12  Java Game APIs & Engines / Java 2D / Re: About multiple buffers when using BufferStrate on: 2002-11-06 18:08:59
Unfortunately, it is not possible to sync while using Blt.  This is simply a hole in the API.  The capability exists on some platforms to allow it, but there is no way to access it through the current BufferStrategy (or other class) methods.

This is something we should add for jdk1.5...
13  Discussions / General Discussions / JavaOne on: 2002-11-05 21:35:21
Want to present a session about your game or application?  It would be great to have more sessions by external (non-Sun) Java developers.  What APIs did you use?  What worked, what didn't?  What suggestions do you have for other developers?

Check out:

But time is running out: submit your abstract by Friday November 8th for review.
14  Java Game APIs & Engines / Java 2D / Re: About multiple buffers when using BufferStrate on: 2002-11-05 21:15:41
I'm not sure which of your multiple questions to respond to, but I'll maybe summarize your posts as "What the heck is up with BufferStrategy?" and try to answer that catch-all...

BufferStrategy _is_ synchronized to the retrace when you are doing page-flipping.  Way deep in the internals of Java2D on Windows, we implement show() as a ddraw Flip() command with the flag DDFLIP_WAIT.  This means that (a) the flip command will wait for the vertical refresh to occur and (b) we will wait for the Flip command to process before we return from the show() call.  Make sense?

Note that the same is not true for non-page-flipping BufferStrategy classes; if you are in windowed mode, you will probably end up using a BltBufferStrategy, which simply uses a ddraw Blt command (on Windows, of course) to copy to the screen.  That command is not sync'd to the vertical retrace, so show() will return as soon as we've sent off the Blt command.

Your guess about vertical retrace being linked to the 60 fps is correct; since you are now waiting for the Flip to occur, your frame rate is maxed at the current refresh rate.

If your code is simply waiting for the show() command to return, that is one place where triple buffering _might_ help; if you had a third buffer available, then show() would return immediately and you could start drawing on the free buffer.  But it's not always a win; if you are drawing much faster than the frame rate, then you will simply get one frame ahead and sit there waiting for the following show() to return.

My explanations are Windows-specific, but the same should be true on any platform that support page-flipping.

Hope that helps...

Pages: [1]
DesertCoockie (22 views)
2018-05-13 18:23:11

nelsongames (74 views)
2018-04-24 18:15:36

nelsongames (68 views)
2018-04-24 18:14:32

ivj94 (751 views)
2018-03-24 14:47:39

ivj94 (81 views)
2018-03-24 14:46:31

ivj94 (605 views)
2018-03-24 14:43:53

Solater (97 views)
2018-03-17 05:04:08

nelsongames (178 views)
2018-03-05 17:56:34

Gornova (388 views)
2018-03-02 22:15:33

buddyBro (1048 views)
2018-02-28 16:59:18
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!