Login
Username:

Password:

Remember me



Lost Password?

Register now!
Sections
Who's Online
46 user(s) are online (41 user(s) are browsing Forums)

Members: 0
Guests: 46

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



« 1 ... 8 9 10 (11) 12 13 14 15 »


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: 782
@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: 5464
@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: 5464
@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: 782
@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: 5464
@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: 5464
@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: 782
@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: 5464
@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: 5464
@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: 782
@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: 5464
@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: 782
@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: 5464
@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

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 5464
@Capehill
I working on port of IrrLicht engine: http://irrlicht.sourceforge.net/ and currently it can be build only with SDL1. While port is working, found 2 issues with it, maybe you can be of any help there.

Issue #1:

When any binary compiled with Irrlicht's "isWindowActive()" function check, then our window always stays black, till i not move mouse cursor inside of the window. Like our window is not active (while it is). On win32 it of course works as expected.

See the usuall rendering loop:

while(device->run())
    if (
device->isWindowActive())
    {
        
driver->beginScene(truetruevideo::SColor(0,200,200,200));
        
smgr->drawAll();
        
driver->endScene();

        
int fps driver->getFPS();

        if (
lastFPS != fps)
        {
            
core::stringw str L"Load Irrlicht File example - Irrlicht Engine [";
            
str += driver->getName();
            
str += "] FPS:";
            
str += fps;

            
device->setWindowCaption(str.c_str());
            
lastFPS fps;
        }

    }


Once i remove that "if (device->isWindowActive())" , it renders then from the begining. But what for sure, is that window is active after running. Just seems Irrlicht's isWindowActive() fail by some reassons. There is source of it:

//! returns if window is active. if not, nothing need to be drawn
bool CIrrDeviceSDL::isWindowActive() const
{
    return (
WindowHasFocus && !WindowMinimized);
}



And those WindowHasFocus and WindowMinimized , handled as SDL_Events, like this:

case SDL_ACTIVEEVENT:
            if ((
SDL_event.active.state == SDL_APPMOUSEFOCUS) ||
                    (
SDL_event.active.state == SDL_APPINPUTFOCUS))
                
WindowHasFocus = (SDL_event.active.gain==1);
            else
            if (
SDL_event.active.state == SDL_APPACTIVE)
                
WindowMinimized = (SDL_event.active.gain!=1);
            break;


So maybe something there fail on our side ?


Issue #2:

On amigaos4 initialising/deinitialising engine more than 2 times from the same binary , cause SDL1 to be not able to reinitialize video modes , and i just have for second time:

"Unable to initialize SDL!: No available video device"

I create simple test case for that bug:

#include <irrlicht.h>
#include <unistd.h>

using namespace irr;
using namespace core;

int main()
{
    
// 1st run

    
IrrlichtDevice *device createDevicevideo::EDT_SOFTWAREdimension2d<u32>(640480), 16falsefalsefalse0);

    if (!
device) {
        return 
1;
    }

    
device->setWindowCaption(L"First run !");

    
sleep(10);

    
device->drop();

// 2st run

    
IrrlichtDevice *device2 createDevicevideo::EDT_SOFTWAREdimension2d<u32>(640480), 16falsefalsefalse0);

    if (!
device2) {
        return 
1;
    }

    
device2->setWindowCaption(L"Second run!");

    
sleep(10);

    
device2->drop();

    return 
0;
}


So on win32 , it just runs second window second time and all fine, but on os4, window from first init open/closes, and then second never come up, as i have "Unable to initialize SDL!: No available video device". But it should , from programm point of view we just init/deinit SDL, nothing else..

I can made archive with those 2 simple test-cases working (with sources, and necessary lib to just compile it easy), so you can check it too if you want to. Issues happens even with software renderer, so it just about out SDL1.

PS. There is full source related to SDL in Irrlicht (1 file), which probabaly can help to understand why both issues happens:

https://gitlab.com/pgimeno/irrlicht-mi ... rrlicht/CIrrDeviceSDL.cpp


Edited by kas1e on 2019/8/22 19:41:46
Edited by kas1e on 2019/8/22 19:43:02
Edited by kas1e on 2019/8/22 19:48:42
Edited by kas1e on 2019/8/22 19:49:15
Edited by kas1e on 2019/8/22 20:11:27
Edited by kas1e on 2019/8/22 20:14:05
Edited by kas1e on 2019/8/22 20:17:55
Edited by kas1e on 2019/8/22 20:20:42
_________________
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: 782
@kas1e

1) Could you debug whether the issue is focus or minimized state?

2) Issue is probably Irrlicht itself: https://gitlab.com/pgimeno/irrlicht-mi ... cht/CIrrDeviceSDL.cpp#L85 Have you added __amigaos4__ specific putenv here?

On the 2nd try, SDL has probably tried to open "x11" video device and got a nullptr: https://github.com/AmigaPorts/SDL/blob ... rc/video/SDL_video.c#L521

   Report Go to top

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

2) Issue is probably Irrlicht itself: https://gitlab.com/pgimeno/irrlicht-mi ... cht/CIrrDeviceSDL.cpp#L85 Have you added __amigaos4__ specific putenv here?

On the 2nd try, SDL has probably tried to open "x11" video device and got a nullptr: https://github.com/AmigaPorts/SDL/blob ... rc/video/SDL_video.c#L521


Damn !:) Once i was able to find it and back at amigans to write about, you pretty well got it just by checking the source ! For me it was "cut-cut" work part by part until i realise that its indeed SDL_putenv("SDL_VIDEODRIVER=x11"); which cause issue.

At moment i tried to put there :

#elif defined(__amigaos4__)
    
SDL_putenv("SDL_VIDEODRIVER=amigaos4");


But that didn't help, still same crash. I assume it just maybe not "amigaos4", but "AmigaOS4" , or "Amiga" or so ?


For the first issue, yeah, will debug it now.

_________________
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: 782
@kas1e

Try "OS4" - https://github.com/AmigaPorts/SDL/blob ... gaos4/SDL_os4video.c#L222

Dunno why Irrlicht even does this. In emergency you could just skip whole putenv business.

   Report Go to top

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

Dunno why Irrlicht even does this. In emergency you could just skip whole putenv business.


Yeah, i just read that its should be avoided, but used for debugging purposes (dunno which ones exactly), just fear that maybe they use it for something which i can overlook.

And yep, OS4 works too, thanks !

Will try to debug first issue now

_________________
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: 5464
@Capehill
Digging more in first issue, and found that for win32 tests i didn't use SDL device before , i use direct win32 one:

https://gitlab.com/pgimeno/irrlicht-mi ... licht/CIrrDeviceWin32.cpp

So, once i rebuild irrlicht for win32 with SDL instead, it have the same issue !

I.e. its not amigaos4 only, but same on win32, which mean that this is bug in irrlicht then. I can think that it can be intendent if it reacts the same and with win32 direct device, but as with win32 its all fine, but different with SDL, then probabaly SDL one need to be fixed in irrlicht itself.

I anyway added printfs to SDL_ACTIVEEVENT case, and when we run binarys, then we have set SDL_APPMOUSEFOCUS, but didn't have set SDL_APPINPUTFOCUS and SDL_APPACTIVE.

Probabaly to fix that, all what is need it add some code when sdl initialised, and window open, make it active not only for SDL_APPMOUSEFOCUS, but also for SDL_APPINPUTFOCUS ?

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


« 1 ... 8 9 10 (11) 12 13 14 15 »



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project