1.5beta1 & Image.setAccelerationPriority

I seem to remember reading somewhere that atm (1.5beta1) this method does nothing?
I’ve tested, and it appears to do nothing.

Is it going to be implemented in a future 1.5 release?

And if not fully implemented, can you atleast implement the special case :-

image.setAccelerationPriority(0.0f);

I know there are other ways of de-managing an image (getRaster().getDataBuffer())
It’d just be nice to start using proper methods, rather than dirty hacks :slight_smile:

Unfortunately, it won’t be implemented in 1.5 =(

And I don’t think it makes much sense to implement only single value, because it’d also be a dirty hack =)

Now that I think about it, while we didn’t have time to implement the full-blown priority management, we indeed should’ve at least tried to make a simple scheme allowing to enable/disable acceleration for a particular image.

I don’t see implementing the special case of 0.0f as a dirty hack :o
I see it as fulfilling the specification of the method!

So, specifying a value of 0 should prevent the image from being accelerated - and at the moment it doesn’t :stuck_out_tongue:

But the spec also says that it’s a hint, so what your quote means is “if this value is actually considered, it should mean this”.

So, to me implementing only one special case looks like a hack.

Ah its only a hint, s’pose your right then.
Personally i’d still prefer a partial implementation rather than nothing at all ::slight_smile:
I wonder if beta2 will throw a NotImplementedYet Exception 8)

Seems 1.5 could be my first choice for a game framework, which is capable of doing what i want.

BUT we should file a petition for a Game SDK, the Java Runtime Download Package is getting bigger and bigger.

For my RT Game i need only AWT ( no Swing ).

Abuse did u test the Fullscreen mode again ? I am starting a new try and create a new GameEngine.

Also alpha blending seems to be hardware accelerated 8)

P.S.: Sorry for thread hijacking

yup, I havn’t managed to crash it when changing resolution/bitdepth/refreshrate/fullscreen etc etc.

I have noticed that 8bit fullscreen is veeeeeery slow though, almost as slow as a software back buffer.
I’m guessing blits to an 8bit vram back buffer arn’t accelerated (probably because it was super buggy, and they couldn’t easily fix it ^_^).

WinXP GF2gts 1.5beta1.