Sun's current implementation 'sucks' to you? Then, why not using an other implementation?...I guess than simply ranting is faster than testing an API and asking for debate about intelligent subjects, like 'how to make sun integrate that other XXX pipeline as a default one', or 'what are the best alternate java2D implementations for gaming?'...Or, even better, starting a new thread like ' why don't we make a fast lightweight java gaming java2d library based on a GL pipeline that will please us' and implementing one...... this is something that could have been done.... mmhhhh.... three years ago, i think...man, all that energy lost for nothing....

Um, you're saying this in reply to *Cas* ?

I don't use LWJGL (sorry, guys), but I know that not only is it done and working, but also how tirelessly (well, actually he may be tired at last ...) Cas has tried to get the GTG / J2D / etc groups @ sun to improve things, (according to his opinion of how they ought to be).

Nevertheless, to stick to your thoughts, i think the right question should be:"why is java2D still not fully hardware accelerated on parts that can actually be"simply because:- java is not slow, we all know it- 3D hardware acceleration were not accessible 10 years ago. Talk about 6 years...

I think that most of the answer is "because no one did it", and also "because it's not as simple as we might think"...

Then, let's be constructive... i started a thread about 1.5 graphic acceleration and added a small contest... get there, participate/

the thread might be interesting to continue if we try something.let's take one of the applications that were done here and convert it to Agile2D or any hardware accelerated java2D implementation. let's see the results we have then, and see how it compares to actual java2d, then compare it to 1.5 java2d.that might be useful in finding where are the things that needs to be improved, if still the GL pipeline (linux) and other accelerations (vram for win32) are too slow or bad.Anyway, it will give us an idea of what we might get to when things get accelerated as we all expect them to be in a near future.

Importantly, drawing generic shapes and text is sometimes slower under OpenGL. The issue with general shapes can be somewhat mitigated by using immutable shapes - Agile2D caches immutable shapes using OpenGL display lists and can render them significantly faster (on the order of 50,000 shapes per second using the same test conditions above).

My own real work (the stuff which pays) does a great deal of general shape drawing (mostly wide polylines), each of which is rendered once only. So while OpenGL may speed up many of the operations you want for games, Java2D needs to provide a good balance of performance for other uses as well. That makes the job of using hardware accelleration much harder --- it can easily turn into hardware decelleration for another group. It is already the case that my code works faster when I turn anti-alliassing ON --- because that stops any attempt to use the hardware and useless punting between system memory and video memory.For complex high quality 2D rendering Java2D seems to work as well as anything available (and allegedly rather better than GDI+). So given that current hardware provides only limited support for 2D, perhaps it is better to leave Java2D as it is and use a specialist API for 3D/games work. Certainly use 3D acc. if possible without significantly compromising performance of code using features which can't be accellerated, but don't hold your breath waiting for dramatic improvements.

Ah - but I don't want everything hyper accelerated!There are a few key areas which are used by the vast number of apps out there which could be accelerated with GL or D3D:

Blitting

Rectangles & triangles

Lines

Leave the other stuff using the normal pipeline.Incidentally poly drawing in GL is not usually optimised in consumer cards. The underlying functionality is meant to be the same as Java2D more or less but because the consumer cards are largely optimised for games, they've never bothered too much with the performance.

The peak was 10, the low 2... not very impressive, and not playable really.

Ick, well I'm glad I'm not using a Mac, how depressing. I get 60FPS solid on my crappy work machine (Win2k) without alpha. 30 solid with alpha. And the scrolling is smooth. Well just one more oddness about J2D, you can't count on any two machines running the same code even close to the same way.

Is there a "big" different between the snowflakes that aren't completely filled images and my block tile? In other words is it likely that a snow flake, having large portions of the image being completely transparent, would perform better?

i've discussed with nonnus, if he permits me to quote our private discussion, i'll tell you how he did his sprite drawing and what conclusion we can draw from that.we'll be able to go further in that way

I did my blending in software from the snowflake buffered image to a backbuffer buffered image blending each pixel.

Agile2d looks interesting, but it breaks the promise of crossplatformness and is gl4java available anymore? And on what platforms?

which means that going software is faster than vram read... This is something interesting, imho. Scott's example is slow, still don't know exactly why, but i believe it is because there are vram reads. This leads me to think that once a pipeline is implemented using a particular method, it has to keep that way as much as possible. the wish to have blits and lines hardware must not be limited to only blits and lines because most of the acceleration, if not all will be lost in mixing techniques. Again imho, accelerating rendering must be seen as a complete solution, not only a trick or two to use at some places. I believe this is partially why it is hard to implement a correct accelerated solution at all.

Agile2D looks nice, but is not a long term solution to me. it is nice to test the concept, but that stops here. GL4Java is ported to linux, OSX and win32, so it is quite cross platform... I think i heard that gl4java was not developed anymore. Anyway, what would be the interest now that we have JOGL...

My question still remains, then -- what type of things are people doing that would require more graphics capability than Java2D has? I'm blitting over 1200 images to the screen using bitmask blending and getting anywhere between 150 and 200 FPS... that's more than enough for most games I would write (I'm working on a 3/4 view or full isometric RPG -- haven't figured out which yet). Does anyone have a demo (even a slow-moving one), of something they've written, or is Java's "slowness" just an excuse to get nothing done?

I'm just curious what people want to acheive that REQUIRES alpha blending and the like that can't be acheived by other means.

It's basecly the same method as used by nonnus29. The background tiles are VolatileImages. Each sprite are dirty rectangles that are rendered in software.

It will run faster that nonnus29's demo because the background tiles are bigger. He use 32x32, I use 64x64. This doubles the speed on my computer. So there seem to be some overhead in useing lots of VolatileImages.

I'm just curious what people want to acheive that REQUIRES alpha blending and the like that can't be acheived by other means.

heh.. maybe that there is some kind of a preventive defense feeling of the java developers - that have been quoted for too long about slowness- that relative slowness is not good, even if it's already nice. There is a strong desire of very fast things so that we can compete with people that have been thinking for too long that we are using slow APIs. That's normal. if we want to be remarked and make minds change about java, we have to be astounishing. Fast is not enough.That's my analysis, it might of course not fit anyone else.

My question still remains, then -- what type of things are people doing that would require more graphics capability than Java2D has? I'm blitting over 1200 images to the screen using bitmask blending and getting anywhere between 150 and 200 FPS... that's more than enough for most games I would write (I'm working on a 3/4 view or full isometric RPG -- haven't figured out which yet). Does anyone have a demo (even a slow-moving one), of something they've written, or is Java's "slowness" just an excuse to get nothing done?

I'm just curious what people want to acheive that REQUIRES alpha blending and the like that can't be acheived by other means.

Alpha Compositing is a fundamental requirement for sooo many 2D effects. I'm sure you don't need me to list them all.The only thing that is more fundamental, is transforms.... and we don't have that accelerated yet either <_<

Alpha Compositing is a fundamental requirement for sooo many 2D effects. I'm sure you don't need me to list them all.The only thing that is more fundamental, is transforms.... and we don't have that accelerated yet either <_<

I'll give you transforms... they definitely could be a big aspect in the playing of some games.

But to me, alpha blending is essentially eye candy that's nice, but not imperative in order to make a good game. I totally understand the desire for it, just not why it's such a big stopping point for some people.

Case in point -- I just finished playing Planescape: Torment for the first time. I've owned it for years, but now I'm going through all of the games I never beat on my "finish all my old games BEFORE I buy new ones" kick (after I was thoroughly disappointed by DX:IW after being such a fan of Deus Ex). The graphics are about 5 years out-of-date, but the gameplay and fantastic story makes it a great game even today. Even older is Fallout2, which I beat right before PS. Both incredible games which had very little to do with the graphics.

Think about it this way -- how cool is it that you can do BITMASK blitting by just setting a flag in a function? I come from the days when you had to do that manually, and it was no fun. Java2D isn't perfect, but it's relatively easy to program, and someday (hopefully soon), they'll add everything we want to it.

It makes a lot of things look nicer. The most critical I can think of is anti-aliased text. Particualrly if you are going tio TVs (which I hope we will in the nto too distant future) anti-aliasing is kinda important.

Yes you can design around it, but having it opens up more options.

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!

This one appears to be faster than the others on the Mac, but there is no FPS display

Keep in mind that the Mac has no hardware acceleration in 1.4.2 that I am aware of, and that if you use an image format that is not supported by the native rendering engine icky slow conversions are done. I think I posted something about this either in Java2D or Performance Tuning a couple months ago.

It's basecly the same method as used by nonnus29. The background tiles are VolatileImages. Each sprite are dirty rectangles that are rendered in software.

It will run faster that nonnus29's demo because the background tiles are bigger. He use 32x32, I use 64x64. This doubles the speed on my computer. So there seem to be some overhead in useing lots of VolatileImages.

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