Hard Light Productions Forums
Archived Boards => The Archive => Mjn.Mixael's Render Boutique => Topic started by: BirdofPrey on February 23, 2015, 03:39:52 pm
-
I figured you'd be the guy to talk to for this.
I am working on redoing the FS1 interface for widescreen support and have made some progress, but there are a couple of items that I am a bit uncertain what to do about and want to avoid duplicating work.
I started on the command briefing screen so I could be sure the briefing anis would fit (they do, yay). I have the basic frames and unlit buttons done.
I still have to do the text and the fine details (there are what look like wire traces leading to the buttons, and the frame appears to be a rough texture. I also need to do the background and get the GTA banner up which is where I need some help.
I think somone already has a FS1 era banner since the banner in FS:Port has a different insignia than the stock FS2.
I am also wondering if anyone either has a reasonable fascimile of the interface background or at least knows a good way to generate (in GIMP) a new one that matches.
Right now it's 1920x1200 but I've made it so I can crop it to 1920x1080 easily to cover both aspect ratios without too much extra work.
Once the base frame is done, I can add button light-up and the fade in animation (iirc, the main frame fades in and the buttons at the bottom right slide into place from off screen edit: so after checking apparently only the mission briefing has an animation for fade in). After I can work on mission briefing and loadout screens where I should be able to reuse the background.
Here's what I have done so far
(http://i209.photobucket.com/albums/bb169/ghostbirdofprey/command-brief.png) (http://s209.photobucket.com/user/ghostbirdofprey/media/command-brief.png.html)
a cut and paste mockup of where stuff's supposed to go
(http://i209.photobucket.com/albums/bb169/ghostbirdofprey/command-brief-mock-1.png) (http://s209.photobucket.com/user/ghostbirdofprey/media/command-brief-mock-1.png.html)
and what I am trying to recreate
(http://i209.photobucket.com/albums/bb169/ghostbirdofprey/CommandBriefOriginal.png) (http://s209.photobucket.com/user/ghostbirdofprey/media/CommandBriefOriginal.png.html)
Any help you may be able to give with this?
Also I know the color matching is a bit off at this point. I started with something workable first, accuracy is for later.
-
I do have all the assets you would need... However, FSO does not currently support hi-res interface files. You can do 640x480 or 1024x768. Before this project becomes worth anything, you'll to convince some coder to basically overhaul the interface code... That's something that has been talked about for a long time but hasn't gone anywhere because that's a big project.
-
Ah well crap.
Guess I'll just save the project file for later. Filed under "Eventually *shrug*
-
You don't necessarily have to stop working on it; having assets already made would make it a lot easier to convince a coder to work on overhauling the interface code.
-
It's more complicated than that, though. Every time it comes up, there's a debate about what format to use? Extend the current system? HTML5? Table based? So then, how do you split up your assets? I suppose he could just draw everything in vector and then wait for some unknown time that it could be used.
-
Sounds like people are MAKING it more complicated than it needs to be.
The format for the images is simple enough: there's the base background image, a mask where each button is and then animations for each button along with a help overlay, and a fade in animation for the mission briefing (in FS1 at least). A system could be implemented that doesn't need the mask, but you pretty much need the rest of the elements in more or less the same format (an alternate for animations at least is stills for, default, mouseover and clicked; the ani just contains all three in one file, but you'd need to generate each image ANYWAYS to make the animation)
If I am not mistaken, the primary limitation of the current system is it's hardcoded rather than a separate table, so modifications would only be in the form of making new graphics (correct me if that's wrong). A table would let you define multiple resolutions and choose the proper image set for it. I don't know why we would use HTML for that. It means learning a new language to use, adding support for another format (do you really want to add a web-browser to FSO?), and most of the things you could accomplish with it are already done by the code anyway.
Might I ask what the limitation is currently preventing the use of larger resolutions under the stock system?
It's usually better to work in steps anyways, just allowing larger images to be utilized is probably good to do before adding support for more options and buttons that weren't in retail and would be the biggest improvement already.
-
I don't know why we would use HTML for that. It means learning a new language to use, adding support for another format (do you really want to add a web-browser to FSO?), and most of the things you could accomplish with it are already done by the code anyway.
Because it's already been done (http://www.hard-light.net/forums/index.php?topic=87130.0); I think it basically just needs some engine hooks to allow it to replace the current interface.
-
Sounds like people are MAKING it more complicated than it needs to be.
The format for the images is simple enough: there's the base background image, a mask where each button is and then animations for each button along with a help overlay, and a fade in animation for the mission briefing (in FS1 at least). A system could be implemented that doesn't need the mask, but you pretty much need the rest of the elements in more or less the same format (an alternate for animations at least is stills for, default, mouseover and clicked; the ani just contains all three in one file, but you'd need to generate each image ANYWAYS to make the animation)
If I am not mistaken, the primary limitation of the current system is it's hardcoded rather than a separate table, so modifications would only be in the form of making new graphics (correct me if that's wrong). A table would let you define multiple resolutions and choose the proper image set for it. I don't know why we would use HTML for that. It means learning a new language to use, adding support for another format (do you really want to add a web-browser to FSO?), and most of the things you could accomplish with it are already done by the code anyway.
Might I ask what the limitation is currently preventing the use of larger resolutions under the stock system?
It's usually better to work in steps anyways, just allowing larger images to be utilized is probably good to do before adding support for more options and buttons that weren't in retail and would be the biggest improvement already.
See, not necessarily. What you described is how FSO currently works. Now let's clarify that. That's a hardcoded system that references almost 1000 files. Very simply, that's just not easy to work with. How would you change that to a table based system? That's a massive table file. That's a massive code patch just to change file references to table-based... not even included the necessary position values and who knows what else.
So if you are going to remake the whole interface based on FSO's current system, that defines how and what you are making. (Essentially replacements for those 1000 files.) But if the interface were something more moddable like HTML5 then you could cut that down significantly. For example, use one background image file for the whole interface and then FSO can place buttons and masks on top of it, like rendering a webpage. Suddenly, in this case, you wouldn't make a 'Command Brief' screen and a 'Loadout' screen. You'd make the background. Then you'd work on some basic button design (with variation, probably). Maybe some screen-specific art, if necessary. And then use a table to put the pieces together. It's a very different process, and one that is far, far easier to create for. I'm not saying that HTML5 is the answer. I'm saying that simply converting the hardcoded stuff to a table would be a bear.. not only to code, but to work with.
-
I don't know why we would use HTML for that. It means learning a new language to use, adding support for another format (do you really want to add a web-browser to FSO?), and most of the things you could accomplish with it are already done by the code anyway.
Because it's already been done (http://www.hard-light.net/forums/index.php?topic=87130.0); I think it basically just needs some engine hooks to allow it to replace the current interface.
Oh, well if it's already done, that's different.
Sounds like people are MAKING it more complicated than it needs to be.
The format for the images is simple enough: there's the base background image, a mask where each button is and then animations for each button along with a help overlay, and a fade in animation for the mission briefing (in FS1 at least). A system could be implemented that doesn't need the mask, but you pretty much need the rest of the elements in more or less the same format (an alternate for animations at least is stills for, default, mouseover and clicked; the ani just contains all three in one file, but you'd need to generate each image ANYWAYS to make the animation)
If I am not mistaken, the primary limitation of the current system is it's hardcoded rather than a separate table, so modifications would only be in the form of making new graphics (correct me if that's wrong). A table would let you define multiple resolutions and choose the proper image set for it. I don't know why we would use HTML for that. It means learning a new language to use, adding support for another format (do you really want to add a web-browser to FSO?), and most of the things you could accomplish with it are already done by the code anyway.
Might I ask what the limitation is currently preventing the use of larger resolutions under the stock system?
It's usually better to work in steps anyways, just allowing larger images to be utilized is probably good to do before adding support for more options and buttons that weren't in retail and would be the biggest improvement already.
See, not necessarily. What you described is how FSO currently works. Now let's clarify that. That's a hardcoded system that references almost 1000 files. Very simply, that's just not easy to work with. How would you change that to a table based system? That's a massive table file. That's a massive code patch just to change file references to table-based... not even included the necessary position values and who knows what else.
So if you are going to remake the whole interface based on FSO's current system, that defines how and what you are making. (Essentially replacements for those 1000 files.) But if the interface were something more moddable like HTML5 then you could cut that down significantly. For example, use one background image file for the whole interface and then FSO can place buttons and masks on top of it, like rendering a webpage. Suddenly, in this case, you wouldn't make a 'Command Brief' screen and a 'Loadout' screen. You'd make the background. Then you'd work on some basic button design (with variation, probably). Maybe some screen-specific art, if necessary. And then use a table to put the pieces together. It's a very different process, and one that is far, far easier to create for. I'm not saying that HTML5 is the answer. I'm saying that simply converting the hardcoded stuff to a table would be a bear.. not only to code, but to work with.
Ah. I guess maybe I was coming from the wrong angle. I was coming from the side where each screen has maybe a dozen buttons, then you need to reference where it is, what it does, and the animation to use, and also specify other assorted things like the animation window, briefing text, and loadout icons (and scrollbars and text etc.), so, per screen, it's not too horribly bad. I'd never work on the entirety of an interface table at once anyways, just like when making a ship, you only modify the section for that ship, and can ignore the rest of it, so from the user perspective referencing a thousand files in the table doesn't seem all THAT daunting . I guess I didn't realize what back end would have to be done, though regardless of what format is chosen there's a fair amount of work to be done regardless since it IS a baked in system. (again what is the limitation that prevents the current built in code from accepting larger images for the same items?)
Really The discussion what to do doesn't need to go much further than what has the most work to benefit ratio.
Still I think it's something that does need to get done at some point simply because it's old, inflexible and not very mod-friendly.
On a side note, how does HTML 5 handle compositing? I know a bit about older HTML version but haven't done anything in 5 yet, last time I worked with HTML each button was basically the entire button area since images didn't overlap, can 5 just overlay the button lights OVER the existing button images?
Maybe you should send over those files, though, while I was waiting for the initial response I finished the button glows so it's already a 90% complete mockup (only missing background, banner and the frame texturing)