|
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: 6826
|
@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). |
|
|
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: 1243
|
@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. |
|
|
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: 6826
|
..
|
|
|
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: 6826
|
@Capehill
Quote:
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.. |
|
|
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: 1243
|
@kas1e
It should be something like this, no allocations, no locks:
if (!SoftwareRendered)
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. |
|
|
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: 6826
|
@Capehill
Quote:
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:
Yep, will do of course |
|
|
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: 1243
|
@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? |
|
|
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: 6826
|
@Capehill
Quote:
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:
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:
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.
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
|
|
|
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: 1243
|
@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. |
|
|
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: 6826
|
@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.
|
|
|
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: 6826
|
@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
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();
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. |
|
|
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: 6826
|
@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. |
|
|
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: 1243
|
@kas1e
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 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:
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" |
|
|
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: 6826
|
@Capehill
Quote:
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:
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:
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)
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. |
|
|
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: 1243
|
@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. |
|
|
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: 6826
|
@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. |
|
|
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: 6826
|
@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 ? |
|
|
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: 1243
|
@kas1e
Is there difference between accelerated and software renderer? You could try to measure:
if (!SoftwareRendered)
|
|
|
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: 6826
|
@Capehill
Quote:
Tried to replace SDL_CreateRenderer(ScreenWindow, -1, 0); on SDL_CreateRenderer(ScreenWindow, -1, SDL_RENDERER_ACCELERATED); give no changes visually, same. Quote:
That log i have when running: Quote:
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:
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 |
|
|
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: 6826
|
@Capehill
I minimize SDL2 version till veeery small test case , so, there is:
#include "IrrCompileConfig.h"
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
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 |
|