Redsquare NEWT ES2 demo on OSX

So I finally got the demo running after some fighting with maven and the shader sources...

Under OSX I often get the following error on launch:
RUN Thread[Thread-2,5,main] GLProfile[GL2ES2/GL2]
Detected screen size 1680x1050
createWindow0 - Parent is neither NSWindow nor NSView : 0x0
*************** viewWillDraw: 0x0x1022063f8Invalid memory access of location 0x746e65765bcd rip=0x10109fd12

But occasionally I get a couple of seconds of rendering before another 'Invalid memory access of location'

when it is running, it's around 2000fps :) and great to see you have es2 on the desktop, that's going to make a lot of android developers happy!

I also now tried the example posted by someone here with the 'NewtCanvasAWT' and internal frames.  So just to feedback, under OSX the NEWT window is at pos 0,0 rather than attached to the internal frame.  Any mouse activity in the newt bit also causes an invalid memory access error.

edit: i'm now on b237 btw

On Tuesday, November 30, 2010 23:52:14 BrickFarmer [via jogamp] wrote:
Yup, I know, NEWT support is unfinished on OSX due to other priorities.
Even though some heavy lifting (threading solution etc) is almost done.

~Sven

Seems I'm not having much luck with OSX.  I now switched my main game code(not newt) over from b220 to b237 and nothing renders anymore, not even the gears demo.  Just a gray box.
I went back a couple versions and it seems b236 was rendering, but with a faulty depth buffer?  I went back all the way to b230 and the depth buffer issue seems to be there before that, ie somewhere between 220-230.  
For the gray screen hudson says something was changed regarding background erase in b237, maybe that's the issue.

On Wednesday, December 01, 2010 16:43:56 BrickFarmer [via jogamp] wrote:
>
> Seems I'm not having much luck with OSX.  I now switched my main game code(not newt) over from b220 to b237 and nothing renders anymore, not even the gears demo.  Just a gray box.
> I went back a couple versions and it seems b236 was rendering, but with a faulty depth buffer?  I went back all the way to b230 and the depth buffer issue seems to be there before that, ie somewhere between 220-230.  
> For the gray screen hudson says something was changed regarding background erase in b237, maybe that's the issue.

Please file a proper bug report (See wiki JOGL FAQ) with the latest hudson master build >= #242,
and hopefully with a tiny test.

Thank you.

~Sven

so you have a sense of humor too, I get paid for that kind of work :)

but I hadn't seen the b242, 'jogamp-next' stops at b237.  So the background issue has been fixed! thanks.

I imagine the depth buffer issue has something to do with GL_POLYGON_OFFSET_FILL since they are the only parts of my scene affected.  But that's about as far as my understanding of depth buffers go I'm afraid.

On Wednesday, December 01, 2010 21:13:20 BrickFarmer [via jogamp] wrote:
>
> so you have a sense of humor too, I get paid for that kind of work :)
Now I just lost my humor and might get a bit angry here.

If you feel bothered to contribute and help to help yourself and all of us,
maybe you are using the wrong tools.

If I may remind you, even if you would have payed me to support you (support contract),
I would ask you for qualified information and cooperation - as any other support company.

This is outrageous.

~Sven

Don't take it the wrong way, I just really hate the bugzilla tool, it feels too much like my day job where the tool is used mostly for politics.  I never did understand why managers consider projects with the highest bug fixing rates, to be better than the projects with hardly any bugs.

Everyone has their own way of feeding back into a community, although some would just squat on the sidelines watching.  I'm actually doing my best to help in my own way.  My plan was to write some demos showing NEWT functionality, possibly as a maven achetype, but I can't do that so far because of the OSX issues.  Plus I had the OSX build issues, and now I have some wierd errors at deployment time.  So it seems like I'm just not having much luck.

I've spent a solid week of my holidays now trying to get various parts of JOGL working and reporting my findings.  Plus the time it took to work out how to install and use git to access the sources.  In the meantime I've been trying to get things working with maven, which I've also been feeding back into the community.  My understanding of JOGL/OpenGL is very weak, and I'm still trying to understand what NEWT even is.  Which is part of the reason for my efforts.  By working on a demo I could help document what it is you are doing.  But my understanding is far from being at the level of a true developer, think of me more as a Tester.  Someone who is able to cut and paste some code and get something working, but far from understands it all.  If I post something here, I'm not necessarily looking for support, since I know you are busy trying to finish the product, but I do feel a duty to document my findings.  

If something as simple as the gears demo stops working under OSX, I don't think responses along the lines of 'write a test case' or 'log a bug' is helpful.  I took the effort to download and install 7 different versions of JOGL to isolate the build that caused the issue.  I also identified a possible 'check in' comment via hudson that sounded related.  I think that's already quite a lot more than many of your users would do.  Although I admit that without knowing my background with bugzilla, my comment sounded rude.  So I apologise for that.

On Thursday, December 02, 2010 11:40:10 BrickFarmer [via jogamp] wrote:
>
> Don't take it the wrong way, I just really hate the bugzilla tool, it feels too much like my day job where the tool is used mostly for politics.  I never did understand why managers consider projects with the highest bug fixing rates, to be better than the projects with hardly any bugs.
>
> Everyone has their own way of feeding back into a community, although some would just squat on the sidelines watching.  I'm actually doing my best to help in my own way.  My plan was to write some demos showing NEWT functionality, possibly as a maven achetype, but I can't do that so far because of the OSX issues.  Plus I had the OSX build issues, and now I have some wierd errors at deployment time.  So it seems like I'm just not having much luck.
>
> I've spent a solid week of my holidays now trying to get various parts of JOGL working and reporting my findings.  Plus the time it took to work out how to install and use git to access the sources.  In the meantime I've been trying to get things working with maven, which I've also been feeding back into the community.  My understanding of JOGL/OpenGL is very weak, and I'm still trying to understand what NEWT even is.  Which is part of the reason for my efforts.  By working on a demo I could help document what it is you are doing.  But my understanding is far from being at the level of a true developer, think of me more as a Tester.  Someone who is able to cut and paste some code and get something working, but far from understands it all.  If I post something here, I'm not necessarily looking for support, since I know you are busy trying to finish the product, but I do feel a duty to document my findings.  
>
> If something as simple as the gears demo stops working under OSX, I don't think responses along the lines of 'write a test case' or 'log a bug' is helpful.  I took the effort to download and install 7 different versions of JOGL to isolate the build that caused the issue.  I also identified a possible 'check in' comment via hudson that sounded related.  I think that's already quite a lot more than many of your users would do.  Although I admit that without knowing my background with bugzilla, my comment sounded rude.  So I apologise for that.

My apologies to you too
and thank you for your words.

As I said before, NEWT is not finished on OSX, hence working with it on OSX would
only make sense if you want to fix it - for now.

Of course, all user input is very welcome.
The only problem with 'unstructured' input is the work we will have with it,
eg to identify the source code, your platform etc.
Hence I have added the nice runtime version info, which should be added to a bug report at least.
This is all documented in the Wiki and should be very plausible
since it makes life easier for all of us.

Bugzilla, well, it's not a must - but it's nice to keep track and make life easier for us too.
  http://jogamp.org/wiki/index.php/SW_Tracking
  http://jogamp.org/wiki/index.php/SW_Tracking_Report_Critical

It's not political for us, but to have an overview and to keep track
where plain emails are just not as well trackable.

Sure, starting with an email might be a good thing.
Later on however, especially if I cannot fix it right away, a persistent bug entry is quite helpful.
You can search for it, it's present in our Wiki etc.
Searching in emails and forum posts is much more a pain for everybody here.

A little bit of structure is recommended to make life easier,
not to higher the paperwork level :)
The more you dig into such project you will realize it yourself,
ie tracking down your own bug reports, whether they are in email or better Bugzilla.

Maybe this makes the situation more understanding.

However you contribute, you are very welcome.
Demos and bug reports, discussing API odds, etc are necessary sure,
hence this project is alive - because of you and others.

And it doesn't matter if you are a big spender / big company
or a 'just having fun home user'. We try to treat you equal
based on the quality of your input, sure thing.

Looking forward to your demonstrations and documentation.
Maybe you like to have a Wiki account for the latter ?

Again: Thank you for your help.

Cheers, Sven