Vega Strike Forums

I'm working on a Hud Editor for PR, but I'm having some trouble deciphering the logic used for placement and scaling of the images.

I am already parsing the .cpt and .spr files, extracting the textures and data, then sending that information to the screen. I have yet to hit upon the combination that puts all the guages in the proper positions at the correct size.

Maybe an explanation of how the .cpt and .spr files translate into screen space would help.

I'm hoping one of the folks that has been working on the code, and is familiar with this aspect, can give me a concise explanation.

I don't know about any of the object display code; but I can comment on an aspect of the general design that you may have overlooked.

In your screen shot, almost half of the screen space is taken up by stuff that obscures my view of space. The very limited vertical view relative to the standard fighter cockpit would be a severe disadvantage in a dogfight, especially if your ship is relatively fast.

@Shissui i believe that the two windows at the top are for actually editing the HUD image.

@Paul i don't work the code but AFAIK all the GUI code is Python.


Enjoy the Choice

Shissui wrote:In your screen shot, almost half of the screen space is taken up by stuff that obscures my view of space. The very limited vertical view relative to the standard fighter cockpit would be a severe disadvantage in a dogfight, especially if your ship is relatively fast.

This is NOT an in game hud. This is a seperate program for editing cockpits. The 2 windows you say are obscuring your view, are for editing the location of the guages and indicators. They are also movable, not fixed.

Let us stop the flame throwing before it begins.

I was attempting to point out a possible design flaw before it became etched in stone. [err. code.] If this is intentional, then the correct response is to make no changes rather than to fight about words that have been put in my mouth by others.

There are even reasons for deliberately blocking the pilots view. I.e. you might do this as a balancing offset for carrying more ordinance than a comparably sized fighter. It might, additionally, be supplemented by a reduced pitch & roll (= faster horizontal turning than vertical or spin). An asymmetric turning response would push the pilot to try to pick the best plane in which to use the ship 2 dimensionally. {This could be "justified" because all those extra light missiles prevent optimal placement of turn jets.}

But, keep in mind that it is not my intent to push your ship design either.

@Loki
No -- you are putting extra obstacles in my view. If you remove those edit windows, then the pilot & console counter & ship frame & opaque dials and such still cover between a third and half the display.

@Paul
If this cockpit is not for in game use, then my initial comment (& my expansion on it above) is, perhaps, entirely irrelevant ?

Or, did you really mean it when you say that you are not designing this HUD for game use ?

Shissui wrote:Or, did you really mean it when you say that you are not designing this HUD for game use ?

The cockpit in the screenshot is already in the game. It is my original design for a new ship, also my original design. Just FYI, those 2 tool windows are NOT included in game. After going thru the process of designing a HUD/cockpit, I am somewhat familiar with how a cockpit works. I also realize what a tedious undertaking it is without some kind of tool to help with the placement of guages and indicators.

JEEZ! SHissui you might want to take a look around you and see what's going on before you start typing.

what's the forum tiitle? "Developer Tools & User Utilities"

what's the topic? "Hud Editor"

and the last line of my original post;

Paul wrote:I'm hoping one of the folks that has been working on the code, and is familiar with this aspect, can give me a concise explanation.

@Shissui
The reason for the last line was to politely discourage posts like your own.

While Loki didn't have the answer requested, he did point me in the direction of a possible solution. Thanks Loki. I'm working thru the python code now.

my 2nd post;

Paul wrote:This is a seperate program for editing cockpits. The 2 windows you say are obscuring your view, are for editing the location of the guages and indicators.

@Shissui
FLAME just so you don't mistake it for something else
So yes, your posts are irrelevant, as Loki politely pointed out. They are also off topic and entirely unhelpful. There are plenty of forums and topics where irrelevant ramblings and opinions are solicited and welcome. So please, Shissui, take your irrelevant self, and your irrelevant comments away from what I was hoping would be my concise, relevant topic. But before you go, could you delete your irrelevant posts, so I can delete mine and maybe salvage this topic.

tut tut.

chill guys.

@Shissui

Paul is not making a new HUD, he is making a HUD Editor (i.e. separate application for making new HUDs for PR easier).

@Paul
Anyway, good luck with it Paul. I'm no coder, so I can't help. But I do hope the finished app can also be used for Vega Strike and the rest of the VS mods (Lord knows we need new HUD layouts).

Oblivion wrote:But I do hope the finished app can also be used for Vega Strike and the rest of the VS mods (Lord knows we need new HUD layouts).

It should work with Vega Strike, Oblivion. I am loading WCU cockpits with the same result as PR cockpits. I still haven't gotten the layout right. It appears the images are scaled and translated twice. Once from the spr files then again from the cpt file. This could be where I'm having trouble.

I'm going to try setting translation to 0,0 and image size to actual in the spr file then do all the translating and scaling in the cpt file. If this works, it will take a little manual editing of old cockpits to get them to work with my Hud Editor.

I just took a look at Vegastrike cockpits, Oblivion. It appears the PR and VS cockpits are very similar, except for one thing. Where PR uses an image for the main cockpit HUD, VS uses a mesh. At the moment, my HUD editor is looking for images, not meshes, so the 1st release (if I ever get that far) will not support VS cockpits.

However, there is no reason I couldn't make another release, or modify the original, to support meshes, as well as images. For that matter, I see no reason why VS couldn't use images instead of meshes for the main cockpit. You could probably take a PR and/or a WCU cockpit and use it in VS. This is unconfirmed of course, I haven't tried it.

I am still trying to discern the relationship between PR cockpit coordinates and screen space. I'm making progress, but it's not there yet.

If there are any people reading this that have worked on the game code for the main executable, please, at least tell me where I might find the section dealing with cockpit projection.

Just a guess... I'm no coder but I made some HUDs and scaled some base images for PR-PU, yet no cockpits.

banshee-cockpit.png banshee-cockpit.png
2 2.66666666
0 -.33333333

Line 1 shows the the cockpit file

Line 2 means:
Make the image at the x axis 2 times larger to fit the screen
Make the image at the y axis 2,66666666 times larger to fit the screen

Line 3 means:
Allocation of the central point of the image, based on a standard coordinate system from -1 to +1.
0 = central x-axis point is at the center of the image.
-.33333333 = central y-axis point is lowered by 1/3 of the lower half of the screen (so 1/6 in total).

I hope this is what you wanted to know, and additionally I hope it is the correct answer.

Thanks Dilloh, that is about what I supposed. Now, in the main cpt file, the guages/indicators also have width and height, as well as, xcent and ycent.

shieldf.spr wrote:
shieldf.png shieldf.png
.2 .05
-.3 -.75

cockpit.cpt wrote:
<ShieldF file="shieldf.spr" xcent=".7373" ycent=".9323" width=".0957" height=".0885"/>

Are these also percentages of the screen, or percentages of the already scaled image? My guess, is the screen.

shieldf.spr should be working like the main cockpit file, some sort of multi-layer. so the file is:
x * 0.2
y* 0.05
xaxis = -0.3
yaxis = -0,75

cockpit.cpt: I'm also guessing. I don't understand why there are additional size and positioning informations. Maybe it is so that "shieldF.spr" can be used for other cockpits and doesn't need a spr file for every single cockpit where the shield.png has a different scale.
If shieldF is the image file for the forward shield png, it is most likely the percentage of the image size. If it was the screen, 0.7 would mean that the file shieldF.png would take 70% of the screen, or 35% if it is compared to the coordinate system.

But as I said, I'm also guessing according to my experience with base files and HUDs. I really think that the best way to find everything out is trial and error. Go play with some values, change the axis positions and scalings, and see what happens to get a deeper understanding.

Dilloh wrote:Go play with some values, change the axis positions and scalings, and see what happens to get a deeper understanding.

I been doing just that for weeks now. I admit, I'm only a novice programmer, but this is really giving me headaches.

Thanks tho Dilloh, you have helped. I'm trying some new things instead of rearranging old ones and making progress. Sometimes a fresh point of view really helps.

Hey, feel free to ask more. I'm barely capable of creating a prog like you are trying to do. It happened by chance that I knew the answer for your question.

So long

BTW: I could make an easy modification to override all dimensions and locations from the CPT file. That would make a lot more sense, to have them there, and would be much easier to mantain and edit, since you don't have to edit .spr files. In fact, you could completely avoid them, methinks...
Interested?
(BTW: I've been doing that for base interfaces too... so most of it is done already)

Could you elaborate on what you intend, Klauss? Are you talking about a change in the excutable for the game, or an additional library?

(EDIT: @paul, I think he's discussing modifying the binary so as to not require a separate sprite file)

That's something we should have done years ago in my opinion.

The workaround when I put the bases together was to make the "basemaker" program auto-generate the .spr files...

A simpler idea might be to make width="" height="" parameters, where if only one is specified, it will scale the other based on the values in the .spr file, and if both are specified, it will ignore the sprite file entirely.

The easiest way is to disregard sprites entirely and go directly to a texture file. That would make editing so much simpler.

ace123 wrote:The easiest way is to disregard sprites entirely and go directly to a texture file. That would make editing so much simpler.

I agree ace, at least for windows systems. Since DirectX creates the sprite based on the size of the texture, all the sizing and placement could be done without the spr files. I can't say what it would do for linux or mac.

FINALLY!


I am loading the .cpt and .spr files and all the gauges/indicators are appearing in thier proper positions and at thier correct sizes.

I still need to debug and write a file saving function, but a 1st release is coming.

Ok, here it is. A first release, call it alpha, of the Hud Editor. It's rough and buggy, but it is useable. I have done enuff testing to know that it does work. Be sure to read the help for tips on using it.

[EDIT]
Ok, I fixed a few bugs and included the directX files need to run this application. It's at filefront.com now because its too big to upload here.

http://files.filefront.com//;6862551;;/