At what size do you design yours?

[Guest Patrick_Waugh]

I started designing my gauges at 512x512, and then would shrink them down to 256x256 in photoshop (for better bilinear etc.), but sometimes forget to un-srink them. So, now I just do them in 256x256.Seems to give me enough resolution and an easy size to find the right size font.Wondering what others do.Patrick

[Guest iholrf]

600x600 - as a psd - export to bmp at 300x300However... my project panel is hard on FPS. My advice is as small as they can be while still being clear.CheersShad

[Guest JeanLuc_]

Whatever the resolution/size of your bitmaps, FS will make a copy in memory, per gauge instance. That is if you have twice the same gauge in a panel, FS will allocate memory for each instance, each having its own copy of the original bitmaps. Furthermore, FS will resize the bitmaps once the gauge is loaded, per gauge instance, to the size they will be displayed at on the screen.In turn, the only ressource you take when having say a 500x500 gauge bitmap instead of 250x250 is the ressource taken by the sole instance of your bitmap stored in the ressource section of the gauge, ressource section which is loaded in memory once only.If the concern is saving ressources and memory, it does not matter much then. What matters is the number of gauge instances, and the screen resolution they will be displayed at. No wonder why some people still find FPS unacceptable with some aircraft, when you consider running the say aircraft at 1600x1200 resolution. You most likely get, as a user, the same visual details with 1280x1024 max WITH AA and AF, while saving A LOT of video card/memory bandwidth, all in all preserving FPS.Hope this helps!

[dragonflightdesign 98]

Depends what my starting point is. I've been working with photos recently so some have started at almost 1000 x 1000, but my finshing point is usually not to exceed around 302 x 302. I have no idea why that size...! I suspect at one time I found a default gauge somewhere around that size and stuck to it ever since.-Dai

[WarpD 824]

>Whatever the resolution/size of your bitmaps, FS will make a>copy in memory, per gauge instance. That is if you have twice>the same gauge in a panel, FS will allocate memory for each>instance, each having its own copy of the original bitmaps.>Furthermore, FS will resize the bitmaps once the gauge is>loaded, per gauge instance, to the size they will be displayed>at on the screen.>>In turn, the only ressource you take when having say a 500x500>gauge bitmap instead of 250x250 is the ressource taken by the>sole instance of your bitmap stored in the ressource section>of the gauge, ressource section which is loaded in memory once>only.>>If the concern is saving ressources and memory, it does not>matter much then. What matters is the number of gauge>instances, and the screen resolution they will be displayed>at. No wonder why some people still find FPS unacceptable with>some aircraft, when you consider running the say aircraft at>1600x1200 resolution. You most likely get, as a user, the same>visual details with 1280x1024 max WITH AA and AF, while saving>A LOT of video card/memory bandwidth, all in all preserving>FPS.>>Hope this helps!>>What really matters is the efficiency of design. Rendering strictly bitmaps that are resized and resampled using GDI (not GDI+) will always impact performance.

[Guest JeanLuc_]

True, however the topic was about default bitmaps included in the gauge ressources, and managed by the FS panel system. In this case, design has little to do with FS copying and resizing all gauges bitmaps to the final display size, and does it for every instance of the gauge in the panel.cfg file, and you can't really prevent this from happening (well, you can to some extent).For custom drawned gauges, be it with GDI, GDI+, True Display XP, True Gauge XP or any other, matters are different indeed.

[Guest Vorlin]

" Furthermore, FS will resize the bitmaps once the gauge is loaded, per gauge instance, to the size they will be displayed at on the screen."For me, this is the killer.I know that the rule is supposed to be power of 2 (128 / 256 / 512 / etc) but I have had great success doing as someone once recommended here in the forums and creating my work at 300.Why 300? Because you get the power of 2, and 3, 4, 5, 6, etc. etc.The trick is that scaling is never at a power of 2. It's 60%, or 77%, or 43.2% or some other strange number.300 can be clearly resized so many ways it's incredbile:50% = 15033.3% = 10030% = 9072% = 216It can even be cleanly divided by 15 and by using 2 steps you can cleanly arrive at any other resize percentage that you can imagine and you can do it with a clean resize every time (50% of 121 resutls in 60.5 and that .5 will mess you up every time).Proof? Try 17%...Step 1: 300 / 100 = 3Step 2: 3 * 17 = 51With 2 simple steps, there is no percentage that can result in any remainder or otherwise "loose" end to tidy up.More importantly, 300 can be directly divided in one step by many, many different numbers. In fact, any number that is divisible by 2 or 3 will divide 300 cleanly... and that's a lot of resize possabilities.I honestly believe that 300 is the ultimate size for flexibility and clean scaling in a low-res image. For higher resolutions, try 600 which has sthe same resizing flexibility and add the benefit of higher resolution.Like Papa John's Pizza... better ingredients make for a better product.Scott / Vorlin

[WarpD 824]

>True, however the topic was about default bitmaps included in>the gauge ressources, and managed by the FS panel system. In>this case, design has little to do with FS copying and>resizing all gauges bitmaps to the final display size, and>does it for every instance of the gauge in the panel.cfg file,>and you can't really prevent this from happening (well, you>can to some extent).>>For custom drawned gauges, be it with GDI, GDI+, True Display>XP, True Gauge XP or any other, matters are different indeed.>Default gauges rendered by FS uses GDI. Not GDI+... GDI.