Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Rampage on July 12, 2003, 07:31:56 pm
-
I have had this thought for some time now. Why not eliminate HUD.TBL? It really serves no other purpose than act as a master list for all shield icons.
What we can do is allow FS2 to automatically search the appropriate shield icon when needed, like it does with the other features.
NOTE: This probably would take a lot of work to implement.
-
not haveing actualy looked at the code in question, I should say, no it shouldn't be too hard, though it might be doing something weird with the files, so I'm not going to say definitivly yes it's easy, now as for eliminateing the HUD.tbl, I don't think we should get rid of it but rather we should make it more useful as a full out listing of the names and locations of all hud graphics, but, I can't do it right nowgiven a number of small problems.
-
The hud.tbl file should be extended to define the layout and content of the HUD. As a further extension we could probably also set it to allow different HUD's for different ships, and put in the structures necessary if 3D huds are ever implemented.
-
I agree there, UP, I've been asking for this for a while, as I need to be able to redefine where the various gauges are, and what not.
-
it would indeed be very nice to have multiple huds for different ships, and moving the gauger around is even better.
-
This is something else I've been looking for in the FSSCP-- species-independant HUDs. Think about Halo or Perfect Dark, where weapons by different species have slightly different targeting reticules. Terran ships will use the standard HUD, but someone would have to redesign the HUD for Vasudan and Shivan ships, and possibly Ancients too.
Whether this should go into the HUD.tbl, I don't know. It would probably be best to create an entirely new table for custom HUDs, as the current HUD.tbl is not used for gague placement and such.
As for eliminating the requirement that the shield icon name be listed in the HUD.tbl... by all means. The game should be able to find the shield icon without needing it listed in a table! Unlike sounds.tbl, which has lots of important information about that particular sound, the HUD.tbl only lists the name.
-
I suggest using a tru HUD.tbl in conjunction with an expanded species.tbl.
The HUD.tbl would contain a number of templates, while the species.tbl will group and assign them to the relevant specie.
-
The TBP HUD might be good for Shivan ships.
-
You think you could implement support for vector graphics via HUD.tbl? Like SVG, so people can code in the GUI and not use raster files. Nice and scalable too
-
no we can't, becase vector graphics look like **** and are hard to work with.
:)
-
Bobbau, this is one of the rare events when I have to disagree with you.
You're right they are hard to work with, but they can look quite good.
On the other hand bringing a true vector based hud would be real hard.
I already suggersted this before in the new resolution thread:
Use vectorgraphics for the definition of the HUDs and ect.
Then when the game starts convert those to orfinary bitmap pictures.
This way the graphics could be converted to any resolution, thereby we could finally manage a whole range of resolutions.
On the otherhand if someone was crazy enough to bring 2D vector graphics support to the engine I'd more then welcome it.
I'm not speaking of spiky low end vector graphics, I'm speaking of stuff Corel Draw can do.
-
If we're going to do multiple resolutions, we can just scale up the standard PCX art. It might not look that great, but it works.
-
Originally posted by GalacticEmperor
As for eliminating the requirement that the shield icon name be listed in the HUD.tbl... by all means. The game should be able to find the shield icon without needing it listed in a table!
That's exactly what I want. :p
-
I also thought of that.
However I think scaling down would be better.
So artists should make a 1600*1200 version.
That should satisfy anyone.
Moreover it would be good if other (more economic size wise) formats were supported other than PCX.
-
Originally posted by Bobboau
no we can't, becase vector graphics look like **** and are hard to work with.
:)
Hard to work with? Perhaps.
Look like ****? Only if you don't know what the **** you're doing. Vector graphics, done well, look good at every resolution, because they don't go grainy as you zoom them up, and they don't lose detail when you scale them down. They only look like **** if you don't do the art right in the first place.
-
I wonder....
Could you imagine what it would be like to make vector graphic texture support.... :devil:
Dream on loony boy:sigh:
That way the Orion would look uber cool at all resolutions.
It would need quite some hardware though.
-
vectors for textures sound a bit impossible and unuseful (textures can be realized with vectors (my textures are usually 70% vectors) but there also is a lot of bitmap work (shadings, dust, scratches etc) required to make a texture nice looking; and I really don't see how an actual engine designed to work with bitmap textures can handle vectors)
but it sounds good -if it is possible- for the HUD (more ingame resolutions!! yahy!!). I just don't understand if you are talking about support for vector image formats or about having the hud aspect defined via code
-
I'm all in favor of a vector based HUD.
Other displays - namely the interface for everything in the game except the mainhall should benefit from it as well.
-
AHEM.
Moving away from vector graphics, how about we get back on topic with some discussion of some fun and useful stuff? Like eliminating the HUD.tbl, and adding custom HUDs. Can it be done? Will it be done?
-
Did anyone read my recommendations to have the engine scale up the old art to crate new resolutions?:doubt:
-
I did Woolie, beside it was already suggested a while ago.
As for deleting the HUD.tbl, I'm against the idea.
Instead it should be made into something useful as Bobboau already said.
-
But what do you think of that idea?
-
The problem with scaling up a texture is that you have to use quite advanced filters to improove the quality and the results may still not be satisfactory.
Scaling down a texture on the other hand doesn't suffer from that problem.
Furthermore if you want to do that in game, those filters would take up much CPU time.
If you want to temporarlyt create all the icons and ect. when starting the game, then scaling down is just as good HD wise.
-
Originally posted by Bobboau
no we can't, becase vector graphics look like **** and are hard to work with.
:)
to an extreme opinion I'll oppose an extreme exemple:
http://juniatwork.mrtio.com/index.php
I'm not talking style, I'm taking technic here. all the pics are vectorial, yup, t²hose chicks are vectorial.
Just to say that with illustrator, or even flash, you can do l33t things.
-
having the game engine scale the image is not as cpu intensive as you might think. video cards are always creating scaled textures for use as mip maps, its one of the reasons we have such awesome framerates. once the image has been scaled it is stored in memory (wether it be system, video, or virtual memory) and the cpu needs not touch it again except to use it. all textures are kept loaded in memory anyway. the images would simply be scaled as part of the loading process.
as i understand the way the hud works, the ani files are used as textures on top of a hard coded 2d polygonal mesh. the mesh then deforms its self to create moving gauges such as the weapon energy gauge. i think that this mesh should be editable so that modders may create gauges anywhere on the screen they want, in any shape they want. then define how the mesh deforms.
an alternitive to rendered gauges would be pre rendered, or animated gauges. this is similar to how microsoft's flight simulators (any of them) work. they are kinda cpu intensive, but they work. you simply have frames of different gauge readings. the frame index then counts up or down. for example you could have a 100 frame animation of an afterburner energy bar the first frame shows the gauge reading 0%, the second frame indicates 1% power, the third indicating 2% and so on. so if you have 50 percent power, then ani frame number 51 is used. of course 100 frames is a few too many, so you may only use 20 frames and round to the nearest 5%.
-
Nuke I was not refering to the sheer scale up of textures.
Instead I was speaking of the refining of those scaled up textures, 'casue those things can look downright bad.
BTW Freespace works preety much the same way with the anis.
The frames you were refering to are there just like that.
Check out a shield.ani you'll know what I mean.
-
well venom, now i know what i'll try to do with photoshop as soon as i'll have some freetime....thanks;)
-
I agree that re-resolving textures would be a bad idea in-game. There are photoshop filters that could resize the current game textures, it examines the layout of colour, creates curves and treats it as a vector graphic for resizing. It's not perfect when asked to double the size of smaller textures (256 x 256) but it is possible, I suppose, to increase the resolution of the in-game textures this way and then replace the in-game ones. This would be having another zip to download on top of the glowmapes though :( And I'm not certain how much difference it would make in-game, you would probably barely notice most of the time.
Flipside :)
-
Hmm...I wonder.
Do these filters indeed do wonders?
If yes, then I wonder if a scaled up version of the original FS1 mainhalls could be created.
BTW a no.1 priority on my to be upgraded in FS is a resizing method for anis.
If we could put together a fairly decent resize and filter method for ani (and avis) then the whole game's outlook would be upgraded.
I think DirectX already has something, some DX guru should be asked.
-
by Flipside:
And I'm not certain how much difference it would make in-game, you would probably barely notice most of the time.
On fighters,probably (except in a very near dogfight), but on capships, you'll certainly notice it; at least I think so.