Screen opening woes in OS4.1FEu1 Classic

	Bottom Previous Topic Next Topic
Register To Post

(1) 2 »

BSzili

Posted on: 2018/3/3 19:30 #1

Quite a regular

I have a piece of code that opens a 320x240x8 screen. It used to work fine on OS4.1FE Classic in WinUAE, but after installing Update 1 it only displays garbage. This is part of a 68k game, but the problem persists whether I compile it for OS4 or not.


#include <proto/exec.h>

#include <proto/graphics.h>

#include <proto/intuition.h>



int main(int argc, char *argv[])

{

    int Display_Width=320;

    int Display_Height=240;



    ULONG modeid = INVALID_ID;



    if (modeid == (ULONG)INVALID_ID)

    {

        modeid = BestModeID(

            BIDTAG_NominalWidth, Display_Width,

            BIDTAG_NominalHeight, Display_Height,

            BIDTAG_Depth, 8,

            TAG_DONE);

    }



    struct Screen *screen = OpenScreenTags(NULL, 

        SA_DisplayID, modeid,

        SA_Width, Display_Width,

        SA_Height, Display_Height,

        SA_Depth, 8,

        SA_ShowTitle, FALSE,

        SA_Quiet, TRUE,

        SA_Draggable, FALSE,

        SA_Type, CUSTOMSCREEN,

        TAG_DONE);



    struct Window *window = OpenWindowTags(NULL,

        WA_Flags, WFLG_BACKDROP | WFLG_REPORTMOUSE | WFLG_BORDERLESS | WFLG_ACTIVATE | WFLG_RMBTRAP,

        WA_InnerWidth, Display_Width,

        WA_InnerHeight, Display_Height,

        WA_CustomScreen, screen,

        WA_IDCMP, IDCMP_RAWKEY|IDCMP_MOUSEMOVE|IDCMP_MOUSEBUTTONS,

        TAG_DONE);



    ULONG window_sig = 1L << window->UserPort->mp_SigBit;



    BOOL bExitGame = FALSE;

    while (!bExitGame)

    {

        ULONG sigs = Wait(window_sig);



        if (sigs & window_sig)

        {

            struct IntuiMessage *imsg;



            while ((imsg = (struct IntuiMessage *)GetMsg(window->UserPort)))

            {

                switch (imsg->Class)

                {

                case IDCMP_RAWKEY:

                    bExitGame = TRUE;

                    break;

                case IDCMP_MOUSEBUTTONS:

                    bExitGame = TRUE;

                    break;

                }

            }

        }

    }



    CloseWindow(window);

    CloseScreen(screen);



    return 0;

}

It can be compiled with:
Quote:

ppc-amigaos-gcc -D__USE_INLINE__ screentest.c -o screentest -lauto

Any ideas on how to fix this? I'm completely stumped because it works everywhere else, and on OS4 only broke after installing Update 1 :(

This is just like television, only you can see much further.

LiveForIt

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/3 20:15 #2

Home away from home

@BSzili

"BIDTAG_Depth, 8"

So it find any chunky or planar mode that is 256 colors. most people don't have fake modes enabled, so should end up with chunky mode, the old 68k game will expect planar mode.

Yes and and also most people wont have a resolution that low, most people only have 640x480.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.

BSzili

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/3 21:04 #3

Quite a regular

I should have made this clear in the first post: I don't need planar modes, I'm blitting the contents with WritePixelArray8/WriteChunkyPixels. My problem is that the code above gives me a screen filled with garbage without drawing anything to it, and nothing else shows up.

Edited by BSzili on 2018/3/3 21:24:10

This is just like television, only you can see much further.

broadblues

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/3 22:24 #4

Home away from home

@BSzili

Well on my x1k PPaint will syill open properly on a CLUT screen. With no garbage. Though it's screen opening code is archaic, so might be side stepping any new bug if there is one.

What versiion of graphics.librray are you using? So I can chack PPaint on that as a starter.

Since you are going to get a CLUT screen did you set the screens palette? Do you see chnage in the random junk when you render?

Could you create a small test program with src so I can test that?

[edit]

I see the src you posted is actual compilabel, sorry will have go with that.

Please do post your graphics.library version though.

Blender For OS4.x : Blues : Walker Broad

broadblues

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/3 22:40 #5

Home away from home

@BZilli

Your test code runs fine on my SAM and x1k so unless it's somethign fixed recently, it must be a WinUAE / OS4 Classic specific issue.

I don't have a WinUAE setup.

One work arround I can think of for classic as OS4 will have RTG (I'd think, excuse be if I'm wrong I dont use OS4 for classic ) then "promote" it to a 16/32 bit screen. This works very well for PPaint, which is other wise a 256 colour application.

Blender For OS4.x : Blues : Walker Broad

xenic

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/3 22:58 #6

Just can't stay away

@BSzili
I copied your test code, replaced all the $A0 with spaces and compiled the program. Here on my X5000 with OS4.1FEu1, it opens a blank screen. It appears to be a "fake" screen because the pointer can only be moved around in a 320x240 box in the upper-left of the display. The screen menu on the Workbench screen shows it as a 320x240 screen. It may only be a problem on OS4.1Fu1 classic.

You should also know that when I highlight & copy from a code box in these forums, the pasted program is full of $A0 characters that GCC flags as errors. I can replace those characters with spaces with my editor but others may have a problem compiling the program.

Amiga X1000 with 2GB memory & OS 4.1FE + Radeon HD 5450

broadblues

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/3 23:51 #7

Home away from home

@xenic
Quote:

I copied your test code, replaced all the $A0 with spaces and compiled the program. Here on my X5000 with OS4.1FEu1, it opens a blank screen. It appears to be a "fake" screen because the pointer can only be moved around in a 320x240 box in the upper-left of the display.

Yes on cards that don;t support modes as low as 320x240 you will get a 320 x 240 screen on a 640x480 mode. That's not "fake" as such. And should not cause the program any issues.

Quote:

It may only be a problem on OS4.1Fu1 classic.

Yeah we need a classic tester to popup here....
Quote:

You should also know that when I highlight & copy from a code box in these forums, the pasted program is full of $A0 characters that GCC flags as errors. I can replace those characters with spaces with my editor but others may have a problem compiling the program.

This occurs on many foums. They preserver the indent structure in code plugin by inserting non breaking spaces. Some more advance plugins have havascript copy menu , but even then few of our browser would work with that. Although strangly when I cut and pasted all the NBSP were just stripped leaving me to have ro read the spaces manually.

Blender For OS4.x : Blues : Walker Broad

BSzili

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/4 7:19 #8

Quite a regular

Thanks for the answers!

@broadblues
It looks like the CLUT8 modes got broken in Classic after Update 1. If I change the depth to 24-bit, the problem goes away. It looks like I have to add a kludge that does this when running on OS4. For the sake of completeness, here's my graphics.library version: 54.226 (2016.09.13.)

@xenic
The forum software indeed adds   characters to the code, I didn't know about this. I should attach the source file as well.
Fortunately the game has a 640x400 high resolution mode, which will fill most of the opened screen, since 640x480 is much more common.

This is just like television, only you can see much further.

BSzili

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/4 8:57 #9

Quite a regular

The plot thickens. When I go into the ScreenMode Prefs, the PAL modes seems to work just fine. It's BestModeID that's returning some odd 320x200x8 modeid for me: 0x00039000

edit: For 640x480x8 (which also works in the ScreenMode Prefs, it's a PIV mode) BestModeID gives 0x00039024

Edited by BSzili on 2018/3/4 9:51:58

This is just like television, only you can see much further.

broadblues

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/4 10:24 #10

Home away from home

those are vga modes

#define VGALORES_KEY 0x00039004
#define VGAPRODUCT_KEY 0x00039024

Do you have the VGA monitor icon in DEVS:Monitors ?

Blender For OS4.x : Blues : Walker Broad

BSzili

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/4 11:03 #11

Quite a regular

@broadblues
I checked, and I have nothing but PicassoIV in DEVS:Monitors, everything else is in the Storage. Despite this I still have pal and multiscan VGA modes in the ScreenMode prefs. Those are probably always available in Classic. I tried enabling the fake native modes, but that doesn't seem to be possible on classic.

I made another test program that prints the modeid's returned by BestModeID, BestCModeIDTags and p96BestModeIDTags, when only the nominal width/height and depth is defined. CGFX matches graphics.library, but the P96 function returns something else regardless of what resolution I specify: 0x00f9024. It looks similar to the VGA productivity mode.
For 16 and 24 bit I get the correct screen modeids from all 3 functions, only 8-bit is broken, I don't get the 640x480 CLUT8 RTG modeid from either of them.

In summary the problem is twofold: the multiscan VGA modes are broken and only show garbage, and in BestModeID the multiscan modes have preference over CLUT8 RTG modes. Wew.

https://drive.google.com/open?id=1JzU-fRAyY08smw5zkMcfQFAXIUtA2R59

Edited by BSzili on 2018/3/4 11:20:05
Edited by BSzili on 2018/3/4 11:48:32

This is just like television, only you can see much further.

smf

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/4 13:43 #12

Just popping in

@BSzili

Quote:

@broadblues
I checked, and I have nothing but PicassoIV in DEVS:Monitors, everything else is in the Storage. Despite this I still have pal and multiscan VGA modes in the ScreenMode prefs. Those are probably always available in Classic. I tried enabling the fake native modes, but that doesn't seem to be possible on classic.

Multiscan is always available in classic if you have the bootvga.kmod module enabled in your kicklayout.

BSzili

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/4 14:25 #13

Quite a regular

@smf
A million thanks! I commented out that line in the kicklayout, the multiscan modes went away and now BestModeID returns "regular" PAL/RTG modes :)

This is just like television, only you can see much further.

LiveForIt

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/4 14:49 #14

Home away from home

@BSzili

Yes but that is not fix, maybe you should make your own BestModeID, that is what i do in MPlayer hint hint, I also check for composition support etc.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.

BSzili

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/4 15:34 #15

Quite a regular

That wouldn't be a fix either, because the the multiscan screen modes would still be broken. They are both workarounds.
This only affects the classic version with the VGA boot option enabled, which is not even used if you have a graphics card, and most OS4 classic users do.

This is just like television, only you can see much further.

LiveForIt

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/4 16:45 #16

Home away from home

@BSzili

I'm sure it be problem if some enabled fakemodes in radion.info tooltype.

(NutsAboutAmiga)

Basilisk II for AmigaOS4
AmigaInputAnywhere
Excalibur
and other tools and apps.

broadblues

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/4 19:41 #17

Home away from home

@BSzili

Quote:

This only affects the classic version with the VGA boot option enabled, which is not even used if you have a graphics card, and most OS4 classic users do.

I thinik it's required t get to the early startup screen where there would be no Radeon or similar driver in force.

Coming back to your emulation, do you have a MultiScan / VGA monitor emulated?

I'm thinking that if you don't the monitors are bound to "nothing" causing the corrupt display.

Given that you have the VGA modes active BetsModeID is returning the correct value in so far as it matches what you asked for and is arguably the best mode for the display size. (but is probably the first matching mode in the display database)

To get round this you need more precision in your tags.

Your specifying NomainalWidtha nd Nominalheight but these two on specify the aspect ratio so specify DesiredWidth and DesiredHeight too. Other wise you may get the first screen mode with the right aspect ratio.

You can also add the board you want to open on. For example if you want to open on the same board as the workbench:-

Get the workbenchs scren ModeID (from GetVPModeID() I think) and bitwise and that with the MONITOR_ID_MASK then pass that to BestModeID with the BIDTAG_MonitorID tag.

You might also open a ModeID requester instead to allow the user to choose, TBH that's only way of getting the right screen in multi monitor setup that doesn't rely on the luck of the right monitor being earlier in the database list that some unwanted nominally compatable one.

Blender For OS4.x : Blues : Walker Broad

BSzili

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/4 20:35 #18

Quite a regular

@broadblues
Yes, BootVGA is for the early boot menu, but it's not required. From the kicklayout:
Quote:

; Uncomment the following line when bootmenu shall use
; MultiScan Productivity (31 kHz 60 Hz). Note: When a graphics card
; is installed, bootmenu will always be displayed on the graphics
; card (31 kHz 60 Hz) anyway, the line has an effect only when
; no graphics card is installed and bootmenu is displayed by the
; AGA chipset.
;
;MODULE Kickstart/BootVGA.kmod

I tried it, and the boot menu shows up on a PIV screen, no issues there.

As for the emulation issues, I didn't have any problems with the Multiscan monitor in OS3.1. I can also see the mouse pointer sprite with the correct palette, it's just the actual screen contents that won't show up.
I can see the rationale behind Multiscan being a better fit given that I only specify the nominal width/height. It wouldn't be a problem if that mode worked.

I'll try to play around with the tags later.

This is just like television, only you can see much further.

broadblues

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/5 1:05 #19

Home away from home

@BSzili

Quote:

As for the emulation issues, I didn't have any problems with the Multiscan monitor in OS3.1. I can also see the mouse pointer sprite with the correct palette, it's just the actual screen contents that won't show up.

I'm not sating it's not broken, I'm just eliminating possibilties.

On your 3.1 setup do you have multiscan monitor icon and do those modes display okay?

If so, are there any options different in your WinUAE machine setup between the two?

Quote:

It wouldn't be a problem if that mode worked.

But that could be

an emulation settings issue
a bug in the emulation
a bug in OS4 for Classic
a bug in OS4 for Classic that only happens on emulation.

Blender For OS4.x : Blues : Walker Broad

BSzili

Re: Screen opening woes in OS4.1FEu1 Classic

Posted on: 2018/3/5 7:48 #20

Quite a regular

@broadblues
Yes, I have the Multiscan monitor in devs:monitors on OS3.1. On OS4 I don't have the PAL monitor in there just PicassoIV, but the native PAL modes work fine, I'm only had issues with Multiscan one. I'll copy my 3.1 setup onto an RDB hardfile to see what it does on the same UAE config.

You are right about all the possibilities, I didn't mean to state it's 100% an OS4 bug. After all, I'm working with the sample size of 1 :)

This is just like television, only you can see much further.

Register To Post	(1) 2 »
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 2 ( 0 members and 2 Anonymous Users )