My A-10C preparation

[Chibawang]

Yea, kind of strange as the screen clearly allows for 10 lines. Maybe it means 8 manipulatable lines, 7 + 1 for the scratchpad?

[rocketeer]

Thank for the link. Now we know the exact dimension of the panel and the window.

[Wags]

Yea, kind of strange as the screen clearly allows for 10 lines. Maybe it means 8 manipulatable lines, 7 + 1 for the scratchpad?

 

7 lines can be manipulated

1 top line for page tilte, WP/SP, FOM etc.

1 line for annunciations

1 line for scratchpad

[rocketeer]

The panels I printed were prepared for A4 size paper, with the intended width of 5.75". But being in US we use letter size. Maybe that's why it's a bit off. Printing at 100% of A4 and at 100% of letter is different I guess.

[PanelBuilder]

If you look through the Black Shark clickabledata.lua the things marked with class_type.LEV and realtive = false expect an absolute value in arm_lim defined range. These can be mapped to a pot.

Yes, I've done this for the Targeting Display Control panel. The board reads the pots for TV brightness and contrast and HMS and sends a value of 0 - 255 for each. This gets converted in lua to 0 to 1. It sends the value only when it changes. A couple of things to consider:

 

I'm using the 5V line from the USB port on my laptop and it seems to be a little flakey. I would get a constant stream of data being sent without touching the pots. A 2200 cap on the interface board quieted it down considerably. Plus the board now sends the value only when it changes by more than 1. It's configurable by command so I can increase this if I want. Now I don't get any data sent unless I actually turn the pot.

 

When I do turn the pot though I get lots of data. Originally I had lua reading just one input value per frame, but it would get hopelessly backed up when I cranked the pots. So now it reads until there's nothing left to read, each frame.

 

A side effact of this is at startup all the switches align at once. If you look at the WCS movie, the two switches align right away. If lua was reading one value per frame, there would have been a few frames between the two switches setting, which I actually thinks looks better.

 

I'm still thinking about ways to cut down on the amount of data sent as the pots are turned.

 

Cheers,

Colin

[Alex_rcpilot]

Thanks for the links, Chibawang. Those modules are really cool. Driven Technologies certainly has a really nice product line. Those square LCDs are pretty impressive.

 

Back to the topic, I wonder how we may export the CDU display content from the game to, say, a custom USB CDC device. It seems to have some none-ASCII characters, I don't know how they'd show up in the raw data packets.

[Alex_rcpilot]

The panels I printed were prepared for A4 size paper, with the intended width of 5.75". But being in US we use letter size. Maybe that's why it's a bit off. Printing at 100% of A4 and at 100% of letter is different I guess.

 

Is it possible for you to find a piece of A3-sized paper and set the printwork to 1:1 scale output?

[Chibawang]

Thanks for the links, Chibawang. Those modules are really cool. Driven Technologies certainly has a really nice product line. Those square LCDs are pretty impressive.

 

Back to the topic, I wonder how we may export the CDU display content from the game to, say, a custom USB CDC device. It seems to have some none-ASCII characters, I don't know how they'd show up in the raw data packets.

 

You're welcome! I'm not sure what characters you're referring to, but new fonts could always be made. If you're talking about extracting them from lua, well, the sim has to send them somehow right? If it's a nonstandard character it's probably substituted for another, or a code string.

[rocketeer]

Is it possible for you to find a piece of A3-sized paper and set the printwork to 1:1 scale output?

 

Yes I can go get A3 paper but it won't fit into my tiny printer that only takes smaller paper.

[rocketeer]

I cam across this site last night. Good info about Open Cockpit's IO cards.

 

Examples.

Description of IO cards

http://personales.ya.com/micabina737/iocards/hard/descripcioni.htm

 

Connection between cards

http://personales.ya.com/micabina737/iocards/hard/numi.htm

 

Display cards connection

http://personales.ya.com/micabina737/iocards/hard/displaysi.htm

 

Connecting different devices to the master card

http://personales.ya.com/micabina737/iocards/hard/elementosi.htm

 

SOIC language example

http://personales.ya.com/micabina737/iocards/soft/ejemplo1_sioci.htm

[Alex_rcpilot]

You're welcome! I'm not sure what characters you're referring to, but new fonts could always be made. If you're talking about extracting them from lua, well, the sim has to send them somehow right? If it's a nonstandard character it's probably substituted for another, or a code string.

 

Well, you know, sometimes we see stuff that we think is odd, but we could be wrong. :music_whistling:

 

Yeah that's what I meant, if there were any non-standard characters, they ought to be converted to some sort of special strings. We will need to know what exactly they are when the time comes.:)

[Alex_rcpilot]

Yes I can go get A3 paper but it won't fit into my tiny printer that only takes smaller paper.

 

Then you're no luckier than I am. Go get some professional help from a copy shop.:megalol:

 

*Edit: or you may tailor your own A4 paper out of A3 if your printer can hold it. lol

Edited January 6, 2010 by Alex_rcpilot

[y2kiah]

Yeah that's what I meant, if there were any non-standard characters, they ought to be converted to some sort of special strings. We will need to know what exactly they are when the time comes.:)

 

If I had to guess how ED will expose the CDU screen, I would look at the Black Shark ABRIS and Shkval as examples. Those screens are rendered to a texture and then mapped onto the 3d surface of the vc mesh. View setup in Lua allows you to tell the engine to render those textures to an abritrary on-screen quad. I imagine the CDU screen will be treated the same as the MFD's (if only for performance reasons), and rendered to a texture, and should be accessible in the same way. You won't need any information about special characters or need to create fonts etc. etc., just draw the image onto an LCD. The actual text visible on the display may or may not be exposed through script.

 

Of course this is all speculation, maybe Wags can verify one way or the other?

 

Is it possible for you to find a piece of A3-sized paper and set the printwork to 1:1 scale output?

 

Copy your PDF with a window capture (Alt+PrintScreen), crop in Paint to include only the document, including whitespace. Paste into Word or any other program onto an 8.5 wide page. Stretch the image to 8.26" x 11.whatever A4 paper is. This should print pretty darn close to 1:1 scale.

[Alex_rcpilot]

If I had to guess how ED will expose the CDU screen, I would look at the Black Shark ABRIS and Shkval as examples. Those screens are rendered to a texture and then mapped onto the 3d surface of the vc mesh. View setup in Lua allows you to tell the engine to render those textures to an abritrary on-screen quad. I imagine the CDU screen will be treated the same as the MFD's (if only for performance reasons), and rendered to a texture, and should be accessible in the same way. You won't need any information about special characters or need to create fonts etc. etc., just draw the image onto an LCD. The actual text visible on the display may or may not be exposed through script.

 

Of course this is all speculation, maybe Wags can verify one way or the other?

 

Well, that's a good point. I agree with you on the possibility that the CDU being treated this way, let's wait for some insiders to clarify this. However, I still tend to favor the *.lua export idea, it's not exclusive anyway. We may have access to both if ED is willing to do this. Yet I wouldn't bring up that image, because I like wider natural view, and it costs space when it's on the main monitors. If I add a monitor dedicated for the CDU, I will have problem finding a tiny one to fit into the right panel, and the expaned window size as a result to the extra monitor also reduces framerate. With a routinely updated brief data packet, the workload on the PC will be significantly reduced. And there are many professional engineers in the community who can take advantage of these data packets and transform them into fancy looking gadgets, I'd like to see that happen.:D

 

I seriously don't mean to urge ED on anything by mentioning this. Just sharing some thoughts.

 

Copy your PDF with a window capture (Alt+PrintScreen), crop in Paint to include only the document, including whitespace. Paste into Word or any other program onto an 8.5 wide page. Stretch the image to 8.26" x 11.whatever A4 paper is. This should print pretty darn close to 1:1 scale.

 

I guess he'd still need those cropped edges to join up with other sheets. Perhaps he would have to combine the images into a huge one on the PC and split them again in pieces of letter sized printouts.

[Chibawang]

I doubt think that's how things work in game, there are far more efficient means such as shaders or sprites. Likewise, it would be easier and less performance heavy to just send text to the LCD.

[y2kiah]

I doubt think that's how things work in game, there are far more efficient means such as shaders or sprites.

 

errrrm... ok. Your doubt is noted. :thumbup:

 

On the other hand I'm experienced with OpenGL and Direct3D, and I'm not quite sure what magic you expect to happen with "shaders or sprites". Render to texture is commonly used to improve performance in situations where a dynamic surface needs to be mapped onto a 3d model, but the surface does not neccesarily need to be rendered every frame. A performance improvement is realized for the cost of additional GPU memory used.

 

Shaders, sprites, and render to texture are not mutually exclusive things as your comment would suggest. "Sprites" as you refer to them (I assume you mean the individual font glyphs) would probably NOT be represented individually but rather combined into a texture atlas, or represented as a signed distance field, and would be rendered to a texture by a shader. The resulting texture would be mapped to the cockpit model and rasterized to the screen using another shader.

 

Likewise, it would be easier and less performance heavy to just send text to the LCD.

 

Actually I wouldn't make that assumption. You'd probably be surprised how much quicker a modern GPU can rasterize and make available a 640x480 image compared to sending data over a much slower bus. Coupled with the fact that the image is cached and only re-rendered when it changes, thus you essentially get the image for free each frame. Your PIC or whatever you choose to run this makeshift unit would be running at what, a whopping 16hz? Do you wonder why everyone seems to complain about latency between the cockpit controls and the sim? There would be no latency with the image method.

[Gadroc]

Actually I wouldn't make that assumption. You'd probably be surprised how much quicker a modern GPU can rasterize and make available a 640x480 image compared to sending data over a much slower bus. Coupled with the fact that the image is cached and only re-rendered when it changes, thus you essentially get the image for free each frame. Your PIC or whatever you choose to run this makeshift unit would be running at what, a whopping 16hz? Do you wonder why everyone seems to complain about latency between the cockpit controls and the sim? There would be no latency with the image method.

 

You may want to rethink your assumptions as well. DCS's current implementation of multi-display for the ABRIS and Shkval are very inefficient. It requires defining a huge overall screen just to display that image that affects overall performance drastically, the FPS hit we take when displaying the ABRIS and Shkval on secondary displays is HUGE.

 

Try this little experiment. Setup your display using the 1camera mode. Load a mission and hit ctrl-pause to pull up the FPS counter. Look around and jot down your average FPS. Now exit the mission and switch to Camera+ABRIS+Shkval and leave all other settings the same. Load the exact same scene and watch your FPS hit. On my setup it's on average 20fps slower.

 

Next look up the commands for turning on shared memory texture exporting. Set them up in the Export.lua and watch your FPS bottom out (it cuts my FPS by half).

 

While in general you are correct about rendering text to an existing 3d scene being very fast. And you are correct about rendering to a texture and mapping that to an object being an effect technique again for rendering into an existing 3d scene. But neither of those scenarios have any relevance on building a cockpit and the most efficient way to get data to the respect electronics or displays in that cockpit.

 

Currently Black Shark exports the EKRAN which is also an LCD type screen via text. Text is much much more flexible for those of us who are building pits. It means we can run a true LCD display or do our own glass display. I currently render out the EKRAN to glass cockpit display using this text, much faster than the hit it would take to display it with the current image supported for ABRIS or Shkval. In addition it would be impossible to take that image and send it to anything other than a full color lcd display driven by a video card.

[y2kiah]

You may want to rethink your assumptions as well. DCS's current implementation of multi-display for the ABRIS and Shkval are very inefficient.

 

I didn't really make any assumptions, did I? I don't recall claiming either method would be quicker than the other. And in this situation I agree with you. Not considering the performance hit to get your second monitor in the mix (which I take for granted anyway), the incremental cost of displaying anything on it is minimal. My point was, that we should not be so quick to talk in absolutes.

 

There are as many ways to implement a software design as there are programmers. I give ED the benefit of the doubt that they will continually improve and optimize. A-10 will be a standalone product, not necessarily subject to the same limitations as BS in the multimon arena.

 

With the Radeon 5870 and 6 monitor outputs on the horizon, it could be a game changer for multi-mon in the pit. Again, it's all speculation at this point and I wouldn't be surprised if both methods will be possible. I'm sure your unit will be sweet when you get it working, however you choose to do it.

Edited January 7, 2010 by y2kiah

[Gadroc]

I didn't really make any assumptions, did I? I don't recall claiming either method would be quicker than the other. And in this situation I agree with you. Not considering the performance hit to get your second monitor in the mix (which I take for granted anyway), the incremental cost of displaying anything on it is minimal. My point was, that we should not be so quick to talk in absolutes.

 

There are as many ways to implement a software design as there are programmers. I give ED the benefit of the doubt that they will continually improve and optimize. A-10 will be a standalone product, not necessarily subject to the same limitations as BS in the multimon arena.

 

With the Radeon 5870 and 6 monitor outputs on the horizon, it could be a game changer for multi-mon in the pit. Again, it's all speculation at this point and I wouldn't be surprised if both methods will be possible. I'm sure your unit will be sweet when you get it working, however you choose to do it.

 

Possibly a poor choice of words on my part. I did not intend on picking a fight.

 

I truly hope that they do improve on what's there for the component displays (and back port it to Black Shark :music_whistling:). Both methods would be good, but if I had to choose one I would choose giving us the raw data instead of an image. That gives us the ability to implement many different solutions. Having an image significantly limits our options for implementing a CDU in the pit.

[y2kiah]

Hey no big deal. I didn't mean to sound confrontational. I see your point about the flexibility. I was probably quick to defend because I don't want to think about all of the work it's going to take :cry:

[Chibawang]

Sorry y2kiah, thanks for the correction. I misread your original post and thought you were saying something much more complicated; insomnia tends to do that to me. :\

 

Also, I speaking in general absolutes, just current DCS absolutes, as Gadroc illustrated (Thanks Gadroc!).

[Alex_rcpilot]

Well, when I game with SoftTH at 5040 x 1050, I can run the game in full-screen mode, which sometimes yields 53FPS on my rig. But running in a window in the same size, I lose about 15FPS at the same scene. Now I add a fourth monitor and make an extra margin of 192 in width to hold the CDU, although the CDU image could be treated in a more efficient way, I'd probably still lose some extra FPS at 5232 x 1050. Well......I don't know, maybe I can live with it, just need to see for myself.

 

*edit: I missed so many replies just while I was typing my own....

Edited January 7, 2010 by Alex_rcpilot

[Tbag]

Does anybody know the dimensions of the side panels. Looked through this thread but if they are somewhere I missed them.

[y2kiah]

Rocketeer Your measurements are just a bit off.

Standard US control heads are 5.745 inch wide + or - 1 hundredth of an inch(145.94 mm).This measurement is the width of the aluminum back plate. The front back light Plexiglas plate is 5.699 inch (144.76mm) wide.both measurements include the paint on the aluminum and on the Plexiglas. Some good references are on http://www.xflight.de

 

I just found an old CDU panel the LCD opening is 3.26 inch (82.68mm)wide by 2.62 inch (66.81 mm)tall it would be close on the new CDU opning

 

I think this was the final verdict, from Deadman a while back. Hope this is what you're looking for.

[Tbag]

Thanks y2kiah, that's part of the information I want. But I'd like to have the total dimensions of the left side panel and the angle between the inner and the outer half. But the information, expecially on the linked site is very good, thanks!