Moa

I have been looking at this for a while (as "one of the people in the 104th"). In fact it is one of the reasons I started my own stats project. Exporting directly from LO via socket to external application seems best for DCS/FC2. Reading the debriefing file is a pain as it is not self-contained as in FC1 (LockOn: Flaming Cliffs 1.x). You also have to parse the mission file to resolve the unit identifier to the unit type. Plus all the other resources need to resolve class IDs to files containing LUA tables. In the mission debrief file I could see no mention of the name of the mission file used. I consider this a design defect from the point of view that you must use external information to tie the debrief log to the mission that was run. No wonder no-one has done BS stats yet despite it being out for a year. The natural language to do this in is LUA, but a decade of using scripting languages (mostly Perl and csh, not much Lua) I now have an aversion to them since the compilers and tools are so weak that you don't get much help to kill bugs that a decent compiler will catch as you are typing. Scripting languages appear faster to develop in but once your project gets big they are actually slower in my experience due to the extra manual work involved in getting an extended source base consistent without compiler support. I had started doing the parsing of BS mission files in Java. A dynamic campaign is a big undertaking and IMHO you need a more powerful language and tools to make it work nicely (as in, to a war simulation level, not just a 'looks about right' level) than lightweight LUA. Java is also good because it lets us run dedicated servers on platforms other than Windows (I have a few spare older machines about that can run Linux fine but suck for Windows).

"bird ingestion" = when a bird gets sucked into your engine and causes an engine failure. Has a hugher probability when flying low (takeoff/landing, nap-of-the-earth).

Wow! that map is excellent. Yes, as an earlier poster said, PNG format is compressed and much better for 'line art' than JPEG. JPEG is designed for photographs only, with anything else it creates visual artifacts that ruin this superb map).

The VNAO (public) mod is available from LockOnFiles - although it is a little hard to find. You can also download the mod directly from the link on the VNAO forums page (top right): http://www.virtualnavairops.com/forum/phpBB4/index.php Make sure you make a backup of your "Air Force" LockOn before installing the "Navy" LockOn. The VNAO mod contains: F-14D and F/A-18 F meshes replacing Su-33 F-16 replacing MiG-29 Carl Vison that can be landed on.

Thanks Aeroscout. Actually, I'm the one working on texture mapping - Yoda is hard at work on the other bits. So I'll ping you with a 104th message (since we're both Phoenix members).

Hi Aeroscout, Those textures look wonderful. Would you mind if I used them as part of some texture-mapping work I'm doing for =RvE=Yoda's LEAVU2 project? if you permit this then some of those textures might even get promoted to 3D controls. http://forums.eagle.ru/showthread.php?t=42942&page=66 Thanks, Mike

Thanks Acedy & Crunch, I now have some free time to delve into those scripts.

My understanding is that yield is advisary only, and might not do anything, and if it does yield then the process continues to run and may immediately re-schedule the yielded thread. Thus, the CPU remains in use, although the thread within the process may change. Sleep makes the thread sleep which relinquishes the CPU. The O/S scheduler may then allow other processes to run, or may reschedule the process if no one else needs it. The CPU does not remain in use by your program (letting other processes complete their tasks). I wonder if the sleep() problem you observed is actually related to the locking problem you were seeing? ps. I've been on kenai chat for a while :)

Copy.

Yes, I agree LockOn data rate should not not capped in any way (I must have been unclear about this). What I was suggesting is that the "Data process and frame generation events" be limited to vsync. Doing it any faster makes no difference to screen, only to CPU usage. That's great news about JOGL 2.0 fixing that locking problem. The other suggestion they made was to use one context - which I also suggested and can explain to you if you want (although managing the sub-windowing would be a pain).

IM yes, but due to me being almost exactly on the other side of the Earth I am at work while you are up. Since I'm consulting at a client site I can't get the IM out through their firewall. I do jump on Leavu2 kenai though from time to time to see if you are there. Using double buffered all we'll be doing when LockOn data arrives is updating the back buffer (burning CPU/GPU time) at a rate faster than the buffers are swapped.

The magnetic poles are precessing completely normally. They always wander around. What is being watched is what the magnetic field of the Sun is doing, since it is unusually quiescent at the moment.

Yoda it is not so much an internal JoGL/OpenGL thing, it is normal high performance programming. Remember for smooth display we don't need a frame rate any higher than the monitor's display rate, we actually need *low latency*. By telling JoGL to render at the monitor speed we're doing several things: 1) Not doing any more work than we absolutely have to (even if we did more a human cannot notice). 2) Telling JoGL that it's ok to let the rest of the system have some time too. 3) Avoiding tearing in the display when a refresh coincides with a vsync. Of these, number 2 probably makes the most difference. If we hog all the CPU then the rest of the system can't run, and eventually the O/S decides that it's time to take over and takes control from your app and lets all the pent up tasks in the system run. In that case it can be inconvenient when the rest of the sytem runs and you miss a vsync update, which makes your frame rate drop to less intermittently. If the rest of the system gets plenty of chances to run (eg. clear I/O etc) then the chances are that when Leavu needs the CPU it'll get it. I notice you do a thread yield in places, which is good, but is advisary only. It would be much better to use: Ok, with regard to locking. It may be a legitimate deadlock but more likely something is blocking the Event Dispatch Thread (EDT) - which is required by the Animator to call display(). I notice some of the code is EDT aware but some is not. If you are doing any Swing operation (eg. calling a JFrame method that creates any events) then you must use SwingUtilities.invokeAndWait or invokeLater I don't think your friend is right. If the application was Swing then it would probably run more smoothly, not less. After Java .6.0_u10 *all* Swing rendering uses JoGL (or DirectX on Windows). If you are using JoGL on top of JoGL Swing then things get simpler for it (it doesn't have to lock and unlock native resources all over the place). Plus, as I said before Swing allows much nicer effects and resizes properly. Also JoGL was multi-threaded and was found to be slow due to lock contention, by making it single-threaded it was found to be faster, but between multiple instances we might still be suffering from contention a bit (not much we can do about it - unless you want to try doing a partially transparent full screen app that renders all 100 panels). nb. FindBugs tool can help find possible thread problems (mostly unsynchronized resources). It is conveniently packaged for NetBeans at the following site (aren't you glad you're using NetBeans :)): https://sqe.dev.java.net/ Also, I haven't checked the leavu2 code (I'm at work now) but using glOrtho projection might speed things up for the leavu 2D rendering, since it doesn't have to do perspective projection calculations. You may already be using it. Tonight I'll be looking at loading images as textures and rendering them. If we can pre-render the background of each display (onscreen menu items etc) and then only render the selected one then we might get another little speedup.

Been profiling stuff and trying different options. I noticed that limiting the refresh rate to the monitor VSync rate dropped CPU usage a lot (which might get you more simultaneous instances). The JoGL command to do this is: gl.setSwapInterval(1); I couldn't see it used in any of the four LEAVU2 NetBeans projects. So perhaps give that a go and see whether it does what you want. Something else that can be tried is the use of an OpenGL profiler. I have not used one myself but I hear they're good for finding pipeline stalls and seeing whether you are fill-rate limited (which I suspect you may be given your already high frame rates and large number of rendering surfaces).

Thanks for the vids. They are very impressive, especially the second one in dimmed light. Ok, no upper limit on frame rate apart from that imposed by export.

Data rate can be anything. This is not the problem. Do you think there ought to be an upper limit to the display refresh rate or should it be unlimited? ('No' is an ok answer, but 'yes' would be better)

"lol yea 120 F degrees durring the summer..." There, fixed that for you (this is an international forum after all :)). Do you still notice the same speed-up over the big cities? If so then the driver is definitely worth getting (I have some Nvidia-equipped machines but am quite slack at updating since I usually get sucky speeds over cities no matter what the driver).

Thanks. I haven't looked over all the new code so some of my questions won't be relevant. I can understand refreshing LockOn faster than 30 Hz but can't understand why mostly static text would need to be refreshed faster than this. You can refresh the model data at any speed, it's just that you might as well sync updates to the refresh of the display (whatever rate that is) or whatever rate humans would notice (which is probably 3ms for most LCDs that have persistence that limits all visible changes to be slower than this). I'm just wondering if we run faster by eliminating unecessary work (that is one way to optimise, the other is to do things more effiicently but that usually reaches its limits sooner).

Oh yeah, what does the refresh rate of the application need to be? 30 Hz? 60 Hz? unlmited? Seems inefficient to re-render information that is updated from Lua at around 10 Hz. Perhaps we could update a buffered display texture no more than 30 Hz. Would allow more screens to be rendered.

Yes, but there are no guarantees as to what is cached and what is not. I was suggesting pre-rendering to BufferedImages and then simply copying those buffered images to your graphics context. That way you are only doing a bit-blit and then you are only fill-rate limited. This technique can be used for all the static text and images in the application (which is acually quite a lot, they don't change shape mauch, just position). I'll be trying this out tonight when I get home from work. Thank you very much. With Swing you can use gradients and a whole bunch if existing effects to make everything look nice. Maybe using GLCanvas in a Swing app might be an good idea - plus it might better solve the layout issues. I'll take a look. On Linux and Mac the window needs focus to get keyboard input, but that's ok since LockOn can't run directly on those platforms anyway. Better to try and use the facilities Java has rather than do JNI.

The Leavu2 Datalink host runs on my new 17" MacBook Pro. Nice work Yoda. I'll try running the other programs and take a look at them. Incidentally, the "Compile on Save" option in the project properties might speed up your development a little. Edit: Leavu starts on OS X too, and client and server can talk.

Have you profiled the time to use Java2D to write a font? It may be faster than JoGL since JoGL likely uses GLU to write fonts - which is probably done in software, where-as all of Java2D after JRE 1.6.0_u10 or later are done in hardware. You would render the text to a BufferedImage and then texture map the buffered image into your target. Ok, it's my bad since I haven't provided the texture map code to you yet. If you don't want perspective correction then rendering the texture as a billboard is easy. That may solve one part of your performance problem. For the second problem I'd suggest switching references to GLCanvas to GLAutoDrawable. Then at run-time decide whether to use GLCanvas or GLJPanel. GLJPanel used to be slower but it might not be any more. I find Swing faster than AWT these days (plus it is more powerful, easier to use, and much nicer looking with Nimbus - check out the look of my scoring applet at http;//stallturn.com/scores/ for an example). The other thing that can be done to speed things up is to cache textures etc that haven't changed and re-use them (yes, again my bad for not giving you the texture mapping code yet). Drawing symbols with textures rather than vectors is very fast, since consumer graphics hardware is oriented more for texture processing than anything else. Also, it's quite hard for us to contribute fully since we don't have Lockon 2.0, so much of Leavu2 doesn't work for us (well, me at least). This means we can only integrate stuff up to a certain point and then we can't test past that :(

Very nice. Thanks for the work compiling this list.

Hi Topol. According to Wikipedia article number of Flankers of all types in service is 680, of which 449 are in Russian service. Doesn't say how many are Su-27SM, but it would be smaller than this. For reference, wikipedia gives approximate numbers of F-16 as 4500+, F-15 as 1198 (630 remain in US use), F-18 as 1480 (A-D), F-18 E/F 400, MiG-29 as 1600+.

Yes. The excellent site for Battlefield 2, http://www.bf2s.com was my inspiration. Yoda, that is an excellent idea. I have a real-time TacView data parser but I have found it to be erroneous sometimes so never integrated it into my stats system. Are the direct export functions reliable or are they sometimes wrong (is the fauklt due to the exported data or TacView's interpretation of it)?