Beta Release: GPT (cockpit texture extraction, remote cockpit control, shm mirror)
-
Bump.
You’ll need to experiment with the source x,y coordinates in the GPT displaysreceiver - to figure out where in the texture the f18 mfds are located.
You can always start with 0,0,1,1 to display the whole texture first -
You’ll need to experiment with the source x,y coordinates in the GPT displaysreceiver - to figure out where in the texture the f18 mfds are located.
You can always start with 0,0,1,1 to display the whole texture firstIs there any chance of getting this info from the devs?
That way we could easily make it work, instead of wasting time doing the trial and error in the blind.
-
Who knows, ask them?
I did my numbers trial and error. took what, 2 minutes? So it’s not exactly super hard. Just draw the whole texture first (x 0->1, y 0->1) and you’ll see approximately where the screens are, then fine tune. -
The link to the "http://gigurra.se/gurrasPitTools/manual.pdf " don’t work, Can you put the right? Thanks for your job.
-
The link to the "http://gigurra.se/gurrasPitTools/manual.pdf " don’t work, Can you put the right? Thanks for your job.
Sorry I’m afraid that one is permanently lost… + outdated!
There is a quick readme available in the release package over at https://github.com/GiGurra/gpt/releases
-
Just a quick question… when I was using an iPad app to control switches via the iPad, there was a bit of a delay between command and actual cockpit input. Does this software (GTP) still have lag? Or is the response instant?
I’m just debating whether to port my Helios and MFDE stuff to a second computer as I’m thinking of running two touchscreens instead of just one, and being able to transfer that workload to another PC seems like a good idea… if there isn’t any lag.
-
In my experience, the GPT key transmitting/receiving tool had no noticeable delay at all.
I use it to send the keystrokes from my auxiliary PC, to which I have my left and right consoles connected, to the main PC.
And it works like a charm.
Enviado desde mi HUAWEI Y530-U00 mediante Tapatalk
-
Thanks for that reply!
Please indulge me a few more questions… still working my way through the threads. Who knew this came out in 2012?! How time flies!!
Anyway, here goes:
1. Is there a “minimum spec” for the secondary PC? Minimum GPU?
2. Does the secondary PC need to be connected to the network or main PC via cable? Or does it do all of this through a wireless network?
3. I suspect this program basically pulls gauge/lights/MFD info from the game, but can it be used to run Helios as well? In other words, can it send commands to the main PC?
4. What, if any, needs to be done on the main PC? Is there a FPS hit when running this?I have a HP laptop with a 980M card on it that I can use, or maybe I can commandeer my son’s PC (which was my old one) that has an i5 750 and a HD 7970 GHz Edition GPU. Either way, I’m planning to connect the PC to one or two touchscreens that run at 1920x1080 resolution each, both screens would display Helios.
-
Whoohoo! Caught up to this point.
1. Seems like there’s no minimum spec as older posts were talking about mid- or low-range hardware circa 2012.
2. Confirmed via network, but dont’ know whether hard-wiring has any benefits.
3. Seems like some people do run GPT+Helios on their slave PCs, but what about gauges? I use MFDE, will that work on the slave PC as well?
4. Seems like minimum, if any FPS hit. So excited about this! -
1. Seems like there’s no minimum spec as older posts were talking about mid- or low-range hardware circa 2012.
I disagree a little bit with that. GPT is relatively CPU hungry. Almost any GPU will do, but first I tried to run it with an old CPU (athlonx64 out something like that) and it didn’t work so well. A friend of mine tried to run it on an old 2008 laptop and gpt was bringing it to its knees and performance was not good.
I built a very cheap computer based on i3 with a the cheapest MB and and old gtx 280 I had somewhere.
But you can try how it works on any old hardware you have….3. Seems like some people do run GPT+Helios on their slave PCs, but what about gauges? I use MFDE, will that work on the slave PC as well?
I use gpt for MFDs, RWR and HUD extraction. For the rest of the gauges I use MFDE. They are fully compatible.
I extract the HUD to record it along with MFDs and instruments for debriefing purposes.
You can see examples here.
https://m.youtube.com/channel/UCBtQtOy6KabjjwFgWdQrd6w
Have fun with gpt. It works great
Enviado desde mi HUAWEI Y530-U00 mediante Tapatalk
-
I disagree a little bit with that. GPT is relatively CPU hungry. Almost any GPU will do, but first I tried to run it with an old CPU (athlonx64 out something like that) and it didn’t work so well. A friend of mine tried to run it on an old 2008 laptop and gpt was bringing it to its knees and performance was not good.
I built a very cheap computer based on i3 with a the cheapest MB and and old gtx 280 I had somewhere.
But you can try how it works on any old hardware you have….I use gpt for MFDs, RWR and HUD extraction. For the rest of the gauges I use MFDE. They are fully compatible.
I extract the HUD to record it along with MFDs and instruments for debriefing purposes.
You can see examples here.
https://m.youtube.com/channel/UCBtQtOy6KabjjwFgWdQrd6w
Have fun with gpt. It works great
Enviado desde mi HUAWEI Y530-U00 mediante Tapatalk
I have an old windows xp machine running my mfds + helios instruments. 5 monitors on that machine with some super cheap gpus. Not sure if it’s a core2 or very old i5 model. But I dont think gpt consumes more than 15% cpu at 50 Hz. But that’s just a guess.
It wouldnt surprise me if it was a bit cpu hungry. It’s very lazily programmed :). I optimized for image clarity and zero response latency. It consumes vast amounts of bandwidth (like 50 mbit^^) - every video frame is a separately encoded jpeg image - super inefficient ^^.
-
It wouldnt surprise me if it was a bit cpu hungry. It’s very lazily programmed :). I optimized for image clarity and zero response latency. It consumes vast amounts of bandwidth (like 50 mbit^^) - every video frame is a separately encoded jpeg image - super inefficient ^^.
one thing is for sure… I wouldn’t have programmed it better…or worse… or at all.
hungry or not, it does perfectly what it is intended for.
And we thank you for it.
-
GiGurra, I get a little lag when I’m using the application in local mode 127.0.0.1 (radar cursor moves small jumps), is there any way around this ??
-
GiGurra, I get a little lag when I’m using the application in local mode 127.0.0.1 (radar cursor moves small jumps), is there any way around this ??
Only locally? Strange. No idea Im afraid
-
I also use local mode and experience no cursor lag.
-
Only locally? Strange. No idea Im afraid
Yes for the extraction of MFD´s to other monitor. I used it. ;D . Not sure if its correct this method.
I also use local mode and experience no cursor lag.
Me yes. With original MFD extraction of BMS no problems but much more FPS consuption an a very little interface UI. :-?
-
Maybe this will save someone some time. To close my part of this thread, I got the F/A-18C MFD’s to display on my dedicated instrument monitors by editing the gpt-DisplaysReceiver-cfg-json file “source” values as follows.
Left MFD: “source”:“source”: {
“x”: 0.0,
“y”: 0.15,
“width”: 0.375,
“height”: 0.375Right MFD:“source”: {
“x”: 0.374,
“y”: 0.145,
“width”: 0.379,
“height”: 0.379No need to edit the “target” values. As suggested, I started by assigning 0, 0, 1, and 1 to the left MFD to display the entire array of instruments. So now you need 2 versions of the file, 1 for F18 and one for F16. I just rename the file for the aircraft I am not flying.
-
Maybe this will save someone some time. To close my part of this thread, I got the F/A-18C MFD’s to display on my dedicated instrument monitors by editing the gpt-DisplaysReceiver-cfg-json file “source” values as follows.
Left MFD: “source”:“source”: {
“x”: 0.0,
“y”: 0.15,
“width”: 0.375,
“height”: 0.375Right MFD:“source”: {
“x”: 0.374,
“y”: 0.145,
“width”: 0.379,
“height”: 0.379No need to edit the “target” values. As suggested, I started by assigning 0, 0, 1, and 1 to the left MFD to display the entire array of instruments. So now you need 2 versions of the file, 1 for F18 and one for F16. I just rename the file for the aircraft I am not flying.
Thank you very much for the values. Work great.
A little trick to make your life easier….[emoji12]
Instead of renaming files back and forth, you can make a copy of the f-16 gpt folder and rename it for example… “gpt f-18”.
Make two shortcuts, one for the start_displays_receiver.bat in the f-16 folder, and the other one for the modified one with the f-18 values.
This way, just clicking on the shortcut corresponding the aircraft you want to fly, you will launch the correct displays.
Just my two cents.
Enviado desde mi HUAWEI Y530-U00 mediante Tapatalk
-
GiGurra, I get a little lag when I’m using the application in local mode 127.0.0.1 (radar cursor moves small jumps), is there any way around this ??
Actually how large jumps are we talking about?
Since gpt export is hard locked at 50 Hz, and doesnt really sync much with the game, there should be some jumping… But it should be in the order of 10-20 milliseconds. (that is ~1/50th of a second). -
Yay! I finally got GPT to work and now my slave PC running Helios can access the sharedmem from the main PC. However, if I press “1” on the slave PC once, the main PC gets two inputs, a first “1” and a second “1”…. If I press 1, then 2 on the slave PC, the main PC gets 1122… I tried vincent’s method of disabling double-tap but that doesn’t work and I can’t get rid of Double-tap -> Double-click under Pen and Touch options. Any help appreciated!