The Dynamic Cockpit Project

Want to edit the game, build your own craft and missions? Here you'll find help, tools, guides and people to discuss with.
Post Reply

Re: The Dynamic Cockpit Project

User avatar
Trevor
Lieutenant JG
Posts: 541
Joined: Thu Dec 04, 2014 7:11 pm

Post by Trevor » Tue Jul 16, 2019 10:03 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

User avatar
keiranhalcyon7
Lieutenant JG
Posts: 599
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Tue Jul 16, 2019 10:12 pm

Seeing as Jeremy just updated his today, some merging may be needed.

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Wed Jul 17, 2019 9:31 pm

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.

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Mon Jul 22, 2019 5:28 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).
dynamic-cockpit-sample-2.jpg
You do not have the required permissions to view the files attached to this post.

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Sun Jul 28, 2019 8:00 pm

Update: Thanks to Jeremy's texture tag hook, it's now very easy to extend this to multiple cockpits:
Dynamic-Cockpit-Sample-3.jpg
Dynamic-Cockpit-Sample-4.jpg
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.

User avatar
JeremyaFr
XWAU Member
Posts: 3922
Joined: Mon Jan 18, 2010 5:52 pm
Contact:

Post by JeremyaFr » Sun Jul 28, 2019 8:08 pm

Great :2thumbs:

User avatar
keiranhalcyon7
Lieutenant JG
Posts: 599
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Sun Jul 28, 2019 8:37 pm

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.)

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Mon Jul 29, 2019 6:09 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):
Dynamic-Cockpit-Sample-5.jpg
Dynamic-Cockpit-Sample-6.jpg
Dynamic-Cockpit-Sample-7.jpg
You do not have the required permissions to view the files attached to this post.

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Mon Jul 29, 2019 6:17 am

RIght now, this is how the dynamic cockpit commands look like:

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
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:

Code: Select all

source-width,height, source-x0,y0,x1,y1, dest-width,height, dest-x0,y0,x1,y1
"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.

User avatar
keiranhalcyon7
Lieutenant JG
Posts: 599
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Mon Jul 29, 2019 8:43 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?

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Mon Jul 29, 2019 6:45 pm

keiranhalcyon7 wrote:
Mon Jul 29, 2019 8:43 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...
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 am
Could a texture be rotated by rotating the polygon/mesh it lives on?
Yes, do you have something specific in your mind?
keiranhalcyon7 wrote:
Mon Jul 29, 2019 8:43 am
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.
keiranhalcyon7 wrote:
Mon Jul 29, 2019 8:43 am
For 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'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 am
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?
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!

User avatar
JeremyaFr
XWAU Member
Posts: 3922
Joined: Mon Jan 18, 2010 5:52 pm
Contact:

Post by JeremyaFr » Mon Jul 29, 2019 7:31 pm

blue_max wrote:
Mon Jul 29, 2019 6:45 pm
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!
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.

User avatar
keiranhalcyon7
Lieutenant JG
Posts: 599
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Mon Jul 29, 2019 8:41 pm

blue_max wrote:
Mon Jul 29, 2019 6:45 pm
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.
These lights:
cannon_lights.PNG
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.)
keiranhalcyon7 wrote:
Mon Jul 29, 2019 8:43 am
Could a texture be rotated by rotating the polygon/mesh it lives on?
Yes, do you have something specific in your mind?
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.
keiranhalcyon7 wrote:
Mon Jul 29, 2019 8:43 am
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.
keiranhalcyon7 wrote:
Mon Jul 29, 2019 8:43 am
For 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'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.
Sure; future developments.
JeremyaFr wrote:
Mon Jul 29, 2019 7:31 pm
blue_max wrote:
Mon Jul 29, 2019 6:45 pm
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!
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.
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.
You do not have the required permissions to view the files attached to this post.

Bman
Lieutenant Commander
Posts: 1167
Joined: Mon Apr 05, 2004 11:01 pm

Post by Bman » Tue Jul 30, 2019 3:04 am

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.

User avatar
keiranhalcyon7
Lieutenant JG
Posts: 599
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Tue Jul 30, 2019 3:22 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?

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Tue Jul 30, 2019 6:14 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.

User avatar
blue_max
XWAU Member
Posts: 2295
Joined: Wed Mar 20, 2019 5:12 am

Post by blue_max » Tue Jul 30, 2019 5:40 pm

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.

User avatar
rogue518
XWAU Member
Posts: 2856
Joined: Wed Jul 12, 2000 11:01 pm
Contact:

Post by rogue518 » Wed Jul 31, 2019 4:18 pm

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... :ops: ) don't want to screw this up.

Sincerely, Rogue518
'Stay in Attack formation!' Darth Vader aka: Anakin Skywalker During the 'Battle Of Yavin'

Safe-Keeper
Cadet 2nd Class
Posts: 95
Joined: Mon Jul 09, 2012 3:07 pm
Contact:

Post by Safe-Keeper » Wed Jul 31, 2019 7:51 pm

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.

User avatar
Trevor
Lieutenant JG
Posts: 541
Joined: Thu Dec 04, 2014 7:11 pm

Post by Trevor » Thu Aug 01, 2019 7:17 pm

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.
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.

Also, on that note, wouldn't it be X-Wing.ini not X-WingCockpit.ini?

Code: Select all

[DynamicCockpit]
;define Dynamic Cockpit attributes here
Trev

User avatar
keiranhalcyon7
Lieutenant JG
Posts: 599
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Thu Aug 01, 2019 10:38 pm

Trevor wrote:
Thu Aug 01, 2019 7:17 pm
Also, on that note, wouldn't it be X-Wing.ini not X-WingCockpit.ini?
Well, this project applies to the cockpits, not the base or exterior opts. I was trying to provide room to have different settings between the cockpit and gunner opts of the same craft.

User avatar
Trevor
Lieutenant JG
Posts: 541
Joined: Thu Dec 04, 2014 7:11 pm

Post by Trevor » Fri Aug 02, 2019 4:29 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

Code: Select all

...
Awing.ini
Awing.opt
AwingCockpit.opt
AwingExterior.opt
…
Shuttle.ini
Shuttle.opt
ShuttleCockpit.opt
ShuttleExterior.opt
ShuttleGunner.opt
...
That Awing.ini deals with all things A-Wing related.

Trev
Last edited by Trevor on Fri Aug 02, 2019 5:03 pm, edited 1 time in total.

User avatar
keiranhalcyon7
Lieutenant JG
Posts: 599
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Fri Aug 02, 2019 4:34 pm

So what kind of structure would you propose for craft with gunner opts?

User avatar
Trevor
Lieutenant JG
Posts: 541
Joined: Thu Dec 04, 2014 7:11 pm

Post by Trevor » Fri Aug 02, 2019 6:12 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.

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

User avatar
keiranhalcyon7
Lieutenant JG
Posts: 599
Joined: Tue Jan 02, 2018 6:41 am

Post by keiranhalcyon7 » Fri Aug 02, 2019 6:20 pm

Seems reasonable to me.

Post Reply