about images bit

[makman94]

Previous posts

Originally Posted by Olamagato

...
But almost all GUI's waste RAM with nonsense big 32-bit textures as example. This is especially true for full HD.
...

Originally Posted by Olamagato

Yes. But SH3 does not use the alpha channel at all in the largest background textures, most of which are in the "data\menu\Data" directory and two in the "data\menu\Gui" directory (MOrderBgnd.tga and RadioMsg.tga). You can safely remove the alpha channel from them because the alpha channel is unnecessary. Only backgrounds overlayed on a 3D view or video require an alpha channel (e.g. periscopes, main menu)
In addition, any entries in menu1024x768.ini type CropX = 0,0,1, Y (Y <1, e.g. 0.75) to CropX = 0,0,1,1 and reduce the multiple-purpose textures into two different textures should be reduced. Especially when the truncated or uncut section does not need an alpha channel.
The alpha channel is only needed for big background textures of both periscopes, uzo, binoculars, deck gun, main menu (mask512.tga) and perhaps a museum (museu.tga). All other textures either are alpha-channel themselves or they do not need it at all.

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 ?

Originally Posted by Olamagato

All other textures either are alpha-channel themselves or...

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 ?

Originally Posted by Olamagato

In addition, any entries in menu1024x768.ini type CropX = 0,0,1, Y (Y <1, e.g. 0.75) to CropX = 0,0,1,1 and reduce the multiple-purpose textures into two different textures should be reduced. Especially when the truncated or uncut section does not 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 ?

[Olamagato]

Originally Posted by makman94

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 ?

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.

Originally Posted by makman94

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.

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.

Originally Posted by makman94

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 ?

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

Originally Posted by makman94

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 ?

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.

[makman94]

Originally Posted by Olamagato

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.

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)

Originally Posted by Olamagato

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.

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)

[HanSolo78]

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.

[Olamagato]

Originally Posted by makman94

hello Olamagato,
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.

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.

Originally Posted by makman94

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).

Yes.

Originally Posted by makman94

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

Yes.
Redmask.tga

Originally Posted by makman94

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 ?

External debugger or profiler only.

[makman94]

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



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

[Olamagato]

Originally Posted by makman94

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.

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.