Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
93 user(s) are online (48 user(s) are browsing Forums)

Members: 0
Guests: 93

more...

Headlines

 
  Register To Post  

(1) 2 »
Screen opening woes in OS4.1FEu1 Classic
Quite a regular
Quite a regular


See User information
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 argcchar *argv[])
{
    
int Display_Width=320;
    
int Display_Height=240;

    
ULONG modeid INVALID_ID;

    if (
modeid == (ULONG)INVALID_ID)
    {
        
modeid BestModeID(
            
BIDTAG_NominalWidthDisplay_Width,
            
BIDTAG_NominalHeightDisplay_Height,
            
BIDTAG_Depth8,
            
TAG_DONE);
    }

    
struct Screen *screen OpenScreenTags(NULL
        
SA_DisplayIDmodeid,
        
SA_WidthDisplay_Width,
        
SA_HeightDisplay_Height,
        
SA_Depth8,
        
SA_ShowTitleFALSE,
        
SA_QuietTRUE,
        
SA_DraggableFALSE,
        
SA_TypeCUSTOMSCREEN,
        
TAG_DONE);

    
struct Window *window OpenWindowTags(NULL,
        
WA_FlagsWFLG_BACKDROP WFLG_REPORTMOUSE WFLG_BORDERLESS WFLG_ACTIVATE WFLG_RMBTRAP,
        
WA_InnerWidthDisplay_Width,
        
WA_InnerHeightDisplay_Height,
        
WA_CustomScreenscreen,
        
WA_IDCMPIDCMP_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.
Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Home away from home
Home away from home


See User information
@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.
Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Quite a regular
Quite a regular


See User information
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.
Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Home away from home
Home away from home


See User information
@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.


Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Home away from home
Home away from home


See User information
@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.



Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Just can't stay away
Just can't stay away


See User information
@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

Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Home away from home
Home away from home


See User information
@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.




Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Quite a regular
Quite a regular


See User information
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 &nbsp; 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.
Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Quite a regular
Quite a regular


See User information
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.
Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Home away from home
Home away from home


See User information
those are vga modes

#define VGALORES_KEY 0x00039004
#define VGAPRODUCT_KEY 0x00039024

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


Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Quite a regular
Quite a regular


See User information
@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.
Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Just popping in
Just popping in


See User information
@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.

Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Quite a regular
Quite a regular


See User information
@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.
Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Home away from home
Home away from home


See User information
@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.
Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Quite a regular
Quite a regular


See User information
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.
Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Home away from home
Home away from home


See User information
@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.
Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Home away from home
Home away from home


See User information
@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.


Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Quite a regular
Quite a regular


See User information
@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.
Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Home away from home
Home away from home


See User information
@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.


Go to top
Re: Screen opening woes in OS4.1FEu1 Classic
Quite a regular
Quite a regular


See User information
@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.
Go to top

  Register To Post
(1) 2 »

 




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




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project