Hyperion Entertainment Message Boards

Would it be safe to say that if an OS4 program opened it's own screen, it would be 32bits? There would be no real reason to open at less since any graphics you would use would be 32bit (transparent backgrounds).

I was just thinking about my program running on Workbench (32bit), but if someone used the Jump Screen function what might be some issues.

I could see it being an issue on Classic with some older programs.

If your program is affected by the resolution of the screen, it had better read the resolution using IIntuition->GetScreenAttrs(). You are liable to get anything.

mritter0 wrote:Would it be safe to say that if an OS4 program opened it's own screen, it would be 32bits? There would be no real reason to open at less since any graphics you would use would be 32bit (transparent backgrounds).

All my OS4 screens are 16 bit. When I first started using OS4 years ago, I had older programs that won't open on 32bit screens or work correctly on 32 bit screens. I hate having my monitor resync when switching screens because I use a lot of different screens. I don't need most of those older programs anymore but continue to use 16 bit screens. Having programs that will only work on a single depth of screen defeats the whole purpose of public screens and the ability of a program or user to change the default public screen. If I want to run a program that only opens on the default public screen and I want it to open on it's own screen, I write a script to switch the default public screen to a screen I have created with SYS:Prefs/Screens and then switch the default public screen back to Workbench after the program is opened. As a partially color-blind person, I can't distinguish any visual difference between a program that opens on a 16 bit screen from the same program on a 32 bit screen.

Transparency obviously works on a 16 bit screen or my Workbench icons would all be rectangles with no transparency. The same holds true for Dopus5 open on it's own 16 bit screen; the disk icons are displayed on the background with full transparency. I don't see why you would need a 32 bit screen. If I D/L programs that won't work right on 16 bit screens, I delete them.

I don't have a problem with resolution, just curious about depth. I load several AISS and custom images which are 32bit. When doing a Jump Screen I free all of the images and reload them with the new screen pointer to get proper depth and such. I was curious if it was a non-issue anymore and needed to do this step. Sounds like yes.

mritter0 wrote:I don't have a problem with resolution, just curious about depth. I load several AISS and custom images which are 32bit. When doing a Jump Screen I free all of the images and reload them with the new screen pointer to get proper depth and such. I was curious if it was a non-issue anymore and needed to do this step. Sounds like yes.

I forgot to point out that even some OS4 native programs open on screens with a depth less than 32. The OS4 version of PPaint only opens on an 8 bit screen. Have you tested your program on 8 bit screens?

mritter0 wrote:I don't have a problem with resolution, just curious about depth. I load several AISS and custom images which are 32bit. When doing a Jump Screen I free all of the images and reload them with the new screen pointer to get proper depth and such. I was curious if it was a non-issue anymore and needed to do this step. Sounds like yes.

Before you jump screen you can inspect the new screen being passed to you via your call to GetAttrs(windowobj,WA_PubScreen,&newscreen,TAG_DONE) or similar.

If the screen is not suitable, you can reject it. (you should probably popup a requester saying why) so if your app really needs a 16/32 colour screen you can check that at that point.

You probably do need to reload images if you jump from CLUT to 16/32 or vice verca but not if you jump from 16/32 to another 16/32 .

xenic wrote: I forgot to point out that even some OS4 native programs open on screens with a depth less than 32. The OS4 version of PPaint only opens on an 8 bit screen. Have you tested your program on 8 bit screens?

It doesn't actualy, PPaint 7.3a opens by default on a 32 bits screen but with a pens colour pallette specified by the current image. This enables me to keep the GUI colours independant of the image, and to display the animation previews in the story board in there true colours when the palette between frames is varying. Also allows proper screen dragging without emabling the expensive planer on RTG GUI prefs setting. You can revert to the old way if you like by editing the prefs.

broadblues wrote: It doesn't actualy, PPaint 7.3a opens by default on a 32 bits screen but with a pens colour pallette specified by the current image. This enables me to keep the GUI colours independant of the image, and to display the animation previews in the story board in there true colours when the palette between frames is varying. Also allows proper screen dragging without emabling the expensive planer on RTG GUI prefs setting. You can revert to the old way if you like by editing the prefs.

Actually, the ability to drag the PPaint screen is very useful for me. Most of my graphics work is creation of custom icons and I usually pass an image back and forth between PPaint and ImageFX. It's really handy to save an image in PPaint, drag the screen down and load it in ImageFX.

Can't you use the clipboard for that?

tonyw wrote:Can't you use the clipboard for that?

Both programs will save & load brushes from the clipboard. My point was that it's more convenient to pass images back and forth between the progams by dragging screens when the screens are using different depths. If they both have the same screen resolution and depth, switching screens would be better. If I could have PPaint open on a 16 bit screen like all my other screens instead of a 32 bit screen, I wouldn't have the resync when switching screens and I wouldn't need to drag ImageFX/PPaint screens up and down.