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 (535)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Java Game APIs & Engines / jMonkeyEngine / jME on OSX on: 2004-12-02 13:18:10
greetings!

i'd like to test jME for my further developments. currently i'm fiddeling with jogl, waiting for lwjgl to get ready on the mac. and before i start to develop a complete scene-graph myself i'll check what you guys did already.

monkey says it runs on mac os x out of cvs - it does not for me  :-/

running ant gives me this (and a lot more):

   [javac] jme/src/com/jme/util/geom/GeometryInfo.java:249: warning: as of release 1.4, assert is a keyword, and may not be used as an identifier
   [javac]             assert (pg.length == 1);

assert is java 1.5 (right?). currently i am not working on tiger/tiger but still on panther/1.4. (10.3.6)

monkey, how do you compile the stuff from the cvs?

here's my root:
:pserver:atze@cvs.dev.java.net:/cvs
repository is jme.
is there another cvs i should use?
2  Java Game APIs & Engines / Java Sound & OpenAL / Re: MacOSX just makes noise on: 2004-08-26 11:54:03
i uses my 'new mail'-sound. it works in mail.app so i thought it should work in joal as well. (and i tried the Footsteps.wav from the example)

does wav have any endiness at all?

could anyone point me to a soundfile that works on mac os?
3  Java Game APIs & Engines / Java Sound & OpenAL / MacOSX just makes noise on: 2004-08-24 19:34:46
hi there,

i tried https://joal-demos.dev.java.net/devmaster/lesson1.html and 2.
joal just makes noises. it sounds a bit like the file i try to play but it's mainly noise.

OpenAL.framework version 1.0.12 -- posted April 21, 2004
joal todays download (binary dist)
mac os x 10.3.5

do i need to change the lessons for macosx?
4  Java Game APIs & Engines / JOGL Development / Re: Easy font-rendering? on: 2004-08-10 13:00:14
try java.awt.Graphics2D.drawString().
5  Java Game APIs & Engines / JOGL Development / Re: jogl API feedback requested for JSR 231 on: 2004-07-21 09:30:54
it's in glext.h among the GL_APPLE_texture_range extension.

#if GL_APPLE_texture_range
#define GL_TEXTURE_RANGE_LENGTH_APPLE      0x85B7
#define GL_TEXTURE_RANGE_POINTER_APPLE     0x85B8
#define GL_TEXTURE_STORAGE_HINT_APPLE      0x85BC
#define GL_TEXTURE_MINIMIZE_STORAGE_APPLE  0x85B6
#endif
6  Java Game APIs & Engines / JOGL Development / Re: 64x64 limit problem on: 2004-07-16 12:48:51
power mac g4, 1ghz (values change with every run a bit):
1  
2  
3  
4  
5  
6  
7  
      public void renderMethod2(int x, int y, GL gl)
      {
            MATRIX_TRANSLATION[12] = x;
            MATRIX_TRANSLATION[13] = y;
            gl.glLoadMatrixf(MATRIX_TRANSLATION);
            gl.glCallList(displayListHandle);
      }

1000000 tiles rendered with method1(immediate) in 6003ms, which makes 166000 tiles/s
1000000 tiles rendered with method2(display lists) in 6853ms, which makes 145000 tiles/s

instead of using a full matrix, let's just translate:
1  
2  
3  
4  
5  
6  
7  
      public void renderMethod2(int x, int y, GL gl)
      {
            gl.glPushMatrix();
            gl.glTranslated(x, y, 0);
            gl.glCallList(displayListHandle);
            gl.glPopMatrix();
      }

1000000 tiles rendered with method1(immediate) in 6081ms, which makes 164000 tiles/s
1000000 tiles rendered with method2(display lists) in 6393ms, which makes 156000 tiles/s

and now, let's assume we're at the right position already (which is - in most cases - pretty useless) Smiley
1  
2  
3  
4  
      public void renderMethod2(int x, int y, GL gl)
      {
            gl.glCallList(displayListHandle);
      }

1000000 tiles rendered with method1(immediate) in 6131ms, which makes 163000 tiles/s
1000000 tiles rendered with method2(display lists) in 3846ms, which makes 260000 tiles/s

what a slow video-card i have...

and apple states:
for a list use a minumum of 16 verticies, less slows you down
7  Java Game APIs & Engines / JOGL Development / Re: 64x64 limit problem on: 2004-07-16 11:33:10
um...

Exception in thread "main" java.lang.Error: Do not use javax.swing.JFrame.add() use javax.swing.JFrame.getContentPane().add() instead
       at javax.swing.JFrame.createRootPaneException(JFrame.java:465)
       at javax.swing.JFrame.addImpl(JFrame.java:491)
       at java.awt.Container.add(Container.java:307)
       at TileDemo.execute(TileDemo.java:37)
       at TileDemo.main(TileDemo.java:22)
8  Java Game APIs & Engines / JOGL Development / GLException: Surface already unlocked on: 2004-07-16 09:15:19
i have my app running under mac os x. now we tried it on windows. here's the exception:
1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
net.java.games.jogl.GLException: Surface already unlocked
        at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.unlockSurfa
ce(WindowsOnscreenGLContext.java:192)
        at net.java.games.jogl.impl.windows.WindowsOnscreenGLContext.free(Window
sOnscreenGLContext.java:134)
        at net.java.games.jogl.impl.GLContext.invokeGL(GLContext.java:271)
        at net.java.games.jogl.GLCanvas.displayImpl(GLCanvas.java:194)
        at net.java.games.jogl.GLCanvas.display(GLCanvas.java:82)
        at net.xytanics.games.engine.Viewport.draw(Viewport.java:191)
        at net.xytanics.games.smsrace.Controller$TickTimerTask.run(Controller.ja
va:88)
        at java.util.TimerThread.mainLoop(Unknown Source)
        at java.util.TimerThread.run(Unknown Source)


the difference i see in the init() method is this:
mac: net.java.games.jogl.GLCanvas[canvas0,0,22,800x578]
win: net.java.games.jogl.GLCanvas[canvas0,4,23,792x573,invalid]

the 'invalid' looks really bad there. any idea, what i have to do to the canvas to make it valid?
here's my construction:
1  
2  
3  
4  
5  
6  
7  
8  
            Frame frame = new Frame("Viewport Frame");
            DisplayMode bMode = aDevice.getDisplayMode();
            frame.setBounds((int) (bMode.getWidth() - bounds.size.width) >> 1, (int) (bMode.getHeight() - bounds.size.height) >> 1, (int) bounds.size.width, (int) bounds.size.height);
            GLCapabilities capabilities = new GLCapabilities();
            canvas = GLDrawableFactory.getFactory().createGLCanvas(capabilities);
            canvas.addGLEventListener(this);
            frame.add(canvas);
            frame.show();


do i have to add frame.setVisible(true) or something like it?
9  Java Game APIs & Engines / JOGL Development / Re: Fullscreen for Mac OS X: Solution on: 2004-07-15 16:42:45
hm.. i don't create a window. here's a rip-off of my contructor-code. please keep in mind that i am working with my modified fullscreen-version of jogl.
the Bounds-class just holds four values: x,y,width,height.
canvas.addGLEventListener(this) is done to get the various callbacks, like public void init(GLDrawable aDrawable) and public void display(GLDrawable aDrawable)
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  
      public Viewport(GraphicsDevice aDevice, DisplayMode aMode, boolean wantsFullscreen)
      {
            super();

            device = aDevice;
            bounds = new Bounds(0, 0, aMode.getWidth(), aMode.getHeight());

            Frame frame = new Frame("Viewport Frame");
            if (wantsFullscreen)
            {
                  System.out.println("will enter fullscreen: " + device);
                  if (device.isFullScreenSupported())
                  {
                        frame.setUndecorated(true); // this is important
                       device.setFullScreenWindow(frame);
                        System.out.println("will change displaymode: " + device);
                        if (device.isDisplayChangeSupported())
                        {
                              device.setDisplayMode(aMode);
                        }
                        else
                              System.err.println("DisplayChange is not supported on " + device);
                  }
                  else
                        System.err.println("Fullscreen is not supported on " + device);

            }

            DisplayMode bMode = aDevice.getDisplayMode();
            frame.setBounds((int) (bMode.getWidth() - bounds.size.width) >> 1, (int) (bMode.getHeight() - bounds.size.height) >> 1, (int) bounds.size.width, (int) bounds.size.height);

            GLCapabilities capabilities = new GLCapabilities();
            canvas = GLDrawableFactory.getFactory().createGLCanvas(capabilities);
            canvas.addGLEventListener(this);
            frame.add(canvas);
            frame.show();
      }


hope that helps Smiley
10  Java Game APIs & Engines / JOGL Development / Re: Java for OpenGL API-Layer Discussion on: 2004-07-08 10:05:29
Quote
Raw bindings to the 'C' openGL APIs shoudl be done once, in one library/class. Never to be done again accept to add bindings to new OpenGL APIs and features.


yes, that's exactly what i'm looking for!

Quote
... the requirements to support subsets of OpenGL for certain platforms


just implement the base standard as an interface. then add the platform/hardware specific methods in a concrete implementation. make that implementation a public class, so that the programmer can decide to stick to the interface (runs on all platforms) or use the native machine-dependent class explicitly (read: has to cast to platform-dependent class) where available.
and there still is GLboolean glIsEnabled(GLenum capability) to avoid falling into a pit.

so is anyone able to come up with such an interface and do an implementation-skeleton that we could just flesh out on the different platforms?
and maybe the interface could have an identifier (String/array) that could tell the programmer what platform-specific extensions are available?

on top of that you could then put any awt/swing/swt/fullscreen/offscreen/... implementation you like.
11  Java Game APIs & Engines / JOGL Development / Re: Java for OpenGL API-Layer Discussion on: 2004-07-07 17:16:45
hm.. no real discussion about my topic.

anyway, my problem with any unreachable (read 'private to the framework' stuff (context in jogl) is that i always and in every system i've used i had to break the lock after i understood the system. otherwise i'd be forced to find another system to work with.

so either i can drill down to a usable context whenever i need it in jogl (try to unload a texture in the draw-method if the object holding the texture is already gc'ed sometime before the draw-call), or i have to find a system that suits my needs better.

i'm currently checking lwjgl. i finaly managed to compile it but i can not get any demo to run. that leaves a bad taste and i have no time to dig deeper into the system.

you can not differenciate a system by saying that it's for game-programmers or for a 'professional'. the difference is only if it is an open or a closed system. closed systems are of no use for anyone than a beginner. such systems are toys (no offense) to play around but not to get the work done the way you want it. (why is elementData in Vector protected? why is String final? there are things in java that i don't like either) Wink

what i need is a clean opengl-binding with no additional restrictions that i don't have if i'd use C instead of java.
<sarcastic>
and if multithreading seems to be a problem to some then don't use awt or whatever might get in your way. or just learn the concepts of multithreading and build the restrictions you want yourself.
</sarcastic>

could we please get this discussion back to the point? thanx a lot!
12  Java Game APIs & Engines / JOGL Development / Java for OpenGL API-Layer Discussion on: 2004-07-06 10:07:52
i open this thread to introduce a possible solution i'd like to see as a standard. this discussion is about the layer structure and the naming conventions in the different layers. my ideas might lead to a concept that is to far away from the current jogl design. if that should be the case please point me to another forum where such a structure could be discussed and set up.

the presented structure is not complete. it is a discussion-base.

i recommend an api layered in the following fashion, from bottom to top:

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  
OpenGLCServer (called GL in jogl)
      static final public int GL_TEXTURE_2D 0xXXXX;
      static public void glVertex3i(int, int, int);
      static public void glVertex3f(float, float, float);
      static public void glVertex4f(float, float, float, float);
      ...

OpenGLServer
      static final public int TEXTURE_2D 0xXXXX;
      static public void vertex(int, int, int);
      static public void vertex(float, float, float);
      static public void vertex(float, float, float, float);
      ...

OpenGLContext
      public static OpenGLContext currentContext();
      public static void clearCurrentContext();
      public void makeCurrentContext();
      public void flushBuffer();
      public OpenGLDrawable drawable();
      public void clearDrawable();
      public void update();
      ...

interface OpenGLDrawable
      public OpenGLDrawable(); // constructor creates suitable OpenGLContext
     public OpenGLContext context(); // returns the context bound to this drawable
     public void display();
      ...

non-window-system-based drawables:
FullscreenOpenGLDrawable implements OpenGLDrawable
OffscreenOpenGLDrawable implements OpenGLDrawable
VirtualscreenOpenGLDrawable implements OpenGLDrawable

view/window-system-based drawables:
AWTOpenGLDrawable implements OpenGLDrawable
SwingOpenGLDrawable implements OpenGLDrawable
SWTOpenGLDrawable implements OpenGLDrawable


OpenGLCServer and OpenGLServer are identical in functionality, they only differ in syntax.
this specification would solve the following - already discussed - problems:

a) porting low-level opengl from c to java
OpenGLCServer wraps the underlying c-functions of OpenGL keeping the c-naming convention. this is a convenience class for c-programmers and other people wanting/having to stick to the c-naming scheme.

b) make opengl a good java citizen
OpenGLServer wraps the server by using method overloading. java programmers should use this interface for any new programs. this should be the recommended way to interface opengl with java. therefore it is not explicitly called OpenGLJavaServer.

c) automatic removal of unneeded pre- and postfixes with java 1.5
a static import of OpenGL(C)Server will remove the need to write
1  
2  
OpenGLCServer.glVertex3i(0,0,0); or
OpenGLServer.vertex(0,0,0);

and instead allow
1  
2  
glVertex3i(0,0,0); or
vertex(0,0,0);


d) partial independency of window-system
FullscreenOpenGLDrawable and OffscreenOpenGLDrawable should be independent of the underlying window-system (awt/swing/...). this opens the possibility of building apps that do not need to know anything about it.

e) exposure of the opengl context
the programmer is able to talk to the context whenever needed, not only in the draw-method. this allows for uploading/destroying textures, generating display-list, ... at a choosen time.

caveats
the server-methods are kept static because opengl is a state-machine. the client itself has limited knowledge about the current active context. the programmer has to ensure that drawing is done to the right (current) context (or that the right context is current).
this becomes an issue when awt and swing are used.
the OpenGLContext has to be exposed to the programmer. otherwise the access to opengl would be to restrictive. the threading issues have to be adressed either by the programmer or by the awt/swing/... based classes.

OpenGLDrawables distinguish between the choosen output-path.
OpenGLContext is pretty near to NSOpenGLContext from apple.
input (keyboard, mouse) is not considered here.

your comments and ideas are welcome!
13  Java Game APIs & Engines / JOGL Development / Re: Fullscreen for Mac OS X: Solution on: 2004-07-06 05:37:42
Quote
Mouse events will not get propageted correctly (dead mouse)


um.. just tested gears in true-fullscreen. the mouse just works! you can turn the gears around as you like. so that problem seems to be gone with DP3 as well.
14  Java Game APIs & Engines / JOGL Development / Re: WWDC OS X Jogl Sessions on: 2004-07-05 22:54:53
gerard was not there. he got a baby two days before Smiley
instead, kenneth took his part. he showed mainly a port of quake 2 (jake2) running on jogl. so there was nothing special about jogl itself. it was more about java and graphics in general and how to optimize the code by using shark and opengl profiler. and that the implementation was faster than before and that threading works better now. many poarts are true for DP3 already, so get it and try it. the exact contents are under non-disclosure anyway and you won't get lots of better information.
but i was happy to be there to get the difference between view-based and fullscreen contexts over to kenneth, so we might see some improvement at that in the future.

15  Java Game APIs & Engines / JOGL Development / Re: jogl API feedback requested for JSR 231 on: 2004-07-05 17:49:21
please add this to the GL class:

     final static int GL_TEXTURE_STORAGE_HINT_APPLE = 0x85BC;
16  Java Game APIs & Engines / JOGL Development / Re: Fullscreen for Mac OS X: Solution on: 2004-07-05 16:42:42
hi there.

i did a quick test with the new Java JDK 1.4.2 Developers Preview 3 (available since WWDC) and fullscreen now works out of the box on mac os x - but it is not a fullscreen NSOpenGLContext, it still renders into a view.

example:
800*600*32:
original code: 10000 frames in 36 seconds = 277 fps
modified code: 10000 frames in 28 seconds = 357 fps
1440*900*32:
original code: 10000 frames in 72 seconds = 138 fps
modified code: 10000 frames in 48 seconds = 208 fps

to get the best performance we still need a modification of MacOSXWindowSystemInterface.m to switch the NSOpenGLContext to fullscreen instead of using a view.
i am pretty sure that the DP3 view-based context does not swap buffers, but instead does a bit-blit to the screen - and that's definitely slower.

Quote
Mouse events will not get propageted correctly (dead mouse)

this is due to the missing window/view that you can not ask for movements. i worked around this in my objc-app by using NSApps currentEvent. here's a sample to catch mouse movements:

     static NSTimeInterval eventNum = 0;
     NSEvent *anEvent = [NSApp currentEvent];
     if(eventNum != [anEvent timestamp] && [anEvent type] == NSMouseMoved)
     {
           eventNum = [anEvent timestamp];
           // you can now use anEvent to do what you need...
           float x = [anEvent deltaX];
           float y = [anEvent deltaY];
     }

yes, this breaks the normal behavior, but we are going to write FAST games, right?
if somebody knows a better way for this please tell me.

Quote
Swing components with AquaL&F will not work.

ok, let's just accept that as a fullscreen-limitation. what i understood about jogl is that it's an open-gl implementation for java, not a way to render swing on top of open-gl. if i go fullscreen i don't need any swing/awt components. i just want to draw open-gl on the screen. maybe that's just my understanding of fullscreen apps.

another possibility would be to add a new 'true' fullscreen mode in jogl, to circumvent the whole awt and swing stuff like this*:
GL context = GLDrawableFactory.getFactory().createGLFullscreenContext(GraphicsDevice, GLCapabilities);
*this comes right from my head, not tested, no deeper thoughts done, so don't scream 'hack' again.
and while we're at it let's add a context.syncToVerticalBlank(boolean).

my code is not a hack and it is unfortunately not rendered useless with the modifications in DP3. it uses NSOpenGLContext as it was intended for fullscreen and brings the highest available performance to jogl on mac os x. let's work together to bring that speed to jogl.
17  Java Game APIs & Engines / JOGL Development / Re: Fullscreen for Mac OS X: Solution on: 2004-06-20 16:03:11
1) yeah, i see that problem too. i'm not sure who eats the events.
2) no idea. maybe because i built it on a newer os version?

and i found a syntax error. i removed my debug code and forgot to rebuild - sorry for that.

i correct it in my first post.
18  Java Game APIs & Engines / JOGL Development / Re: Fullscreen for Mac OS X: Solution on: 2004-06-19 19:39:15
if you can build jogl on macos x at all, you're at the start.

- replace the method in
jogl/src/native/jogl/MacOSXWindowSystemInterface.m
with my modified method.
- build jogl (ant macosx) and
- copy the jogl.jar and libjogl.jnilib to your usual directory (/Library/java/Extensions) and you have fullscreen enabled.

then modify Gears.java with the example code and run it.

then just enjoy those gears running faster than ever in fullscreen Smiley
19  Java Game APIs & Engines / JOGL Development / Re: Fullscreen for Mac OS X: Solution on: 2004-06-19 19:23:50
excuse me if i get enthusiastic, but by sight of my eye the fullscreen version is _WAY_ faster than the original!

now for something completely different: i'd like to have vbl sync.... i could build it in there, but how do i know if you want the sync?
20  Java Game APIs & Engines / JOGL Development / Re: Fullscreen for Mac OS X: Solution on: 2004-06-19 19:12:28
sorry, i have no idea what webstart is.
but here is an example that works with my modification and brings the Gears-demo into fullscreen.

first: a method to select a DisplayMode to your liking.
second: a modification to main() to use fullscreen instead of a window.

please excuse that i did not built in a switch to toggle between windowed and fullscreen - that is left as en exercise to you Smiley

     static public DisplayMode getBestModeForParameters(GraphicsDevice aDevice, int aDepth, int aWidth, int aHeight)
     {
           DisplayMode aModeArray[] = aDevice.getDisplayModes();
           DisplayMode aBestMode = null;
           for (int i = 0; i < aModeArray.length; i++)
           {
                 DisplayMode aMode = aModeArray;
                 if (aMode.getWidth() >= aWidth && aMode.getHeight() >= aHeight && aMode.getBitDepth() >= aDepth) // is aMode fitting at all?
                 {
                       if (aBestMode != null)
                       {
                             if (aMode.getWidth() <= aBestMode.getWidth() && aMode.getHeight() <= aBestMode.getHeight() && aMode.getBitDepth() <= aBestMode.getBitDepth()) // is aMode better?
                                   aBestMode = aMode;
                       }
                       else
                             aBestMode = aMode;
                 }
           }
           return aBestMode;
     }



     public static void main(String[] args)
     {
           Frame frame = new Frame("Gear Demo");
           GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
           GraphicsDevice aDevice = ge.getDefaultScreenDevice();
           DisplayMode aMode = getBestModeForParameters(aDevice, 32, 800, 600);
           if (aDevice.isFullScreenSupported())
           {
                 aDevice.setFullScreenWindow(frame);
                 if (aDevice.isDisplayChangeSupported())
                       aDevice.setDisplayMode(aMode);
           }
           frame.setBounds(0, 0, (int) aMode.getWidth(), (int) aMode.getHeight());

           GLCanvas canvas = GLDrawableFactory.getFactory().createGLCanvas(new GLCapabilities());
           // Use debug pipeline
           //    canvas.setGL(new DebugGL(canvas.getGL()));
           System.err.println("CANVAS GL IS: " + canvas.getGL().getClass().getName());
           System.err.println("CANVAS GLU IS: " + canvas.getGLU().getClass().getName());

           canvas.addGLEventListener(new GearRenderer());
           frame.add(canvas);
           // frame.setSize(300, 300); atze: this is not needed for fullscreen!
           final Animator animator = new Animator(canvas);
           frame.addWindowListener(new WindowAdapter()
           {
                 public void windowClosing(WindowEvent e)
                 {
                       animator.stop();
                       System.exit(0);
                 }
           });
           frame.show();
           animator.start();
     }


please give me feedback if this works for you!
if not all errors are mine and i'd like to remove them.
21  Java Game APIs & Engines / JOGL Development / Fullscreen for Mac OS X: Solution on: 2004-06-19 15:55:21
hi folks,

here is the fix to get a fullscreen context under mac os x!
this is an almost clean solution. the only dirty part is that i don't know for sure if you really want to be fullscreen. the decision is made on the size of the window that wants the context:
if the window is exactly the size of the current screens resolution, a fullscreen context is generated, otherwise a view-based context is built.

all changes i did begin with a commented 'atze:'

void* createContext(void* shareContext, void* view,
                   int redBits,
                   int greenBits,
                   int blueBits,
                   int alphaBits,
                   int depthBits,
                   int stencilBits,
                   int accumRedBits,
                   int accumGreenBits,
                   int accumBlueBits,
                   int accumAlphaBits,
                   int sampleBuffers,
                   int numSamples)
{
     if (gAutoreleasePool == nil) // atze: create a pool as early as possible
           gAutoreleasePool = [[NSAutoreleasePool alloc] init];
     
     int colorSize = redBits + greenBits + blueBits;
     int accumSize = accumRedBits + accumGreenBits + accumBlueBits;
     
     NSOpenGLContext *nsChareCtx = (NSOpenGLContext*)shareContext;
     NSView *nsView = (NSView*)view;
     
     // atze: if the views window covers the entire screen make the gl-context fullscreen
     NSWindow     *aWindow        = [nsView window];
     NSRect       aWindowFrame    = [aWindow frame];
     NSScreen     *aScreen        = [aWindow screen];
     NSDictionary *aDictionary    = [aScreen deviceDescription];
     NSNumber       *aDisplayNumber = [aDictionary objectForKey:@"NSScreenNumber"];
     CGDirectDisplayID aDisplay = (CGDirectDisplayID)[aDisplayNumber longValue]; // this is kind of ugly

     // atze: we can not use NSScreens size, because it's the hardware resolution
     // atze: the GDDisplayPixelsXX returns the soft-resolution
     size_t aScreenWidth  = CGDisplayPixelsWide(aDisplay);
     size_t aScreenHeight = CGDisplayPixelsHigh(aDisplay);

   // atze: does the window cover the entire screen?
     if(aScreenWidth == (size_t)NSWidth(aWindowFrame) && aScreenHeight == (size_t)NSHeight(aWindowFrame))
     {
           nsView = nil; // atze: ignore the view, go fullscreen!
     }

     /* atze: what are these checks for? just create a context, regardless of that views state.
     if (nsView != nil)
     {
           NSRect frame = [nsView frame];
           if ((frame.size.width == 0) || (frame.size.height == 0))
           {
                 fprintf(stderr, "Error: view width or height == 0at \"%s:%s:%d\"\n", __FILE__, __FUNCTION__, __LINE__);
                 // the view is not ready yet
                 return NULL;
           }
           else if ([nsView lockFocusIfCanDraw] == NO)
           {
                 fprintf(stderr, "Error: view not ready, cannot lock focus at \"%s:%s:%d\"\n", __FILE__, __FUNCTION__, __LINE__);
                 // the view is not ready yet
                 return NULL;
           }
           [nsView unlockFocus];            
     }
     */

     NSOpenGLPixelFormatAttribute attribs[] =
     {
           ((nsView == nil) ? NSOpenGLPFAFullScreen : NSOpenGLPFAWindow), // atze: allow a fullscreen context
           NSOpenGLPFANoRecovery, YES,
           NSOpenGLPFAAccelerated, YES,
           NSOpenGLPFADoubleBuffer, YES,
           NSOpenGLPFAColorSize, colorSize,
           NSOpenGLPFAAlphaSize, alphaBits,
           NSOpenGLPFADepthSize, depthBits,
           NSOpenGLPFAStencilSize, stencilBits,
           NSOpenGLPFAAccumSize, accumSize,
           NSOpenGLPFASampleBuffers, sampleBuffers,
           NSOpenGLPFASamples, numSamples,
           NSOpenGLPFAScreenMask, (NSOpenGLPixelFormatAttribute)CGDisplayIDToOpenGLDisplayMask(aDisplay), // atze: choosen screen
           (NSOpenGLPixelFormatAttribute)0
     };

     NSOpenGLPixelFormat* fmt = [[NSOpenGLPixelFormat alloc] initWithAttributes:attribs];
     NSOpenGLContext* nsContext = [[NSOpenGLContext alloc] initWithFormat:fmt shareContext:nsChareCtx];
    nsContext setView:nsView];
     else  // atze: here comes the fullscreen context
           [nsContext setFullScreen];
       
     // [nsContext retain]; atze: nsContext is retained already
       
     //fprintf(stderr, "      nsContext=%p\n", nsContext);
     return nsContext;
}
22  Java Game APIs & Engines / JOGL Development / Re: compiling jogl on mac os x on: 2004-06-19 12:55:08
never mind...

i had the antlr.jar in /Library/Java/Extensions - that was the error.
after removing it from that location it builds.
i consider this a bit strange....

and all those deprecation-warnings Smiley

atze

oh, i had to repair this:
java.compile:
   [javac] Compiling 91 source files to /Volumes/Data/Users/xxx/jogl/build/classes
   [javac] /Volumes/Data/Users/xxx/jogl/src/net/java/games/jogl/impl/macosx/MacOSXGLContext.java:177: deleteContext(long,long) in net.java.games.jogl.impl.macosx.CGL cannot be applied to (long,<nulltype>)
   [javac]       if (!CGL.deleteContext(nsContext, null)) {
   [javac]               ^
   [javac] /Volumes/Data/Users/xxx/jogl/src/net/java/games/jogl/impl/macosx/MacOSXDummyGLContext.java:113: destroy() in net.java.games.jogl.impl.macosx.MacOSXDummyGLContext cannot override destroy() in net.java.games.jogl.impl.GLContext; attempting to assign weaker access privileges; was public
   [javac]   private void destroy() {
   [javac]                ^
   [javac] Note: /Volumes/Data/Users/xxx/jogl/src/net/java/games/jogl/GLCanvas.java uses or overrides a deprecated API.
   [javac] Note: Recompile with -deprecation for details.
   [javac] 2 errors

this looks like an app-killer:
   [apply] src/native/jogl/MacOSXWindowSystemInterface.m: In function `updateContextRegister':
   [apply] src/native/jogl/MacOSXWindowSystemInterface.m:148: warning: no return statement in function returning non-void

this is wrong:
@implementation ContextUpdater
{
}

static NSOpenGLContext *theContext;
static pthread_mutex_t resourceLock = PTHREAD_MUTEX_INITIALIZER;

a) implementations don't have an instance-var block {}
b) static vars and function do not belong inside an implementation or interface.
23  Java Game APIs & Engines / JOGL Development / Re: compiling jogl on mac os x on: 2004-06-19 10:26:42
antlr: 2.7.4
ant: 1.6.1
jogl: cvs checkout today

same error.
day before yesterday i used Java 1.4.2_03, so that is not part of the problem.
jogl/doc/HowToBuild.html seems not enough if you can build it but i cant.

any special cvs ceckout-option the get that lastest? i just use
cvs update -d

help!!!
24  Java Game APIs & Engines / JOGL Development / Re: compiling jogl on mac os x on: 2004-06-18 16:58:03
is anyone here able to build jogl with 10.3.4 and java 1.4.2_04?

here's a verbose output of my problem:
[Loaded .... lots deletes ...]
[Loaded net.java.games.gluegen.cgram.CToken]
[Loaded .... lots deletes ...]
CharScanner; panic: ClassNotFoundException: net.java.games.gluegen.cgram.CToken

how is this possible?
25  Java Game APIs & Engines / JOGL Development / compiling jogl on mac os x on: 2004-06-17 20:04:05
i have all i need (ant, antlr, jogl). and now i am stuck here:

java.generate:
    [echo] Generating GL interface class
 [gluegen] CharScanner; panic: ClassNotFoundException: net.java.games.gluegen.cgram.CToken

BUILD FAILED
/Volumes/Data/Users/xxx/jogl/make/build.xml:1122: Following error occured while executing this line
/Volumes/Data/Users/xxx/jogl/make/build.xml:531: GlueGen returned: 1

any help?
26  Java Game APIs & Engines / JOGL Development / Re: animator causes blank white screen on: 2004-06-16 19:17:25
i'm having the same problem under MacOS X.
the vm-trick won't help me - i have no directx.

i get it running in a frame, but not in fullscreen. just a black screen.
display() is called. glFlush() and glFinish() do not help.

any idea?
27  Java Game APIs & Engines / JOGL Development / Re: GLContext from other classes on: 2004-06-16 15:34:59
the stupid questions of a newbie... when i hit the submit-button i found the answer:
i have to keep the canvas and just call display() on it after a tick() and everything works as i want - with the exception of uploading textures.

so the one question still is unanswered:
any way of talking to the context outside of display() to do some modifications to it?
28  Java Game APIs & Engines / JOGL Development / Re: GLContext from other classes on: 2004-06-16 15:25:41
hi there,
i have that same very problem. i need to control the drawing outside an animator, as i animate the objects by myself. not to mention that i upload textures when i need them - which is definitely not inside of display() or init().

i call tick() on all my objects, then draw() and finally i issue a glFlush() when i think my gl-calls are complete.
this is impossible with the current structure (as far as i can see).

is there any hook to get to that context and call a makeCurrent() or something equal when i need it?
or can i halt the gl-thread until i signaled all my objects to tick() and then have that thread display() once?
or - the best solution - can i just _not_ detach a new thread for gl and keep all the calls in my own thread?

jogl looks like what i need, but this is a heavy drawback for me, as i can not rewrite all my code. i know that one should not fight the api but use it.
any ideas welcome!
Pages: [1]
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

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

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

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

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

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (50 views)
2014-07-17 23:47:54

danieldean (42 views)
2014-07-17 23:41:23

MustardPeter (44 views)
2014-07-16 23:30:00

Cero (60 views)
2014-07-16 00:42:17

Riven (57 views)
2014-07-14 18:02:53
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!