Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (568)
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  
  'get'ting the sun.java2d.blahblah property flags.  (Read 3979 times)
0 Members and 1 Guest are viewing this topic.
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Posted 2004-04-23 13:44:28 »

I had the urge to redo my DisplayModeDialog,
and thought i'd add an 'advanced settings' dialog which allowed you to set exactly which property flags you wanted active.
I intended to get the default settings for this dialog by using getProperty(blahblahflagname), however it appears these properties arn't set until you set them yourself?
Is this correct, or have I just made some silly mistake?

And if they are indeed not set unless an app. sets them, is there a way to find out what the 'default' flag settings are in a given JVM?

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

Senior Member




If only I knew what I'm talking about!


« Reply #1 - Posted 2004-04-25 03:35:14 »

It all depends on a property. I.e. I'd think that for some vm properties there are default values.

But as for the java2d properties, unfortunately you can't get their default values.

I guess you can just have a combobox for each flag:
default
true
false
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #2 - Posted 2004-04-25 12:22:54 »

yup, thats sort of what i've done.

Some of the flags appear to be interpretted in a tristate manner (unspecified, false & true) sun.java2d.ddlock is 1 of these (though I have no idea what it does Grin)

Here is the Dialog in its current state - It now supports multiple display devices (I slapped a few extra gfx cards in my machine, and it seems to detect their presence and capabilities fine (though I didn't actually try rendering to them)
1 thing I did notice though, for Java to detect extra gfx cards in WinXP,
the 'extend my Windows desktop onto this monitor' checkbox has to be set in Display Settings.

http://www.pkl.net/~rsc/DisplayModeDialog.jar

btw, there are a few flags that I have no idea as to their function, can you help?

These are :-
sun.java2d.accelReset
sun.java2d.checkRegistry
sun.java2d.disableRegistry
sun.java2d.allowrastersteal
sun.java2d.offscreenSharing
sun.java2d.ddlock
sun.java2d.managedimages (I guess this 1 is for enabling/disabling the use of managedImages - though I can't see anywhere that it is currently used Roll Eyes)

:edit:

oh yeah, is there any chance that in the near future we can have something along the lines of :-

1  
2  
bufferStrategy.setVsync(boolean value);
bufferStrategy.getVsync();

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 trembovetski

Senior Member




If only I knew what I'm talking about!


« Reply #3 - Posted 2004-04-26 01:31:40 »

Quote

These are:...


Sorry, can't help you. =) See, if I told you it'd mean that these properties will become "public", and I can't do that w/o asking for permission from higher quthorities..

The good news is that our technical writer is wrapping up an article on all known public java2d flags, it should be out  soon.

Quote

oh yeah, is there any chance that in the near future we can have something along the lines of :-


I don't think so (definitely not in the near future).

Why would you need that? Supposedly you can figure out whether the strategy is synched or not by checking if it's Flip or Copy strategy. Also, you can request a particular one by using createStrategy(buffers, BufferCapabilities)..
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #4 - Posted 2004-04-26 15:13:00 »

Quote

Why would you need that? Supposedly you can figure out whether the strategy is synched or not by checking if it's Flip or Copy strategy. Also, you can request a particular one by using createStrategy(buffers, BufferCapabilities)..


Needed because Flip or Copy should NOT imply Sync or No Sync.  And I believe that it has been shown elsewhere in there forums that getting sync'd blits in windowed mode on Win XP is possible.  (Though maybe hardware dependent)

Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #5 - Posted 2004-04-26 16:24:19 »

As I see it there are 2 independant issues here :-

1) Is it technically possible to have an un-vsynced page flip?

2) Does bufferStrategy.show() *have* to block when using a 2 page vsynced flipping strategy?

I don't know the answer to either of those questions,
but if 1) isn't possible, and 2) has to block, then there is nothing wrong with the current api. (apart from the lack of windowed mode (blit strategy) vsync)

If 1) is possible, then we need capability to specify whether we want vsync'ed strategy or not.
and if 2) doesn't have to block, then we need a way of specifying whether we want it to block or not.
(perhaps bs.show(boolean block))

[going off on a tangent]

hmm, thinking further, I can see why bs.show() blocks.
If it didn't, when you came to render the next frame, you would potencially be rendering onto the front buffer (if the previous refresh hadn't completed yet)

However, this could be avoided, by making getDrawGraphics() the blocking call (if the buffer page you want a context onto is currently the front page, block)

This would be advantageous in most game loops, as you would be able to do the physics for the next frame and then block when you come to render it, rather than blocking at the end of the previous frames render.

1  
2  
3  
4  
5  
6  
while(true)
{
    doPhysics();
    render(bufferStrategy.getDrawGraphics());
    bufferStrategy.show();
}


at the moment the above code when using a vsynced 2 page flipping strategy would behave like this :-

loop
{
  doPhys
  render
  block until next vblank.
  change video pointer
}

If you made getDrawGraphics() the blocking call, the behaviour would be :-

loop
{
  doPhys
  block if vblank hasn't occured yet
  render
  change video pointer
}

Because you would potencially spend less time blocking, you would increase the maximum throughput in situations of high load(basically iron out any fps stutters). In the best case scenario, you would get the entire doPhys code executed for free!

I don't know if this technique is possible though...
as I don't know exactly what bs.show() has to do to cause a page flip.
(does it change the video pointer, then block until the gfx card says 'vblank',
or does it wait for the gfx card to say 'vblank' and *then* change the video pointer.
If its the later, then you can scrub this [going off on a tangent] bit, as it simply can't work ^_^)

[/going off on a tangent]

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

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #6 - Posted 2004-04-26 17:50:05 »

Quote
at the moment the above code when using a vsynced 2 page flipping strategy would behave like this :-

loop
{
  doPhys
  render
  block until next vblank.
  change video pointer
}

If you made getDrawGraphics() the blocking call, the behaviour would be :-

loop
{
  doPhys
  block if vblank hasn't occured yet
  render
  change video pointer
}


But that last loop is WRONG.  you can't change the video pointer some arbitrary amount of time after waiting on the Vblank.  That would be the SAME as unsync'd with a timer.  you would get tearing.
Since the video pointer MUST change immediately after the vlbank wait to be useful you are back to this.

loop
{
  doPhys
  block if vblank hasn't occured yet
  change video pointer
  render
}

Which basically is the same as the first loop you had, but with the physic calcs (state updating) done after the render of the previous state but before it is shown.

Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #7 - Posted 2004-04-26 18:46:34 »

ah ok, that kind-of answers my 1st question.
'Can the video pointer be changed part way through a refresh', you are saying it can, and causes tearing.
If this is true, then unvsynced page flipping (issue '1)') is possible and support for it needs to be added.

The reason I asked, is I would have expected any change to the video pointer to not take effect until the next refresh.
(The gfx card would read the video pointer only once (at the start of a refresh) and use that same value through out)
If this were the case, you could quite safely change the video pointer part way through a refresh -
So long as you blocked the program from writing to the newly referenced video page until the vblank was received.

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

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #8 - Posted 2004-04-26 19:11:00 »

Heres a little pseudo code expressing the behaviour i'd expect.
Does the GraphicsCard behave like that (copying the videoPointer at the start of a refresh)?
or does it always reference the original videoPointer.
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
59  
60  
61  
62  
63  
GraphicsCard
{

      videoPointer
      vblank =      false;
      hblank =      false;

      while(true)
      {
             copyOfVideoPointer = videoPointer
             for(int      i = 0;i<      displayHeight;i++)
             {
                   sendLine(copyOfVideoPointer+i*displayWidth);
                   hblank = true;
             }
             vblank = true;
             wait      for next      refresh
      }
}


Game
{

      while(true)
      {
             //physics code
            Graphics g      = BufferStrategy.getDrawGraphics();
              // render      code
            BufferStrategy.show();
      }
}

mySuggestedBufferStrategyImplementation
{

      Graphics      getDrawGraphics()
      {
            while(!vblank);
            return new Graphics(videoPointer);
      }

      void show()
      {
            GraphicsCard.vblank = false;
            videoPointer =      nextVideoPage;
      }
}

currentBufferStrategyImplementation
{
      Graphics      getDrawGraphics()
      {
            return new Graphics(videoPointer);
      }

      void show()
      {
            GraphicsCard.vblank = false;
            while(!GraphicsCard.vblank);
            videoPointer =      nextVideoPage;
      }
}

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

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #9 - Posted 2004-04-27 18:30:31 »

Actually I should be more careful.. What I meant was that if you could change the actual pointer outside of the vertical blanking interval there would be tearing.  It IS possible that the write to the video pointer is buffered and would only take effect on the next vertical blank.. That might depend on the drivers.. I don't know what they are like these days.  I know that in the display settings you can disable the v-sync.. I wonder if that is what it does... let's you flip the buffer any time instead of latching the buffer pointer during the vertical blank.  

My main point was supposed to be that waiting for the vertical sync is going to cost you the same amount of time in any case .. the net effect of both loops would be that they have the same amount of time to process and render a frame.

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #10 - Posted 2004-04-27 22:11:56 »

Quote

the net effect of both loops would be that they have the same amount of time to process and render a frame.


Are you sure?
I thought the loop i suggested was superior, because, instead of doing nothing while waiting for the vblank, I was instead doing the physics calculations for the next frame.

I can achieve the same result by using 2 Threads, and toggling between them (both will only be active at the same time, when the render Thread is blocked in bufferStrategy.show() [waiting for the vblank])
I have yet to profile it, though it should give a performance gain(if the overhead of task switching is not too large)

Still, if the behaviour of the hardware was compatible with what I expect it to be, it would be possible to do this without the need for 2 Threads.
There must be some1 out there who knows how all this low level **** is handled :-/ (I always said abstraction was a fundamentally flawed concept Wink)

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
//physics Thread
while(true)
{
     doPhysics();
     physicsDone = true;
     notify(); //wake the render Thread
    wait(); //and now wait for the render Thread to wake us up again
}

//render Thread
while(true)
{
     if(physicsDone==false) wait(); //physics for this frame arn't done yet, so sleep until the physics Thread wakes us
    render();
     physicsDone = false;
     notify(); //wake the physics Thread so it is processing while waiting for the vblank
    bufferStrategy.show(); //blocks waiting for vblank
}


btw The code above is again seudo code,
I know using a non-atomic operation for setting and checking the physicsDone flag is not Thread safe ^_^

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

Senior Member




If only I knew what I'm talking about!


« Reply #11 - Posted 2004-04-28 02:36:52 »

Switching back and forth between threads _will_ be costly..
Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #12 - Posted 2004-04-28 10:51:57 »

yah, that thread toggling idea was just abit of fun ^_^ (infact, because bs.show() appears to block by spinning on a boolean it doesn't work properly at all)

anyhow, im absolutely positive non-vsynced page flipping is possible,
and vsynced windowed mode is also possible, soooo....
/me trundles off to make an RFE...

add it to BufferCapabilities perhaps?

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

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #13 - Posted 2004-04-28 11:52:37 »

FFS will the java.sun.com web admin get off their asses and fix the fkin bug submission page!!! arrrrrg!!
I'm sick of having to enter the data twice  Angry

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

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #14 - Posted 2004-04-28 23:44:28 »

Quote
Switching back and forth between threads _will_ be costly..


If the thread is going to block properly anyway then a context switch is inevitable (to the system idle thread).

However, if the wait for vertical is a busy loop... (which it shouldn't be, since the refresh rate is so slow relative to what the processor could be doing...)  then everything would be hosed in terms of doing a decent threaded implementation.

My point about the loops being equal above is that the 'if' condition would have to be such that you would usually need to wait, otherwise you couldn't keep up at the display refresh rate. (That makes sense, right?)

Offline Abuse

JGO Knight


Medals: 12


falling into the abyss of reality


« Reply #15 - Posted 2004-04-29 15:46:16 »

http://developer.java.sun.com/developer/bugParade/bugs/5039246.html

Make Elite IV:Dangerous happen! Pledge your backing at KICKSTARTER here! https://dl.dropbox.com/u/54785909/EliteIVsmaller.png
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.

Pippogeek (39 views)
2014-09-24 16:13:29

Pippogeek (30 views)
2014-09-24 16:12:22

Pippogeek (20 views)
2014-09-24 16:12:06

Grunnt (46 views)
2014-09-23 14:38:19

radar3301 (28 views)
2014-09-21 23:33:17

BurntPizza (64 views)
2014-09-21 02:42:18

BurntPizza (36 views)
2014-09-21 01:30:30

moogie (42 views)
2014-09-21 00:26:15

UprightPath (51 views)
2014-09-20 20:14:06

BurntPizza (54 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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!