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?

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 )

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.

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

These are :-sun.java2d.accelResetsun.java2d.checkRegistrysun.java2d.disableRegistrysun.java2d.allowrasterstealsun.java2d.offscreenSharingsun.java2d.ddlocksun.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 )

:edit:

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

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)..

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)

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.

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 ^_^)

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.

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.

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.

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.

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 )

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

//physics Threadwhile(true){doPhysics();physicsDone = true;notify(); //wake the render Threadwait(); //and now wait for the render Thread to wake us up again}

//render Threadwhile(true){if(physicsDone==false) wait(); //physics for this frame arn't done yet, so sleep until the physics Thread wakes usrender();physicsDone = false;notify(); //wake the physics Thread so it is processing while waiting for the vblankbufferStrategy.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 ^_^

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?)

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