about images bit
 

Previous posts


yes, but the largest background textures ingame without alpha are ONLY the three-four we mentioned ( CLog.tga , MOrderBgnd.tga , RadioMsg.tga and BackPap2.tga ) so only these three-four can be reduced to 24-bit as concerned the ingame big images. (do you know if there is a way that we can reduce a tga image to less than 24-bit without losing its quality ?).
I insist on the ingame big images becuase i have the sense that all the rest big background images (for the menu screens before entering the game) are not running when you play the game.Is this correct or they are running all the time ?

about the small images-items
can you explain this a little further ? as i get it ,you are saying that we can have an alpha channel without the image being at 32-bit. What do you mean by "textures either are alpha-channel themselves" ? To make more clear my question: All of the items that you see at , for example , periscope station need alpha channel (buttons,clock...etc) so, can we have them without being at 32-bit ? Can you give an example of a specific small item that appearing on periscope station and doesn't need an alpha channel ?

this is a very good idea , have you eliminate these crops at your setup ? if yes , what was the gain at ram usage when you are ingame ?

I'm afraid that all textures in the game are loaded into RAM, both from the menu and from the actual game. I think so because copies of these images are in the memory of VRAM, and this usually means that the originals are in RAM at the time of their first use. This probably means that large 2D textures occupy RAM memory even when they are not needed. However, I am not 100% sure about menu background images. However, all 2D simulator images are sure to be in the memory because during screen switching there are no disk operations or caches that could cause re-loading of images from files.

Some small files working as alpha channel for background images without alpha channel e.g. night filter mask.
You can make even 7-bit gray texture with 1-bit alpha but SH3 engine cannot use that file. The game uses only simple truecolor images with an 8-bit alpha channel or without. You probably can not even apply bitmap compression in files, although I have not tried it. This could give about 25-50% savings for large background textures.

No. You're right. All overlaid non-rectangular objects taken from textures require an alpha channel.

Yes, I removed unused texture parts or split to two files with remove crops in menu1024x768.ini. But I did it not for the memory savings because here it would be little or none.

Most savings result from multiple use of the same texture for different purposes and removal of all unnecessary parts of it. For example, a periscope correctly uses a quarter of texture properly rotated using the Crop command with the correct positioning of each quadrant instead of using one huge texture with a small area of transparency as in the older Conus GUI where a large unnecessary red_ws.tga mask with the entire screen size was used for the left upper quarters even without switching off the others. The syntax of menu1024x768.ini allows for a lot of manipulation and even memory savings.

hello Olamagato,
thank you for all the info that you are sharing,

i turned all the large images that not needed alpha (including menu screens ...etc) from 32 to 24-bit and the gain at ram that i saw was not something really worthy.
the values i saw running a full modded stock game ( with viib uboat from wise,full interior , my ui at 1680x1050 and MEP v6) was:
Ram usage by sh3.exe at attack periscope station (in torpedo training mission) was 1.687mb with the images at 24-bit against 1.688 mb with the images at 32-bit.
I also split to separate images all the small items appearing on attack scope page ( i mean the parts from the bottom area of periscope.tga)

if by "bitmap compression" you mean the compress (RLE) button that exists in the tga save settings in paint.net ....yes it can be done. (i have done it so in all magui's images). If you mean something else , i can't say.

Exept night filter mask (you mean the Night_filter.tga right ?) and the StrTactMap.tga, have you noticed any other image with that behaviour ?


i used the windows task manager for monitoring the ram usage by the sh3.exe so i don't know if this is valid at all. Is there any program that shows ingame at real time the ram usage ? (i found on net many programmes ,such as msi afterburner, which display the ram ingame but all of them display the whole ram usage and not only the ram by sh3.exe)

I also worked on this issue since I ran on RAM problems with WAC. Now I prefer to reduce image depth to only 256 colours with irfan view. The amount of RAM usage decreased a lot since I used this method for over a year now. But to gain some megabytes you have to rework many images.

In my 1360x768 resolution on my GUI saving on 16 files reduced from 4 to 3 MB was about 10 MB in comparison to the original GWX GUI working at 1024x768 resolution. And in fact, it's not much, although when they are missing a few MB, saving them is how to play or not to play.

Yes.
Yes.
Redmask.tga

External debugger or profiler only.

ok , i made a final test just for see if ram usage ingame is influenced by the menu screens before entering ingame.
The test took place on gwx with only one mod installed, my 1680x1050 ui.

The ram usage (in both cases) is measured when i was at att periscope station in torpedo training mission at the exact same ingame time.

The first pic is showing the ram usage with all menu screens at 32-bit

Then,i pushed all menu screens to the extreme less i could make them ( decrease color depth to 2 colors only black/white ) and left everything else (which appearing ingame) untouched.
The second pic is showing the measure of ram usage at this case

https://www.mediafire.com/convkey/68...d8rzelzl6g.jpg

From the results, i see that menu screens are not influencing the ram usage ingame so i don't believe that from menu screens could be any gain at the ingame ram usage.
Something that i noticed from the case of reduced depth of images is the faster loading time to get me into the main screen (propably becuase of the very lower mb that they had in total).

What do you think ? is my way of checking menu screens valid ?


EDIT: I am wrong, i think i figured out what is going on but i have no solution yet. There is no difference in RAM usage at my previous test becuase the quality of images is also altered via menu.ini at their MatFlags and TexFmt lines and ,as i didn't changed these lines at the test, the output was the same in both cases.
By changing the matflags i saw a difference of about 20mb at ingame ram usage so it seems that you are right at the statement that menu screens are also loaded even ingame.
As i never figured the logic behind the Matflags and TexFmt i picked up a combination (MatFlags=0x21 ,TexFmt=0x9) that worked excellent in all images.But now it seems that these values are responsible for ram wasting so must become understanable.
Searching for such code , i found this: https://stackoverflow.com/questions/...-notation-mean
but it seems that sh3 devs have built their own logic on these mysterious "0x..."
Maybe anyone around here knows something more to enlight

Yes, you're right. MatFlags and TexFmt defines what SH3 engine treat texture file.
As for the prefix 0x, this means a number in the hexadecimal code, each digit 0-9 and A-F corresponding to the next four bits of the number. For example, 0x7C means 124, which is not very useful, but much more useful is that 7C are two four bits with values of 7 and 12, i.e. 0111 and 1100. The whole number in this case is 01111100. The individual bits or their groups can be assign different meanings and in this way include several pieces of information simultaneously.
Unfortunately, it turned out that I lost all copies of the tutorial to menu1024x768.ini, which originally could be found on the forum at http://forum.kickinbak.com/viewtopic.php?f=70&t=6 (as Submarine Sim Central • View topic - Menu 1024X768 tutorials).
Hence, because the last time I did it in 2012, I do not remember now what numerical values of "Texture Format" and bits "Material Flags" corresponded to what texture formats.

If anyone has access to the working mirror of this forum or has a copy of that forum, I would be interested in this material myself.
I made a mistake by not checking that the lost information was not on the subsim forum.

hello Olamagato,

yes, i am aware of these conversions to binary but yesterday ,as i was searching, i think that i found something very close to TexFmt lines.

Have a look here (scroll down to p21): http://tfc.duke.free.fr/coding/tga_specs.pdf

By looking to this document, TexFmt lines doesn't seem to lead to binary (e.g. 01111100 etc) but directly to tga format types.

Sh3 is using at TexFmt lines the values 0x2 , 0x9 , 0xA and 0xB* which in decimal give 2 , 9 , 10 and 11 respectively.

So , it seems these TexFmt lines lead directly to tga format type 2 , type 9 ,type 10 and type 11 respectively.

*it also uses to some entries the value TexFmt=0x5 and to two entries the TexFmt=0x8 which is puzzling

this is just a thought by looking at this document (as it was so close to the values used by sh3) and ,of course, the binaries to be the way.Are you sure that you saw ,at this tutorial you mentioned, a matching to binaries ?

About MatFlags:
MatFlags look more responsible for the diplay behaviour of image (seem to have a combination with the Display lines) as , by changing MatFlags values, i see images getting stretched or start repeating themselfs till fulling the screen or their altered dimension.For the color depth of them ,i guess, are responsible the TexFmt lines.

Lets hope this tutorial to be found and spread some light :yep:

Texture format (TexFmt) duplicates the type of image contained in the texture file. I don't know why the SH3 in so many places duplicates information, which is already included in the resources, but apparently the developers did not want to be addicted to the evolving standards for encoding image files.
As for types 5 and 8, I think that these are formats that have not become a standard or were probably obsolete when you saved the specification you found.

Yes, but I just forgot that these values simply correspond to the Targa formats you have found.

As long as we do not have access to the tutorial to which someone has also experimented experimentally to check the effects, we need to discover these values in menu1024x768.ini.
I once remembered them all doing the old widescreen gui for GWX, but now I would have to trace and recreate everything again.

It seems that a lot of useful knowledge that was extremely useful for editing the GUI at the moment has been lost. I was sure that all modders use and develop this knowledge, but apparently I was wrong. :06:

Are you looking for the latemail tutorial? I have that somewhere on my computers, but have not found it yet. In the meantime, I did find these:

/zAmboni: Tutorial: Deconstructing the menu_1024_768.ini file items

scudder: The Big Unofficial Guide to menu_1024_768.ini v1.1 download

olc post in: menu_1024_768.ini guide? latemail post at the bottom of the page.

:salute:

Yes. This is it (or almost)
Many thanks.

Sorry , i don't understand you here, you think that my thought is correct or not ?

the "old widescreen gui for GWX" (made by Rubini if i am not mistaken) doesn't contain any breaking editing in its lines. It was a simple readjustment of items on screen just for serving the 1360x768 needs so i don't believe that there is anything usefull for matflags and texfmt lines in there.

it is not that bad as you see it. You have your edited menu.ini which contain the knowledge of this missing tutorial.
Have a look in there and tell me the whole entry for the navigation.tga and the whole entry for the mask512.tga.
I will test your values at Display , MatFlags and TexFmt lines of these two entries and see if we have any good gain at ingame ram usage.



thank you for the inputs Propbeanie.
i am aware of all these and none containes any usefull info about the matflags and texfmt lines.OLC's infos are the most usefull info (which are the same transfered in Latemail's tutorial) but even these infos were suspicions of OLC,most of them never cleared and he ended up to use matflags=0x29 and texfmt=0x9 to all.

if this missing tutorial you are talking about is the Latemail's tutorial , i have it but as i said above the only info that containes about matflags and texfmt lines are the thoughts of OLC and there is no matching to any binaries. So, propably you are talking for some other tutorial. If this tutorial you are talking about were ever posted here in subsim i would had have it.Do you remember if it had ever posted here ?



*From some more tests i made , i have the sense that for having worthy ingame ram saving ,the quality of menu images must heavily reduced. Lets see

Sorry those were not of use. I have found a "Latemail.pdf" on my computer, and he talks about taking the SH4 NavMap tools over into SH3, and how he edited the menu_1024_768.ini, but I do not see reference to matflags or texfmt line definitions. As for texfmt, skwasjer had a tutorial on creating a text font, but again, probably not much use here... :salute:

No problem Propbeanie , it is always nice posting links familiar to topic (i have found many links at past in threads that were not exactly for that reason).
As for the Texfmt , this has nothing to do with texts or fonts (texfmt = texture format). For texts are the lines "Text","TextFlags" ,"TextPosFlags" and "TextOffsetY"

I found this:
Hi hope can there be something useful for you

Latemail (Lauf Zum Ziel ) tutorial :
menu1024.ini_bearbeitung.pdf but not in English
1-in German language :
http://www.mediafire.com/file/w1wjtd...itung.pdf/file

2-In Russian language:
https://docviewer.yandex.ru/view/0/?...4NH0%3D&page=1