RvEYoda

I use the JOGL built in class TextRenderer. It does that stuff for me (keeps a cache as a set of dynamically changing preloaded textures of rendered strings) , but has serious overhead problems :P. Not efficiently written. I am trying to get some more answers about it in jogamp forums (see http://forum.jogamp.org/Which-JOGL-TextRenderer-should-I-use-tp3199861p3199861.html;cid=1311671711804-713). If you got some text rendering class for JOGL 2 that is fast, then I'd love to use it :). However it does feel good to know that at least my code is fast, and the limiting factor is JOGL and opengl itself (the two heaviest things being glDrawElements and textrendering) With text rendered I am getting about 2200-2500 fps, and if I remove my text (just rendering geometry by commenting out tr draw3d and flush calls) I get ~ 8000 fps

Cool. Pm me your MSN details and ill contact you

Alright now using VBOs and checked some other stuff. Profiled again and the jogl TextRenderer now takes up about 70% of the entire cpu time spent during one OpenGL display iteration. Out of the remaining 30% rendering VBOs takes up about half and the rest is other minor stuff. So if performance is not good enough now well...Someone write a new text renderer for me ^^.

Ah crap. Forget everything I've ever written. Looks like I've been looking in the wrong place :P. I made some proper profiling and there are 2 things taking up 80% of the cpu time in gear: About half of that is doing the actual geometry rendering: gl.glVertexPointer(2, GL2.GL_FLOAT, 0, vertices); gl.glDrawElements(primitiveType, nVertices, GL2.GL_UNSIGNED_INT, indices); and the other half is calling the JOGL textrenderer: tr.draw3D(text, x, y, 0, scale); tr.flush(); If I comment out those 4 lines then execution time is cut by > 80%. Stupid stupid stupid Yoda..please do profiling properly next time from the start. Sending transformation matrices = super fast, cos/sin is only responsible for about 4-5% of the total time. In the process however I did write new cos/sin implementations that run a lot faster, using pre-generated tables of taylor polynomials, implementation below (Just too bad these dont do more than cut the execution time by 2% :P due to the above mentioned!): public final static float sinTaylorTable(float x) { x = x % TWOPI; final int base = blockSize * (int) (scaleF * (offsF + x)); final float x0 = sinData[base], d0 = sinData[base + 1], d1 = sinData[base + 2], d2 = sinData[base + 3], r = x - x0; return d0 + d1 * r + d2 * r * r / 2.0f; } public final static float cosTaylorTable(float x) { x = x % TWOPI; final int base = blockSize * (int) (scaleF * (offsF + x)); final float x0 = cosData[base], d0 = cosData[base + 1], d1 = cosData[base + 2], d2 = cosData[base + 3], r = x - x0; return d0 + d1 * r + d2 * r * r / 2.0f; }

Moa, I think you should reread my post :P. Looks like you misunderstood parts of it ^^. If a packet is completely lost that is not a problem imo with the sim-gear link. you will have a gap of 1/30 s instead of 1/60 s, and since I transmit a snapshot of the sim every time there is no need to receive every message. I never read back from VRAM (and I didnt before either). Using OpenGL FFP function calls is quite slow, and with an extra layer of JNI on top of that it is faster to perform on-CPU transformations or go with shaders. There is a quite long post about it here that I started: http://jogamp.org/forum.html. After I finish making all my transformations I make one single call to glLoadMatrixf. As I wrote in my previous post about lookup tables: It seems that if I make them larger than a couple of hundred entries, they arent put into the CPU cache anymore and then it becomes super slow to read them (I tested). So Maybe some intelligent solution with low N would be possible here with smart interpolation. However I have thought about the idea of creating lookup tables of low term taylor series for different cos/sine argument regions. If you have any ideas on how a good lookup implementation should be made though, I would gladly try it. Cos/Sine operations are still almost the biggest performance hit of the entire GEAR application! The biggest hits are (not in any particular order) sine calls, cosine calls, glLoadMatrixf calls, textrenderer calls (which I have made to an absolute minimum) Back to the openGL stuff, I made two classes to perform the math for my 2d graphics: package opengl.matrix2d; import sloppymath.SloppyMath; import com.jogamp.opengl.util.GLBuffers; import java.nio.FloatBuffer; public class Matrix2d { private final static float TODEGREES = 180f / (float) Math.PI; private final FloatBuffer out = GLBuffers.newDirectFloatBuffer(16); private boolean isDirty = true; private float // a11 = 1, a21 = 0, a31 = 0, a41 = 0, a12 = 0, a22 = 1, a32 = 0, a42 = 0, a13 = 0, a23 = 0, a33 = 1, a43 = 0, a14 = 0, a24 = 0, a34 = 0, a44 = 1; public Matrix2d() { out // .put(0, a11).put(1, a21).put(2, a31).put(3, a41) // .put(4, a12).put(5, a22).put(6, a32).put(7, a42) // .put(8, a13).put(9, a23).put(10, a33).put(11, a43) // .put(12, a14).put(13, a24).put(14, a34).put(15, a44); // } public final void loadIdentity() { a11 = 1; a12 = 0; /* a13 = 0; */ a14 = 0; a21 = 0; a22 = 1; /* a23 = 0; */ a24 = 0; /* a31 = 0; a32 = 0; a33 = 1; a34 = 0; a41 = 0; a42 = 0; a43 = 0; a44 = 1; */ isDirty = true; } public final void rotateZ(final float angDeg) { // multiplying A*B the previous matrix (A) with the rotational matrix B { cos -sin // sin cos // 1 // 1 } // Changes all elements in the first 2 cols final float cos = SloppyMath.cosTaylor8f(-angDeg / TODEGREES), sin = SloppyMath.sinTaylor9f(-angDeg / TODEGREES), na11 = a11 * cos + a12 * sin, na21 = a21 * cos + a22 * sin/*, na31 = a31 * cos + a32 * sin, na41 = a41 * cos + a42 * sin*/; a12 = -a11 * sin + a12 * cos; a22 = -a21 * sin + a22 * cos; /* a32 = -a31 * sin + a32 * cos; a42 = -a41 * sin + a42 * cos;*/ a11 = na11; a21 = na21; /* a31 = na31; a41 = na41;*/ isDirty = true; } public final void scaleX(final float scale) { a11 *= scale; a21 *= scale; /* a31 *= scale; a41 *= scale;*/ isDirty = true; } public final void scaleY(final float scale) { a12 *= scale; a22 *= scale; /* a32 *= scale; a42 *= scale;*/ isDirty = true; } public final void scaleXY(final float sx, final float sy) { a11 *= sx; a21 *= sx; /* a31 *= sx; a41 *= sx;*/ a12 *= sy; a22 *= sy; /* a32 *= sy; a42 *= sy;*/ isDirty = true; } public final void translateXY(final float dx, final float dy) { a14 += dx * a11 + dy * a12; a24 += dx * a21 + dy * a22; /* a34 += dx * a31 + dy * a32; a44 += dx * a41 + dy * a42;*/ isDirty = true; } public final void translateX(final float dx) { a14 += dx * a11; a24 += dx * a21; /* a34 += dx * a31; a44 += dx * a41;*/ isDirty = true; } public final void translateY(final float dy) { a14 += dy * a12; a24 += dy * a22; /* a34 += dy * a32; a44 += dy * a42;*/ isDirty = true; } public final FloatBuffer copyInto(final FloatBuffer fb) { return fb// .put(0, a11).put(1, a21).put(2, a31).put(3, a41) // .put(4, a12).put(5, a22).put(6, a32).put(7, a42) // .put(8, a13).put(9, a23).put(10, a33).put(11, a43) // .put(12, a14).put(13, a24).put(14, a34).put(15, a44); // } public final FloatBuffer getBuffer() { if (isDirty) { out.put(0, a11).put(1, a21).put(4, a12).put(5, a22).put(10, a33).put(12, a14).put(13, a24); isDirty = false; } return out; } public final void onPush(final Matrix2d nextMatrix) { nextMatrix.a11 = this.a11; nextMatrix.a12 = this.a12; nextMatrix.a14 = this.a14; nextMatrix.a21 = this.a21; nextMatrix.a22 = this.a22; nextMatrix.a24 = this.a24; nextMatrix.isDirty = true; } } package opengl.matrix2d; import java.nio.FloatBuffer; public class Matrix2dStack { private static final int MAXDEPDTH = 32; private final Matrix2d[] matrices = new Matrix2d[MAXDEPDTH]; private Matrix2d current; private int iCur = 0; private boolean isDirty = true; public Matrix2dStack() { for (int i = 0; i < MAXDEPDTH; i++) { matrices[i] = new Matrix2d(); } current = matrices[iCur]; } public final void pop() { current = matrices[--iCur]; isDirty = true; } public final void push() { final Matrix2d next = matrices[++iCur]; current.onPush(next); current = next; } public final void loadIdentity() { current.loadIdentity(); isDirty = true; } public final void rotateZ(final float angDeg) { current.rotateZ(angDeg); isDirty = true; } public final void scaleX(final float scale) { current.scaleX(scale); isDirty = true; } public final void scaleY(final float scale) { current.scaleY(scale); isDirty = true; } public final void scaleXY(final float sx, final float sy) { current.scaleXY(sx, sy); isDirty = true; } public final void translateXY(final float dx, final float dy) { current.translateXY(dx, dy); isDirty = true; } public final void translateX(final float dx) { current.translateX(dx); isDirty = true; } public final void translateY(final float dy) { current.translateY(dy); isDirty = true; } public final FloatBuffer getBuffer() { return current.getBuffer(); } public final FloatBuffer copyInto(final FloatBuffer fb) { return current.copyInto(fb); } public final boolean wasDirty() { final boolean wasDirty = isDirty; isDirty = false; return wasDirty; } } For the stack class the wasDirty method is there as a utility for the renderer. It is to make sure it doesnt load the same modelview matrix 2 times in a row with glloadMatrixF. The name "wasDirty" should probably be renamed to something like "loadInto" and take the gl interface as an input.

Been fooling around with optmizing a little bit of everything, and it resulted in (another) complete rewrite of the graphics engine of GEAR, and some other stuff... * Implemented my own transformation matrices and my own opengl-ish matrix stack, cause going through JNI (and in fact OpenGL in general) is too slow ;). Also OpenGL is single threaded while mine could be run from any number of threads. (So all interactions I have with opengl are 1. send finished transf matrix, 2. Send color, 3. send geometry). So now I feel like I've optimized this to death (check image below for cpu load results at 60 fps, 0.43% cpu avg ^^). As it turns out, the most expensive operations by far are transferring my finished transformation matrices and performing rotational transformations (becaue of Java's fall back to software cos/sine/tan). There for I .... * Implemented my own cosine/sine/tan functions :P (approx 3x faster than java in the best conditions, I use a quick range reduction to +- 90 deg and then use a simple taylor, well maclaurin to be precise, polynomial that is accurate to approx 6th decimal (enough for gear graphics purposes)) The reason Java is slow is because outside [-pi/4,pi/4] it no longer uses machine cos/sine directly but instead goes through a lot of code (I don't know why theirs is so slow) to make sure their answers are basically exact to n bits by some formal definition, something we don't really require here. I experimented with a few different approaches to get around this. The first was to make a lookup table and then add some interpolation, but this was waaay too slow, probably because it had to go fetch stuff from the main ram each time for any tables larger than what the CPU cache allowed. The second attempt (seen also in the code below) was to go through JNI to call standard C cos/sin in Math.h, well turns out the jni overhead was too much and the result was a function about as fast as the java built in ones (so no gain there) with the obvious lack of precision. Thirdly I decided to simply implement my own, the code can be seen below: (turns out a direct tan maclaurin expansion fails totally, so I used a more blunt approach and just divided the sine expansion with the cos one. It's not fast though and I basically don't use that, but the sine and cos are much faster than their Java built in counterparts so when I need to rotate some graphical object I only use them and never Java's built in ones) package sloppymath; import gear.Native; public abstract class SloppyMath { private static final float PI = (float) Math.PI; private static final float HALFPI = (float) (Math.PI / 2.0); private static final double TWOPIDOUBLE = 2.0 * Math.PI; private static final double QUARTERPI = Math.PI / 4; /*! * Sucks, and only for testing (not used atm). * Not as precise as standard java cos and slighty slower, due to JNI overhead. */ public final static float sinJNI(final float rads) { return Native.sin(rads); } /*! * Sucks, and only for testing (not used atm). * Not as precise as standard java cos and slighty slower, due to JNI overhead. */ public final static float cosJNI(final float rads) { return Native.cos(rads); } /*! * Significantly faster than java sin. * Precision is about last decimal wrong for single precision floats */ public final static float sinTaylor9f(final float r) { // Get within +-180º (use doubles here) float r1 = (float) (r - TWOPIDOUBLE * (int) ((r < 0 ? -0.5 : 0.5) + r / TWOPIDOUBLE)), s = 1; // Get within +-90º if (r1 < -HALFPI) { r1 += PI; s = -1; } else if (r1 > HALFPI) { r1 -= PI; s = -1; } return s * (// +r1 - r1 * r1 * r1 / 6.0f + r1 * r1 * r1 * r1 * r1 / 120.0f - r1 * r1 * r1 * r1 * r1 * r1 * r1 / 5040.0f + r1 * r1 * r1 * r1 * r1 * r1 * r1 * r1 * r1 / 362880.0f); } /*! * Significantly faster than java cos. * Precision is about last decimal wrong for single precision floats */ public final static float cosTaylor8f(final float r) { // Get within +-180º (use doubles here) float r1 = (float) (r - TWOPIDOUBLE * (int) ((r < 0 ? -0.5 : 0.5) + r / TWOPIDOUBLE)), s = 1; // Get within +-90º if (r1 < -HALFPI) { r1 += PI; s = -1; } else if (r1 > HALFPI) { r1 -= PI; s = -1; } return s * (// +1 - r1 * r1 / 2.0f + r1 * r1 * r1 * r1 / 24.0f - r1 * r1 * r1 * r1 * r1 * r1 / 720.0f + r1 * r1 * r1 * r1 * r1 * r1 * r1 * r1 / 40320.0f); } /*! * Faster than java tan on average ((r < QUARTERPI && r > -QUARTERPI) it is slightly slower). * Precision is about last decimal wrong for single precision floats */ public static final float tanTaylor9f(final float r) { // Math.tan is faster for small arguments if (r < QUARTERPI && r > -QUARTERPI) { return (float) Math.tan(r); } // Get within +-180º (use doubles here) float r1 = (float) (r - TWOPIDOUBLE * (int) ((r < 0 ? -0.5 : 0.5) + r / TWOPIDOUBLE)); // Get within +-90º if (r1 < -HALFPI) { r1 += PI; } else if (r1 > HALFPI) { r1 -= PI; } return // (// +r1 - r1 * r1 * r1 / 6.0f + r1 * r1 * r1 * r1 * r1 / 120.0f - r1 * r1 * r1 * r1 * r1 * r1 * r1 / 5040.0f + r1 * r1 * r1 * r1 * r1 * r1 * r1 * r1 * r1 / 362880.0f) / (// +1 - r1 * r1 / 2.0f + r1 * r1 * r1 * r1 / 24.0f - r1 * r1 * r1 * r1 * r1 * r1 / 720.0f + r1 * r1 * r1 * r1 * r1 * r1 * r1 * r1 / 40320.0f); } public static final float abs(final float val) { return val < 0 ? -val : val; } public static final int round(final float val) { return (int) ((val < 0 ? -0.5f : 0.5f) + val); } }

Yeah it's not an entirely bad idea but it will be difficult to do well since gear runs virtually any resolution and size, and must adapt to such conditions

it is how i started, but it becomes difficult to iff with this I've found. Still, it's what I have right now.

The data export has been somewhat cleaned up, but not the way you have it, however I might change it. The sim client is also modular so it can be replaced depending on what sim you are using. (for example x-plane would likely be different) My FC scripts export one message per lua iteration/simulation frame * Each message now starts with a header, containing a "key" string and a message size parameter (in bytes/characters). * TCP transmissions, so I don't implement any own checksum. We should not see any corrupted data if I understand this correctly. (during so many hours of use in both leavu and gear Ive never seen any) * Each section begins with a key -- Finalize the data going out with a header data = table.concat(data); return string.format('%s%s%s%s', '!!dnacv02mJ8onvalPD893HNid8V9h6782sdu!!', string.len(data), '\n', data); preferably each sub section should also have a size or ending, but currently they dont. I still use '\n' as a separator for my stuff. But you can ofc replace it. So basically u can map it like this read byte[] bytes = getNewBytes. find key "................." in bytes parse integer after key -> numBytes read numBytes and parse those. catch me on msn and we can discuss it If I make any significant changes it might be to change to xml instead. I'm already using that in gear for presets.

Did some testing yesterday, luckily at least GG was around to help :P. We've decided that there is at least one tricky decision to make before moving on. What kind of symbols should we use for what kind of contacts? :/ Right now I have my own symbols but GG prefers http://www.baesystems.com/ProductsServices/bae_prod_eis_mids_terminals.html (and the problem is that THAT small picture is basically all information we've got there), though I don't know how to represent all types of targets with that. Basically these need to be easily distinguishable and easily remembered/intuitively understood: * My scan contacts (1 type of symbol) * My designated contact (1 type of symbol) * My designated primary target (1 type of symbol) * Datalinked scan contacts (1 type of symbol) * Datalinked designated contacts (1 type of symbol), comes with id of wingman number or name * Datalinked designated primary target (1 type of symbol), comes with id of wingman number or name * All the above must have 1 friendly version and one non-friendly version. Perhaps 3 versions (F, N, E) So we need at least 12 types :P All help and suggestions on this is helpful

So guys, anyone up for some testing? I'm on msn right now and will be for the rest of the day

Ok I'll be home tomorrow before noon, and after lunch/the evening I'll be free for testing and taking suggestions on what to improve from testers. (Let us decide on a more specific time!). In terms of improving remember we're not really trying to imitate some plane, but rather trying to produce something new and better. I will also be available the same times either saturday or sunday (not decided yet), so if you guys add me on msn we can discuss it. ancient[underscore]banana[underscore]tmuk[at]hotmail[dot]com Don't try to use that for emailing though cause it actually isn't an email address :). I'm hoping GG also will have time and perhaps also some other 44th guys. I'll see if some rve are up for it though I think we're kind of inactive nowadays. Any other squad that wants to test/help out will of course be welcome.

Just to give a quick progress update. I'm out here in the middle of nowhere until Friday. While I'm mostly disconnected from the internet, I've still got my laptop with me and gear is moving forward. If anyone is interested in helping out, everything from stress testing to developing would be much appreciated.

The gear data data propagation design is nearing completion, though I expect the fc parts will never be "done", altough specific instruments will. Important is to separate "This instrument is done" (will probably happen at some point), "Gear is done" (what does this even mean?) For example someone could make some kind of VVI instruments or AOA instrument, those might get *done*. I myself might say "ok now my mfd is done", though someone could easily enhance it by adding further pages to it. Neither of these two though, would qualify as "now GEAR is done".

Only separate screens, because I do not know how to make it into an overlay. If you have example source code overlays for lofc2 then I could probably integrate it, but researching and learning that myself would take too much time away rom my primary goals with gear. Besides we would probably also want to find out a way to place it overlayed on top of the cockpit mfd, and that would is even further away from what I know how to do :).

First thing im going to do after the fc2 interface is to make an x-plane interface, maybe also a hud in there since it's so easy to overlay x-plane graphics :)

haha this is an excellent idea :). I wouldn't be surprised if there were some easter eggs like these possible in future ED software ^^. I recall there were some futuristic aircraft 3d models you could replace the original ones with. For a while I replaced my fc2 F-15 with something that looked imo pretty nice, called VF-somethingish.

I'm going to interpret that question in two ways and answer both. 1. "Would we be able to use the gear data export scripts online with fear without fear of anybody making some sort of uber app that would have info that shouldn't be there?" - Depends. The data export scripts export own sensor data. Allowing such a data export script means removing export.lua file from integrity check (or having a standardized file). Doing either of these does NOT allow export of global data (tacview style), but there is at least one bug in fc2 itself that causes more data to be available for export than the in-game instruments show. More precisely, there is a bug: own sensor radar data available does not mask ecm contacts. This is a bug in lockon, not gear. Even though my own data export scripts don't deliver this data to Gear, someone could potentially do that by writing their own data export script. Once the own sensor data is out of the game, developers can do whatever they like with it. It's a law of physics or whatever you want to call it, doesn't have anything to do with gear :). Developers could make whatever app they like from it. Now we are ready to answer #2 2. "Would we be able to use the gear in its entirety online with fear without fear of anybody making some sort of uber app that would have info that shouldn't be there?" Depends on what you think shouldn't be out there (read full gear description in 1st post before following below). The gear instrument loader could potentially load any type of 2d or 3d instrument showing any infromation in any format based on data received from either: # the fc2 data export scripts/interface of own sensor data # the gear data link server, players connecting and sharing own sensor data if either of these two data sources can produce knowledge that you find "shouldn't" be out there, then you have your answer, cause instruments and data representation in Gear can be made to look like whatever you want them to, certainly a lot more informative than the existing ingame instruments. For example: Would it be possible to create a GCI application or AWACS application connecting to the data link server, and sending information to players gear instruments through the data link, even controlling players' games with stuff like radar command input? Yes in theory. Has nothing to do with gear really. As soon as you allow export of own sensor data - That is all that is needed. - Gear is an application of that. Yes gear is a bad name, cause instruments can be made fully interactive (like leavu, even more so), and can also send commands back to lockon should you wish to implemetned that (like modify radar scan angles, cursor positions etc). Further more I made my mfd instrument a little bit more futuristic by making the screen itself work like a touch screen. So my mfd instrument has three input methods: click with mouse/touch screen on bezel buttons, click with mouse/touch screen on mfd screen, use keybindings. I implemented an mfd menu system that is 1:1 with falcon 4, even though the specific pages implementations are differnt. Code example below on how I've done it for my HSD page: @Override protected final void inputOsbCommand(final OsbCommand osbCommand) { switch (osbCommand.osb) { case (depOsb): DEP = !DEP; break; case (dcplOsb): DCPL = !DCPL; break; case (expOsb): expIndex = expIndex + 1 < expViews.length ? expIndex + 1 : 0; break; case (netOsb): NET = !NET; break; case (hsiOsb): HSI = !HSI; break; case (scaleUpOsb): displayScaleIndex = (higherDisplayScaleAvailable() && DCPL) ? displayScaleIndex + 1 : displayScaleIndex; break; case (scaleDownOsb): displayScaleIndex = (LowerDisplayScaleAvailable() && DCPL) ? displayScaleIndex - 1 : displayScaleIndex; break; } }

I don't think that would be something I could do within a reasonable amount of time. It would require some form of dll injection (replacing the direct3d dlls with your own custom built ones and tricking fc2 to run it - that way you can inject custom draw/paint instructions or export data/textures) like what AISTv is doing. Since I'm working in Java that would be virtually impossible, unless I (as I see my options) made some kind of client-server (for example using windows shared memory or just plain old network sockets) setup where the GEAR part produces a texture which the injected dll running can receive and overlay. Well although I probably COULD figure out the above, I would still need to find out where to place the texture, how do I find somewhere in the cockpit to place it? :P. At this point I have no experience of direct3d dll injections and my attempts att contacting the aistv author have not been successful. Also I will have a lot of work just to get the intended GEAR features finished in the near future. However: If someone supplied the source code or made such a dll for me! That would be a whole different thing, then I would definitely see if I couldnt implement it.

It has been quite a while since I last worked on anything related to Fc. Now I have a couple of weeks of vacation and I've got some ideas. Initially I thought I would implement these in Leavu2, however eventually I realized that Leavu2 was written when I was very green in terms of Java programming. Also even though leavu theoretically could be used with any sim, that was not its initial design idea, so it would be very messy. So I've decided that if I'm going to make any new tools like leavu, it would have to be an entirely new tool written properly from the ground up, with much better ability for extensions, custom new instruments by users and an easier architecture to code. Also a new and cleaner data export would be required. So I'd like to present some of the things I've worked on for the last couple of days, so far what I call GEAR. General External Avionics Renderer, the name should be changed to something less silly. Come on Leavu? Gear? TIACAFAP (This Is A Cool Abbreviation For A Program). GEAR is NOT an mfd. GEAR is an arbitrary instrument loader for any sim. Here below is a picture from early work on the instrument I'm in the process of implementing right now. The idea is that more users/developers will come with ideas and hopefully implement new instruments themselves, so that we could create a nice database. Here's how it works: GEAR has a few parts, some are optional. Some are included, many are not, and that is intentional. The minimum required parts are: * GEAR: the instrument loader (sim independent) * DATA EXPORT: a sim specific data export module for your sim (I am making one for fc2, virtually done) * DATA EXPORT INTERFACE: a data interface inside the GEAR instrument loader which receives and translates the sim specific details from the data export to formats that the GEAR instrument loader can use. (I am making one for fc2) The optional parts so far are: * GEAR: Datalink server (sim and data format independent through Java Serialization interface). This server can handle both sim specific messages or just general GEAR data. Unlike leavu this is not a separate application but is actually launched from inside the GEAR instrument loader itself. * DATALINK INTERFACE/CLIENT: a data interface between the GEAR loader and the datalink server (I have so far made one implementation capable of sending fc2 data) * THE INSTRUMENTS!: Pick an (or a couple of) existing one, make your own or dowload someone else's From the users point of view all the above are just the same program (except the first which is made into something loaded by the sim) Usage: A user starts the instrument loader and loads an instrument profile (which can be made to happen automatically on startup, think like touch buddy), or just adds instruments from a menu. When he started it he also specified which simulator he would like to get data from and what data interpretation layer he wishes to use. Some details on what GEAR is intended to be: - Open Source (written in Java with some custom native JNI additions) - An high performance (low CPU/GPU load) opengl renderer for 2d instruments (or ability to add whatever u like). Instruments run at whatever rate you want them, for example 100 fps. JOGL is used. - A standardized abstracted interface to make it work with any sim, (so you can implement your own data export from other sims, regardless of coordinate systems etc). - A standardized abstracted interface to potential datalinks. (Currently I've only made an implementation for Fc2). - Compared to Leavu? Much cleaner design, code, rendering and data propagation/interfacing. Much easier to make own additions. Significantly better data export from lockon. Much easier installation. (Significantly faster, can run about 50 simultaneous display on 1 core) I know there was a lot of debate on leavu this and leavu that. This time I can frankly say I won't hold back on posibilities. I will make the instruments that I myself implement as useful as they can be on own sensor data. Note on the miserable failures of the LEAVU 2 renderer ;) - The old Leavu rendering setup is completely scrapped. It had an ugly abstraction layer between instrument and renderer, which made absolutely no sense. A new much lighter interface like setup is now made. The only part really remaining in the graphics department is the coordinate system :). Programming API example: Here is a sample on how you could implement your own rendering/instruments. You write a Java Instrument as an AWT window/component or similar, you add an OpenGL Canvas (rendering surface) to it. Then you implement a specific OpenGL callback interface, which has only one function :glPaint, example below. public final class Mfd20 extends Instrument implements GlDisplayCallback { protected DataInterface dataInterface; @Override public final void glPaint(final GLAutoDrawable gLDrawable, final GL gl, final GLU glu, final Object cbd) { gl.glColor4f(1, 1, 1, 1); gl.glBegin(GL.GL_LINES); gl.glVertex2d(0, 0); gl.glVertex2d(1, 1); gl.glEnd(); if (dataInterface instanceof WaypointsInterface) InterfacedWaypoint[] ifwp = ((WaypointsInterface)dataInterface).getWaypoints(); } } The code above produces the following image: Yes it's an mfd but only because it's the onl instrument I got at the moment :P. You could make it look like whatever you want. About overlaying the game graphics themselves I don't think that would be something I could do within a reasonable amount of time. It would require some form of dll injection (replacing the direct3d dlls with your own custom built ones and tricking fc2 to run it - that way you can inject custom draw/paint instructions or export data/textures) like what AISTv is doing. Since I'm working in Java that would be virtually impossible, unless I (as I see my options) made some kind of client-server (for example using windows shared memory or just plain old network sockets) setup where the GEAR part produces a texture which the injected dll running can receive and overlay. Well although I probably COULD figure out the above, I would still need to find out where to place the texture, how do I find somewhere in the cockpit to place it? :P. At this point I have no experience of direct3d dll injections and my attempts att contacting the aistv author have not been successful. Also I will have a lot of work just to get the intended GEAR features finished in the near future. However: If someone supplied the source code or made such a dll for me! (or wanted to co-author the project or similar) That would be a whole different thing, then I would definitely see if I couldnt implement it. Performance and CPU hit With gear comes a lot more efficient code compared to the old Leavu. Here is an example of how much CPU % gear @ 60 fps requires from my i7 @ 3.36 GHz. Ok for everyone that wants to inspect and/or contribute to the source, "Public" SVN account is up! (read-only) It includes everything you need, from fc2 exports to native jogl libs and java code. I recommend you use Netbeans IDE for both checking it out and trying it. 1. Install 32bit Java JDK with Neatbeans 2. Open Netbeans and checkout the SVN repository from: rep: https://www.gigurra.se/svn/GEAR/GEAR user: public password (blank):

You are absolutely right. Read up on scan angles. These mechanical radars have very small scan angles, in fact 4 bars (lockon fixed setting) will generate a scan which is less than +- 5 degrees up and down in relation to your radar's off-horizon setting! For horizontal you should see +- 60 degrees by default For chasing running targets, lockon radars have detection range multiplier of 1/3. This is even further reduced if you are not selecting a favorable PRF. Also remember unless you are in bore CAC, your radar will rarely ever point to where your nose is. The antenna will point towards the horizon + your offset setting, even if you start pitching up and down. This is a problem cause lockon hasnt implemented an angle indicator for the antenna setting (well it is there but it is showing the wrong thing :)), only an indirect indicator showing what your top and bottom scan altitudes are at the cursor range. I'd say the radar implementation for the f-15 isn't that bad, it's just missing a lot of automation and indicators that would normally help the pilot.

Oh I haven't tried it. Possibly he compiled it with some .net or vs redistributable that you dont have?

Is there any chance we could perhaps have the source code for your dll? It would be fantastic since we could basically create very cool new cockpit features with it. (assuming you are using a dll hook for it) Well we probably dont even need the full code, I'm just curious how you actually find the specific texture of the mfd in your code. If you could share with us that stuff...wow.

No leavu cannot export mfds. I created my own mfds. However AISTV did export it through injecting a d3d-dll hook (I believe). I would very much like to know how to do that, it would be great to be able to do it myself :). How did you render the maverick view on the su27 display? I must learn this...Cause with that I could render leavu in-pit! I tried PMing him but got no reply :(.

unfortunately I can't find it and your link seems to be dead, but I did find this: http://www.flightlink.com/osc/product_info.php?products_id=47 I think I'll get this and maybe put some buttons on it :).