Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (482)
Games in Android Showcase (110)
games submitted by our members
Games in WIP (550)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 [2]
  ignore  |  Print  
  Vote time: RFE - Developer controlled swap buffer  (Read 7341 times)
0 Members and 1 Guest are viewing this topic.
Offline moorej

Senior Newbie




Mmmm Lasagna....


« Reply #30 - Posted 2003-10-27 08:53:53 »

I have been in an email discussion with Ken on implementing this functionality and there is a disconnect between our philosophies, and seeing that there are other people trying to solve this problem, I thought maybe we can all just post our concept implementations, the actual code isn't important here, just the methodology and why:

Here it goes for me:
One of the onus' of OpenGL has not been safety, but always flexibility, if safety was the primary concern than there wouldn't be the inventive ways that people of bastardized some of the OpenGL calls, resulting in very nice effects or visualizations.  The makeCurrent and free are just another necessary part of OpenGL, no safer or less safer than any of the other state changing functions.  Granted it has much more far sweeping side effects, but so does going into the wrong matrix mode in the middle of your drawing routine.

My methodology behind doing the implementation in the way that I had sent is because it offered both safety, convenience and the ability to kick you in the butt if you did it wrong.  Safety and convenience through the classes that manage the buffer swap automatically, the different SwapBufferPolicy(s), but I also exposed the [make curent and free] calls.  Granted the swapBufferPolicy classes could have been written to use package only accessor's for buffer swapping, but then the user would have to add to this repository if they needed a different behavior.  Granted they can be very sneeky and insert a rouge class into the package, basically making a different jogl than everyone else is using, but when updates are available, they once again have to repackage.

-Jason (just my 3 and a half cents)
Offline GKW

Senior Member




Revenge is mine!


« Reply #31 - Posted 2003-10-31 20:35:34 »

Finally found some time to get everything done.

Go here to get the files.

I had to rename jogl.dll to jogl.zip to upload it to geocities so rename it back to jogl.dll after download.

1)  GLCanvas and GLJPanel should work a lot better inside JInternalFrames.

2)  GLJPanel has been implemented with pbuffers.  This will allow you to use the lastest version of OpenGL that your graphics card supports unlike the previous implementation which used DIB's and the MS software renderer.  Also if you have a nvidia card it will use render to texture rectangle and you will get ok frame rates.  As soon as OpenGL 1.5 comes out we can use the ARB render to texture rectangle and everyone will get the love.

This is WINDOWS ONLY!!!!!
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #32 - Posted 2003-11-01 02:56:42 »

Quote
I had to rename jogl.dll to jogl.zip to upload it to geocities so rename it back to jogl.dll after download.


You mean you didn't actually ZIP it?Huh?

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

Senior Member




Revenge is mine!


« Reply #33 - Posted 2003-11-01 03:39:39 »

Yeah I was running out the door.  It is now an actual zip and 1/8th the original size.  I don't think you really even need it but I figure just in case I forgot to remove some of my own native code.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #34 - Posted 2003-11-03 23:39:04 »

FYI, a "per-thread GLContext stack" has been checked in to the JOGL repository. This enables calling GLDrawable.display() recursively as well as calling another drawable's display() method from within a GLEventListener's display() implementation. It was a prerequisite for exposing swapBuffers() in the public API, which should now be almost trivial to implement correctly and which is on my list of things to do.
Offline GKW

Senior Member




Revenge is mine!


« Reply #35 - Posted 2003-11-04 01:08:58 »

Looks cool.  That will fix the little hack I did for GLJPanels using render to texture rectangle.  I will try to integrate what I did into the new framework.
Offline GKW

Senior Member




Revenge is mine!


« Reply #36 - Posted 2003-11-10 19:24:35 »

I merged my code with the code now in the tree.  The source is now available in joglsource.zip and the jar is the working jar.  The dll from the source tree will work just fine.  I also forgot to mention that I added dispose methods to GLCanvas and GLJPanel.  It seemed to be a waste of resources not to have a dispose method.  Along those lines what would you think about a destroy method in GLEventListener?  It would make cleanup a little more automatic.

The files are here.
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #37 - Posted 2003-11-12 18:31:05 »

Thanks for your changes. I want to avoid exposing destroy() at the moment because I think it should be possible to fix the issue of destroying and recreating the OpenGL context by overriding addNotify() and removeNotify() as Pepijn van Eeckhoudt did in GL4Java (and which I haven't yet ported over). I'll try to review your changes over the next week.

FYI, my current priority is fixing the visual / pixel format selection problems that have been seen e.g. on lower-end cards. It looks like most of JOGL's code in this area needs to be restructured and some minor public API changes are necessary (to the GLCapabilitiesChooser interface).
Offline GKW

Senior Member




Revenge is mine!


« Reply #38 - Posted 2003-11-12 19:33:43 »

The only problem I see with overridding addnotify is that someone might want to keep the canvas around and reattach it later and not have to have everything reset.  Which is exactly what the code I just posted does.  When the internal frame iconizes the glcanvas, removeNotify() is called.  If you are loading textures in your init you can expect a sizeable wait while they are reloaded.
Offline GKW

Senior Member




Revenge is mine!


« Reply #39 - Posted 2003-11-12 19:37:12 »

I forgot to mention that I would like to do a fix for moving the canvases around to different monitors in a multiheaded config but I don't have a second monitor handy.  I am going to see if I can scrounge up a little 15incher.  I think all you need to do is keep track of what GraphicsDevice you are on and then when ancestorMoved events are generated  all you have to do is check if the component moved to a different GraphicsDevice and then re-init the device context and the rendering context.  Shouldn't be to hard.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline bobthekochka

Innocent Bystander




Java games rock!


« Reply #40 - Posted 2003-11-16 14:56:06 »

I am surprised that this was never implemented???  There are a lot of times when you will want to control when to swap.  How do you do this with JOGL (I am currently using GL4Java)?  In my case I have my own rendering thread... sometimes I re-render my entire scene in the back buffer and then swap and sometimes I render in the front buffer using an XOR Op for rubberbanding etc.  Obviously when I only render in the front buffer I don't want a swap but it seems like I can not control that in JOGL... My point is that this is an important feature Smiley
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #41 - Posted 2003-11-20 15:24:50 »

I'm running into the same problem here trying to develop a multi-headed application (actually an SGI cave app).  It's really frustrating that this is not a proper OpenGL port, but just a hand-wavy attempt at it.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline moorej

Senior Newbie




Mmmm Lasagna....


« Reply #42 - Posted 2003-11-20 19:31:07 »

I will have to defend Ken and the JoGL team here a little.  It's definitely not a hand wavy attemp at an OpenGL binding, they are trying to mitigate the risks involved of the makeCurrent,free, and swapping conundrum that appears.  We all want it to be as robust as possible and as safe as possible.  I am on your side that this functionalty needs to exist and I have some ideas, but what the JoGL team needs is feedback of what you are trying to accomplish in each of the programs, whether it be manual buffer swapping or makeCurrent and free operations.  I have already submitted to Ken an implementation that supports custom swapBufferStrategies that will allow your desired behavior, but he had some problems with me making too many things public.  We'll get through this I'm sure, but it's going to take some thought.

-moorej
Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #43 - Posted 2003-12-10 16:40:28 »

Any news on this? =/

Play Minecraft!
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #44 - Posted 2003-12-10 16:54:41 »

Who knows. Not sure why its taken 3 months to close the loop on this feature. I say we ping Sun, and then make the change Smiley

This doesn't exactly require a red ribbon comittee...

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline Ken Russell

JGO Coder




Java games rock!


« Reply #45 - Posted 2003-12-11 21:11:01 »

The underlying support whicih this feature required, a per-thread notion of the OpenGL contexts that have been made current, was only committed within the past few weeks.

Pressing J2SE 1.5 work has prevented active work on JOGL recently though I hope that will change in the near future.
Offline Markus_Persson

JGO Wizard


Medals: 14
Projects: 19


Mojang Specifications


« Reply #46 - Posted 2003-12-11 21:31:11 »

Cool, thanks for letting us know. =)

Play Minecraft!
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #47 - Posted 2003-12-13 02:30:54 »

Quote
The underlying support whicih this feature required, a per-thread notion of the OpenGL contexts that have been made current, was only committed within the past few weeks.

Pressing J2SE 1.5 work has prevented active work on JOGL recently though I hope that will change in the near future.


Well since we're all one big open source family, can you or someone else post the intended path so someone else can take a crack at it?

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Pages: 1 [2]
  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.

CopyableCougar4 (14 views)
2014-08-22 19:31:30

atombrot (28 views)
2014-08-19 09:29:53

Tekkerue (25 views)
2014-08-16 06:45:27

Tekkerue (23 views)
2014-08-16 06:22:17

Tekkerue (15 views)
2014-08-16 06:20:21

Tekkerue (22 views)
2014-08-16 06:12:11

Rayexar (61 views)
2014-08-11 02:49:23

BurntPizza (39 views)
2014-08-09 21:09:32

BurntPizza (31 views)
2014-08-08 02:01:56

Norakomi (37 views)
2014-08-06 19:49:38
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!