RvEYoda

The current MFD was designed for the F-15 mostly yes, but Leavu2 itself could be used by any AC if you create some 3D instruments.

In fact i have 3 clients connecting to the same game machine here, at the same time ;). All running 30-50 fps data input/framerate. This can also be increased or set to the same as teh actual game framerate if you want to.

As long as it is detected as a normal "monitor" and you can drag windows to it, you can use it. You may want to disable the Leavu2 button-frame though, and just control it with keyboard commands.

You cannot disable the lua export script, only make sure each player has the same export script. The standard export script doesn't actually export any data (at all, it only shows how to do it), so there would be no data to be shared.

Maybe buy them a cake? Game integrity checks can be performed by the server on clients in the DCS engine, by checking the contents of files. You can add the export scripts to make sure it doesnt actually export any data at all. This can be troublesome when some servers use different mods. For this purpose I previously suggested it may be useful to develop a server browser tool that automatically sets up your game to match the requirements of each server. You were led to believe what and where and when? I have never said anything else about Leavu than what it is. I have not lied to you or anyone else about it. One has to wonder what the public response would be if I went and implemented a two seater mod for leavu that let user #2 control user #1's plane.

No, the datalink server is actually just a general server, It could probably be used as a dedicated game server, or a chat server. Leavu itself isnt really bound to lockon either. It can be used with lockon since I wrote a data export script using Lockon's data export functionality, as described here by ED : http://lockon.co.uk/index.php?lang=en&end_pos=567&scr=default Future purpose is to let them run with any sim, so I can create a cockpit working for multiple games. As a beta tester, Leavu has proven extremely useful for me in helping finding bugs in not just the lua export parts of the game, but also features of the game itself.

Someone has to create 3D or 2D graphics for it, then it would work fine.

Yes this is what I mean, Kenai chat is incredibly impractical. Much better to have a working IM, even if it is only from home :).

Could you explain to me how the Thread.yield works and why Thread.sleep(1) is better?

No, data export rate IS limited, I'm just saying it isnt an explicit frequency (time/second), but a minimum time interval between data batches. It should be capped, because I dont want to steal cpu time from lockon's single game thread, nor export faster than our monitor's update rate :)

How it works right now. The data batch rate can be capped ( by default 30-50 fps ). Lockon data rate is not locked to an explicit frequency! Instead it has a "minimum time before next update" and at least 1 lockon frame between updates. This is due to a lesson learned in lrm development. Lrm originally used coroutines for a fixed update rate, however this can cause major issues during normal game stutters ( the queued coroutine calls will then group up and make the stutter MUCH worse). Later LRM switched to a "per beforeNextFrame" system, which is also used by Leavu2 for data export. This has the drawback of not locking data export rate to a fixed interval ( only a minimum or maximum interval ), but this is compensated by processing teh data upon arrival. Lockon data export function luaExportBeforeNextFrame if currentTime - lastExportTime > minimumInterval then lastExportTime = currentTime; ExportData(); end end

I have been talking to Michael Bien ( one of the JOGL creators ) and it looks like the freeze issue is indeed JOGL-AWT related, and may be solved with JOGL 2.0 http://www.javagaming.org/index.php/topic,22075.msg182135.html#msg182135 If you check my sample you will notice the crash is demonstrated without any actual rendering ( or connection to the leavu project ) at all. It is just a short AWT app ( as in my previous post ). In Leavu2 : Displaying of graphics is already capped at monitor refresh rate. ( like you mentioned ) Vsync is already on to avoid tearing. Furthermore rendering is also limited so it only renders when new data arrives. The rendering thread waits until a new data batch arrives, then renders a frame. This frame is transmitted to the monitor intact asap ( with vsync ). An approach with a locked update rate is not good and I've tried it. It suffers because lockon transmits data at rates depending on its framerate. The latency will be poor because it is not synchronized with the data input rates. In fact I found quite a bit of bugs in the integrated features of Netbeans. However when I tried Eclipse I found even more issues so I went back to netbeans. The integrated SVN client of netbeans is complete crap though :P If we are going to work together, then please, can you not considering using an IM software? This forum posting, PMs, IDE chat is hopeless. It takes 2 weeks to complete 1 minute of discussing something :) I really appreciate your input but this type of communication is simply hopeless.

Found the cause of the bug It has nothing to do with LEAVU, the bug is caused by AWT-JOGL interactions. I wrote the following test program and it shows the same crashes once you create enough displays. This test program renders nothing, it just adds windows when you press a button, until it freezes, and isnt using anything except standard JOGL and AWT code. package joglscreens; import java.awt.Frame; import javax.media.opengl.GLCanvas; public class MainWindow extends javax.swing.JFrame { public MainWindow() { initComponents(); } @SuppressWarnings("unchecked") private void initComponents() { ...*auto generated code for the window*... } private void jButton2ActionPerformed(java.awt.event.ActionEvent evt) { Frame F = new Frame(); F.setSize(400, 400); F.add(new GLCanvas()); F.setVisible(true); } public static void main(String args[]) { java.awt.EventQueue.invokeLater(new Runnable() { public void run() { new MainWindow().setVisible(true); } }); } private javax.swing.JButton jButton2; } I have opened a thread on JOGL forums regarding this here: http://www.javagaming.org/index.php/topic,22075.msg182135.html#msg182135

Compared to what? Im not sure I've explained it clearly enough. There IS a limit to the upper frame rate rendered. Without that the program would try to render at the highest possible fps (1000... ?). But now it only renders a new frame when data arrives, which is capped by the lockon framerate ( unlikely to go above 100?) and/or a custom minimum time diff between frames. By default configured to what represents 30 fps, and would probably not be raised much higher than 60. If you limit rendering to screen update rate (also 60 fps), you should not gain any performance? I dont follow :( Code below from my custom OpenGL Animator class. while (true) { try { synchronized (this) { wait(100); } <-- Waits 100 ms or until notified ( by new data ) to render a single frame for (GLCanvas screen: screens) screen.display(); <-- Tells the openGL thread to render a frame } catch (Exception e) { e.printStackTrace(); } } } I added gl.glsetSwapInterval(1); to the init code of the Leavu2DRenderer class. It isnt going to hurt I guess Results Well I don't understand this at all. Im still rendering it at 30 fps fully smooth but the gl.glsetSwapInterval(1); cut the total CPU usage of leavu2 by almost 40 % :P. Must be some internal OpenGL thing! Thx Moa, can you explain why this helps even though I only call the OpenGL rendering thread at 30 fps ? It froze when I went above 67 mfds now. Shit I dont see why it should freeze :P Commited it to the repository update: The freeze when using a LOT of displays seems to be caused by Java AWT having problems with adding the GLCanvas to the gridbag of the gui window. It is likely, that if we do not use AWT and move to a 100% OpenGL based solution, that these problems would disappear. New tests I can add 200 GLCanvas objects no problem. I can add 200 AWT windows no problem. However if I add more than 40-50 GLCanvas objects each inside its own AWT Frame the program freezes, even if I have turned off the actual rendering to the GLCanvas objects and they arent doing anything This is also what one of my friends thought earlier..hmm. AWT and JOGL deadlock each other ? :P My friend also thought Swing would be even worse for it

Why should there be? If someone wants to update his instruments at 200 Hz, why not let him? :) Now that I think of it, there is already an upper limit set. I limited the data export rate to the framerate of lockon, so you cant go above that. Actually export depends on the "beforeNextFrame" function in lua, so this guarantees there will not be any issues with a lot of exports "queueing up" during a standard game stutter. The sim must produce at least 1 frame before another data batch is sent to Leavu2. Here is me feeding leavu2 at 30 Hz from FC2

You can chose yourself what rate the data is sent at. The display only renders when data arrives, only when something has changed. ( except for menu text ) Also if you want really smooth instruments, i recommend 50 hz data input rate which generates a completely smooth feeling imo. ( I run 30 though, I find it decent, it is just a number in the export script )

I provide arbitrary data input rates from lockon (default is 30-50 fps), and render the displays at the same rate that data comes :). I can use leavu radar screen with no latency from the ingame radar screen at all. There are 3 threads working. Thread 1 is the data receiving thread. When it detects a new set of data received, it notifies... Thread 2 updates the state of the instrments and then notifies the ... Thread 3, rendering thread, renders a frame! Basically Thread 1 does data receiving and pattern recognition, if the receive pattern is matched it sends the received dat sequence for processing. while (!toDie && (b = is.read()) != -1) { byte[] data = receiveBuffer.input((byte) b); if (data != null) { subscriber.process(data); Thread.yield(); } } } where the read-command is set to a 1.5 seconds timeout. ( more breaks the loop ) The "process(data)" call notifies Thread 2, where each instruments receives and processes the new data, and then decides what to place in its "rendering queue": while (true) { try { synchronized (this) { wait(100); } for (Instrument instrument : instruments) instrument.update(); animator.update(); } catch (Exception e) { e.printStackTrace(); } } and Thread 3 renders a frame with the current "rendering queue" of each instrument: while (true) { try { synchronized (this) { wait(100); } for (GLCanvas screen: screens) screen.display(); } catch (Exception e) { e.printStackTrace(); } } } Most models are rendered using automatically cached GLlists. ( display lists ) The first time they are rendered they use the glVertex3d(...), and the second call just uses the display list generated by call 1. If a previously generated display list is not used for one frame, I remove it from OpenGL's internal state.

If it allows for a chat lobby, then definitely! How do we connect it to the game ?

Jogl Already uses Java2d to render bitmapped text to textures. http://people.eecs.ku.edu/~miller/Courses/JOGL/jogl-1.1.1-docs/com/sun/opengl/util/j2d/TextRenderer.html I suggest you look into the TextRenderer source code. I have messed around with it a bit and made it a bit faster than the original, but it still is by far the slowest part of the program. ( my performance numbers above are with my optimizations, otherwise it's even slower ). I think we should rewrite the entire thing though. I have tried GLJPanel before, and it was unfortunately significantly slower in some situations. A pretty frame is not important at the moment :) Btw love ur scoring app design! Implementing new parts Moa maybe you could write a native JNI library for OSX and Linux that allows for keyboard detection? Either that or we use some built in java stuff, but for windows i had to use JNI since I want to detect keyboard input even when LEAVU2 does not have window focus. It will be called by the Keyboard class in its state updating function : /** * Used by internal thread to update the exposed state of each subscribed key */ private static final void scanKeyboard() { for (Key key : keysToScan) { boolean held = leavu.Win32.keyHeld(key.keyCode) < 0; key.hasBeenPressed = held && !key.isHeld; key.hasBeenReleased = !held && key.isHeld; key.isHeld = held; } } The native call here is "leavu.Win32.keyHeld(int)" In Windows I implemented the keyHeld function by using GetKeyState() JNIEXPORT jshort JNICALL Java_leavu_Win32_keyHeld(JNIEnv *env, jclass cls, jint keyCode) { return (jshort)GetKeyState((int)keyCode); } GLJPanel problems When set up to try a GLJPanel now for performance testing I get the following issue when resizing the window, so for now at least Ill stick with GLCanvas. Some geometric shapes below are missing and Text is completely scrambled after resizing a GLJPanel. It may be due to my TextRenderer Optimizations or my hacking of the Animator class.

Here is me playing datalinked to....myself! I have one instance of Leavu2 running as "Observer" (Obs) and one running as "Game Host" (Game). I was allowed to release this picture.

Questions to people with OpenGL experience and JOGL in particular: As some of you may or may not know, the performance goal of leavu2 is to be able to render above 100 instruments of MFD complexity simultaneously on the same computer. I conducted some performance tests on Leavu2, and I cannot quite reach my goal. ( can do about 50 ) I have tried to analyze where the performance problems come from, and have isolated 2 main causes, both caused by standard JOGL methods and classes ( not my own ) - So I've hit a bit of a wall here : 1. On average 70% of the CPU time consumed by LEAVU2 is caused by the JOGL TextRenderer class. It is very slow, and if we wrote our own alternative we could probably improve Leavu2 performance a lot! Does anyone know an alternative? This is mainly an issue with 2D text rendering ( as 3D text is not really required ). I'm even willing to go so far as to use simple geometric objects to create text. The text doesnt need to be pretty, only readable. 2. Much of the remaining 30% comes from the internal method calls after calling GLCanvas.display(). The GLCanvas does a lot of shit before calling GLEventListener.display(), and it is this stuff happening before GLEventListener.display() that takes time. As you probably know, the GLCanvas.display() is the basis for any JOGL application, so to replace it would require quite a bit of work. Solving just cause 1 would be enough to reach the overall LEAVU2 performance goals, but I believe if we work on both 1 and 2 we can make it almost 100 times faster, able to render several thousand MFDs simultaneously using only a single computer. I was really annoyed to see that it was the standard JOGL classes causing these issues, and not my own code ( which could be corrected much faster ).

In Open Falcon you can make aim54s do this regularly :), you end up dogfighting vs a phoenix!

Much of DCS is already using LUA to produce the game itself. LUA is a very fast language, and trigger-logging will likely produce much more overhead than a simple LUA export of position, and landing events are already written by default to mplog afaik. ( No need to do it twice ) The solution with least risk for stuttering should be to export this data not as files, but through sockets to a receiving program. Eliminate as much fileIO as possible imo, which has many orders of magnitude worse latency than a simple lua call ( which is already used by the game itself all the time ) You could even use your already present tacview scripts and grab the data on units from those, and you wont even need to call any extra LoGet-functions. ( Since tacview already does that )

So lets say we get a landing trigger, what trigger response to we set to it ?