Java-Gaming.org    
Featured games (91)
games approved by the League of Dukes
Games in Showcase (581)
games submitted by our members
Games in WIP (500)
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  
  How to render TRANSLUCENT VolatileImages reliably?  (Read 1062 times)
0 Members and 1 Guest are viewing this topic.
Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Posted 2004-07-31 22:10:20 »

I brought this issue up months ago, back in 1.4.0 as a potencial problem when TRANSLUCENT VolatileImages eventually get implemented.

Now in 1.5 they finally have been I'm not seeing anything in the API that has been changed to ever make TRANSLUCENT VolatileImages work reliably.

The loop suggested in the API for ensuring a VolatileImage is draw correctly simply does not work when dealing with TRANSLUCENT images, the reason is because when performing a TRANSLUCENT blit, both the source and destination pixels contribute to the resultant pixel color.
The destination pixel will therefor be effectively corrupt if you render the source image twice.

Heres the sequence of operations that causes the problem.

1) Validate VolatileImage to make sure its ok to blit.

2) blit it to the backbuffer.

3) outside event causes the VolatileImage to lose its contents.

4) contentsLost is called, and returns true.

4) so your code has to restore the VolatileImage.

5) and then re-blit it to the backbuffer. etc etc.

This loop could potencially go on forever, but for simplicity lets say it happens only twice.
This still means a TRANSLUCENT image has been rendered onto the backBuffer twice, when it should have only been rendered once.
This will result in incorrect pixel values in the destination.

So, am I missing something - or are Volatile TRANSLUCENT images kinda fundamentally buggy?

[edit]
I guess the simplest solution is to change the definition what contentsLost() returns.

Instead of a boolean indicating whether the contents has been lost since the last call to validate(),
it should be changed to indicate if the contents has been lost since the last time the image was drawn?
[/edit]


p.s. I assume managed BufferedImages can behave in the exact same way, as their cached copy in vram can potencially lose its contents at any time also?

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #1 - Posted 2004-07-31 22:37:33 »

> p.s. I assume managed BufferedImages can behave in the
>exact same way, as their cached copy in vram can
>potencially lose its contents at any time also?

AFAICR their copy is stored in RAM not VRAM (storing the copy in vram doen't make much sense does it?)

弾幕 ☆ @mahonnaiseblog
Offline Abuse

JGO Coder


Medals: 10


falling into the abyss of reality


« Reply #2 - Posted 2004-07-31 22:41:07 »

Quote
> p.s. I assume managed BufferedImages can behave in the
>exact same way, as their cached copy in vram can
>potencially lose its contents at any time also?

AFAICR their copy is stored in RAM not VRAM (storing the copy in vram doen't make much sense does it?)


I'm going to assume you misread, or misunderstood what I said Huh

managed BufferedImages are cached in VRAM, so they can be HW accelerated.

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #3 - Posted 2004-08-01 01:38:45 »

Excuse my sillyness Grin

Well, one "copy" is stored in ram and the other one in vram. And yea, it can of course loose it's content, too... in that case the ram copy jumps in.

For that reason I just use managed BufferedImages. I don't really see an advantage in using volatile images, because I would have to care about that stuff myself.

弾幕 ☆ @mahonnaiseblog
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.

xsi3rr4x (57 views)
2014-04-15 18:08:23

BurntPizza (55 views)
2014-04-15 03:46:01

UprightPath (68 views)
2014-04-14 17:39:50

UprightPath (51 views)
2014-04-14 17:35:47

Porlus (68 views)
2014-04-14 15:48:38

tom_mai78101 (92 views)
2014-04-10 04:04:31

BurntPizza (153 views)
2014-04-08 23:06:04

tom_mai78101 (249 views)
2014-04-05 13:34:39

trollwarrior1 (205 views)
2014-04-04 12:06:45

CJLetsGame (212 views)
2014-04-01 02:16:10
List of Learning Resources
by SHC
2014-04-18 03:17:39

List of Learning Resources
by Longarmx
2014-04-08 03:14:44

Good Examples
by matheus23
2014-04-05 13:51:37

Good Examples
by Grunnt
2014-04-03 15:48:46

Good Examples
by Grunnt
2014-04-03 15:48:37

Good Examples
by matheus23
2014-04-01 18:40:51

Good Examples
by matheus23
2014-04-01 18:40:34

Anonymous/Local/Inner class gotchas
by Roquen
2014-03-11 15:22:30
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!