 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?
|
|
|
|
|
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)  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); 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 |
|
|
|
|
10
|
Java Game APIs & Engines / JOGL Development / Re: Java for OpenGL API-Layer Discussion
|
on: 2004-07-08 10:05:29
|
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! ... 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)  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(); public OpenGLContext context(); 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 javaOpenGLCServer 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 citizenOpenGLServer 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.5a 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); |
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 contextthe 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. caveatsthe 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! |
|
|
|
|
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 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. |
|
|
|
|
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. 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. 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. |
|
|
|
|
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 |
|
|
|
|
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 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 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?
|
|
|
|
|
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!
|
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|
