Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
33 user(s) are online (12 user(s) are browsing Forums)

Members: 1
Guests: 32

Daytona675x, more...

Support us!

Recent OS4 Files
OS4Depot.net




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


Re: SDL1 open issues
Posted on: 2019/8/24 8:36   #221
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill
In meantime found some fork, where one man trying to replace sdl1 on sdl2 in irrlicht. There is new CIrrDeviceSDL2.cpp():
https://github.com/okuoku/irrlicht-gen ... rlicht/CIrrDeviceSDL2.cpp

So i adapt it to current source, but to find out that it's so much slower than sdl1 version, that its just unreal. I made a few tests for some example

winxp, amd 1.6ghz, sdl1 : 30fps, sdl2: 14fps
win10, icore6 2.7ghz, sdl1: 110fps, sdl2: 60fps
amigaos4, x5k, sdl1: 28fps, sdl2: 2fps (!)

So while on win32 builds everything twice slower, on amigaos4 everything just stops :)

Yeah, it mean that this sdl2 migration doing something very wrong, and strangely on amigaos4 it not just twice slower, but almost stop everything.

I think its about CIrrDeviceSDL::present() realisation and how the surface and blitting done, see there some SDL_CreateRGBSurfaceWithFormatFrom with SDL_PIXELFORMAT_ARGB8888 as default , and some strange SDL_RenderCopy().. Imho something there cause those heavy issues (And still strange, why on amigaos4 it made not just slower, but just everything about to stop, mouse jerky, whole system overloaded, etc).
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/24 9:40   #222
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1070
@kas1e

It allocates (and frees) 2 surfaces per frame! There should be just a pre-allocated streaming texture which gets updated once per frame and finally presented.

At the moment I don't have time to check it more but the implementation just looks very slow and pointless.
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/24 9:51   #223
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
..
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/24 9:56   #224
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill
Quote:

At the moment I don't have time to check it more but the implementation just looks very slow and pointless.


In general it just copy of SDL1 version, just he tried to port it to SDL2 .. And the only real difference is that CIrrDeviceSDL::present() realisation with re-copy of 2 surfaces, etc.

I tried to play with it by commenting out parts,etc, but its just slow all the time, even if i keep only one surface.. If you will have time, maybe you can give a try to fix that part ? If all will be same by speed as with sdl1, we can get rid of sdl1 there, and maybe it automatically will fix "windowactive" issue too. Plus having SDL2 for all new stuff always better today..
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/24 14:08   #225
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1070
@kas1e

It should be something like this, no allocations, no locks:

if (!SoftwareRendered)
    return true;

if (SDL_UpdateTexture(ScreenTexture, NULL /* update whole texture */, surface->getData(), surface->getPitch()) != 0) {
    // SDL_GetError
}
    
if (SDL_RenderCopy(ScreenRenderer, ScreenTexture, NULL, NULL) != 0) {
    // SDL_GetError
}
    
SDL_RenderPresent(ScreenRenderer);
return true;


But the above code is not compiled. I'm assuming here that the incoming data ("surface") is of same size and format as texture ("ScreenTexture").

PS. please make a ticket for window focus issue.
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/24 18:28   #226
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill
Quote:

But the above code is not compiled. I'm assuming here that the incoming data ("surface") is of same size and format as texture ("ScreenTexture").


Well, that definately the way to do how you show it. I just copy+paste your code, without any creation of sdlsurface. And it even render something to the window (just half of the window , and with wrong colors), but it renderes for sure, and speed is MUCH better.

Should't somewhere sdlsurface be created at all , or , there is no needs for ?

And how to deal with "format" then, probabaly still need to call SDL_LockTexture ?

Quote:

PS. please make a ticket for window focus issue.


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

Re: SDL1 open issues
Posted on: 2019/8/24 19:02   #227
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1070
@kas1e

Ideally, Irrlicht should be configured to render to an ARGB "surface" (I mean video::IImage, not SDL_Surface) which could be then uploaded to the texture. SDL_Surface would be only an extra step and hopefully unnecessary.

Do you know how to configure Irrlicht renderer?

Texture is created here: https://github.com/okuoku/irrlicht-gen ... /CIrrDeviceSDL2.cpp#L1219

When surface is matching, then it should be alright.

We try to do this: https://wiki.libsdl.org/MigrationGuide ... ered_frames_to_the_screen

1) Let Irrlicht render its SW surface
2) Update texture (pixels travel to VRAM if accelerated renderer used)
3) Render texture
4) Profit?

So this is SW renderering, how about HW? I suppose Irrlicht speaks also OpenGL?
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/24 20:07   #228
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill
Quote:

Ideally, Irrlicht should be configured to render to an ARGB "surface" (I mean video::IImage, not SDL_Surface) which could be then uploaded to the texture. SDL_Surface would be only an extra step and hopefully unnecessary.


I think we can't rewrite irrlicht a lot, it will bring other problems imho. Its pretty heavy , and the more things to change in other files can lead to problems we will not see from first look :)

At least, if with SDL1 it was with SDL_Surface, and it even was allocated each frame, maybe at first we can do same with SDL2, and then, thinking about how to get rid of it for speed.

Quote:

Do you know how to configure Irrlicht renderer?


Its not configured as i can tell, you just choice what one to compile in. Everything controlled from one include file : include/irrCompileconfig.h


Quote:

So this is SW renderering, how about HW? I suppose Irrlicht speaks also OpenGL?


Yeah sure OpenGL (over gl4es, minigl too old for). gl4es usage was the main point why i working on it. I made a port year ago, just now want to make it "all allright" for release, to have and opengl, and software renders works (software rendering will help for example those ones who don't have ogles).

Initially Irrlicht support those drivers:

software rendering
burning video (same as software, just more accurate)
directx 8 & 9
opengl

you can configure to use or one of them, or all of them, or some of them, etc.

Also, it can be configured to which device do render things. And initially Irrlicht support those: SDL1, win32 and X11.

So, you can mix it all you want. Just choice what drivers to compile in , and which device use with.

And as whole Irrlicht now progress veeery slow, all the tries like adding SDL2, or OpenGLES2 support, done by those random patches there and there by ppls who don't test things much, and "oh, i made it works ! its enough".

And before i can go route like "sdl2 + opengl" on amigos4, i firstly need to made "sdl2+software rendering" works on both, amigaos4 and win32 (and be the same or better by speed as sdl1), and then, when all works on both oses, i can add opengl there (for both oses again, so can test differences between, etc).

And as next step i will try to add opengles2 directly without opengl (and so gl4es), but firstly need that software rendering to be sure that SDL2 rewrite works as expected , and then all other work can be done on top of it.


PS. ah, and what i forget to tell : i do all tests on 1.8.4 irrlicht. That link where SDL2 patch placed, are from unfinished 1.9.0 release. Its all the same, just there is no surface->getData() , but surface->lock() instead. So i had to change it.

Its in include/IImage.h and relevant part are:

//! Use this to get a pointer to the image data.
    /**
    return Pointer to the image data. What type of data is pointed to
    depends on the color format of the image. For example if the color
    format is ECF_A8R8G8B8, it is of u32. */
    void* getData() const
    {
        return Data;
    }

    //! Lock function. Use this to get a pointer to the image data.
    /** Use getData instead.
    return Pointer to the image data. What type of data is pointed to
    depends on the color format of the image. For example if the color
    format is ECF_A8R8G8B8, it is of u32. Be sure to call unlock() after
    you don't need the pointer any more. */
    _IRR_DEPRECATED_ void* lock()
    {
        return getData();
    }


but that for unfinished 1.9.0, for 1.8.4 there was only surface->lock():

https://sourceforge.net/p/irrlicht/cod ... ases/1.8/include/IImage.h

So, that one we need to use.


Edited by kas1e on 2019/8/24 20:23:19
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/24 20:21   #229
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1070
@kas1e

I mean that video::IImage surface has to be ARGB8888 format or texture updating fails. This surface is created somewhere, and maybe it uses totally different format for some reason. You can use printf to debug bitmasks, for example, then we know what's there.
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/24 20:25   #230
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill

Well, if consider that we use not surface->getdata() from 1.9.0, but surface->lock() from 1.8.4, then that what writen in IImage.h about:

//! Lock function. Use this to get a pointer to the image data.
    /** After you don't need the pointer anymore, you must call unlock().
    return Pointer to the image data. What type of data is pointed to
    depends on the color format of the image. For example if the color
    format is ECF_A8R8G8B8, it is of u32. Be sure to call unlock() after
    you don't need the pointer any more. */


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

Re: SDL1 open issues
Posted on: 2019/8/25 7:11   #231
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill

I just added:

printf("surface->getRedMask() = %08x, surface->getGreenMask() = %08x, surface->getBlueMask() = %08x, surface->getAlphaMask() = %08xn",surface->getRedMask(), surface->getGreenMask(), surface->getBlueMask(), surface->getAlphaMask());


Rigth at begining of our block, and that what i have when i run example and it renders to half of screen with a wrong colors:

surface->getRedMask() = 00007c00
surface->getGreenMask() = 000003e0
surface->getBlueMask() = 0000001f
surface->getAlphaMask() = 00008000


Now, I see in the SDL1 code:
https://sourceforge.net/p/irrlicht/cod ... rrlicht/CIrrDeviceSDL.cpp

In that CIrrDeviceSDL::present , that at begining they do that:

sdlSurface->format->BitsPerPixel=surface->getBitsPerPixel();
    sdlSurface->format->BytesPerPixel=surface->getBytesPerPixel();
    if ((surface->getColorFormat()==video::ECF_R8G8B8) ||
            (surface->getColorFormat()==video::ECF_A8R8G8B8))
    {
        sdlSurface->format->Rloss=0;
        sdlSurface->format->Gloss=0;
        sdlSurface->format->Bloss=0;
        sdlSurface->format->Rshift=16;
        sdlSurface->format->Gshift=8;
        sdlSurface->format->Bshift=0;
        if (surface->getColorFormat()==video::ECF_R8G8B8)
        {
            sdlSurface->format->Aloss=8;
            sdlSurface->format->Ashift=32;
        }
        else
        {
            sdlSurface->format->Aloss=0;
            sdlSurface->format->Ashift=24;
        }
    }
    else if (surface->getColorFormat()==video::ECF_R5G6B5)
    {
        sdlSurface->format->Rloss=3;
        sdlSurface->format->Gloss=2;
        sdlSurface->format->Bloss=3;
        sdlSurface->format->Aloss=8;
        sdlSurface->format->Rshift=11;
        sdlSurface->format->Gshift=5;
        sdlSurface->format->Bshift=0;
        sdlSurface->format->Ashift=16;
    }
    else if (surface->getColorFormat()==video::ECF_A1R5G5B5)
    {
        sdlSurface->format->Rloss=3;
        sdlSurface->format->Gloss=3;
        sdlSurface->format->Bloss=3;
        sdlSurface->format->Aloss=7;
        sdlSurface->format->Rshift=10;
        sdlSurface->format->Gshift=5;
        sdlSurface->format->Bshift=0;
        sdlSurface->format->Ashift=15;
    }


So they do check what video formats textures have, and set sdlSurface's format to necessary value because of this. Question is what and to which we need to set, if we don't use sdlSurface. I.e. can we call SDL_UpdateTexture()+SDL_RenderCopy() with necessary format taken from the above check ?

I just removed from the above checks all sdlSurfaces sets, and just put prinfs, so in our case (i.e. with your code and when it draws half of screen with wrong colors), its video::ECF_A1R5G5B5 format. That explain probably "half of screen" drawing and wrong colors as well. Need somehow to tell to SDL_UpdateTexture()+SDL_RenderCopy() what format we use.
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/25 7:24   #232
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill
I think that check on formats need be added rigth before SDL_CreateTexture() , but strange that this one called inside of CIrrDeviceSDL::resizeWindow ! And that function didn't have any surface::IImage, so i can't there to that check and put necessary value for format.
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/25 10:28   #233
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1070
@kas1e

Quote:


In that CIrrDeviceSDL::present , that at begining they do that:



I don't understand why, because if I'm reading the correct code, Irrlicht SW renderer is hard-coded to 16-bit: https://github.com/okuoku/irrlicht-gen ... t/CSoftwareDriver.cpp#L33

It would be interesting to know would Irrlicht work nicely if this hard-coded format was changed to 32-bit. Maybe it's slower to render 32-bit but it should look nicer too.

Second option is to modify texture format to 16-bit (same as Irrlicht's). But not even SDL software renderer support this exact format with 1-bit alpha so it means (as far as I know) that SDL will do colour conversion step during texture update.

Third option is to manually convert colour format but I don't like this one.

Quote:

Need somehow to tell to SDL_UpdateTexture()+SDL_RenderCopy() what format we use.


No. We have already told SDL which colour format we want to use when we created the texture. It is application's responsibility to provide valid data.

https://wiki.libsdl.org/SDL_UpdateTexture "pixels - the raw pixel data in the format of the texture"
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/25 13:43   #234
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill
Quote:

I don't understand why, because if I'm reading the correct code, Irrlicht SW renderer is hard-coded to 16-bit: https://github.com/okuoku/irrlicht-gen ... t/CSoftwareDriver.cpp#L33


I think its done for simplifity things and for speed. Software rendering mostly used for some test probably and for comparing things, it probabaly just have no needs to be 32bit aware.

Quote:

It would be interesting to know would Irrlicht work nicely if this hard-coded format was changed to 32-bit. Maybe it's slower to render 32-bit but it should look nicer too.


Its already not that fast on amigaos4 as it should be, because of all kind of reassons (i will post benchmarks later in some other thread), so make it be even more slower even in software rendering imho no go. Its just on level of old 1.6ghz amd :) (Probably because of missing DMA in graphics.library as well as anything else). But probabaly for theoretical reassons and for checks, it can be intersting to play with..

Quote:

Second option is to modify texture format to 16-bit (same as Irrlicht's). But not even SDL software renderer support this exact format with 1-bit alpha so it means (as far as I know) that SDL will do colour conversion step during texture update.

Third option is to manually convert colour format but I don't like this one.


What i mean, is that we do call SDL_CreateTexture() with some image format. So, all we need there, is to check what image format we have, and put it to the SDL_CreateTexture() instead of SDL_PIXELFORMAT_ARGB8888.

I think about something like this:

void CIrrDeviceSDL::resizeWindow(u32 x, u32 y)
{
    
    if (ScreenWindow)
    {
        SDL_SetWindowSize(ScreenWindow, x, y);
    }
    if (ScreenTexture)
    {
        SDL_DestroyTexture(ScreenTexture);
        ScreenTexture = NULL;
    }
    

    if ((surface->getColorFormat()==video::ECF_R8G8B8) || (surface->getColorFormat()==video::ECF_A8R8G8B8))
    {
        //printf("video::ECF_R8G8B8) || (surface->getColorFormat()==video::ECF_A8R8G8B8n");
        if (surface->getColorFormat()==video::ECF_R8G8B8)
        {
            //printf("video::ECF_R8G8B8n");
            ScreenTexture = SDL_CreateTexture(ScreenRenderer, SDL_PIXELFORMAT_RGB888, SDL_TEXTUREACCESS_STREAMING, Width, Height);
        }
        else
        {
        }
    }
    else if (surface->getColorFormat()==video::ECF_R5G6B5)
    {
        //printf("video::ECF_R5G6B5n");
        ScreenTexture = SDL_CreateTexture(ScreenRenderer, SDL_PIXELFORMAT_RGB565, SDL_TEXTUREACCESS_STREAMING, Width, Height);
    }
    else if (surface->getColorFormat()==video::ECF_A1R5G5B5)
    {
        //printf("video::ECF_A1R5G5B5n");
        ScreenTexture = SDL_CreateTexture(ScreenRenderer, SDL_PIXELFORMAT_ARGB1555, SDL_TEXTUREACCESS_STREAMING, Width, Height);
    }

                            
}


But that didn't work, as at moment when this resizeWindow() is called , it seems that image's surface didn't containt necessary format, and it return ECF_R8G8B8 sadly.. Maybe just code need to be restuctured a little, so when we will call SDL_CreateTexture() format of image's surface will be known, and so all will works.
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/25 16:55   #235
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1070
@kas1e

This line https://github.com/okuoku/irrlicht-gen ... /CIrrDeviceSDL2.cpp#L1219 should be changed to SDL_PIXELFORMAT_ARGB1555. Then it should match Irrlicht's hard-coded format.
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/25 18:44   #236
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill
I now understand why they in SDL1 (and in that SDL2 patch) version do check on all things (i.e. on argb8888 as well, and on rgb565, not only a1555): because Irrlicht have 2 different software renderers. One called exactly like that "softwarerenderer" but its not very accurate. And another one, called "BurningsVideo", which is also software renderer, but this one much more accurate. And there is his file : CSoftwareDriver2.cpp (see 2 at end)

So, when you use SDL in irrlicht, you may choice and "software renderer" and "burnings video", which boch software. And while in first one, a1555 are hardcoded, second one maybe more accurate in that terms.
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/25 19:12   #237
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill
I anyway tried with your code and a1555 , results are : on win32, both sdl1 and sdl2 the same by speed. Maybe sdl2 on 1-2 fps less.

But the same code on amigaos4 with sdl2 , crawl a lot ! Just give 2-3 fps, instead of 30 as with SDL1.

I think there some other bug flying around in that SDL2 patch. Strange that on amigaos4 it that reacts, and on win32 not.

There is my current version:
http://kas1e.mikendezign.com/aos4/irrlicht/CIrrDeviceSDL.cpp

As said its ok on win32, same as sdl1 by speed. Just on amigaos4 by some reassons give 2-3 fps. Maybe something with events, which somehow ok for win32 and not for aos4 ?
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/25 19:49   #238
Just can't stay away
Joined:
2007/7/14 21:30
From Lothric
Posts: 1070
@kas1e

Is there difference between accelerated and software renderer?

You could try to measure:

if (!SoftwareRendered)
    return true;

Uint32 a = SDL_GetTicks();

if (SDL_UpdateTexture(ScreenTexture, NULL /* update whole texture */, surface->lock(), surface->getPitch()) != 0) {
        // SDL_GetError
}

Uint32 b = SDL_GetTicks();

if (SDL_RenderCopy(ScreenRenderer, ScreenTexture, NULL, NULL) != 0) {
    // SDL_GetError
}

Uint32 c = SDL_GetTicks();

SDL_RenderPresent(ScreenRenderer);

Uint32 d = SDL_GetTicks();

printf("Update %u, Copy %u, Present %u\n", b - a, c - b, d - c)

return true;



   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/25 20:01   #239
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill
Quote:

Is there difference between accelerated and software renderer?


Tried to replace SDL_CreateRenderer(ScreenWindow, -1, 0); on SDL_CreateRenderer(ScreenWindow, -1, SDL_RENDERER_ACCELERATED); give no changes visually, same.

Quote:

You could try to measure:


That log i have when running:

Quote:

Update 9, Copy 0, Present 5
Update 8, Copy 0, Present 1
Update 8, Copy 0, Present 0
Update 8, Copy 0, Present 0
Update 8, Copy 0, Present 0
Update 9, Copy 0, Present 0
Update 9, Copy 0, Present 0
Update 8, Copy 0, Present 0
Update 8, Copy 0, Present 0
Update 8, Copy 0, Present 0
Update 8, Copy 0, Present 0
Update 8, Copy 0, Present 0
Update 7, Copy 0, Present 0
Update 7, Copy 0, Present 1
Update 7, Copy 0, Present 1
Update 7, Copy 0, Present 0
Update 7, Copy 0, Present 1
Update 8, Copy 0, Present 0


What i can't get currently, its why on win32 in terms of speed there is not such massive slowdown with 1:1 same code. We test pretty much of SDL2 apps already over our SDL2 , so strange..

On win32 when i put the same measure code, i have such output:

Quote:

Update 3, Copy 4, Present 7
Update 2, Copy 0, Present 1
Update 3, Copy 0, Present 1
Update 2, Copy 0, Present 1
Update 3, Copy 0, Present 0
Update 3, Copy 0, Present 1
Update 3, Copy 0, Present 2
Update 2, Copy 0, Present 1
Update 2, Copy 0, Present 1
Update 3, Copy 0, Present 0
Update 3, Copy 0, Present 0
Update 3, Copy 0, Present 0
Update 3, Copy 0, Present 1
Update 2, Copy 0, Present 2
Update 2, Copy 0, Present 1
Update 2, Copy 0, Present 1
Update 2, Copy 0, Present 1
Update 3, Copy 0, Present 0
Update 3, Copy 0, Present 0
Update 3, Copy 0, Present 0
Update 3, Copy 0, Present 0
Update 3, Copy 0, Present 1
Update 2, Copy 0, Present 1
Update 2, Copy 0, Present 1
Update 2, Copy 0, Present 1
Update 3, Copy 0, Present 0


And no slowdowns

ps. just in case i check debugbuffer : nope, there is nothing which can slow things down that much.

edit: there definately something with that sdl2 code: i find out that on win32 descructor never called !


Edited by kas1e on 2019/8/25 20:49:18
Edited by kas1e on 2019/8/26 13:49:19
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Posted on: 2019/8/26 9:22   #240
Home away from home
Joined:
2007/9/11 12:31
From Russia
Posts: 6329
@Capehill
I minimize SDL2 version till veeery small test case , so, there is:

#include "IrrCompileConfig.h"

#ifdef _IRR_COMPILE_WITH_SDL_DEVICE_

#include "CIrrDeviceSDL.h"
#include "IEventReceiver.h"
#include "irrList.h"
#include "os.h"
#include "CTimer.h"
#include "irrString.h"
#include "Keycodes.h"
#include "COSOperator.h"
#include <stdio.h>
#include <stdlib.h>
#include "SIrrCreationParameters.h"
#include <SDL2/SDL_syswm.h>
#include <SDL2/SDL_video.h>


namespace irr
{
    
//! constructor
CIrrDeviceSDL::CIrrDeviceSDL(const SIrrlichtCreationParameters& param)
    : CIrrDeviceStub(param),
    ScreenWindow(0), ScreenTexture(0),
    MouseX(0), MouseY(0), MouseXRel(0), MouseYRel(0), MouseButtonStates(0),
    Width(param.WindowSize.Width), Height(param.WindowSize.Height),
    Resizable(false), WindowHasFocus(true)
{

    printf("ebaniy constuctor!n");
    fflush(stdout);


    if (SDL_Init( SDL_INIT_TIMER|SDL_INIT_VIDEO| SDL_INIT_NOPARACHUTE ) <0)
    {
        os::Printer::log( "Unable to initialize SDL!", SDL_GetError());
        Close = true;
    }

    createWindow();

    // create cursor control
    CursorControl = new CCursorControl(this);

    // create driver
    createDriver();

    if (VideoDriver)
        createGUIAndScene();
    
    printf("ebaniy constructor done!n");
    fflush(stdout);

}


//! destructor
CIrrDeviceSDL::~CIrrDeviceSDL()
{
    printf("ebaniy descrutctor!n");
    fflush(stdout);
    
    if (ScreenTexture) 
    { 
    SDL_DestroyTexture(ScreenTexture); 
    ScreenTexture = NULL; 
    } 
    SDL_DestroyWindow(ScreenWindow);
    SDL_DestroyRenderer(ScreenRenderer);

    SDL_Quit();

    os::Printer::log("Quit SDL", ELL_INFORMATION);
}

bool CIrrDeviceSDL::createWindow()
{
    if ( Close )
        return false;

    int flags = 0;
    ScreenWindow = SDL_CreateWindow("Untitled", SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, Width, Height, flags);
    ScreenRenderer = SDL_CreateRenderer(ScreenWindow, -1, 0);
    ScreenTexture = SDL_CreateTexture(ScreenRenderer, SDL_PIXELFORMAT_ARGB1555, SDL_TEXTUREACCESS_STREAMING, Width, Height);


    return true;
}


//! create the driver
void CIrrDeviceSDL::createDriver()
{
    switch(CreationParams.DriverType)
    {
    case video::EDT_SOFTWARE:
        #ifdef _IRR_COMPILE_WITH_SOFTWARE_
        VideoDriver = video::createSoftwareDriver(CreationParams.WindowSize, CreationParams.Fullscreen, FileSystem, this);
        #else
        os::Printer::log("No Software driver support compiled in.", ELL_ERROR);
        #endif
        break;

    default:
        os::Printer::log("Unable to create video driver of unknown type.", ELL_ERROR);
        break;
    }

}


//! runs the device. Returns false if device wants to be deleted
bool CIrrDeviceSDL::run()
{
    os::Timer::tick();

    SEvent irrevent;
    SDL_Event SDL_event;

    while ( !Close && SDL_PollEvent( &SDL_event ) )
    {
        switch ( SDL_event.type )
        {
        case SDL_MOUSEMOTION:
            irrevent.EventType = irr::EET_MOUSE_INPUT_EVENT;
            irrevent.MouseInput.Event = irr::EMIE_MOUSE_MOVED;
            MouseX = irrevent.MouseInput.X = SDL_event.motion.x;
            MouseY = irrevent.MouseInput.Y = SDL_event.motion.y;
            irrevent.MouseInput.ButtonStates = MouseButtonStates;

            postEventFromUser(irrevent);
            break;
        
            
        case SDL_QUIT:
            Close = true;
            break;

        default:
            break;
        } // end switch

    } // end while

    return !Close;
}


//! pause execution temporarily
void CIrrDeviceSDL::yield()
{
    SDL_Delay(0);
}


//! pause execution for a specified time
void CIrrDeviceSDL::sleep(u32 timeMs, bool pauseTimer)
{
    const bool wasStopped = Timer ? Timer->isStopped() : true;
    if (pauseTimer && !wasStopped)
        Timer->stop();

    SDL_Delay(timeMs);

    if (pauseTimer && !wasStopped)
        Timer->start();
}


//! sets the caption of the window
void CIrrDeviceSDL::setWindowCaption(const wchar_t* text)
{
    core::stringc textc = text;
    SDL_SetWindowTitle(ScreenWindow, textc.c_str());
}


//! presents a surface in the client area
bool CIrrDeviceSDL::present(video::IImage* surface, void* windowId, core::rect<s32>* srcClip)
{

    if (SDL_UpdateTexture(ScreenTexture, NULL /* update whole texture */, surface->lock(), surface->getPitch()) != 0) { 
        // SDL_GetError 
    } 
     
    if (SDL_RenderCopy(ScreenRenderer, ScreenTexture, NULL, NULL) != 0) { 
        // SDL_GetError 
    } 
     
    SDL_RenderPresent(ScreenRenderer); 
    return true;
}


//! notifies the device that it should close itself
void CIrrDeviceSDL::closeDevice()
{
    Close = true;
}


//! return Pointer to a list with all video modes supported
video::IVideoModeList* CIrrDeviceSDL::getVideoModeList()
{
}
 
 


//! Sets if the window should be resizable in windowed mode.
void CIrrDeviceSDL::setResizable(bool resize)
{
}


//! Minimizes window if possible
void CIrrDeviceSDL::minimizeWindow()
{
    if (ScreenWindow) {
        SDL_MinimizeWindow(ScreenWindow);
    }
}


//! Maximize window
void CIrrDeviceSDL::maximizeWindow()
{
    if (ScreenWindow) {
        SDL_MaximizeWindow(ScreenWindow);
    }
}

//! Restore original window size
void CIrrDeviceSDL::restoreWindow()
{
    // do nothing
}

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


//! returns if window has focus.
bool CIrrDeviceSDL::isWindowFocused() const
{
    return WindowHasFocus;
}


//! returns if window is minimized.
bool CIrrDeviceSDL::isWindowMinimized() const
{
    return WindowMinimized;
}


//! Set the current Gamma Value for the Display
bool CIrrDeviceSDL::setGammaRamp( f32 red, f32 green, f32 blue, f32 brightness, f32 contrast )
{
    return false;
}

//! Get the current Gamma Value for the Display
bool CIrrDeviceSDL::getGammaRamp( f32 &red, f32 &green, f32 &blue, f32 &brightness, f32 &contrast )
{
    return false;
}


//! returns color format of the window.
video::ECOLOR_FORMAT CIrrDeviceSDL::getColorFormat() const
{
        return CIrrDeviceStub::getColorFormat();
}

} // end namespace irr

#endif // _IRR_COMPILE_WITH_SDL1_DEVICE_


As you can see there is almost no code left, but it works as expected on win32 (same speed as for sdl1, etc). On amigaos4 the same 1:1 code copied and compiled in, bring some madness-move of camera, without stop. Like i move mouse fast fast everywhere. At least visually.

Then, once i add check/set on "focus", i.e. to make run() be like this:

//! runs the device. Returns false if device wants to be deleted
bool CIrrDeviceSDL::run()
{
    os::Timer::tick();

    SEvent irrevent;
    SDL_Event SDL_event;

    while ( !Close && SDL_PollEvent( &SDL_event ) )
    {
        switch ( SDL_event.type )
        {
        case SDL_MOUSEMOTION:
            irrevent.EventType = irr::EET_MOUSE_INPUT_EVENT;
            irrevent.MouseInput.Event = irr::EMIE_MOUSE_MOVED;
            MouseX = irrevent.MouseInput.X = SDL_event.motion.x;
            MouseY = irrevent.MouseInput.Y = SDL_event.motion.y;
            irrevent.MouseInput.ButtonStates = MouseButtonStates;

            postEventFromUser(irrevent);
            break;
        case SDL_WINDOWEVENT: 
            switch (SDL_event.window.event) 
            { 

            case SDL_WINDOWEVENT_ENTER: 
            case SDL_WINDOWEVENT_FOCUS_GAINED: 
                printf("we got events about focus=truen");
                fflush(stdout);
                WindowHasFocus = true; 
                break; 
                 
            case SDL_WINDOWEVENT_LEAVE: 
            case SDL_WINDOWEVENT_FOCUS_LOST: 
                printf("we got events about focus=falsen");
                fflush(stdout);
                WindowHasFocus = false; 
                break; 
            } 
            break; 
            
        case SDL_QUIT:
            Close = true;
            break;

        default:
            break;
        } // end switch

    } // end while

    return !Close;
}


Then everything stops, and i have 1-2 fps. On win32, all works as before, without visuall change of course. With or without focus check/set it have the same fps. But on amigaos4 without check everything moves fast-fast, but with check, everything stops.

It looks like something with mouse / focus code in our sdl2 cause this. Maybe the fact that without "focus" value being checked/set everything just start moves like a madman, and that when i put back focus checks and it all start to be slow like hell, are the roots of the same issue ?


EDIT: interesting, that when i run that code with set/check on focus, but didn't set it, only printfs , then i can see that for win32, when i run app, it just says:

we got events about focus=true
we got events about focus=false

And nothing more.

But if i run it under amigaos4, its flood me with those entries without stop until i move mouse. Something pretty different there between our and win32 sdl2 ports.

As i say its just i have now 2 files (sdl1 ones and sdl2 ones), which i just copy to win32 vesion and to amigaos4 version. And with win32 version it all works, speed same in both versions. On amigaos4, sdl1 one ok, and sdl2 : when set on windowfocus used : 2 fps. When no set, then like i move mouse fast-fast in all the directions.

EDIT2: Oh, and i go pretty close now : i found that if i just change creating of sdl_window be SDL_FULLSCREEN one, then both bugs gone ! I.e. in fullscreen everything works and when i check/set focus, and when i didn't. In boch cases all renders fine, speed the same, and no flood of those "true/false". In other words, issue is with window mode only, and only on amigaos4 side (with the same 1:1 sdl2 code)


Edited by kas1e on 2019/8/26 13:30:22
Edited by kas1e on 2019/8/26 13:36:52
Edited by kas1e on 2019/8/26 14:04:59
Edited by kas1e on 2019/8/26 14:06:04
Edited by kas1e on 2019/8/26 14:08:21
Edited by kas1e on 2019/8/26 14:14:51
Edited by kas1e on 2019/8/26 14:47:09
Edited by kas1e on 2019/8/26 16:22:59
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top


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



[Advanced Search]



Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project