Home » MODDING HQ 1.13 » v1.13 Coding Talk » RII - Resolution Independent Interface [UPDATE :RII v4f]
|
|
|
|
Re: RII - Resolution Independent Interface[message #205893]
|
Thu, 08 January 2009 21:11
|
|
BirdFlu |
|
Messages:438
Registered:September 2007 Location: Lampukistan |
|
|
I previously promised details on the new XML files. Here they are.
1. Introduction
The graphical user interface can be seen as consisting of three components. These components are the structure, the layout and the function of the GUI. The structure is the set of all GUI elements like buttons, images, regions, text areas, etc. The layout describes where the single GUI element is located on the screen. Some elements are functional, like buttons and regions, in the sense that they react somehow when a mouse cursor is hovering over that element and alternatively a mouse button is pressed or released.
The idea of this project is to externalize the layout of the GUI. The structure and the function remain hardcoded. This approach is relatively simple to implement as the positions of the single elements, and also futher properties, can be defined in an external file. This data is then read in on program start and can then be used during the rendering process. The structure of existing code remains the same. Therefore, the introduction of new bugs should be minimal and mostly be restricted to misaligned GUI elements.
2. Type hierarchy
There are several GUI elements accessible through the XML files and they have the following basic form
Element names have to be explicitly defined in the code, so only registered elements can be accessed from outside. Names have to be unique for all registered elements. The type of an element can only be one of the following values
"Node", "Surface", "Image", "TextArea", "Button"
The types build a hierarchy starting with Node. The hierarchy can be seen as a IsA relationship. So, a Surface is a Node, an Image is a Surface, etc.
Node
`- Surface
|- Image
|- TextArea
`- Button
2.1 Node element
Depending on the type, several properties can be defined. The Node element has only the 'offset' property that defines a displacement to another Node element. If no other element is given, then 'offset' is the displacement to the screen origin (0,0) or (left,top).
When the offset property is not defined, then the 'x' and 'y' values are set to 0 by default. You can also define only 'x' or only 'y', the missing one gets the default value.
2.2 Surface element
As a Surface is a Node, it inherits the 'offset' property, but it also defines a 'size' property
Both width 'w' and height 'h' have to be defined, as no default value would make much sense. It is though possible to explicitly set a value of 0. The reason for this is that the 'size' property is not always fully evaluated (only width is required, for example). Sometimes a surface element is supposed to contain some text. In such cases it is desirable to define the height of this surface depending on the used font. To do that you can replace 'h' with 'fontheight'
where the value of 'fontheight' has to be one of the registerd fonts (see section about element type TextArea).
2.3 Image element
An Image element is a Surface and thus has the two properties 'offset' and 'size'. Additionaly it lets you define a video object by specifying a filename of a STI image file.
As STI is multi-image file format you can also specify the subimage with the 'subimage' attribute. Obviously the value of 'subimage' has to be nonnegative.
2.4 TextArea element
The TextArea element allows you specify the appearance of the text that is supposed to be rendered inside.
You can specify the font by setting the value of the 'fontname' attribute to on of the values from the following list
"LARGEFONT1", "SMALLFONT1", "TINYFONT1", "FONT12POINT1", "CLOCKFONT",
"COMPFONT", "SMALLCOMPFONT", "FONT10ROMAN", "FONT12ROMAN", "FONT14SANSERIF",
"FONT10ARIAL", "FONT14ARIAL", "FONT10ARIALBOLD", "FONT12ARIAL", "BLOCKFONT",
"BLOCKFONT2", "FONT12ARIALFIXEDWIDTH", "FONT16ARIAL", "BLOCKFONTNARROW", "FONT14HUMANIST"
You can also specify the foreground and the background color of the font. The 'background' attribute can be one the colors from the following list
"FONT_BLACK", "FONT_BEIGE", "FONT_BLUE", "FONT_LTBLUE", "FONT_LTGREEN",
"FONT_LTRED", "FONT_RED", "FONT_WHITE", "FONT_YELLOW"
Additionaly you can set the values
"MAP_BOTTOM_COLOR" = 32 * 4 - 9
"CHAR_TITLE_COLOR" = 6
"CHAR_TEXT_COLOR" = 5
Instead of the given symbolic color names, sometimes index values from the palette of the font are used in the code. Thus, you can omit the 'foreground' attribute and instead specify the 'foregroundindex' attribute that takes nonnegative integer values.
2.5 Button element
The Button element lets you specify multiple button specific properties. Additionally to the obligatory 'offset' and 'size' properties the Button element also accepts the 'buttonimage' and 'buttonstate' property.
Similar to the 'vobj' property of the Image element, the 'buttonimage' property also accepts the path to STI image file that contains the required images for the different states of the button. These states are defined in the 'buttonstate' property, where the attributes 'grayed', 'off_normal', 'off_hilite', 'on_normal', 'on_hilite' can take a nonnegative integer value that corresponds to a valid image index in the given button image file. If an attribute is omitted its value is set to -1 by default.
3. Layout hierarchy
The section about type hierarchy defines how one GUI component can be described in an XML file. This section is about the definition of many GUI components and its logical grouping.
A relevant relationship between two components is the relative distance of their origins on the screen. This distance doesn't change when one component is moved, which consequently means that the other element has to be moved too. In this situation one component can be considered as a root node to the other component and it is describes in the XML file in the following way
With this approach it is possible to move or position a whole group of elements by just offsetting their root node. Since every GUI component type is a "Node" it can be a parent or root node of many other GUI components.
Currently a layout hierarchy of the Map Screen is defined in the code and is accessible via an XML file. The hierarchy is not enforced though, that is when an element is declared as a child of another element in the XML file it is not tested whether this corresponds to the definition in the code. This allows to just write down every element as a plain list, but it is harder to "see" the relationship in the XML file. To do so, you have to look it up in the code. So this leaves us with three possibilities.
- leave it as it is
- remove the layout hierarchy and just keep the plain list
- remove the hardcoded hierarchy and implement the possibility to dynamically define the parent/child relationship for two elements and so allow to build custom hierarchies
That's it. Should be enough to understand what is going on in the XML files. So, open the files, change values and see what happens.
PS. I didn't write a list of all possible element names, but you can look them up in the XML files.
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
Re: RII - Resolution Independent Interface[message #206001]
|
Sat, 10 January 2009 13:46
|
|
BirdFlu |
|
Messages:438
Registered:September 2007 Location: Lampukistan |
|
|
The SM images, as far as i have seen it, are not directly referenced in the code. They are processed with some generic tileset handling functions, i guess. And the images are soooooo tiny anyway that giving each one an own palette is like going from ugly 50 pixels to some not so ugly 50 pixels, but what do i know.
Splitting MD images, on the other hand, should be relatively simple.
And rendering rgba images is problematic in its own way. Multiple rendering of one rgba image can have different results. This is so, because the result depends on the image itself AND on the surface you want render to. If you render the rgba image two times the surface has to be identical both times. With rgb rendering this is not a problem, since you overwrite whatever was there before. With rgba rendering, however, you blend the image with the surface AGAIN. To void this you would have to rerender the other surface too. And, the more rgba images you have on the screen at one time, the more you have to rerender stuff. This would probably require some modifications to the rendering code. So, keeping the rgba images at a low level would be advisable.
Edit :
Here are the splitted images
MD sti images
MD png images
We gotta start with something.
[Updated on: Sat, 10 January 2009 15:25] by Moderator Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Re: RII - Resolution Independent Interface[message #206583]
|
Sun, 18 January 2009 08:46
|
|
Kaiden |
|
Messages:504
Registered:September 2003 |
|
|
You got it too MM, maybe it can get hosted somewhere and not lost. I'm sure it's on Nitrat's site somewhere, but I've never found it anywhere. I got it from someone off the Basis forums years ago.
@Kaerar, by crippled, I mean it's the same source with all the strategic stuff commented out, I think some of the original JA2 source files are missing, and I'm sure some code was just flat out deleted instead of commented. I also think the hacked things together in UB worse than they did in the original JA2.
On the other hand, there are some nice things to say about UB, like um well, it has snow. So it's highly possible that someone may consider porting 1.13 over for those who like... snow.
Now back to your regularly scheduled thread about dynamic resolutions (woot).
Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
Re: RII - Resolution Independent Interface[message #209720]
|
Wed, 04 March 2009 23:31
|
|
BirdFlu |
|
Messages:438
Registered:September 2007 Location: Lampukistan |
|
|
jaggyHi, BirdFlu. Managed to download it at work. This will not work with revision 2124, right? Tried it but it crashes to desktop. Any chance of getting this to work with earlier revisions? Too far into the game to want to start all over again. Thanks in advance. Theoretically, it would be possible to backport my stuff to older revisions, as it doesn't really rely on much. But practically, there is no easy, automatic way to do this. I would have to merge the two revisions manually, meaning working on something that is already obsolete. And if I had to choose, i would rather work on the future than on the past.
And anyway, this project is still in a very early stage with a lot of things not working properly. You probably wouldn't want to play a whole game right now.
Report message to a moderator
|
|
|
|
Re: RII - Resolution Independent Interface[message #210464]
|
Wed, 18 March 2009 03:13
|
|
BirdFlu |
|
Messages:438
Registered:September 2007 Location: Lampukistan |
|
|
Ok, here is the new version (Alpha_V3) of this mod (based on SVN revision 2624).
This update contains little RII related code, it only fixes the time display when planning a path on the strategic map. The rest is completely new stuff, which is
- VFS : Virtual File System
- Conversion of SLF archives to 7z (.jdc.7z) archives (with additional STI to PNG conversion)
- Loading and Drawing PNG files
- Splitting MDGUNS.STI, MDP1ITEMS.STI, MDP2ITEMS.STI, MDP3ITEMS.STI in separate STI files
Here the same with a little more details.
VFS :
There has to be a new file (vfs_config.ini) in the directory of the executable file. I provide three example files that implement three different configurations. One that uses the old SLF libraries and two that use the new 7z archives. You have to rename one of these files to "vfs_config.ini" or the game won't start. Inside the vfs_config.ini you will find several (non-commented) sections. In the first section (vfs_config) you define which profiles will be looaded.
[vfs_config]
PROFILES = SlfLibs, Vanilla, v113, RII, UserProf
Each Profile has a name ("NAME="), a link to the real file system ("PROFILE_ROOT") and a list of locations
[PROFILE_SlfLibs]
NAME = SLF Libs
LOCATIONS = Ambient, Anims, ...
PROFILE_ROOT =
[PROFILE_Vanilla]
NAME = Vanilla Dirs
LOCATIONS = data_dir
PROFILE_ROOT =
A location is a place where data files can be found and is defined by a location type ("TYPE="), that can be either "DIRECTORY" or "LIBRARY", a mount point in the VFS ("MOUNT_POINT=") and the path to the actual location (directory or archive) specified relative to the PROFILE_ROOT. In the case of a library there is an alternative way to specify the path ("VFS_PATH="), where the archive file will be searched in the VFS first, and when unsuccessful default to the "PATH=" entry.
[LOC_RII_dirs]
TYPE = DIRECTORY
PATH =
MOUNT_POINT =
[LOC_Ambient]
TYPE = LIBRARY
PATH = Data/Ambient.slf
VFS_PATH = Ambient.slf
MOUNT_POINT =
There is one "special" profile
[PROFILE_UserProf]
NAME = Player Profile
LOCATIONS =
PROFILE_ROOT = Profiles\UserProfile
WRITE = true
that is defined as writeable. You won't (should not) be able to write any files when you don't have a writeable profile. This profile is supposed to contain user data, like temporary files, config files and also savegames. Make sure you have at least one writeable profile, and one of these profiles should ideally be on top of all other profiles (rightmost profile in the vfs_config.ini file).
SLF -> 7z :
In order to use the new 7z archives you have to create them first. There is a second executable file (Ja2Convert.exe) that can do this for you. There are also two batch files (convert.bat, convert_nopng.bat) that calls Ja2Convert.exe with different parameters and converts all slf archives. The new 7z archives are written into the directories "Profiles/libs" and "Profiles/libs_png" that are also referenced in two of the three vfs_config.ini files.
STI -> PNG@7z :
Creating PNG files is nice, but using them in the game is even nicer. Actually, whenever a STI file (filename.sti) should be loaded, i first look whether there is a .jpc.7z (filename.jpc.7z) counterpart. When there isn't one, i load the STI file. Right now the conversion is as straight as possible, meaning that paletted STI images will be converted to paletted PNG images. To be more precise, one STI image is converted into an 7z archive where the subimages of the STi file will be stored as separate PNG images (named 0.png - n.png, or 00.png - nn.png). When there is additional data stored in the file, it will be written to the file "appdata.xml" and also stored in the archive. Non paletted STI images are written as 24 bit rgb files (0.png@filename.jpc.7z). These are mostly loadscreens, but also a couple of other files too.
MDP :
I splitted the files MDGUNS.STI, MDP1ITEMS.STI, MDP2ITEMS.STI, MDP3ITEMS.STI into separate STI files and load these file into their own 'VideoObject's. There isn't really much more to say about it.
Have fun.
EDIT : forgot the things that are not working
- videos are not working (different file calls, not the regular FileOpen, FileRead function). will have to take a closer look at it
- multiplayer is not working, because of the ini file (that i don't evaluate now)
- only enhanced description box is working, in the regular box i seem to have forgotten to load the background image (probably lost during merging)
- stuff that didn't work in older versions
[Updated on: Wed, 18 March 2009 03:44] by Moderator Report message to a moderator
|
|
|
|
|
|
Re: RII - Resolution Independent Interface[message #210467]
|
Wed, 18 March 2009 03:21
|
|
CptMoore |
|
Messages:224
Registered:March 2009 |
|
|
Questions about 24bit pngs? Can I use them for the gun images? And the loading screens?
Just asking, me don't need no features (yeyeye, hollywood english at its best with double negative only counting as one).
Report message to a moderator
|
Sergeant 1st Class
|
|
|
|
Goto Forum:
Current Time: Fri Mar 29 10:16:14 GMT+2 2024
Total time taken to generate the page: 0.02468 seconds
|