Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
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  
  NetBeans OpenGL Pack preview release is out  (Read 6093 times)
0 Members and 1 Guest are viewing this topic.
Offline bienator

Senior Member




OutOfCoffeeException


« Posted 2007-08-09 19:22:44 »

Today we have released a preview version of the NetBeans OpenGL Pack.

screenshot of the GLSL editor:

 

some of the features are:
- GLSL Editor with syntax coloring, code completion including GLSL doc and native compiler/linker integration for error annotations
- OpenGL Capabilities Viewer
- ready to run JOGL demos and RedBook samples
- GLCanvas and GLJPanel integration into the NetBeans Form Designer
- JOGL project templates

requirements:
-shader capable graphics card
-NetBeans 6 beta1 or later

get the update center here:
https://netbeans-opengl-pack.dev.java.net/

Offline Ken Russell

JGO Coder




Java games rock!


« Reply #1 - Posted 2007-08-16 01:29:45 »

Great stuff! I've added links to your project from the JOGL home page.
Offline bienator

Senior Member




OutOfCoffeeException


« Reply #2 - Posted 2007-08-16 18:19:03 »

Great stuff! I've added links to your project from the JOGL home page.
cool, thanks

(btw nice logo)

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

Junior Member





« Reply #3 - Posted 2007-08-16 18:51:55 »

GREAT!
Especially the GLSL editor and compiler support! (personally I don't care much about the rest..  Smiley)

however: it does not work with nb6 M10, does it?
the screenshots look like nb6, but I got the following error adding the nbm:

Quote
Plugin NetBeans OpenGL Pack Update Center cannot match its dependencies:
module org.netbeans.modules.autoupdate.services > 1.3

I could add it manually with the following url:
https://netbeans-opengl-pack.dev.java.net/updatecenter/updates.xml
but I got an UnsatisfiedLinkError when starting nb..
Offline bienator

Senior Member




OutOfCoffeeException


« Reply #4 - Posted 2007-08-16 20:00:48 »

however: it does not work with nb6 M10, does it?
no it doesn't work with m10. 
You will need a nightly build (august or later).
get it here: http://bits.netbeans.org/download/6.0/nightly/
(i am using the build of the 9th August; seems to be stable)


please use NetBeans 6 beta 1 or later.

Offline Nighthaven

Junior Newbie





« Reply #5 - Posted 2007-10-07 08:25:10 »

I followed the installtion instruction.but after i downloaded the nbm file,i can't installed the netbeans opengl pack update center.It stocked,just  "establish a connection" for ever.So i'm wondering, is the update center still working?I tried it last night,and this morning.
Offline Nighthaven

Junior Newbie





« Reply #6 - Posted 2007-10-07 09:57:29 »

I tried the url Mr zero mentioned.It works now.I guess something wrong with the nbm file.it won't work if  i followed the instruction on https://netbeans-opengl-pack.dev.java.net/servlets/ProjectProcess?tab=2,so maybe you should fix it.

btw: really cool tools,helps a lot.
Offline bienator

Senior Member




OutOfCoffeeException


« Reply #7 - Posted 2007-10-07 19:29:41 »

Hi Nighthaven,

great to hear that you like our tools.

sorry I can't reproduce your problem. I have removed all modules (update center included) and reinstalled everything via the update center again and everything worked.
The update center module holds just a link to the updates.xml file containing all locations of the modules, there is not much what could be wrong with the nbm.
The only thing I can imagine is that the java.net file server was temporary down as you tried downloading the modules.

Offline tomk

Junior Newbie





« Reply #8 - Posted 2007-10-15 20:40:31 »


Hi,

Concerning the Netbean's module/lib native library placement and System.loadLibrary(...) semantics,  does this nbm offer both 32 and 64 bit support for a given OS?   If so, how?!

Thanks,

Tom
Offline cylab

JGO Ninja


Medals: 38



« Reply #9 - Posted 2007-10-15 21:36:29 »

Unfortunately we did not manage to get this to work, hence the flat layout of the modules/lib directory. We were planning to solve this issue with the netbeans team, but haven't put any efforts into this til now.

Mathias - I Know What [you] Did Last Summer!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline bienator

Senior Member




OutOfCoffeeException


« Reply #10 - Posted 2007-10-15 21:39:30 »

Hi Tom,
Concerning the Netbean's module/lib native library placement and System.loadLibrary(...) semantics,  does this nbm offer both 32 and 64 bit support for a given OS?   If so, how?!
No, the jogl.nbm deploys JOGL just for 32bit VMs. It is possible to customize the lib loading in NB but I haven't tried it yet.
see http://bits.netbeans.org/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/api.html bottom of page.

I am curious, are you running NetBeans on an 64 bit VM? I just asking because 64bit VMs are the most of the time slower than 32bit VMs (you normally just choose the 64bit VM if you have large heap requirements).

EDIT: damn, cylab was faster  Grin

Offline tomk

Junior Newbie





« Reply #11 - Posted 2007-10-15 23:35:27 »


Thanks for the responses.

We are developing a tool based on the NetBeans platform.  We are looking at using a 64 bit JRE to overcome heap limitations as well as virtual-memory address space limitations.  We've experienced huge improvements in I/O with MappedByteBuffers but with 2^(32-1) of virtual address space we are very limited (especially since we're also using a lot of physical memory and heavy use of heap reduces virtual address space left for mapped file i/o).  So yeah, 32 bits is quite limiting for us...

I appreciate the ease that System.loadLibrary(...) offers with regards to transparent cross-platform native library loading, but it really doesn't cover 32 vs. 64 at all *ouch*.

I'd already looked at the URL you've posted and I've come to the conclusion that the current incarnation of netbeans can't handle this use case and can't without changes the the module classloader (org.netbeans.StandardModule$OneModuleClassLoader) in bootstrap.jar.

The classloader implements findLibrary(...) as such:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
    /** look for JNI libraries also in modules/bin/ */
    protected String findLibrary(String libname) {
        String mapped = System.mapLibraryName(libname);
        File lib = new File(new File(jar.getParentFile(), "lib"), mapped); // NOI18N
       if (lib.isFile()) {
            return lib.getAbsolutePath();
        } else {
            return null;
         }
    }


Note that the comment is wrong and the class loader actually looks in modules/lib.

I think the only way we're going to get this to work is if we can get the NetBeans crew to search in platform specific paths.   i.e. for windows search in modules/lib/windows-i586 or modules/lib/windows-amd64 dependent on architecture.  That would allow us to create module wrappers and support both 32 and 64 bit native libraries if they are forced to share the same name.

This issue affects any Java API extension library utilizing System.loadLibrary(...) sematics (Java3D, JAI, JAI ImageIO, etc...) so hopefully we can convince the NetBeans crew to modify the module class loader to parse paths dependent on platform.  Without this change I have to create mulitple build targets dependent on platform...  kind of goes against the java "build once, run everywhere" mantra...

I've posted to dev@openide.netbeans.org about this.  If you 2 could chime in so that we can get critical mass it would be swell...

Thanks much,

Tom
Offline tomk

Junior Newbie





« Reply #12 - Posted 2007-10-16 00:12:50 »


I've submitted http://www.netbeans.org/issues/show_bug.cgi?id=118951 regarding this.  It affects more than just a JOGL wrapper but any Java API extension relying on System.loadLibrary(...) naming semantics (Java3D, JAI, JAI ImageIO, ...) .  I'm not so concerned they take my suggestion for a fix as much as getting a fix...

I hope something happens!  I look forward to using your OpenGL pack when we migrate to NB 6.0!  I should help with GLSL our shader devel...

Thanks,

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

Riven (18 views)
2014-07-29 18:09:19

Riven (13 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (31 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (41 views)
2014-07-23 21:16:32

Riven (28 views)
2014-07-23 21:07:15

Riven (29 views)
2014-07-23 20:56:16

ctomni231 (60 views)
2014-07-18 06:55:21
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!