Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (757)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (844)
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] 2 3
1  Discussions / Jobs and Resumes / Short Fuze is hiring! Software engineers needed to build Moviestorm. on: 2008-09-26 09:48:39
We're hiring at Short Fuze. Come join a small, friendly company in central Cambridge and help us make Moviestorm the killer 3D movie making application.

Find out about Moviestorm and whether it's your thing at:

Job description and stuff at:
Ideally we're looking for Java / OpenGL experts but talent, enthusiasm and a keenness to learn are just as important, if not more so.

Dave Lloyd
2  Game Development / Performance Tuning / Re: Extremely variable performance with the JIT on: 2007-08-08 10:24:02
erikd - the behaviour between the client and server jits is definitely different but nevertheless our app gets stuck at a low framerate with either.
I get the same behaviour within the ide (NetBeans in this case) and wrapped as a standalone binary.
We usually set the heap to 256M. It's possible this changes the behaviour but hard to tell.
Your question about the profiler is interesting as that always has the low framerate even when I've excluded all of the time critical classes from being profiled - I'm guessing that the profiler disables the JIT?

cas - are you sure jits are completely repeatable? Surely in a multithreaded app, some methods may clock up their 1500 invocations sooner than others and then (and I'm guessing here) they may be filling the queue to the JIT. Where should I be looking for alignment issues? Aren't nio buffers suitably aligned at allocation?

3  Game Development / Performance Tuning / Re: Extremely variable performance with the JIT on: 2007-08-02 13:32:46
Cas - it either ran at 4fps or 26fps for the duration. Occasionally (under unknown circumstances possibly involving minimising to desktop, possibly involving going and getting a cup of tea), occasionally it would transition from 4fps to 26fps which I put down to the JIT finally catching up.

Riven - nice to know I'm not the only one with JIT shaped bruises on my forehead. If I get any further with this I post a follow up here.

DzzD - I've been using the JDKs almost exclusively. If the JREs are different this just makes the nightmare worse Sad
Incidentally I don't really notice the difference in init time between the server and client vms but that could be because the init step is quite slow (lots of models to load).

Thanks all,
4  Game Development / Performance Tuning / Extremely variable performance with the JIT on: 2007-08-01 16:19:04

I've been tearing my hair out with some very wierd performance problems which I'm currently blaming on the JIT and was hoping was that someone might be able to shine some light on things.

Our Moviestorm application uses JOGL to render fairly complex scenes. We're using shaders, our character models are pretty rich and there's a lot of math to handle the animations and kinematics. The net result is that both the GPU and the CPU are pretty busy.

We've done various performance improvements recently (with much help from the wonderful NetBeans profiler) but kept coming across runs where the framerates varied wildly: one benchmark is a crowd scene with 20 characters varies from 4fps to 26fps!!

I currently suspect the JIT for several reasons:
(*) Setting the CompileThreshold really high mostly forces the framerate to be very low
(*) Choosing -server over -client with the same CompileThreshold gives 26fps vs 22fps
(*) Choosing JDK6 vs JDK5 gives 26fps vs 24fps
(*) Long load times frequently seem to result in low framerate

So I'm trying to get a handle on this - for our app we really need to guarantee that the user will see the high framerate - restarting it when it's stuck in low is not an option.

(1) Is there a limit to how much gets compiled - possibly being consumed by the early load stuff before the real work starts?
(2) Does the JIT compile methods in a queue and wait to avoid stealing too many cycles from the app  - resulting in latecomers being denied compilation?

Any other thoughts or suggestions for what we can do?

5  Java Game APIs & Engines / JOGL Development / Re: Blog: Easy 2D/3D Mixing in Swing on: 2007-07-30 21:52:40
It's been mentionned that the TextureRenderer might use the JOGL / Java2D bridge. Any idea if/when that might happen?
6  Discussions / Jobs and Resumes / Wanted: Java Engineers, England on: 2006-10-23 18:51:53
Short Fuze is looking for experienced Java programmers to help build our Moviestorm product - find out more at We need expertise in Swing and user interface construction, Open GL, shaders, core engine design, movie editing, animation etc.

We are also looking for server engineers with experience in developing JSP & Servlets and maintaining Tomcat systems to help build and maintain the Moviestorm community servers.

We're a small Cambridge start up but we are well funded with excellent investors and looking to grow fast. Join us now and get in at ground level with plenty of opportunity to have a defining role in the growth of the company and the development of Moviestorm.

Salaries commensurate with experience and generous share options (IR approved) .

Contact Dave Lloyd ( for more details
7  Java Game APIs & Engines / JOGL Development / Re: Confused about GL contexts and texture loading... on: 2006-05-13 14:53:18
Excellent - that'll make things a lot easier!
8  Java Game APIs & Engines / JOGL Development / Re: Confused about GL contexts and texture loading... on: 2006-05-13 14:06:38
Thanks, Ken. Does that mean texture sharing works with pbuffers? Or only depending on OpenGL implementation? If the latter, how does one tell whether the local texture shares textures IDs? I have some places where offscreen rendering would be very useful, but I'm currently reusing the main frame buffer to avoid reloading textures - perhaps unnecessarily.
9  Java Game APIs & Engines / JOGL Development / Confused about GL contexts and texture loading... on: 2006-05-13 12:28:29
I've got myself a bit confused about GL contexts with JSR-231 and was hoping the good people here could help me:

The general tactic used in a lot of the utility code seems to be to the current GL from GLU.getCurrentGL () rather than passing it around. This is particularly the case in the JOGL utility code supporting Textures which I'm looking to move to.

However applications may end up using distinct GL contexts particularly if PBuffers are used. In this case textures loaded in one context are invalid when used in another context. In the past I have keyed texture IDs off GLDrawable/GLAutoDrawable.

What is the preferred pattern these days? Should I have a texture wrapper class that keys from GL (or GLAutoDrawable or GLContext...) to com.sun.opengl.util.Texture or extend Texture to handle keying ID to context internally? Or avoid having multiple contexts like the plague...?
10  Java Game APIs & Engines / JOGL Development / Re: GLSL and getAttribLocation on: 2006-05-08 20:53:40
11  Java Game APIs & Engines / JOGL Development / GLSL and getAttribLocation on: 2006-05-08 14:38:30
Slightly offtopic, but how fast are the GLSL variable location enquiry functions such as getAttribLocation () and getUniformLocation ()? Should I be caching the results for performance or does it not make much odds. I'm presuming at the least that the bytes of the string are not copied across to JOGL but I'm aware that some GL enquiry functions can have significant overhead.
12  Java Game APIs & Engines / JOGL Development / Re: color coded picking on: 2006-05-08 14:34:39
Thanks Riven! I don't have many names - typically only one or two per object (and that might be 3-5000 tris) with a scene with maybe 100 objects max (I'd read that lots of names could be a problem). But if the selection rendering itself is slow that would explain much. I'll have to try redoing the selection code to use colour picking.
13  Java Game APIs & Engines / JOGL Development / Re: color coded picking on: 2006-05-08 10:25:46
Basically you don't use select mode anymore.

Interesting! Would someone enlighten me as to why?

I do use select on scenes with lots of tris and have been wondering about it's performance. Most of my crashes seem to occur in glDrawElements in select mode as well... I would've expected select mode to be efficient as you don't need to do real painting. It's also useful to get the name stack out (Object ID, Subobject ID) and occasionally to see items behind the front tri...
14  Discussions / Jobs and Resumes / Re: Wanted: Java / OpenGL engineer on: 2006-05-05 19:11:46
Thanks Jeff! (You might recall that we met when I was at nGame and we were on Sun's stand at GDC)

We have just hired a chap for this role, but I hasten to add that we're stil looking for further members of the dev team over the next six months. So even if you're reading this ad a few months from now, please email me as dave at shortfuze dot co dot uk.
15  Java Game APIs & Engines / JOGL Development / GLCanvas and keyboard focus with Mac Os on: 2006-04-21 16:43:58
We've been porting our app to Mac Os this week and apart from a few minor issues, the main hurdle we have hit involves differences between how keyboard focus is handled on Windows and Mac.

The basic structure has a GLCanvas as the content pane of a JFrame with a 2D control panel laid over it. On Windows, the keyboard events correctly go to the appropriate controls but not on a Mac. The mouse events work fine however. As a debug we've been printing out the current focus owner as reported by the KeyboardFocusManager whenever a mouse click is received (and after the mouse event has been handled). On Windows it reports the components as expected, but on the Mac it is always null.

Can anyone tell me what differences there are between Windows and Mac in this area? Is this a difference in behaviour between the implementations of GLCanvas?

16  Discussions / General Discussions / Re: Generic OpenGL UI Project? on: 2006-04-20 16:48:51
Hey, Dave ! Since the last time I read something on Fuze3D (on ShortFuze) I thought you were almost dead.. Is Fuze3D still active ?

Hiya! Yup and its the basis of our great new application (to be announced later in the year). When I get some time away from the main app I'll be updating the Fuze3D package (which we are of course keeping open source) - but that won't be until late summer I'm guessing now.
17  Java Game APIs & Engines / JOGL Development / Re: crash with Intel 855GM on: 2006-04-19 17:20:49
IIRC the Intel graphics shares memory with the main system. If your memory is slightly dodgy I wouldn't be surprised if OpenGL shakes things up. You might want to try memtest86 and leave that soak testing. It usually finds problems. A while back I add some more RAM and had occasional BSDs every day until I ran memtest and found the ram was suspect. Different stick of ram solved the problem (both apparently identical spec tho different manufacturers).
18  Game Development / Newbie & Debugging Questions / Re: Can a Swing GUI be used in a direct-rendering game? on: 2006-04-11 13:35:22
For my Swing menus I have only had deadlocks a couple of times, but the JTextFields I use reliably cause AWT Event thread deadlocks when I type or delete characters.  What kind of Swing components are you using in your game?  Maybe it only works because you use simple components which rarely cause a dead-lock with your game thread.
I think I'm using virtually every Swing component known somewhere or other! Not everything works quite as expected (JOptionPane is a big no-no) but mostly it does. All my painting etc is done ultimately under the JOGL display () method which I suspect is in fact on the EDT.
19  Game Development / Newbie & Debugging Questions / Re: Can a Swing GUI be used in a direct-rendering game? on: 2006-04-11 12:51:53
Yep, Swing on JOGL works fine for me. Ignore repaints and repaint the swing parts afresh each frame.
20  Java Game APIs & Engines / JOGL Development / Re: Render loop is creating a lot of garbage with JOGL on: 2006-04-11 12:48:52
try to allocate objects outside display(..) or inner loops and REuse them.
Yuck! Sorry but that would make for really foul code having to carry all that scratchpad for JOGL. And given the rest of the heap traffic in my app (cos any real game will play with some big and complex data structures) the JOGL traffic must be lost completely in the noise.

Trust the garbage collector - particularly when it comes to high turnover of short lived young generation stuff. There's a lot of FUD about GCs (and I've been using GC'd languages for <cough> 20+ years now) and it's only really where you need realtime hardware response that avoiding GCs is advantageous and only because of its asynchronous nature.
21  Discussions / General Discussions / Re: Generic OpenGL UI Project? on: 2006-04-11 12:42:50
Quoth Princec:
Swing and AWT (or even SWT) doesn't mix too well with the game rendering and input model (which is continuous).

Well YMMV but I'm having a lot of success building a very rich game UI using Swing on JOGL. There are some differences - mostly since the UI gets repainted every frame some of the repaint logic is pretty redundant for example - and some annoyances to do with lightweight vs heavyweight - worst examples being anything modal (Swing has some really dumb legacies cos it's all descended from AWT - they really should have been parallel hierarchies).

However that aside, being able to design complex HUDs in NetBeans with the lovely NetBeans forms editor is just brilliant. All the advantages of Swing - peering and the ability to completely customise look, feel and even deep behaviour - allows you to use desktop widgets that look and act completely gamey particularly. These are wheels I'd hate to reinvent.

Hopefully in about 6 months or so when the product launches you'll be able to see for yourselves  Wink

What I think we should be doing is persuading the guys at Sun to give us a lightweight Swing that only needs an input event queue and an output Graphics and has other no dependencies on AWT, native windows etc etc.
22  Discussions / Jobs and Resumes / Wanted: Java / OpenGL engineer on: 2006-03-28 11:55:59
Short Fuze is looking for a software engineer with Java and OpenGL experience:
  • Strong maths, physics, engineering or comp-sci background essential
  • Recent experience on a PC or console game title an advantage.
  • Should be based in Cambridge or its surroundings and must have the ability to work from home, both in terms of motivation and a suitable home office environment
  • Salary subject to negotiation depending on experience and ability.
  • The company operates an approved share option scheme.
This is an opportunity to join a start-up at ground level and get involved in something big.

Short Fuze is a small, but highly innovative Cambridge-based start-up company working in the emerging field of machinima - the use of technology developed for computer games to make low-budget films. The founders and management are recognised experts in machinima, as well as experienced entrepreneurs, and the company is funded by NESTA, GEIF, CREATE and the Cambridge Angels. The company's vision is to spark a worldwide revolution in movie-making. Short Fuze is a member of the Academy of Machinima Arts & Sciences.

Please reply to dave at shortfuze dot co dot uk
23  Java Game APIs & Engines / JOGL Development / Re: Simple Java2D drawings over a GLCanvas/GLJPanel problem on: 2006-03-27 09:55:07
when i updated jogl with the most recent version, i got several compilation errors asking for a further argument
in most of OpenGL commands. For example:

gl.glVertex3fv( float[] posiiton,  int index);

What is this second number??!?
This is the new offset parameter now required by many calls that take an offset parameter. See the sticky topic on migrating from jogl 1.1.1 to jsr-231 for that and other changes that might be required.
24  Java Game APIs & Engines / JOGL Development / Re: Another problem with glDrawElements () on: 2006-03-23 16:14:38
Hmmm. I've set my GLCanvas to use DebugGL - not a squeak. As far as I can tell, all is good before the call to glDrawElements. But I'm still getting this periodic crash. More often than not it's in select mode when that happens but not always. (It feels like it always crashes after a mouse click, but not sure.)

Any further suggestions for tracking this down?
25  Java Game APIs & Engines / JOGL Development / Re: Experiences of migrating from JOGL 1.1.1 to JSR231 on: 2006-03-23 11:21:20
Please never  integrate any math package into GL/GLU directly. There are lots of diffrent math packages out there, and doing that would favor one. IMHO that's no ok, even for javax.vecmath since OpenGL is math api independent.
I'm sorry, but I couldn't disagree more! The greatest strength of Java is its broad and consistent set of APIs. When you have a task in front of you, unlike with C++, you don't have to choose between half a dozen different APIs (e.g, STL or MFC? Just for lists and things), there is just one that all other packages work cleanly with. The real bane for me with 3D is that when I work with some new software package the odds are that it uses a different vector package (GLEEM uses its own for example) and all of a sudden I do not have portable code. Remember: write once, run anywhere!

Vector algebra is a real basic of what we're doing here. Perhaps we need the JCP to reexamine the javax.vecmath package (which I agree is sufficient but not very useable - though Java's lack of user defined operators doesn't help there).
26  Java Game APIs & Engines / JOGL Development / Screenshot - RFE on: 2006-03-20 16:16:14
It would be very useful if the Screenshot class could select any screen rectangle. Thus the core method would have the following signature:
public static BufferedImage readToBufferedImage (int x, int y, int width, int height, boolean alpha) throws GLException;
27  Java Game APIs & Engines / JOGL Development / Another problem with glDrawElements () on: 2006-03-16 19:17:14
I'm getting a random (1 in 20 or less) VM crash in glDrawElements (). I do not believe this is the same problem as mentionned in the sticky thread as I had it with the old 1.1.1 JOGL as well.

Here's the dump I get:
# An unexpected error has been detected by HotSpot Virtual Machine:
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x3d384a41, pid=2892, tid=1996
# Java VM: Java HotSpot(TM) Client VM (1.5.0_02-b09 mixed mode, sharing)
# Problematic frame:
# C  0x3d384a41

---------------  T H R E A D  ---------------

Current thread (0x0310e3b0):  JavaThread "AWT-EventQueue-0" [_thread_in_native, id=1996]

siginfo: ExceptionCode=0xc0000005, reading address 0x02f8e000

EAX=0x3da9ea24, EBX=0x036a00c0, ECX=0x00002400, EDX=0x03200004
ESP=0x0361f2e0, EBP=0xbf800000, ESI=0x02f8e000, EDI=0x00000000
EIP=0x3d384a41, EFLAGS=0x00210202

Top of Stack: (sp=0x0361f2e0)
0x0361f2e0:   0000003f 036a00c0 00000008 00000675
0x0361f2f0:   3d0a8a42 036a00c0 3da9e7e0 031fffb8
0x0361f300:   032000b4 031f7000 00000004 00002aa2
0x0361f310:   0000003f 3d3849d0 3d0a939b 031fffb8
0x0361f320:   00000000 00000004 00001405 036a00c0
0x0361f330:   031f7000 00002aa2 3ceabf9e 3d920c80
0x0361f340:   00000004 00000000 ffffffff 00002aa2
0x0361f350:   00001405 031f7000 0361f380 0310e3b0

Instructions: (pc=0x3d384a41)
0x3d384a31:   10 8b 7e 08 89 78 14 8b 35 cc 65 6a 03 8d 34 ce
0x3d384a41:   8b 3e 8b 6e 04 89 78 18 89 68 1c 83 c0 20 3b 54

Stack: [0x035e0000,0x03620000),  sp=0x0361f2e0,  free space=252k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x3d384a41

[error occurred during error reporting, step 120, id 0xc0000005]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J  com.sun.opengl.impl.GLImpl.glDrawElements0(IIILjava/lang/Object;I)V
J  com.sun.opengl.impl.GLImpl.glDrawElements(IIILjava/nio/Buffer;)V
J  fuze3d.geometry.GeometryBuffer.draw(Ljavax/media/opengl/GL;I)V
J  fuze3d.animation.ms3d.MS3DModel$MaterialShader.draw(Lfuze3d/scenegraph/SceneView;Lfuze3d/geometry/Geometry;)V
J  fuze3d.scenegraph.Shape3D.renderObject(Lfuze3d/scenegraph/SceneView;)V
J  fuze3d.scenegraph.SceneObject.render(Lfuze3d/scenegraph/SceneView;)V
J  fuze3d.scenegraph.SceneObject.display(Lfuze3d/scenegraph/SceneView;)V
J  fuze3d.scenegraph.Group.display(Lfuze3d/scenegraph/SceneView;)V
J  fuze3d.scenegraph.Group.display(Lfuze3d/scenegraph/SceneView;)V
v  ~RuntimeStub::alignment_frame_return Runtime1 stub
j  fuze3d.scenegraph.ViewSpecificGroup.display(Lfuze3d/scenegraph/SceneView;)V+42
J  fuze3d.scenegraph.Group.display(Lfuze3d/scenegraph/SceneView;)V
J  fuze3d.scenegraph.Group.display(Lfuze3d/scenegraph/SceneView;)V
v  ~RuntimeStub::alignment_frame_return Runtime1 stub
j  fuze3d.scenegraph.SceneView.render()V+646
j  fuze3d.scenegraph.SceneCanvas.display(Ljavax/media/opengl/GLAutoDrawable;)V+56
j  com.sun.opengl.impl.GLDrawableHelper.display(Ljavax/media/opengl/GLAutoDrawable;)V+29
j  com.sun.opengl.impl.GLDrawableHelper.invokeGL(Ljavax/media/opengl/GLDrawable;Ljavax/media/opengl/GLContext;Ljava/lang/Runnable;Ljava/lang/Runnable;)V+132
j  java.awt.event.InvocationEvent.dispatch()V+11
j  java.awt.EventQueue.dispatchEvent(Ljava/awt/AWTEvent;)V+26
j  java.awt.EventDispatchThread.pumpOneEventForHierarchy(ILjava/awt/Component;)Z+200
j  java.awt.EventDispatchThread.pumpEventsForHierarchy(ILjava/awt/Conditional;Ljava/awt/Component;)V+26
j  java.awt.EventDispatchThread.pumpEvents(ILjava/awt/Conditional;)V+4
j  java.awt.EventDispatchThread.pumpEvents(Ljava/awt/Conditional;)V+3
v  ~StubRoutines::call_stub

---------------  P R O C E S S  ---------------

Java Threads: ( => current thread )
  0x033ace30 JavaThread "Java Sound Event Dispatcher" daemon [_thread_blocked, id=3368]
  0x0306bf58 JavaThread "TimerQueue" daemon [_thread_blocked, id=3008]
  0x031b5008 JavaThread "Thread-3" [_thread_blocked, id=2872]
  0x009f3b00 JavaThread "Timer-0" daemon [_thread_blocked, id=3296]
  0x02fbe760 JavaThread "Java2D Disposer" daemon [_thread_blocked, id=1036]
  0x00237fe8 JavaThread "DestroyJavaVM" [_thread_blocked, id=2880]
=>0x0310e3b0 JavaThread "AWT-EventQueue-0" [_thread_in_native, id=1996]
  0x03099d10 JavaThread "AWT-Shutdown" [_thread_blocked, id=3072]
  0x030a5b38 JavaThread "AWT-Windows" daemon [_thread_in_native, id=1908]
  0x0099ed58 JavaThread "Low Memory Detector" daemon [_thread_blocked, id=3232]
  0x0099d908 JavaThread "CompilerThread0" daemon [_thread_blocked, id=3224]
  0x0099cbc8 JavaThread "Signal Dispatcher" daemon [_thread_blocked, id=2316]
  0x0099adb8 JavaThread "Finalizer" daemon [_thread_blocked, id=2896]
  0x009998a0 JavaThread "Reference Handler" daemon [_thread_blocked, id=2576]

Other Threads:
  0x00997018 VMThread [id=1984]
  0x009a02f0 WatcherThread [id=2476]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

 def new generation   total 10240K, used 7130K [0x16aa0000, 0x175b0000, 0x17e50000)
  eden space 9152K,  74% used [0x16aa0000, 0x17143b38, 0x17390000)
  from space 1088K,  30% used [0x174a0000, 0x174f2de0, 0x175b0000)
  to   space 1088K,   0% used [0x17390000, 0x17390000, 0x174a0000)
 tenured generation   total 135544K, used 115850K [0x17e50000, 0x202ae000, 0x26aa0000)
   the space 135544K,  85% used [0x17e50000, 0x1ef729e8, 0x1ef72a00, 0x202ae000)
 compacting perm gen  total 8192K, used 7323K [0x26aa0000, 0x272a0000, 0x2aaa0000)
   the space 8192K,  89% used [0x26aa0000, 0x271c6df8, 0x271c6e00, 0x272a0000)
    ro space 8192K,  66% used [0x2aaa0000, 0x2aff88a8, 0x2aff8a00, 0x2b2a0000)
    rw space 12288K,  46% used [0x2b2a0000, 0x2b834818, 0x2b834a00, 0x2bea0000)

Any suggestions for how I might attack this? I've tried most things I can think of and got nowhere so far....
28  Java Game APIs & Engines / JOGL Development / Re: Problem with ATI Radeon 9200 on: 2006-03-16 10:50:16
Ken - I'll try Gears and get back to you (it's actually on one of our investors' machines...) Does that mean that if the ATI driver can't support the required capabilities it falls back on the Microsoft implementation (i.e., the most restrictive!).

JavaJeff - Haven't tried removing opengl32.dll, but we have put the very latest ATI drivers on the machine. I'll let you know if that fixes it when I can get to the machine in question.
29  Java Game APIs & Engines / JOGL Development / Problem with ATI Radeon 9200 on: 2006-03-15 23:37:34
I've just made the jump from JOGL 1.1.1 to JSR231 and one of the problems I was hoping to solve was an issue with an ATI Radeon 9200 where it only found the Microsoft 1.1 driver.

However this persists and I was wondering whether anyone had a clue what might be wrong with my app or with the GL driver installation.

I've used GLView on the machine and it finds the correct drivers:
Vendor: ATI
Version: 1.3 WinXP Release

Whereas my app reports:
Vendor: Microsoft
Version: 1.1.0

I can't think why the two apps would see different GL drivers. Is there anything peculiar about choosing capabilities that I'm missing?

30  Java Game APIs & Engines / JOGL Development / Re: Render to Video on: 2006-03-15 11:41:04
Thanks for the advice. JMF is indeed proving to be very cruddy. It's a real shame that Java is not better supported in this regard - one of the very few areas where I've actually felt let down by the APIs.

Ho well, the native route it is going to have to be....
Pages: [1] 2 3
EgonOlsen (45 views)
2018-06-10 19:43:48

EgonOlsen (25 views)
2018-06-10 19:43:44

EgonOlsen (47 views)
2018-06-10 19:43:20

DesertCoockie (202 views)
2018-05-13 18:23:11

nelsongames (127 views)
2018-04-24 18:15:36

nelsongames (126 views)
2018-04-24 18:14:32

ivj94 (867 views)
2018-03-24 14:47:39

ivj94 (128 views)
2018-03-24 14:46:31

ivj94 (771 views)
2018-03-24 14:43:53

Solater (143 views)
2018-03-17 05:04:08
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 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‑
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!