Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
31 user(s) are online (25 user(s) are browsing Forums)

Members: 0
Guests: 31

more...
Support us!
Recent OS4 Files
OS4Depot.net



« 1 ... 8 9 10 (11)


Re: SDL1 open issues
Supreme Council
Joined:
2006/11/19 18:16
From London, England
Posts: 1293
@Capehill

Done

Simon

_________________
Comments made in any post are personal opinion, and are in no-way representative of any commercial entity unless specifically stated as such.
----
http://codebench.co.uk
   Report Go to top

Re: SDL1 open issues
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 713
@Raziel

OS4Depot requires e-mail when submitting, but there is a checkbox for hiding the address from public.

@Rigo

Thanks again.


   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5319
@Capehill
Tried today to rebuild some very old piece of sdl1 app, some diskamg engine (i.e. play music, read articles, ability to flip pages, etc), and found issue:

If i build everything with very old SDL1 from 2012 times (i.e. that one which was long time official one), then everything looks correctly.

If i build with latest new sdl1 (that one from os4depot), then i have issues: i move mouse (textured one) and mouse pointer leave trailings of itself. If i tried to flip pages , they also didn't flips, and everything stays like it first page (like no swap buffers happens when need it , or no erasing, etc).

See video below of how it looks like. The same 1:1 source code, just first run its binary compiled with old (2012) sdl1 , and second run (starting from 0:40 on video) its second binary compiled from same source , but linked with last release of SDL1.

https://youtu.be/rd2EzDXy3u4

I well understand that its all a bit vague , but maybe you alrady have a clue where to look at :) It also can be that issue and with code itself, just with old SDL1 it wasn't materialized, dunno. Or maybe it still new SDL1 bug.

Can of course also upload related SDL code for brief check.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5319
@Capehill
Started comparing different sdl versions, and for now found that with the version from adtools page (that one from which we start all bug-fixes at begining, etc) there no such bugs.

Then i tried release 1.2.15 RC 1 , from github, and bug already there. So it's something in the middle. Will try to roll back commits to see when issues starts.

To note , diskmag didn't use OpenGL here, pure SDL.


EDIT: i seems to find out when problems starts : when was compositing support added. But i need to recheck twice to be sure.


Edited by kas1e on 2019/8/8 12:40:15
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 713
@kas1e

It would be useful to see the source code. Especially how surfaces are created and used.

   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5319
@Capehill
Rechecked few times to be sure , and yes, its all happens when compositing support was added.

This commit:
https://github.com/AmigaPorts/SDL/comm ... d51457cd1565b6a1ae274072f

Once i rever that one back, all start to work.

I grab only SDL related sources of app and put it to archive there:
http://kas1e.mikendezign.com/aos4/sdl1/sdl1_newbug.zip

SDL_System.cpp , there is what all starts (at top there SDLSystem::SDLSystem) where initialisation, setvideomode, etc. Also there SDLSystem::init_display, where surfaces setup, etc.

Will try to check in meantime what change exactly cause that issue, but its something from above commit in SDL_os4surface.c (but where else, mostly that file was touched there :) ).

I tried to setup in that SDL_os4surface.c accelerated = 0 instead of 1, also os4video_device->hidden->haveCompositing = FALSE instead of TRUE : no luck. Bug disappear only when i full replace SDL_os4surface.c with previous version where no compositing was added. I.e. it can be not compositing itself, but maybe some function's changes,etc

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5319
@Capehill
Found !

It wasn't compositing at all, and it wasn't even SDL_os4surface.c !

Its SDL_os4utils.c

If you check adtools repo, there was some ifdefs to disable reporting of some masking, i.e. there is how it was (see #if 0 commeting outs with comments about p96 can't usefully works with):

BOOL
os4video_PPFtoPF
(SDL_PixelFormat *vformatuint32 p96Format)
{
    
vformat->Rmask vformat->Gmask vformat->Bmask vformat->Amask 0;
    
vformat->Rshift vformat->Gshift vformat->Bshift vformat->Ashift 0;
    
vformat->Rloss vformat->Gloss vformat->Bloss vformat->Aloss 8;

    switch(
p96Format)
    {
    case 
RGBFB_CLUT:
        
vformat->BitsPerPixel 8;
        
vformat->BytesPerPixel 1;
        break;

    case 
RGBFB_R8G8B8:
        
vformat->BitsPerPixel 24;
        
vformat->BytesPerPixel 3;

        
vformat->Rmask 0x00FF0000;
        
vformat->Rshift 16;
        
vformat->Rloss 0;

        
vformat->Gmask 0x0000FF00;
        
vformat->Gshift 8;
        
vformat->Gloss 0;

        
vformat->Bmask 0x000000FF;
        
vformat->Bshift 0;
        
vformat->Bloss 0;

        break;

    case 
RGBFB_B8G8R8:
        
vformat->BitsPerPixel 24;
        
vformat->BytesPerPixel 3;

        
vformat->Rmask 0x000000FF;
        
vformat->Rshift 0;
        
vformat->Rloss 0;

        
vformat->Gmask 0x0000FF00;
        
vformat->Gshift 8;
        
vformat->Gloss 0;

        
vformat->Bmask 0x00FF0000;
        
vformat->Bshift 16;
        
vformat->Bloss 0;
        break;

    case 
RGBFB_R5G6B5PC:
    case 
RGBFB_R5G6B5:
        
// We handle these equivalent and do swapping elsewhere.
        // PC format cannot be expressed by mask/shift alone
        
vformat->BitsPerPixel 16;
        
vformat->BytesPerPixel 2;

        
vformat->Rmask 0x0000F800;
        
vformat->Rshift 11;
        
vformat->Rloss 3;

        
vformat->Gmask 0x000007E0;
        
vformat->Gshift 5;
        
vformat->Gloss 2;

        
vformat->Bmask 0x0000001F;
        
vformat->Bshift 0;
        
vformat->Bloss 3;
        break;

    case 
RGBFB_R5G5B5PC:
    case 
RGBFB_R5G5B5:
        
vformat->BitsPerPixel 15;
        
vformat->BytesPerPixel 2;

        
vformat->Rmask 0x00007C00;
        
vformat->Rshift 10;
        
vformat->Rloss 3;

        
vformat->Gmask 0x000003E0;
        
vformat->Gshift 5;
        
vformat->Gloss 3;

        
vformat->Bmask 0x0000001F;
        
vformat->Bshift 0;
        
vformat->Bloss 3;
        break;

    case 
RGBFB_B5G6R5PC:
    case 
RGBFB_B5G5R5PC:
        return 
FALSE// L8r

    
case RGBFB_A8R8G8B8:
        
vformat->BitsPerPixel 32;
        
vformat->BytesPerPixel 4;

        
vformat->Rmask 0x00FF0000;
        
vformat->Rshift 16;
        
vformat->Rloss 0;

        
vformat->Gmask 0x0000FF00;
        
vformat->Gshift 8;
        
vformat->Gloss 0;

        
vformat->Bmask 0x000000FF;
        
vformat->Bshift 0;
        
vformat->Bloss 0;

#if 0
/* Don't report alpha mask, since P96 can't usefully support it */

        
vformat->Amask 0xFF000000;
        
vformat->Ashift 24;
        
vformat->Aloss 0;
#endif
        
break;

    case 
RGBFB_A8B8G8R8:
        
vformat->BitsPerPixel 32;
        
vformat->BytesPerPixel 4;

        
vformat->Rmask 0x000000FF;
        
vformat->Rshift 0;
        
vformat->Rloss 0;

        
vformat->Gmask 0x0000FF00;
        
vformat->Gshift 8;
        
vformat->Gloss 0;

        
vformat->Bmask 0x00FF0000;
        
vformat->Bshift 16;
        
vformat->Bloss 0;
#if 0
/* Don't report alpha mask, since P96 can't usefully support it */

        
vformat->Amask 0xFF000000;
        
vformat->Ashift 24;
        
vformat->Aloss 0;
#endif
        
break;

    case 
RGBFB_R8G8B8A8:
        
vformat->BitsPerPixel 32;
        
vformat->BytesPerPixel 4;

#if 0
/* Don't report alpha mask, since P96 can't usefully support it */

        
vformat->Amask 0x000000FF;
        
vformat->Ashift 0;
        
vformat->Aloss 0;
#endif

        
vformat->Bmask 0x0000FF00;
        
vformat->Bshift 8;
        
vformat->Bloss 0;

        
vformat->Gmask 0x00FF0000;
        
vformat->Gshift 16;
        
vformat->Gloss 0;

        
vformat->Rmask 0xFF000000;
        
vformat->Rshift 24;
        
vformat->Rloss 0;
        break;

    case 
RGBFB_B8G8R8A8:
        
vformat->BitsPerPixel 32;
        
vformat->BytesPerPixel 4;

#if 0
/* Don't report alpha mask, since P96 can't usefully support it */

        
vformat->Amask 0x000000FF;
        
vformat->Ashift 0;
        
vformat->Aloss 0;
#endif

        
vformat->Rmask 0x0000FF00;
        
vformat->Rshift 8;
        
vformat->Rloss 0;

        
vformat->Gmask 0x00FF0000;
        
vformat->Gshift 16;
        
vformat->Gloss 0;

        
vformat->Bmask 0xFF000000;
        
vformat->Bshift 24;
        
vformat->Bloss 0;
        break;

    default:
        return 
FALSE;
    }

    return 
TRUE;
}


So, in commit about adding of compositing, those #if 0 was deleted (probabaly in hope that if we get rid of p96 calls, then there should't be any issues to remove those ifdefs).

Once i put them back, all start to works and bug disappear.

I even download very latest SDL1 code (that one from github, one on which we now with latest sources), and just doing it like this:

BOOL
os4video_PIXFtoPF
(SDL_PixelFormat *vformatPIX_FMT pixf)
{
    
vformat->Rmask vformat->Gmask vformat->Bmask vformat->Amask 0;
    
vformat->Rshift vformat->Gshift vformat->Bshift vformat->Ashift 0;
    
vformat->Rloss vformat->Gloss vformat->Bloss vformat->Aloss 8;

    switch(
pixf)
    {
    case 
PIXF_CLUT:
        
vformat->BitsPerPixel 8;
        
vformat->BytesPerPixel 1;
        break;

    case 
PIXF_R8G8B8:
        
vformat->BitsPerPixel 24;
        
vformat->BytesPerPixel 3;

        
vformat->Rmask 0x00FF0000;
        
vformat->Rshift 16;
        
vformat->Rloss 0;

        
vformat->Gmask 0x0000FF00;
        
vformat->Gshift 8;
        
vformat->Gloss 0;

        
vformat->Bmask 0x000000FF;
        
vformat->Bshift 0;
        
vformat->Bloss 0;
        break;

    case 
PIXF_B8G8R8:
        
vformat->BitsPerPixel 24;
        
vformat->BytesPerPixel 3;

        
vformat->Rmask 0x000000FF;
        
vformat->Rshift 0;
        
vformat->Rloss 0;

        
vformat->Gmask 0x0000FF00;
        
vformat->Gshift 8;
        
vformat->Gloss 0;

        
vformat->Bmask 0x00FF0000;
        
vformat->Bshift 16;
        
vformat->Bloss 0;
        break;

    case 
PIXF_R5G6B5PC:
    case 
PIXF_R5G6B5:
        
// We handle these equivalent and do swapping elsewhere.
        // PC format cannot be expressed by mask/shift alone
        
vformat->BitsPerPixel 16;
        
vformat->BytesPerPixel 2;

        
vformat->Rmask 0x0000F800;
        
vformat->Rshift 11;
        
vformat->Rloss 3;

        
vformat->Gmask 0x000007E0;
        
vformat->Gshift 5;
        
vformat->Gloss 2;

        
vformat->Bmask 0x0000001F;
        
vformat->Bshift 0;
        
vformat->Bloss 3;
        break;

    case 
PIXF_R5G5B5PC:
    case 
PIXF_R5G5B5:
        
vformat->BitsPerPixel 15;
        
vformat->BytesPerPixel 2;

        
vformat->Rmask 0x00007C00;
        
vformat->Rshift 10;
        
vformat->Rloss 3;

        
vformat->Gmask 0x000003E0;
        
vformat->Gshift 5;
        
vformat->Gloss 3;

        
vformat->Bmask 0x0000001F;
        
vformat->Bshift 0;
        
vformat->Bloss 3;
        break;

    case 
PIXF_A8R8G8B8:
        
vformat->BitsPerPixel 32;
        
vformat->BytesPerPixel 4;

        
vformat->Rmask 0x00FF0000;
        
vformat->Rshift 16;
        
vformat->Rloss 0;

        
vformat->Gmask 0x0000FF00;
        
vformat->Gshift 8;
        
vformat->Gloss 0;

        
vformat->Bmask 0x000000FF;
        
vformat->Bshift 0;
        
vformat->Bloss 0;


//        vformat->Amask = 0xFF000000;
//        vformat->Ashift = 24;
//        vformat->Aloss = 0;

        
break;

    case 
PIXF_A8B8G8R8:
        
vformat->BitsPerPixel 32;
        
vformat->BytesPerPixel 4;

        
vformat->Rmask 0x000000FF;
        
vformat->Rshift 0;
        
vformat->Rloss 0;

        
vformat->Gmask 0x0000FF00;
        
vformat->Gshift 8;
        
vformat->Gloss 0;

        
vformat->Bmask 0x00FF0000;
        
vformat->Bshift 16;
        
vformat->Bloss 0;

//        vformat->Amask = 0xFF000000;
//        vformat->Ashift = 24;
//        vformat->Aloss = 0;

        
break;

    case 
PIXF_R8G8B8A8:
        
vformat->BitsPerPixel 32;
        
vformat->BytesPerPixel 4;

//        vformat->Amask = 0x000000FF;
//        vformat->Ashift = 0;
//        vformat->Aloss = 0;

        
vformat->Bmask 0x0000FF00;
        
vformat->Bshift 8;
        
vformat->Bloss 0;

        
vformat->Gmask 0x00FF0000;
        
vformat->Gshift 16;
        
vformat->Gloss 0;

        
vformat->Rmask 0xFF000000;
        
vformat->Rshift 24;
        
vformat->Rloss 0;
        break;

    case 
PIXF_B8G8R8A8:
        
vformat->BitsPerPixel 32;
        
vformat->BytesPerPixel 4;

//        vformat->Amask = 0x000000FF;
//        vformat->Ashift = 0;
//        vformat->Aloss = 0;

        
vformat->Rmask 0x0000FF00;
        
vformat->Rshift 8;
        
vformat->Rloss 0;

        
vformat->Gmask 0x00FF0000;
        
vformat->Gshift 16;
        
vformat->Gloss 0;

        
vformat->Bmask 0xFF000000;
        
vformat->Bshift 24;
        
vformat->Bloss 0;
        break;

    default:
        
dprintf("Unknown pixel format %dn"pixf);
        return 
FALSE;
    }

    return 
TRUE;
}


I.e. comminting the same parts as it was before, and all working too with latest sdl1.

I of course can find out which one exactly cause issues in my case, but probably better will be to understand why there is issues at all, and maybe we should or put those commented outs back, or maybe somewhere inside SDL some code which check those reports made false assumptions.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 713
@kas1e

First of all, thanks for searching for the issue. Example code used only SW surface(s), so it would have been surprising if it would have ended somewhere in the composite code path.

I can't recall the exact reason why #ifdefs were removed but I think they were required for compositing to work, since compositing uses the alpha channel. Removing alpha channel might also break compositing but I haven't tested this.

It can be that there has to be some condition ("if accelerated alpha surface" or something) for alpha channel report.

Can I get the complete code, or will you do the rest of debugging (surface properties and such)?

   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5319
@Capehill
Yes of course will prepare whole archive. Just i need to upload it with ready to use .dat file, so you only will have needs to build source, and replace .exe in distrib. If not today, then tomorrow for sure

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5319
@Capehill
Sended you PM with source code and instructions of how to build/use it all. If you need any more help, plz ask ! I of course workarounded it already, but will be good to understand wtf and fix it.

ps. there lately was some new SDL1 fixes in main repo, seems they prepared for SDL1.2.16 release.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 713
@kas1e

Did some investigation and it seems that with the older SDL library, main video surface has surface.format.Amask 0 (which makes sense in light of your experiments) while with the compositing one Amask is non-zero. Demo engine creates another surface using SDL_DisplayFormat, called "current" and it appears that this one has SRCALPHA flag set with the newer library which breaks the rendering. Doing SDL_SetAlpha(current, 0, 0) in engine code cures the rendering by removing SRCALPHA flag.

Forcing Amask to 0 on this line: https://github.com/AmigaPorts/SDL/blob ... aos4/SDL_os4video.c#L1274 should remove Amask from the main video surface and thus also cure the issue. Could you confirm?


   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5319
@Capehill
Yes, setting hidden->screenSdlFormat.Amask to 0 in that SDL_ReallocFormat() fix it too.

If it didn't broke anything else (like compositing), will be good to add it to our repo of course )

Thanks for fast fix !

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Quite a regular
Joined:
2007/7/14 20:30
From Lothric
Posts: 713
@kas1e

Alpha issue might still need more testing and investigation.

I tried to merge the 1.2.16 changes, sadly whole configure script is now in conflict. I wonder would it be possible to insert OS4 changes into configure.in and regenerate configure from that? Or just ignore it and create a ticket so that people know about it.

   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5319
@Capehill

Quote:

I tried to merge the 1.2.16 changes, sadly whole configure script is now in conflict. I wonder would it be possible to insert OS4 changes into configure.in and regenerate configure from that? Or just ignore it and create a ticket so that people know about it.


Is makefile.amigaos4 still works ? If so, then we can just skip those issues with configure scripts. Imho, 1.2.16 version is probabaly if not latest one from 1.2.x , but pretty close to it. So even if we will keep only "make -f makefile.amigaos4" way, it will be not worse for sure, and will not give us any issues in future. Imho of course.

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top


« 1 ... 8 9 10 (11)



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project