FP Which are better BMP or JPG for Future Pinball Textures?

[SpacePirateScott]

Sorry if this question has been answered already, but apparently you can't search on either BMP or JPG. :)

So when I'm making a texture for a Future Pinball table I have the option of importing it as .JPG, BMP or TGA. It looks like if you have an alpha channel you need to use TGA, but is it best practice to use BMP or JPG? Yes I know JPG is lossy, but that really isn't a problem if you set the quality to high and they are still significantly smaller than BMPs. The question I have is this: is a difference in load times or some either performance impact? Has anyone done any testing on this?

 

[AnonTet]

If you need transparency you're stuck with BMP and/or TGA otherwise JPG files can save you a lot of space.

 

[SpacePirateScott]

I have a lot of large textures and it's impacting the loading time. I was wondering if BMP or JPGs are faster to load. Jpgs require more processing to uncompress, but BMP's are larger so more loading time. I was wondering whether anyone had done any testing to see the impact on the "Injecting Textures" time.

 

[AnonTet]

Notifying @TerryRed on this one.
Anyway, it broader answer is always a compromise and regarding JPG all I can say is that don't save with max quality. Save it at 85% and chroma subsampling 4:2:0.

I think the option of using compressed images in the video settings should help as does bilinear/trilinear filtering at visual quality expense, of course.

 

[madmrmax]

Notifying @TerryRed on this one.
Anyway, it broader answer is always a compromise and regarding JPG all I can say is that don't save with max quality. Save it at 85% and chroma subsampling 4:2:0.

I think the option of using compressed images in the video settings should help as does bilinear/trilinear filtering at visual quality expense, of course.

I believe the compressed images actually leads to slower load times as it is compressing the images during load. That was something I read from Terry's overview of 32bit vs 64bit Future Pinball.

 

[Popotte]

Black said a long time ago that it compress the pics (even .jpg). So, if you don't have a lot of pics and/or hudge pics, it's not a problem.

 

[TerryRed]

You can see my testing when enabling Texture Compression here:

Future Pinball being 32 bit - NOT a limitation!

Future Pinball being 32 bit is NOT a limitation FP is a 32 bit app. A 32 bit app is limited to being able to access 4 GB of system ram max. Some claim FP being 32 bit is a big a limiting factor. With VP, yes that may be the case for some newer VP tables (as it typically needed to load all...

pinballnirvana.com

As for which is better to use for things like load times... I honestly always used JPG for most things and TGA for anything with alpha channel. I rarely use BMP except for things like BALL Textures, etc. The difference in quality is not noticeable in modern 4K displays or VR, etc as long as you use quality of around 85 for JPG.

I've never tried testing BMP vs JPG for loading times... though in the end all images are "injected" and formatted for texture use in vram. The only difference is probably just with or without texture compression.

 

[SpacePirateScott]

Well, there is nothing like running some experiments if you want to know something. Here are some timing tests I did. (this was done on one computer with only one table, so your results may vary). I timed the duration from when "Injecting Textures" until "Compiling Script" across multiple executions and averaged the results. The Jpgs where all saved at a fairly high quality (10 out of 12 in photoshop)

First of all, I didn't find any significant differences between lauding FP, loading a table and running vs. exiting from the table and rerunning again. So caching on the computer didn't have a noticeable impact.

Unizipped:
BMP : 436 MB
JPG : 60 MB

Zipped:
BMP: 78 MB
JPG: 58

Fpt: Size
BMP: 113 MB
JPG : 76 MB

Conclusion: raw Bmps take significantly more space on the disk, but when zipped or imported in the table, they are only about 1/3 larger the Jpg

Loading Times:
JPG with S3TS: 9.7 secs
JPG: 5.9 secs
BMP with S3TC: 7.4 secs
BMP -3.4 secs

Conclusions:
- S3TC added significant load times. Considering it also degrades the quality of the images, you shouldn't use this unless you have a really old video card and are having issues with running out of texture memory.

-BMP vs JPG: The bmps consistently loaded significantly quicker, ~33%.

Overall conclusions:
- Given how cheap hard drive space is, and that bmps are lossless, I think we should use bmp instead of jpgs. Also, just stop using S3TS unless you really need it.

 

[SpacePirateScott]

I also tested "Indiana Jones - Fortune and Glory Edition" for S3TS on and off and found similar results:
- with S3tS: 38 secs for injecting textures
-without S3TS; 27 secs.

It looks like all of the videos frames are .jpg, so if someone has several hours with nothing to do, you could export the .jpgs and reimport them as bmps and cut another 10 seconds off the loading time... :)

 

[madmrmax]

Wonder if there is any other impact on memory size. For example, if you tested "maxing out" image (as much as possible with the knowledge that Terry had a hard time actually maxing out FP). Does BMP take more video memory by chance? or is the image decoded from JPG or BMP, etc into the same memory and the image format only a storage thing?

 

[TerryRed]

I don't think anyone uses S3TS (texture compression setting) at all except those with a very old computer, or a GPU with low vram. Anyone with a PC like that, should be realistic regarding running modern high end tables made in 2024 :)

JPG and BMP and TGA would use the same amount of vram I believe as they are all uncompressed when applied to textures (its the resolution of the texture that determines how much vram is needed). The only difference is when using textures compression as was shown.


For most "normal" tables without 1000's of images, using BMP should not be a problem.


For tables like what I do that use many larger 4K images and a crap load of texture animation (Silent Hill, MOTU CE, etc)... using BMP would add up very fast and make a very large table file.

I confirmed that FP tables can't go above around 1.4 GB in "file size" or FP will crash / not work.

Again though... I'm not the normal usage case :) (so JPGs it is)



I made a video a while back showing the differences when using Trilinear Filtering vs Bilinear Texture Filtering (in FP settings) and the difference in load time and visual quality. On my newer PC, tables with many 1000's of textures can load rather quickly when using Bilinear. Even with Trilinear they don't take that long.

 

[SpacePirateScott]

I made a video a while back

Thanks, that explained why my cabinet was a lot slower than my desktop.

 

[SpacePirateScott]

Also, in your video you where talking about the bump maps on the light lens. Are all of your insert lights BAM models? I can see that the light is recessed as well. These look really good. I think you can do this with a custom FP model, but I didn't think that those use bump maps.

 

[TerryRed]

Also, in your video you where talking about the bump maps on the light lens. Are all of your insert lights BAM models? I can see that the light is recessed as well. These look really good. I think you can do this with a custom FP model, but I didn't think that those use bump maps.

View attachment 42886

None of them are BAM models. BAM models can't be used below the playfield as they render in front / on top of the playfield layer no matter what (so they can't be hidden or obscured at all under the playfield layer, even partially). BAM models can definitely use bump (normal) maps. :)

The video was only HD, so it doesn't show it as well... but all the inserts are FP models and are "bulb lights". They are recessed into the playfield. I also use normal (bump) maps with them as well. These need to be made as a FP model (from milkshape models using the FP Model Editor) and they use both the recessed insert model, and a mask model in the shape of the opening you want.





Some, like the Skeletor triangles, or the very small round lights are just flat FP shape / round lights that use normal maps as well.

Most my PinEvent table releases use the same kind of models for inserts.

 

[AnonTet]

First of all, I didn't find any significant differences between lauding FP, loading a table and running vs. exiting from the table and rerunning again.

You really should exit FP, not just the table to reload a table. Especially on more complex tables, one time, is enough to start having issues from physics/gameplay to more visual ones like textures not showing up.

 

[Popotte]

For me .bmp are just in FP in order to produce some transparency. Don't forget that FP was released in 2005 and not all graphic cards were enough powerful to generate .tga... (it's the same for power of 2 size).

 

[SpacePirateScott]

I also use normal (bump) maps with them as well.

Where is this set? I don't see an option for this anywhere. Is it done in MilkShape3D or does FP automatically apply a normalmap based on the name of the texture? Is that why the round lens has these texture names? insert-round-normalmap and insert-round-colormap in this example?

 

[TerryRed]

Where is this set? I don't see an option for this anywhere. Is it done in MilkShape3D or does FP automatically apply a normalmap based on the name of the texture? Is that why the round lens has these texture names? insert-round-normalmap and insert-round-colormap in this example?

View attachment 42892

BAM is what supports normal maps. They can be used on most any FP models / items / surfaces, etc.... or with a BAM model.

If it's with a BAM model, then that is done through the BAM Model Importer app.

If it's with a FP model / item, then you must do the following:

- name your regular texture as "Name_of_Texture-ColorMap.bmp"
- name your normal (bump) texture as "Name_of_Texture-NormalMap.bmp"
- if the texture is not directly used on an item in the editor, then add them to an Image List, so FP and BAM can see them
- if the texture is used directly on an item in the editor, then use the ColorMap texture
- SAVE the table! (or images may not be loaded when table is run)
- BAM will recognize the naming of the textures and apply the normal map automatically

I create normal maps on this site usually:

NormalMap-Online

Online NormalMap Generator FREE! Create a Normalmap directly inside your browser! No Uploads required, completely client-based

cpetry.github.io

 

[TerryRed]

One other thing.... FP is REALLY picky with the BMP files it will work with. I'm not sure the proper BMP format, but whenever I export BMPs from GIMP, and sometimes MS paint... the texture will not work with FP.

Easy solution... double click on the image to open it in windows Image Viewer (or right-click and Open With if its associated with another app), then in Windows Image Viewer, click to rotate the image (4 clicks for 360). This saves the file in a format that FP agrees with. Don't ask me why... but it works.