Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (778)
Games in Android Showcase (231)
games submitted by our members
Games in WIP (856)
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 ... 4 5 [6]
151  Java Game APIs & Engines / Java 2D / Re: JDK 1.5.0-beta2 is now available on: 2004-05-28 19:11:06

I'd love to know exactly what is accelerated through the opengl pipeline - any chance of a doc covering what (in optimal conditions) is accelerated?

I'll check out the triple-buffering problems you've reported...

There is no official doc about what is/isn't accelerated with the OGL pipeline, although I think I'll have to come up with something more official soon.  In the meantime, I keep answering this question partially, so let me just point to one such response:


edit: I think the triple-buffering problem is the same as all the other VolatileImage problems on Nvidia boards.  (As I described above, they don't properly report when VRAM is exhausted, and that's why you're seeing the white/black screens, and then potentially a crash.  This is already reported under  5026186.)
152  Java Game APIs & Engines / Java 2D / Re: JDK 1.5.0-beta2 is now available on: 2004-05-28 18:28:20
For those that mention that openGL pipeline is much worse on Windows, remember that ON WINDOWS you were already getting an accelerated pipeline with DirectDraw/Direct3D.  The openGL pipeline is far newer and really meant for giving the first HW acceleration to Linux/Solaris.

Of course still report all the bugs and performance issues.

Now if performance was worse on Linux someone REALLY goofed Smiley

Yes, please file bugs if you come across any quality or performance issues with the OGL pipeline.  But first, please take a look through the bug database to see if something's been filed already (search for the keyword "OGL").  We've already filed quite a few bugs for many of the issues reported here today.

And Scott, don't be surprised if performance of the OGL pipeline is still worse (than X11) in some cases on Linux.  There are some outstanding driver issues that need to be resolved before we can try to enable this stuff by default.  It's not that we've "goofed", but more like we've got 18 billion different driver/hardware/platform combinations to support, and we want to make sure we've covered all our bases before this becomes our default pipeline.  These things take time...

153  Java Game APIs & Engines / Java 2D / Re: JDK 1.5.0-beta2 is now available on: 2004-05-28 18:21:01
Addendum for Chris,

OGL acceleration works almost perfectly on a nVidia Geforce 3 TI winXP. The problem here is that I get lower performance than without opengl acceleration Huh

- Can you suggest a board type where we can be sure it works at best ?

- Have you got some performace hints about getting the best with java2d and the ogl pipeline ?

- Re-iteration: have you got some more cmdline switches to better control the ogl pipeline ?



Regarding the issues you reported above:

- The OGL pipeline probably can't be enabled on most Matrox boards, because they don't support the newer pbuffer and render_texture extensions

- On your GeForce 2, if you're running a complex Swing app, you'll likely run out of VRAM rather quickly, and there is a known bug in Nvidia's drivers such that they don't report an error when VRAM is exhausted, and then they render black.  We're in the process of reporting this bug to Nvidia (there is no workaround; see 5026186).

- There are a few basic problems in ATI's latest drivers (4.4 I think?) that make the OGL pipeline unusable on Radeon boards (crashes, artifacts, etc, as you've reported).  We're tracking this under 5033205; we'll submit the relevant bugs to ATI and hopefully they will be fixed soon.

- In general, you might find performance lacking if there is a lot of software rendering going on (if your images cannot be cached in textures).  This will happen if you're grabbing the DataBuffer and mucking with the pixels; we will have to use glDrawPixels(), which is notoriously slow on x86 OGL drivers.  We have a workaround that we will implement in an upcoming release (see 5020009).

- Swing performance is also likely to be slower due to relatively poor performance of pbuffer->screen copies.  We have some ideas about allocating the Swing backbuffer in the native OGL backbuffer, which helps reduce context switching and also increases back->front copy speeds.  There are some problems with this approach, so look for a fix in an upcoming release.

To answer your specific questions above...

- I've found that performance/stability is best on GeForce 4 and above.  The current problems with Radeon boards are frustrating, but hopefully ATI will have them sorted out in the near future.

- There are really no OGL-specific performance hints.  (Well, there's only one I can think of: use power-of-two dimensions for your image if you're using TexturePaint, since that's the only way we can accelerate TexturePaints optimally).  This may change in the future, so I wouldn't go out of my way to use this optimization...

- There are no other system properties related to the OGL pipeline.  (I'd like to keep things as simple as possible; we already have too many flags for the Windows and X11 pipelines.)


154  Java Game APIs & Engines / Java 2D / Re: JDK 1.5.0-beta2 is now available on: 2004-05-28 16:37:23
is there any documentation about opengl acceleration and other additional features of java2d ?


Hi Mik,

I just updated my original post with a link to the 2D-specific page of new features, which includes more details about the OGL pipeline on Windows.

155  Java Game APIs & Engines / Java 2D / JDK 1.5.0-beta2 is now available on: 2004-05-27 21:20:22
In case you haven't seen this:

Release notes:

New 2D features (includes more info about the OGL pipeline):

There were numerous 2D-related bug fixes and enhancements integrated in 1.5-beta2... I'm sure many of you will be interested in playing with the OGL-based pipeline, which is now also available on Windows.  (There were also many bug fixes for the OGL pipeline in general, and to improve stability on Linux.)

You can still enable the OGL-based pipeline using the following system property (on all platforms):

Note there is a minor change in the flag semantics... If you want to see a message printed to the console stating whether the pipeline could be enabled successfully, use "True" (note the uppercase 'T'):

Please download this latest beta2 release and send us your feedback; this is your chance to make sure the 1.5 final release is as stable as possible.


edit: added link to 2D-specific features list...
156  Java Game APIs & Engines / Java 2D / Re: Solaris Java 2D Performance on: 2004-04-16 23:17:50
Hey Chris,

do you want to test Castalia, my Java2D-intensive app too ?

Let me know,


Hi Mik,

Sure, send it along to the address in my profile.  I'll try to get to it next week.

157  Java Game APIs & Engines / Java 2D / Re: Solaris Java 2D Performance on: 2004-04-16 14:18:51
EDIT: Of course, if someone with a solaris box is happy to get in touch I can put in the option for the OpenGL pipeline to test with.

Hey Kev, we've got a couple (and by couple I mean 8 billion) Solaris/SPARC machines here... I'd be glad to try out your game to see how it performs on Solaris (with and w/o OGL enabled).  Please send me mail (at the address in my profile).

Actually, from your above posts, it wasn't clear whether you were referring to Solaris/SPARC or Solaris/x86... Most of the performance issues depend on the underlying hardware.  For example, Sun doesn't currently ship accelerated OGL libraries for Solaris/x86 (although Xi Graphics does, for a fee).  This is likely to change in the coming months though... Stay tuned.

There are some flags that can sometimes help improve performance on Solaris, see here:

Mr. Trembovetski might have some more specific hints about Solaris performance...

158  Java Game APIs & Engines / Java 2D / Re: News: OGL on Win in 1.5.0b2 on: 2004-04-16 14:01:37
Repetita Juvant

Do you know if OGL/WGL acceleration will be on by default in the final 1.5 release ?

No, it will not be enabled by default in 1.5.

159  Java Game APIs & Engines / Java 2D / Re: BufferedImage.flush() causing exception on: 2004-03-02 23:20:55
Is there any reason that not flushing the BufferedImage would be harmful to an app?  Right now I just null the thing as a workaround but do I really even need to do it?

It's certainly not harmful to not call flush().  The benefit of flush() is that it is a synchronous way to clean up all the resources (cached copies, etc) used by the image.  If you don't call it (and just null the image out, as you're doing), those resources will be freed up eventually when the garbage collector comes around.

160  Java Game APIs & Engines / Java 2D / Re: BufferedImage.flush() causing exception on: 2004-03-02 18:46:32
The BufferedImage is not null at this point but the exception is always thrown.  I am using 1.5.0.

This bug has been fixed already for 1.5-beta2, which will be released in the not so distant future.  See bugid 4992282.

161  Java Game APIs & Engines / Java 2D / Re: ->here<- HW accelerated images RFE 50021 on: 2004-02-26 20:47:54

One common optimisation done by normal GL rendering things is to pack related images into a single texture. This is likely to be a sensible thing to do in Java2D as well. Detecting usage of subimages in this way would be very beneficial to performance; having to call glBindTexture for every single image change kills performance if the texture ID changes each time.

Yes, I agree that stuffing multiple sprites into a single image is a valid optimization for Java 2D.  In most cases there is no performance hit for copying/transforming a subimage (using the drawImage() variant that takes src/dst regions).  This is especially beneficial for the OGL pipeline, because there's less chance of texture memory fragmentation.  If you had a bunch of 20x20 sprites, and you put each one into a separate managed image, each of those guys would be cached in a 32x32 texture, which is a waste of texture memory.  If you packed all your sprites efficiently into a 512x512
(or some other power-of-two dimension) image, then you could use the drawImage() variant mentioned above to extract the subregions of your sprite image.  And potentially, as you mention, performance could improve since you're bound to the same texture object for many different sprites.

So it sounds like most people want to use translucent VolatileImages as sprites.  Now here's a follow-on to my last question... Why do you want to use VolatileImages instead of managed images for sprites?

[I would argue that managed images are a better fit for the sprite-based situations you guys mentioned.  The only downside I can think of is the added footprint of the system memory copy, but managed images are certainly easier to deal with than VolatileImages (no worries about incompatible GCs, lost surfaces, etc, that's all taken care of under the hood).  But that's just me; I'd like to see what your reasons are for choosing one over the other.]

162  Java Game APIs & Engines / Java 2D / Re: ->here<- HW accelerated images RFE 50021 on: 2004-02-26 15:41:08
Q to Chis: When you say "hardware accelerated rendering" do you also mean transforms and bilinear/bicubic interpolation ?

It depends on which direction you are talking about...

If you render to a VolatileImage (implemented as a pbuffer, in hardware), all rendering operations are accelerated via OpenGL, just as if you had been rendering to the screen.  Refer to the long list of OGL-accelerated operations that I've posted to these forums from time to time (e.g. compositing, bilinear image transforms, etc, etc).

If you copy a VolatileImage to another accelerated surface (i.e. the screen or another VolatileImage), this copy operation will be handled by OpenGL.  In theory, it should be pretty fast, because it's a VRAM->VRAM operation.  But in reality, we've found that straight pbuffer->screen copies are not as performant as say, a texture->screen operation.  This is especially true when you start enabling per-fragment operations, such as blending, or if you specify a non-identity transform.  To answer your question more closely, yes, we will attempt to accelerate pbuffer->screen transforms, but we can only do bilinear in hardware (no bicubic in OGL).  These pbuffer->screen transforms will go through an intermediate texture codepath, so performance will not be as good as if you were transforming a managed image to the screen.  We're working on a solution for this performance issue.

The bottom line is... If all you want is a translucent sprite, and you want to blend it and transform it to your backbuffer, you should probably just use a managed image.  (I mentioned this in the workaround for 5002129.)  If you have a complex scene that changes, and you want to render it into an offscreen, then a (translucent) VolatileImage may be better suited for the task.

Now here's an opportunity to ask a question to the esteemed community... I know many of you were clamoring for the ability to create translucent VolatileImages, and we added new methods in 1.5 for this purpose.  The question is: how exactly are you planning to use translucent VolatileImages in your game (e.g. motion parallax style backdrops?  simple sprites?  something else?)?

163  Java Game APIs & Engines / Java 2D / Re: Java2D not OpenGL'ed on Win on: 2004-02-24 18:30:07
Thanks Chris.. getting accelerated translucent images in the OGL pipeline would be great.

On the other issue - is there anything happening in terms of supporting translucent or irregularly shaped windows?  I know there is an existing RFE for these, and all the major platforms support them now.

I just filed a new RFE:
5002129: OGL: translucent VolatileImages should be hardware accelerated

Should show up here eventually:

(Yes, that's right, we've entered a brave new world where bugid's start with the number 5... My eyes haven't yet adjusted.)

As for the non-rectangular window issue, the RFE is:

The AWT team explored adding this feature, but I believe it was too risky for Tiger (difficult to spec and implement consistently across all platforms).  Hopefully they'll get to it in a future release.

164  Java Game APIs & Engines / Java 2D / Re: Java2D not OpenGL'ed on Win on: 2004-02-24 14:51:53
Bitmask transparency is not needed here.

We need full alpha support in order to get high quality and speed from OpenGL.

Bu the question still remains an maybe some officials here can answer: is the lack of full alpha support the cause of the absence of Java2D OpenGL acceleration on win ?

Could you please explain further why you expect a full hardware alpha channel will give you:
 - high quality, and
 - speed

As Cas mentioned, most modern OpenGL drivers support a full ("stored alpha") channel in hardware on some visuals/pixfmts.  This means that your destination surface is RGBA instead of RGB.  Note that this issue is completely separate from the discussion of whether you can have bitmask or translucent heavyweight windows.  Even if you have an OGL stored alpha channel, it does not mean that you will be able to "see through" the window when the alpha values are not 1.0.

Now, I should mention how this all relates to the OGL-based Java 2D pipeline.  In theory, the OGL pipeline could implement translucent VolatileImages (a new feature in 1.5) in hardware, using the concepts mentioned above (i.e. pbuffer with stored alpha).  However, this is not currently implemented, so if you ask for a translucent VolatileImage with OGL enabled, you will get back a system memory surface.  As I mentioned, it's just a Small Matter Of Programming, so I will file an RFE today and hopefully we'll get to it in an upcoming release.

With that implementation in place, I think javazoid will get the desired effect (hardware accelerated rendering to a translucent offscreen surface).

All that said, it should be clear now that this issue has nothing to do with the fact that the OGL-based Java 2D pipeline is not available on Windows in 1.5.  That issue has already been addressed countless times on this forum, but I can say for sure that we have a prototype working in-house, and we'd like to include it (as an alternate pipeline) in an upcoming release.

165  Game Development / Performance Tuning / Re: The Gloves Are Off on: 2004-02-13 21:09:20

Note: in my code I use the BufferedImage....getData method to get an int[] for the backbuffer BufferedImage which I drawImage onto the BufferStrategy gc every loop, but I only get the int [] once at the beginning then keep modifying the array.  Just wanted to point that out from Abuse post.  Probably a unmanaged, nonvram image is  good in this case.

I've been trying these demos on various machines here at work (they're all good testcases for us, especially for the new OGL pipeline).  I'm finding that performance for nonnus29's testcase is relatively poor with OGL enabled, but I think that's because we're using OGL to copy a software (unaccelerated, non-managed) image to the backbuffer and flipping on every frame.

Just to back up what you and Abuse suspected, managed images will no longer be accelerated once you call getRaster() or a related method.  In this context, I don't see why you need to modify any image arrays directly.  It would be great if we could see your source code.  But from what I can tell, a more optimal approach would be something like:
 - load bigimage.gif
 - copy each tile from bigimage.gif into its own managed image (createCompatibleImage())
 - render each tile directly into the BufferStrategy backbuffer (no need for an
    intermediate BufferedImage)
 - call

If you follow this approach, everything should be accelerated, and with OGL enabled, every tile will be cached in a texture, and the snowflakes will be alpha blended to the backbuffer all at hardware speeds.  Let me know if this makes sense.  It would be great to see an updated testcase.

166  Java Game APIs & Engines / Java 2D / Re: JSE1.5 BETA1 opengl java2D ┬ápipeline on: 2004-02-12 16:50:08
sweet... now all i have to do is install Linux Wink

oh yeah, a quick question that just popped into my head.
Which AlphaComposite rules are accelerated atm?
all of them? or only some of them?

All AlphaComposite rules are accelerated in most cases.  In a couple cases involving antialiased shape rendering, I believe we only accelerate Src and SrcOver.  This may improve in the future when we take more advantage of advanced hardware features, like fragment shaders and multisampling.

167  Java Game APIs & Engines / Java 2D / Re: JSE1.5 BETA1 opengl java2D ┬ápipeline on: 2004-02-12 15:09:45
What are the flags to enable ogl acceleration?
I've yet to find them in the release notes for 1.5 :-/

The most detailed instructions are here:

There's also a link to the original RFE, which contains some more (possibly outdated) information.

As others have mentioned, there have been a number of quality, stability, and performance fixes integrated into 1.5-beta2, so those of you looking to test the new OGL pipeline on Linux/Nvidia configs should be a bit more happy.  There are still of course some strange driver bugs that cause sporadic "issues", but we're doing our best to track them down and resolve them (either by working around them or by submitting bugs to the driver teams).

Also in beta2:
 - hw accelerated GradientPaint and TexturePaint renderers (only when AA is disabled, but that will change in the future)
 - better support for Linux/ATI configs
 - many other bug fixes

Right now the pipeline is only available on Linux and Solaris.  We've got a prototype up and running on Windows, but there are a number of issues (display mode switches, multimon, fullscreen, etc) we must resolve on that platform before the pipeline can be included safely (hopefully in a release that follows Tiger).  Also, I know the Apple guys are excited to have a full OGL pipeline again, and they're planning on having it available in their 1.5 release.  So pretty soon you should be able to count on having the pipeline available on all major platforms, but whether it will be enabled by default on any of them will take some time to sort out.

If you have any specific (hopefully small) testcases that demonstrate bugs in the OGL pipeline, please submit them through the normal channels:

I'll be sure to look into them right away.  We'd like to shake out as many issues as possible before the final 1.5 release.


P.S. It would be fun to see some folks respond to pepe's "contest".  Hint: render some managed images with some arbitrary transforms, alpha compositing, and a complex (Shape) clip for good measure.  That should all be accelerated in hardware with OGL enabled... (Abuse's "Rocks" or "Balls" or "FireStarter" or whatever-it's-called-these-days is a great demo of what I just described.)
168  Java Game APIs & Engines / JOGL Development / Re: Partial redraw implemented in 2d? on: 2003-10-31 18:15:15
Sure, you can use JOGL to do 2D rendering, but it can be a headache if you're not familiar with OpenGL, and it doesn't do anything to improve Swing performance.

You may be interested in the JDK 1.5 release (beta will be out in a few months) that has an optimized Java 2D implementation based on OpenGL.  Your existing Java 2D/Swing apps should see improved performance on Solaris/Linux just by using 1.5 (assuming the appropriate OpenGL drivers are installed).  Just how much improvement you see is dependent on what your app does, but if you do a lot of complex transforms, blending, AA text, complex clipping, translucent sprites, etc, you should definitely be happy.

(Java 2D Team)
169  Java Game APIs & Engines / Java 2D / Re: OpenGL and Java2D on: 2003-09-26 20:57:43
Yeah, seems to have been the reaction everywhere, however it still appears to be the case.

I think they're worried about breaking the window (working) accelerated version. Maybe we'll be able to switch between the two with some runtime flag or something?

campbell is still registered here isn't he? Where art thou oh Java2D bod?


Hey Kev,

As I've mentioned in numerous threads, OpenGL is our #1 priority for Linux and Solaris, because those platforms are in dire need of a performance boost.  This does not preclude a Windows port in a future release (possibly using a command line switch, as you suggest), but we need to get our ducks in a row on the X11-based platforms first.  Once things are stable on those platforms, we can look into supporting OGL on Windows.

And I should note, there are plenty of improvements coming in our DirectX based Windows pipeline for Tiger.  We use the API's that give us the most bang for the, um, buck (and most stability); on Windows, that happens to be DirectX, on Linux/Solaris it happens to be OGL...

170  Java Game APIs & Engines / Java 2D / Re: Either PSP or Java has a broken gif codec :S on: 2003-08-19 03:42:25

I was going to use this in a project at work, but unfortunately there are some leaks in ImageIO that caused huge problems for me... I needed to stream video as JPEGs (JMF is so flakey and worked so poorly that it was unusable). ImageIO seems to make a lot temp files that it never gets rid of. (Why it is making temp files at all is another question. Maybe I needed a setUseCache(false)? )

Yes, if you call setUseCache(false), we won't create a temp file (in some cases, the temp file can help improve performance, but in your case you'll be reading so many images that it's best to disable the cache).


There is also a memory leak that happens when reusing a reader the only work around has other problems.
I was forced to go back to AWT image loading.. which is also buggy.. failing to decode occasionally where ImageIO had no problems.  Seems to be related to thinking it is done reading and yet the image isn't ready... sigh...

I think there may be one or two outstanding bugs related to "leaks" in JPEGImageReader reuse that were fixed for 1.5... Are you calling ImageReader.reset() between each reuse?  That should ensure that the reader cleans up any resources used for the last image decoding.


Oh yeah, why isn't there a method?  I had to do hacks to wrap my buffer with an InputStream

Hmm... You might want to look at the new JAI/IIO Tools package, which includes a couple Image{In/Out}putStreams based on NIO:

If this doesn't suit your needs, or if you have any ideas about how NIO/IIO interaction could be made easier for developers, please submit an RFE.

171  Java Game APIs & Engines / Java 2D / Re: Either PSP or Java has a broken gif codec :S on: 2003-08-19 03:23:11
Quote we are still going to have to copy the image into an 'optimal' managed image?

Can't we just specify where we intend to render the image at load time?


1 image, GraphicsConfiguration intendedDestination)

I'm sorry, I wrote two completely separate thoughts in nearby sentences.

The first thought is:
BufferedImages are now all managed by default, so all you have to do is call  You can render the returned image immediately to any surface (other BufferedImages, the Swing backbuffer, the screen), and we'll cache that image in hardware as appropriate (it's "managed" under the hood, you don't have to worry about anything).  So no need to copy the image returned by IIO into another image.

The second thought is:
If you are creating an image yourself (say you want to do some custom rendering into it), and you will be rendering that image to a screen or backbuffer surface, it's still best to call GraphicsConfig.createCompatibleImage().  That's what we've been telling folks all along, and that remains unchanged.

Hopefully that clears up some confusion.  We really need to finish up that elusive "Java 2D Images Explained" document, which should be a good reference.  I know that the various image types and creation methods have been mysterious in the past.  This new managed image work should clear things up a bit, because the answer is always simply "BufferedImage".  No matter how it was created, or what ColorModel it uses, we'll try to accelerate it under the hood.

172  Java Game APIs & Engines / Java 2D / Re: Either PSP or Java has a broken gif codec :S on: 2003-08-18 21:51:18
Chris, is there any chance in 1.5 that ImageIO will return "Managed" images?  Where they're automatically grabbing VRAM if/when appropriate?

What an excellent question... Smiley  The answer is an emphatic "yes".  We just completed that work a couple weeks ago, so that all BufferedImages (even those returned by ImageIO) can now be considered "managed images".  Of course, it's still best (as always) to use GraphicsConfig.createCompatibleImage() so that we pick the most optimal format for your device.  But at least now you don't have to go through trickery to get your IIO images "managed", as we take care of that for you under the hood.

I hope this makes things easier for you guys...

173  Java Game APIs & Engines / Java 2D / Re: Either PSP or Java has a broken gif codec :S on: 2003-08-18 20:51:28

I believe its a bug with ImageIO, cos if I load the same images with toolkit.createImage/MediaTracker, the problem goes away.

Which kinda suprised me actually, I would have thought both would have used the same underlying codec -
the AWT utility classes must be in a real mess Shocked

btw, are we going to see a mass-deprecation in 1.5, finally saying goodbye to all the old ways of creating/loading/managing and rendering of images?

Probably no deprecation in 1.5, but we've been trying to steer people away from those APIs for a while now.  IIO is definitely the preferred method for loading images, and we're doing everything we can to make it behave/perform as well as the old 1.1-era Toolkit image APIs.

174  Java Game APIs & Engines / Java 2D / Re: Either PSP or Java has a broken gif codec :S on: 2003-08-18 18:19:41
I've got here 2 gifs, identical in every way, *except* the bitmask color is at index 0 in image B, and index 12 in image A.

Image B loads fine, Image A *appears* to load fine.
However, when I apply a rotation tranform to it during drawing, I get an ugly opaque band across the top few rows of the image Huh
The color of the band is dependant on the color at palette entry 0 :S

And yes, I am absolutely positive it is not my code Wink
here are the 2 images

Hi Abuse,

That looks like a bug to me, but I'm not sure whether it a Java 2D problem or an IIO bug.  Either way, it's something for our team to look at... So if you could submit a bug report (with your source code and images included), we'll be sure to check it out.

175  Java Game APIs & Engines / Java 2D / Re: Accelerated transformations on: 2003-08-14 17:34:03
Can/are transforms accelerated with the DirectX rendering in 1.5?

Hi Sam (I mean Steve, er, Scott Smiley),

Probably not in time for 1.5, but we hope to get there soon.

176  Java Game APIs & Engines / Java 2D / Re: Accelerated transformations on: 2003-08-14 16:29:45

Cool! Cheesy

This means there's a hope that we will have hardware transformation using ONLY Java2D (not other non-standard libraries) in release 1.5?

That's the hope... In 1.5 you will get hardware acceleration of transforms when the OGL-based Java 2D pipeline is enabled.

177  Java Game APIs & Engines / Java 2D / Re: Accelerated transformations on: 2003-08-14 14:50:33
Isn't java 2d being implemented on top of OpenGL in Tiger for linux and solaris? I'd have guessed that the new implementation will use accelerated transforms, I could be wrong tho..



Yep, for more info, see the thread over in the JOGL forum.  We definitely try to accelerate complex transforms in hardware, especially when rendering images to accelerated surfaces.  It's pretty amazing having this stuff work at hardware speeds.  (Turn on bilinear filtering, and you don't even take a performance hit!)

178  Java Game APIs & Engines / Java 2D / Re: Is this still considered "right"??? on: 2003-08-06 16:37:49

I am running the latest publicly available Developer Preview (DP102)..   Are you running some later build that you know the issues have been fixed in? (would you be allowed to say if you were? Smiley )

I haven't tried the latest DP102 yet, but I'm pretty sure the fixes I mentioned haven't gone into that one.  I'll keep my fingers crossed for the next one I guess (we don't usually get early access to Apple's DP builds).

179  Java Game APIs & Engines / Java 2D / Re: Is this still considered "right"??? on: 2003-08-06 02:53:25

I just thought I would point out that this app fails spectacularly on Mac OS X with Java 1.4.1... totally unusable.  It's kind of hard to imagine how they managed to get it to behave so poorly.  Could be Apple bugs.. but I've never seen anything else on the Mac do anything like this.

[I'm the author of Mu...]  I agree that it's mostly unusable on Mac OS X, which is pretty disappointing since that's my primary development platform (when I'm not at work).  Fullscreen is especially broken with Apple's 1.4.1... I submitted 3 or 4 bugs to Apple that affect Mu, and I think they've been resolved for their next release.  I also brought up the fullscreen issues to their 2D lead last time I saw him, and he's aware of them.  He's hoping to have some of those resolved for the next release as well.

Thanks for checking out the app... Part of the goal of Mu is to demonstrate some "best practices" when using 2D, Swing, fullscreen, etc. all in conjunction.  If you get a chance to try it on another platform, let me know how it goes, or if you have any suggestions/comments.

Pages: 1 ... 4 5 [6]
hadezbladez (358 views)
2018-11-16 13:46:03

hadezbladez (191 views)
2018-11-16 13:41:33

hadezbladez (361 views)
2018-11-16 13:35:35

hadezbladez (90 views)
2018-11-16 13:32:03

EgonOlsen (2190 views)
2018-06-10 19:43:48

EgonOlsen (2226 views)
2018-06-10 19:43:44

EgonOlsen (1384 views)
2018-06-10 19:43:20

DesertCoockie (2022 views)
2018-05-13 18:23:11

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

nelsongames (2312 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46 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!