The Dynamic Cockpit Project
Re: The Dynamic Cockpit Project
- Trevor
- Posts: 541
- Joined: Thu Dec 04, 2014 7:11 pm
As far as I am aware there are only 2 versions of ddraw.dll - yours and Jeremy's and yours is the "latest" assuming it was taken from Jeremys final codebase.
Trev
Trev
- keiranhalcyon7
- Posts: 599
- Joined: Tue Jan 02, 2018 6:41 am
Seeing as Jeremy just updated his today, some merging may be needed.
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 am
Thanks for your support guys. I'm talking with Darksaber regarding what would be the best way to implement this; but once we settle on something, I think the community will be able to help.
I based my work off of Jeremy's ddraw. The last time I refreshed was around May or so. I can refresh again; but depending on what he changed, it might take a while, so I'm probably not going to do it right away. But yes, I can update my ddraw with the latest code from Jeremy's ddraw.
In VR things tend to look a bit bigger; but in this case, the text in the middle panel is hard to read. That was just a clumsy choice on my part: I can just as easily make a bigger text panel on the sides of the cockpit. However, if the cockpits are going to be updated, I think the panels will be bigger anyway.
I based my work off of Jeremy's ddraw. The last time I refreshed was around May or so. I can refresh again; but depending on what he changed, it might take a while, so I'm probably not going to do it right away. But yes, I can update my ddraw with the latest code from Jeremy's ddraw.
In VR things tend to look a bit bigger; but in this case, the text in the middle panel is hard to read. That was just a clumsy choice on my part: I can just as easily make a bigger text panel on the sides of the cockpit. However, if the cockpits are going to be updated, I think the panels will be bigger anyway.
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 am
This is a screenshot taken in regular (non-VR) mode showing both the dynamic cockpit elements *and* the HUD at the same time. I intentionally removed the background of the HUD for this experiment. I'll put it back later. (Yes, I know it's too small/unreadable, we're going to fix that too).
You do not have the required permissions to view the files attached to this post.
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 am
Update: Thanks to Jeremy's texture tag hook, it's now very easy to extend this to multiple cockpits:
Yes, I know some areas are bit small. Some people from the XWAUP are working on modifying the cockpits to make things easier to read; so we'll have a solution for that. If people don't mind the occasional bug I think I can release a preview soon. The general workflow involves using XWAOptEditor to export the texture that will be modified, making a "hole" in it using the alpha component, and writing down the names of the textures and the coordinates of the source and destination, in pixels.
Yes, I know some areas are bit small. Some people from the XWAUP are working on modifying the cockpits to make things easier to read; so we'll have a solution for that. If people don't mind the occasional bug I think I can release a preview soon. The general workflow involves using XWAOptEditor to export the texture that will be modified, making a "hole" in it using the alpha component, and writing down the names of the textures and the coordinates of the source and destination, in pixels.
You do not have the required permissions to view the files attached to this post.
- keiranhalcyon7
- Posts: 599
- Joined: Tue Jan 02, 2018 6:41 am
Very nice. Question: I assume the "source and destination, in pixels" are (or will be) in a format like "x0,y0,x1,y1,x2,y2,x3,y3". If x3 is less than x2, is the image mirrored? (So as to allow the cannon charge indicators to count up towards the center, rather than strictly left to right.)
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 am
Thanks Jeremy!
@keiranhalcyon7: It's more like (x0,y0, x1,y1) -- simple rectangles, and yes, you can flip the destination coordinates to mirror on the x or y (or both) axes (in fact, in some cases you *must* mirror the textures). The HUD elements can also be scaled; but not rotated. Yes, you can change the direction in which the lasers are charged so that they fill-up towards the center (if I understood your comment, this is what you meant):
@keiranhalcyon7: It's more like (x0,y0, x1,y1) -- simple rectangles, and yes, you can flip the destination coordinates to mirror on the x or y (or both) axes (in fact, in some cases you *must* mirror the textures). The HUD elements can also be scaled; but not rotated. Yes, you can change the direction in which the lasers are charged so that they fill-up towards the center (if I understood your comment, this is what you meant):
You do not have the required permissions to view the files attached to this post.
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 am
RIght now, this is how the dynamic cockpit commands look like:
The first line identifies the destination texture: that's the texture that will receive a HUD element. It has the format "OPT-name,Texture-name". The texture names can be seen in XwaOptEditor.
"cover_texture" is the name of the texture that will have the transparency holes punched in it. It can be a relative or absolute path.
The "uv_coords" line has the format:
"source" here means the HUD offscreen buffer and it's in screen coordinates. My setup is set to 3240x2160 pixels, for instance. The source x0,y0,x1,y1 must obey the rules: x0 < x1 and y0 < y1 or nothing will be displayed. The "destination" texture refers to the cover texture. The destination coordinates can be flipped to mirror the HUD element. There can be up to four "uv_coords" per destination texture. Each line should fill one hole in the cover texture.
"erase_coords" is optional can be used to remove the HUD element from the final HUD display. If this line is omitted, the HUD element will appear both in the cockpit and on the regular HUD. It has the same format as "uv_coords" without the destination coordinates.
Code: Select all
; Shields display
[XwingCockpit.opt,TEX00098]
cover_texture = DynamicCockpit\x-wing-shields-cover.png
uv_coords = 3240,2160, 325,388, 542,672, 128,128, 77,12, 109,60
erase_coords = 3240,2160, 261,400, 557,730
"cover_texture" is the name of the texture that will have the transparency holes punched in it. It can be a relative or absolute path.
The "uv_coords" line has the format:
Code: Select all
source-width,height, source-x0,y0,x1,y1, dest-width,height, dest-x0,y0,x1,y1
"erase_coords" is optional can be used to remove the HUD element from the final HUD display. If this line is omitted, the HUD element will appear both in the cockpit and on the regular HUD. It has the same format as "uv_coords" without the destination coordinates.
- keiranhalcyon7
- Posts: 599
- Joined: Tue Jan 02, 2018 6:41 am
Thanks, blue_max. Yes, that is exactly what I meant about filling up towards the center. Now we just need the lights in the center like in the prior games...
A couple comments & questions:
Could a texture be rotated by rotating the polygon/mesh it lives on?
If that code lived in XwingCockpit.ini, the opt name can become implicit.
For simplicity of deployment, could the cover texture live in the opt (perhaps even default to the on-disk version of the destination texture)?
For the erase coords, do you think you could hijack the usual functions of the home/end/etc. keys to reproduce the default HUD toggling functionality while still getting the gauges info?
A couple comments & questions:
Could a texture be rotated by rotating the polygon/mesh it lives on?
If that code lived in XwingCockpit.ini, the opt name can become implicit.
For simplicity of deployment, could the cover texture live in the opt (perhaps even default to the on-disk version of the destination texture)?
For the erase coords, do you think you could hijack the usual functions of the home/end/etc. keys to reproduce the default HUD toggling functionality while still getting the gauges info?
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 am
Please, remind me what these lights did? Did they tell you which cannon was ready to fire next? If we know where this information is stored in XWA's memory, then maybe it could be implemented later.keiranhalcyon7 wrote: ↑Mon Jul 29, 2019 8:43 amThanks, blue_max. Yes, that is exactly what I meant about filling up towards the center. Now we just need the lights in the center like in the prior games...
Yes, do you have something specific in your mind?keiranhalcyon7 wrote: ↑Mon Jul 29, 2019 8:43 amCould a texture be rotated by rotating the polygon/mesh it lives on?
If you're talking about the coordinates, yes, I believe we could remove the OPT name. However, I think we would need to wait for the project to be a little more mature and the XWAUP team would have to approve this first.keiranhalcyon7 wrote: ↑Mon Jul 29, 2019 8:43 amIf that code lived in XwingCockpit.ini, the opt name can become implicit.
This sounds like it's technically possible; but again, the project needs to be more mature and the XWAUP team would have to discuss this and approve it first.keiranhalcyon7 wrote: ↑Mon Jul 29, 2019 8:43 amFor simplicity of deployment, could the cover texture live in the opt (perhaps even default to the on-disk version of the destination texture)?
This sounds like it would have a number of advantages -- If I understood correctly what you're saying. However, I can't hijack keyboard events right now. I can listen to them, and react; but I cannot suppress them. I'm replacing XWA's main message loop with my own; but I believe the DirectInput layer can listen to keyboard events through a different mechanism. If someone knows how to suppress keyboard events in ddraw, please let me know!keiranhalcyon7 wrote: ↑Mon Jul 29, 2019 8:43 amFor the erase coords, do you think you could hijack the usual functions of the home/end/etc. keys to reproduce the default HUD toggling functionality while still getting the gauges info?
- JeremyaFr
- Posts: 3982
- Joined: Mon Jan 18, 2010 5:52 pm
- Contact:
The function that process keyboard input is L004FBA80. The pressed key is stored in the variable at address 0x08053C0. You may want to hook this function and filter the pressed key.blue_max wrote: ↑Mon Jul 29, 2019 6:45 pmThis sounds like it would have a number of advantages -- If I understood correctly what you're saying. However, I can't hijack keyboard events right now. I can listen to them, and react; but I cannot suppress them. I'm replacing XWA's main message loop with my own; but I believe the DirectInput layer can listen to keyboard events through a different mechanism. If someone knows how to suppress keyboard events in ddraw, please let me know!
- keiranhalcyon7
- Posts: 599
- Joined: Tue Jan 02, 2018 6:41 am
These lights:
The info is certainly there, somewhere; the required images may not be. Don't worry about it for now; it can be future work. (Also potential future work: a visual throttle slider.)
Nothing specific at the moment, just the possibility of exotic cockpits that buck the normal rules and orient their cannon charge indicators (or other instruments) in other directions.Yes, do you have something specific in your mind?keiranhalcyon7 wrote: ↑Mon Jul 29, 2019 8:43 amCould a texture be rotated by rotating the polygon/mesh it lives on?
Sure; future developments.If you're talking about the coordinates, yes, I believe we could remove the OPT name. However, I think we would need to wait for the project to be a little more mature and the XWAUP team would have to approve this first.keiranhalcyon7 wrote: ↑Mon Jul 29, 2019 8:43 amIf that code lived in XwingCockpit.ini, the opt name can become implicit.
This sounds like it's technically possible; but again, the project needs to be more mature and the XWAUP team would have to discuss this and approve it first.keiranhalcyon7 wrote: ↑Mon Jul 29, 2019 8:43 amFor simplicity of deployment, could the cover texture live in the opt (perhaps even default to the on-disk version of the destination texture)?
That's one possibility. Another is to disable the code that sets the HUD element visibility state (which may be in that very function, for all I know), or to disable the code that reads the HUD element visibility state. The latter may be best in light of the overloaded functionality of the delete & page down keys; these don't just toggle the element visibility, but also select the element for interaction with the arrow keys.JeremyaFr wrote: ↑Mon Jul 29, 2019 7:31 pmThe function that process keyboard input is L004FBA80. The pressed key is stored in the variable at address 0x08053C0. You may want to hook this function and filter the pressed key.blue_max wrote: ↑Mon Jul 29, 2019 6:45 pmThis sounds like it would have a number of advantages -- If I understood correctly what you're saying. However, I can't hijack keyboard events right now. I can listen to them, and react; but I cannot suppress them. I'm replacing XWA's main message loop with my own; but I believe the DirectInput layer can listen to keyboard events through a different mechanism. If someone knows how to suppress keyboard events in ddraw, please let me know!
You do not have the required permissions to view the files attached to this post.
-
- Posts: 1170
- Joined: Mon Apr 05, 2004 11:01 pm
Very nice! Maybe other than the targeting recticle, is it your plans to optionally move "everything" floating in the field-of-view from top of the cockpit window to the cockpit dashboard, including the forward and rear craft sensors? Yeah it would be a lot of work to redo the cockpit textures to accommodate this project and is up to XWAUPG team. But for future upgraded models it would probably be more feasible to implement. Great work.
W-I-P: TFTC, MC Viscount Cr., ISD-II Avenger, NL-1 Platform, Ton-Falk Esc. Cr., & Misc.
- keiranhalcyon7
- Posts: 599
- Joined: Tue Jan 02, 2018 6:41 am
Oh, that makes me think, what happens if the targeting bracket travels through one of the cut-out zones, or through an erase zone?
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 am
Thanks Jeremy for the info, I can probably try that later. Also, thanks keiranhalcyon7, those are good options too. BTW, I can recognize the brackets easily and render them as usual so that they don't disappear when they enter the erase zones. The main problem right now is the triangle pointer when something gets targetted, because it also renders some text around the borders and that texts gets copied to the dynamic cockpit elements. I'm still trying to figure out how to keep the triangle pointer; but remove the text...
@Bman if you look closely you'll notice that the forward and rear sensors have already been moved into the cockpit. It's a little small; but it's there, I promise. The other elements on the top can also be moved to the cockpit.
@Bman if you look closely you'll notice that the forward and rear sensors have already been moved into the cockpit. It's a little small; but it's there, I promise. The other elements on the top can also be moved to the cockpit.
- blue_max
- Posts: 2296
- Joined: Wed Mar 20, 2019 5:12 am
Alright, I think it's time I released a preview of this project:
https://www.dropbox.com/s/orv43bbjudh58 ... 1.zip?dl=0
I consider this a beta release. It's functional; but it may have a few issues and it's not complete yet. I'll try to write a tutorial on how to use this feature later.
https://www.dropbox.com/s/orv43bbjudh58 ... 1.zip?dl=0
I consider this a beta release. It's functional; but it may have a few issues and it's not complete yet. I'll try to write a tutorial on how to use this feature later.
- rogue518
- Posts: 2863
- Joined: Wed Jul 12, 2000 11:01 pm
- Contact:
I was always was hoping for this.... Never thought it was possible, I will wait for a tutorial for this , just got 32-bit mode working ( even though the Readme for the Dynamic Cockpit Project says not available in 32-bit mode at the time... ) don't want to screw this up.
Sincerely, Rogue518
Sincerely, Rogue518
'Stay in Attack formation!' Darth Vader aka: Anakin Skywalker During the 'Battle Of Yavin'
-
- Posts: 95
- Joined: Mon Jul 09, 2012 3:07 pm
- Contact:
Holy ****. Just when I think some limit has been reached someone blows my mind again. Just wow.
My two cents: don't think having to look down to see the instruments is going to be that much of a problem in VR, it'll probably just add to immersion. It will also add to the challenge, of course, but if I had a VR headset I think I'd just appreciate that,
In the films the X-Wing pilots sat so that the cockpit took up a significant portion of their forward vision, so maybe in XWA the cockpit should be raised slightly? I think it was much higher in First Strike than it is in XWA, if memory serves.
My two cents: don't think having to look down to see the instruments is going to be that much of a problem in VR, it'll probably just add to immersion. It will also add to the challenge, of course, but if I had a VR headset I think I'd just appreciate that,
In the films the X-Wing pilots sat so that the cockpit took up a significant portion of their forward vision, so maybe in XWA the cockpit should be raised slightly? I think it was much higher in First Strike than it is in XWA, if memory serves.
- Trevor
- Posts: 541
- Joined: Thu Dec 04, 2014 7:11 pm
The ini files should be extendable since each hook should only read its own section, obviously, I agree that for any "Pak" XWUP would need to approve and the ini section structure finalised so it didn't incur multiple re-downloads.If that code lived in XwingCockpit.ini, the opt name can become implicit.
If you're talking about the coordinates, yes, I believe we could remove the OPT name. However, I think we would need to wait for the project to be a little more mature and the XWAUP team would have to approve this first.
Also, on that note, wouldn't it be X-Wing.ini not X-WingCockpit.ini?
Code: Select all
[DynamicCockpit]
;define Dynamic Cockpit attributes here
- Trevor
- Posts: 541
- Joined: Thu Dec 04, 2014 7:11 pm
That wouldn't be a problem if it was built into the ini structure.
Remember the ini format was to reduce the number of superfluous files hanging around in the flightmodels folder - the final folder structure being
That Awing.ini deals with all things A-Wing related.
Trev
Remember the ini format was to reduce the number of superfluous files hanging around in the flightmodels folder - the final folder structure being
Code: Select all
...
Awing.ini
Awing.opt
AwingCockpit.opt
AwingExterior.opt
…
Shuttle.ini
Shuttle.opt
ShuttleCockpit.opt
ShuttleExterior.opt
ShuttleGunner.opt
...
Trev
Last edited by Trevor on Fri Aug 02, 2019 5:03 pm, edited 1 time in total.
- keiranhalcyon7
- Posts: 599
- Joined: Tue Jan 02, 2018 6:41 am
So what kind of structure would you propose for craft with gunner opts?
- Trevor
- Posts: 541
- Joined: Thu Dec 04, 2014 7:11 pm
I kinda took your question a bit far but thought I would post it anyway.
here is an ini proposal (3 actually) for cockpit with gunner being same format but under a different Group.
here is an ini proposal (3 actually) for cockpit with gunner being same format but under a different Group.
Code: Select all
;Xwing.ini
[Camera]
;Camera X,Y,Z
X = -250
Y = 400
Z = 100
FamX = -250
FamY = 400
FamZ = 100
[Pilot]
;mesh index, angle, speed, behavior
6, 32, 2, 1
9, 32, 2, 2
[SFoils]
;mesh index, angle, opening speed, closing speed
1, 8, 1, 1
2, 12, 1, 1
3, 12, 1, 1
4, 8, 1, 1
10, 8, 1, 1
11, 12, 1, 1
12, 12, 1, 1
13, 8, 1, 1
14, 8, 1, 1
15, 12, 1, 1
16, 12, 1, 1
17, 8, 1, 1
35, 64, 2, 1
36, 64, 2, 1
37, 50, 2, 2
38, 12, 1, 1
39, 12, 1, 1
40, 12, 1, 1
[Size]
ClosedSFoilsElevation = 60
[Sound]
EngineSoundInterior = 1
EngineSoundFlyBy = 1
WeaponSoundBehavior = 0
[WeaponColor]
WeaponColor = 0
WeaponColor280 = 0
WeaponColor281 = 0
[DynamicCockpit]
enabled = 1
; - remove OffscreenBuffer.Width, OffscreenBuffer.Height and calculate at runtime
; - remove ReplaceTexture.width, ReplaceTexture.height and calculate at runtime
; === format proposal 1 - least change ===
;IDOriginalTexture = strReplacement
;OffscreenBuffer.x0, OffscreenBuffer.y0, OffscreenBuffer.x1, OffscreenBuffer.y1,
;boolRemoveHUDElement,
;Texture.x0, Texture.y0, Texture.x1, Texture.y1
; === example ===
; Targeting Computer
TEX00097 = DynamicCockpit\x-wing-targeting-comp-cover.png
1180,1720, 2060,2180, 1, 13,12, 242,115
; Left Radar and Energy Recharge Levels
TEX00096 = DynamicCockpit\x-wing-left-radar-cover.png
;could be set to same texture name if opt changed
;TEX00096 = TEX00096
327,0, 675,347, 0, 40,28, 98,111 ; Left radar
271,0, 289,171, 0, 220,11, 228,78 ; Laser power
271,174, 289,341, 0, 229,11, 236,78 ; Shield power
2948,0, 2971,171, FALSE, 237,11, 245,78 ; Engine power
;2948,174, 2971,341, 0, 237,11, 245,78 ; Beam recharge rate
261,0, 693,395, TRUE, 0,0,0,0 ;erase Larger HUD Element
; === format proposal 2 ===
;IDOriginalTexture = strReplacement
;OffscreenBuffer.u0, OffscreenBuffer.v0, OffscreenBuffer.u1, OffscreenBuffer.v1, ;these are floats of range 0-1
;boolRemoveHUDElement,
;Texture.x0, Texture.y0, Texture.x1, Texture.y1
; === example ===
; Right radar
TEX00095 = DynamicCockpit\x-wing-right-radar-cover.png
0.791358024691358,0, 0.8993827160493827,0.1606481481481481, 1, 148,28, 206,111
; === format proposal 3 - Pre-configured HUD Elements, there always in the same place afterall ===
;IDOriginalTexture = strReplacement
;strHUDElement = boolRemoveHUDElement,
;Texture.x0, Texture.y0, Texture.x1, Texture.y1
; === example ===
; Shields and Hull display
TEX00098 = DynamicCockpit\x-wing-shields-cover.png
Shields = 1, 77,12, 109,60
; Left Text panel
TEX00026 = DynamicCockpit\x-wing-left-panel.png
LeftDisplayPanel = 1, 132,125, 211,237
; Laser Levels - custom co-ords
TEX00094 = DynamicCockpit\x-wing-lasers-panel-cover.png
; Let's split the laser charge and x-mirror the right side so that
; they recharge towards the center:
0.4222222,0.7592592592592593, 0.4969135802469136, 0.787037037037037, TRUE, 52,7, 130,53
0.5061728395061728, 0.7592592592592593, 0.5830246913580247,0.787037037037037, TRUE, 219,7, 140,53
[DynamicGunner]
;same format as above