Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Axem on June 11, 2018, 02:23:43 am
-
It's almost 20 years since FreeSpace 2 was made and we're still stuck with 1024x768 as our highest interface resolution.
How barbaric.
Sure it upscales, but wouldn't it be nice to have crisp and clear interface art?
High res interface for FSO has always been a bit of a chicken and egg thing. Coders won't work without assets, and who would make assets if they're not going to be used?
When I was making JAD2.22 I had the insane idea to make a completely new interface for it (be sure to play it if you haven't! /shamelessplug). Making it (the interface) wasn't that bad, just tedious and motivation sapping. But I planned ahead. I made it so that one day, if 1080p resolutions ever came to FSO, I would be ready!
And as it happened, coders were just waiting for that one day someone would show up with 1080p res art and stuff might get going.
It just took a year for us to realize this missed connection...
Well, I did need a bit of help which MageKing supplied to help cut up the 1080p interface art correctly. I had a series of batch scripts from Water that would cut things up, but it only worked for 1024. But now, we're all good!
Here is a preliminary test "3_" interface set for the pilot selection screen. I'll begin converting more over the next week or so. The slicer folder has the batch script and base images for the lit and hover button sets. The batch script also has the x,y and width and height of the buttons as part of the call to the graphic magick cropping to make them. So for new button coordinates you can just grab them from there.
https://drive.google.com/open?id=1FfAq0kTPf3EAur012EFun8xbiqz24kF7
-
You beauty!! :yes: :yes: :yes:
-
It's unprecedented...
-
It would probably be a good idea to make this new system based on the aspect ratio of the interface instead of hard-coding "3_" to mean 1080p. This might need a new table to make the file name formats configurable by the modder.
I have a lot of free time now so I guess I could try to implement this :nervous:
-
So UI is going to be completely modable like it's been talked sometimes before?
-
I hope so. With arbitrary resolutions of varying screen sizes. Perhaps 3D? Just like Unreal Engine?
-
So UI is going to be completely modable like it's been talked sometimes before?
No, this will only allow the modder to specify user interface image files with a higher resolution. The discussion about a completely new UI system is here: https://www.hard-light.net/forums/index.php?topic=93176.0
I hope so. With arbitrary resolutions of varying screen sizes. Perhaps 3D? Just like Unreal Engine?
If you implement it yourself, sure :p
-
I think there was a LUA scripted mainhall in Starfox SoL that used fs2 missions as background, but it probably won't work on newer builts (and I never checked that).
Q. Why does it require a new table then? Is this due to the different size ratio of widescreen?
-
I think there was a LUA scripted mainhall in Starfox SoL that used fs2 missions as background, but it probably won't work on newer builts (and I never checked that).
Q. Why does it require a new table then? Is this due to the different size ratio of widescreen?
At the moment, the interface is completely hardcoded. We cannot really move controls around (we can fudge locations a bit, but that's about it), we can't really do much of anything with the interface as coders, and modders can do even less. The only way to make the interface customizable is by introducing definitions for it that the engine reads on startup.
-
That's the problem. Later on, we could make it modular.
-
If we get the ability to have full aspect ratio/full resolution interfaces, no matter how clunky... I will personally buy the coder(s) a 6 pack each. I'm not even joking.
-
*cough* https://www.hard-light.net/forums/index.php?topic=93176.msg1861484#msg1861484 *cough*
I would love to work with a modder so that we can actually get that branch ready for merging. It's working pretty well but I will need input by some modders for determining if the system will work properly.
-
I am not qualified to comment on what system to use. All I require is for it to be able to do what we already do, but without the resolution limitations. Play anims, show text, don't mess with mainhalls, use buttons.
Beyond that, if I can figure out creating mainhalls using that clunky table system then I can figure out how to mod using any of these options you linked to.
-
The libRocket implementation I liked to can do everything you mentioned which is also the reason why I prefer it at this moment.
If you want and have the time we could try implementing some UIs with that to see how well it actually works for a modder like you since the system is worthless if it's unusable.
-
Sounds like a plan to me :)
-
Me too. If I only had a spare time available...
-
So, I looked at the UI code a bit to see how easy it would be to add support for dynamic resolutions to the old UI system. Unfortunately, it looks like pretty much all the coordinates are hard-coded for the individual resolutions. That means that a system with proper support for dynamic resolutions would need to have access to all those coordinates.
In my opinion, such a system would be at least as much work to implement as a comparable libRocket solution without all the additional flexibility libRocket provides.
@Axem: I know that adapting to a new system would be difficult but I believe that it would make the UI system of FSO easier to use in the long run. What is your opinion on that topic?
EDIT: I want to clarify that your current work would not have been for nothing. The individual parts of your custom interface should be adaptable to the new system.
-
I sort of figured it wouldn't be easy. If you think this is a great impetus to go ahead with a new interface system then, well... have at it? I mean its your time and sanity at play here!
My only apprehension about libRocket is its another thing for modders to have to learn. I know its HTML/CSS basically, but not all of us are mjn. :p (But maybe with that, you can get mjn into a blood oath contract to make some interface templates that we can later keep reusing for other uses)
-
I thought about how to add support for the higher resolution image files and found two possible solutions:
- Expose the coordinates of each element (button, text, ...) in a table and let the modder specify them
- Add some sort of declarative UI markup for specifying the locations
1. is too specific for the individual UI screens in my opinion so every screen would need a lot of additional table parsing code without actually improving the UI situation much. 2. would be nice but that pretty much replicates what libRocket already does.
I think I'll put together a small libRocket test mod with a short tutorial for the FSO specific features. We could use that as a starting point for developing a template for FS2 style interface elements.
-
Wat. C'mon Axem, you learned LUA for modding!
-
Hope you're ready for 1999 era html FS2 interfaces then. Sign into GTVAOL today :p
-
Has anybody asked one of the TC teams for their opinion? I'd guess it would be used there more likely than in normal mods (maybe beside BTA).
-
The newest version of the libRocket builds are available here: http://swc.fs2downloads.com/builds/test/libRocket/
Here is the test mod I have been using for testing the changes: http://www.mediafire.com/file/eo15507zh0nwdxa/libRocket.zip/file
I also uploaded a mirror of the libRocket documentation since the original is not available anymore.
Main documentation (https://asarium.github.io/libRocket/wiki/documentation.html)
Lua Manual (https://asarium.github.io/libRocket/wiki/documentation/LuaManual.html)
libRocket has a visual debugger which is also available in FSO by pressing "Ctrl+Shift+D".
I also added a special action for reloading the markup of any changed files to make interface development faster. You can use that by pressing "Ctrl+Shift+R".
-
I'll take a look at it...
-
m!m, I loaded up the test mod and I'm not quite sure yet what I'm looking at, but i'm going to read the documentation you linked and see if I can't figure it out. Any tips would be appreciated.
Most of the screen is blank when I start the mainhall. I have an apply button, an anim and some window titles maybe? If i click near the anim I end up at a thing that says "welcome to the second tab!". Seems like some of the UI test is missing.
prntscrn didn't capture the generated UI and FSO failed to save a screen to the screenshots folder....
-
The things you are seeing is my test data which is why there isn't much to see unfortunately. It mostly contains test data for me to test various features of libRocket (for example the animation).
One major difference to HTML is that RML (the markup language of libRocket) supports templates which are very useful for things like styling windows consistently which will be very useful for maintaining that FS2 UI look.
-
From the tutorial file it looks like I should be able to select something (fonts?) and press Apply. In game all I get is the Apply button. Is that correct?
Additionally, how did you get that apply button to work like that? It's a single image file. There are a few lines that jump out as possible ways you told the RML to use just a portion of the image.. just looking for clarification. This feels like I need to reverse engineer this to be able to try and build something new.
-
As far as I can tell, the <select> isn't showing up in the UI, I'm guessing because the RCSS (or RSS?) code for it is missing but haven't really looked into that.
The whole UI appearance is defined by the RCSS, both which image to use as well as which area.