Ouch. I suppose it's possible to use LockBitmapTags() instead of.
I think you can also try to work around the original issue by passing a proper non-NULL pixel format to SDL. All modes are OK in window case. Only in fullscreen backend starts checking for appropriate modes.
Cadog: probably bug with compositing changes. Have you tested Beret, by the way? You need to add SDL_DOUBLEBUF|SDL_HWSURFACE for fullscreen, otherwise (single-buffer) will flicker.
Strange that only happens with gl4es, and not with minigl, and only with latest versiosn of SDL. The way i add gl4es changes the same as i do for adtools's verions (which one renders correctly with the same gl4es library), so maybe with recent changes in SDL something else need to be added/checked ?
Quote:
Have you tested Beret, by the way? You need to add SDL_DOUBLEBUF|SDL_HWSURFACE for fullscreen, otherwise (single-buffer) will flicker.
Game runs, but bottom of the screen offten "redraws" so i can see it, and in game itself it happens as well. Also when i move mouse cursor over the main menu , everything slows down.
That all probably because by default everything builds with -DDEBUG ?
Can we use something like "make -f makefile DEBUG=no" or something to disable debug ? I see there was added in makefile that:
So then we can do "make -f makefile.amigaos4 debug=no" to build non-debug version, and just "make -f makefile.amigaos4" to build debug versions.
When i build it without debug, then no slowdowns.
But flickering still here. It not flickering maybe, but "redraws of part of screens", sometime in the middle of screen, sometime at bottom. Sometime it even unpossible to see part of screen as it redrawed.
Also, when i press "alt+enter" so it go to the window mode, everything start to be veeeeery slow, 1fps maybe.
Yeah, but what print is causing the slowdown? I'm running with debug all time and Beret with HWSURFACE runs around 20 FPS while SWSURFACE runs around 11 FPS (Sam440).
Makefile debug switch was meant to be disabled by a comment, like #, but it can be changed of course. You can make a pull request if you like.
Yeah, but what print is causing the slowdown? I'm running with debug all time and Beret with HWSURFACE runs around 20 FPS while SWSURFACE runs around 11 FPS (Sam440).
It was slowdowns caused when on title screen i move mouse over all the place , and in debug log there was a loooot of prinfs about mouse movements.
Quote:
Makefile debug switch was meant to be disabled by a comment, like #, but it can be changed of course. You can make a pull request if you like.
Ah ok, that no problems if it expected to be like this. Just maybe adding it like i show can be easy for us (so not need to open/change/save makefile) ? I can create pull request if you think its better to have it like i show of course.
Through main issues is that strange flickering/redrawing, as well as when we do alt+enter everything going to 1fps in window mode (with SFSURFACE its ok), and that issues with gl4es ..
Ok, I can understand that event debug slows down. Seems that my object files were not in sync and I have no event debug at the moment so I cannot experience the slowdown. But I would need the serial log from flickering case. You could enable manually DEBUG in surface.c and video.c file?
Cadog issue seems to be an unsupported texture combo passed to MiniGL, hence the "invalid operation" print. Texture format is GL_BGRA and data type GL_UNSIGNED_INT_8_8_8_8 which is not supported ( http://www.hyperion-entertainment.biz ... s/updates-kc/src/unpack.c see mglUnpackers).
As a workaround whole format check can be removed and let game do surface conversion before glTexImage2d. I'm trying to understand has something changed between SDL versions. Does older SDL create a surface with different params, for example.
Which sources you are using for Cadog? I compiled these http://www.martin.st/software/cadog/ . Game also crashes when quitting because it seems to trigger GL calls after exit.
@Capehill No no, you miss the point about Cadog. Yes, MiniGL version have some issues, but that not the point. Point is that GL4ES version now have issues, while before didn't. With the same gl4es library.
Back in times, when i made Cadog port, then yes, i had to fix source code a bit, to make it works on minigl. But problem is not with minigl now, with MiniGL seems all works as before. I.e. MiniGL version have those issues with format and before, and now. But behaviour with GL4ES are changed.
With GL4ES Cadog have no needs to be changed/fixed, it works as it, because GL4ES have all support for RGBA/BGRA and GL_UNSIGNED_INT_8_8_8_8. But with latest version of SDL, it have no background picture anymore (those parts which are fade in).
So problem is not with minigl. With MiniGL all works as before (probably, i will recheck now), its that with GL4ES it start to works wrong.
I.e. the same 1:1 libgles.a , with the same way as i add gl4es to the sdl, works differently with SDL compiled from adtools, and with your latest one (didn't render fade in parts, like something wrong with Alpha or something).
Which sources you are using for Cadog? I compiled these http://www.martin.st/software/cadog/ . Game also crashes when quitting because it seems to trigger GL calls after exit.
Yes, i use the same sources. Game same crashes on exit because doing some free of texture which is not allocated or already freed, so it's just bug in the code of game (i remember back in times i fix it for minigl version as well).
Problem is that something changes lately, which make GL4ES (not minigl) version didn't "fade in" all the background image and stuff.
Maybe it also has new issue with MiniGL too, but at least i can see its have with GL4ES for sure.
I will try to build MiniGL versions with new and adtools's SDL's to see if it reacts the same as before.
I may try also to build SDL version which is before adding of HWsurface (i see there was some changes related to Alpha, so maybe it somehow related), to see if it that commit which cause issues.
It's can be just me doing something wrong of course (taken in account how hackish adding of GL4ES into SDL done from my side)..
I need to know what are your modifications done to Cadog. It seems to me that IMG_Load returns a similar surface (32-bit, with alpha channel) with both old and updated SDL. So problem may be in surface conversion rather. After that it's all OpenGL job.
One difference with old and updated SDL is that now alpha channel (Amask etc) is reported. Earlier it was 0.
@Capehill With GL4ES i have do no modification in Cadog (at all), it works as it. For MiniGL i sadly do not remember what changes i do back in time, and sources of that port somewhere in the old Peg2's hdd in dust :(
But i anyway do test most of commits of SDL lately, and seems that issue not related to the HWSURFACE commit at all, but to the "fix test mem" commit.
I test about 5 commits starting from adtools till fix-test-mem and all of them working, including "fix timer" commit.
Then i test "fix test mem" commit (mar 11, 2018) with usuall adding of the same GL4ES code as i do before for all previous versions: and there no background anymore.
So something brokens with "fix test mem" commit.
I see there mostly was "space/tabs" conversions, but also there was "Improve debug logging and modify WaitThread behaviour to send CTRL_C to waited threads if interrupted" ,as well as "Add debug logging and destroy semaphore after use". So i enable debug logging , and that what i have on serial when run Cadog over GL4ES:
Quote:
[os4_initialize] SDL 1.2.15 [os4timer_initialize] timer=0x6FF51050 [os4timer_initialize] ITimer=0x6FF9D400 [os4timer_Init] Initializing timer for process 0x6D44D1D0 [os4timer_Init] Done [os4thread_initialize] Primary process 0x6D44D1D0 [os4video_initialize] Device opened [os4video_Available] Probing Picasso96API.library [os4video_Available] Success [os4video_CreateDevice] Creating OS4 video device [os4video_CreateDevice] Compositing should be possible, gfx version 54 [os4video_CreateDevice] Device created [SDL_DestroyMutex] NULL mutex [os4video_CreateWMCursor] Creating cursor 16x16 [os4video_CreateWMCursor] cursor = 0x67529010 [os4video_ShowWMCursor] Setting cursor 0x67529010 [OS4_OpenAhiDevice] Device open [OS4_OpenAhiDevice] Got Interface [OS4_OpenAhiDevice] ahi_open = 1 [OS4_CloseAhiDevice] Aborting I/O... [OS4_CloseAhiDevice] Closing device [OS4_CloseAhiDevice] Deleting I/O request [OS4_CloseAhiDevice] Deleting message port [OS4_CloseAhiDevice] done closing [OS4_AudioAvailable] AHI is available [OS4_CreateDevice] Allocating device [OS4_CreateDevice] Clearing [OS4_CreateDevice] Initializing [OS4_CreateDevice] device = 0x674F52B0 [OS4_OpenAudio] New format = 0x9010 [OS4_OpenAudio] Buffer size = 8192 [SDL_CreateSemaphore] Semaphore 0x674F5708 created [SDL_SYS_CreateThread] Creating child thread 0x674F53C8 with args 0x674F56F0 [SDL_SYS_CreateThread] Child process 0x6C521480 (SDL thread 0x674f53c8) [RunThread] Running process 0x6C521480 (SDL thread 0x674F53C8) [blockOnSem] Process 0x6D44D1D0 blocked on semaphore 0x674F5708 (signals 0x100) [os4timer_Init] Initializing timer for process 0x6C521480 [os4timer_Init] Done [blockOnSem] Process 0x6D44D1D0 starts to wait for signals [SDL_SemPost] Process 0x6C521480 incrementing semaphore 0x674F5708 (count 0) [blockOnSem] Process 0x6D44D1D0 wait over [blockOnSem] Process 0x6D44D1D0 obtained semaphore [blockOnSem] Process 0x6D44D1D0 decrementing semaphore 0x674F5708 (count 1) [SDL_DestroySemaphore] Destroying semaphore 0x674F5708 [OS4_OpenAhiDevice] Device open [SDL_DestroySemaphore] Done [OS4_OpenAhiDevice] Got Interface [OS4_OpenAhiDevice] ahi_open = 1 [os4video_SetCaption] Setting title to Cadog Adventures [os4video_SetCaption] Setting icon caption to Cadog Adventures [os4video_SetVideoMode] Requesting new video mode 640x480x32 [os4video_SetVideoMode] Requested flags: ANYFORMAT OPENGL RESIZEABLE [os4video_SetVideoMode] Current mode 0x0x32 [os4video_SetVideoMode] Current mode flags [os4video_SetVideoMode] Current hwdata 0x00000000 [os4video_SetVideoMode] Creating new display [os4video_SetVideoMode] Deleting old display [os4video_SetVideoMode] Calling CreateDisplay [os4video_CreateDisplay] Creating a 640x480x32 display [os4video_CreateDisplay] Window mode [os4video_CreateDisplay] Screen depth:32 pixel format:6 [getBestWindowPosition] Visible screen: (0,0)/(1440x900) [openSDLwindow] Trying to open window at (395,194) of size (640x480) [os4video_SetVideoMode] Obtained flags: ANYFORMAT OPENGL RESIZEABLE de] New display created [os4video_ShowWMCursor] Setting cursor 0x67529010 [os4video_ResetCursor] Cursor image set [os4video_ShowWMCursor] Setting cursor 0x00000000 [os4video_ResetCursor] Cursor image blanked [os4video_CheckMouseMode] isMouseRelative=0 [os4video_EventHandler] Window active [os4video_CheckPointerInWindow] Pointer outside of window [os4video_HandleEnterLeaveWindow] Pointer left window [os4video_CheckPointerInWindow] Pointer outside of window [os4video_CheckPointerInWindow] Pointer outside of window [os4video_CheckPointerInWindow] Pointer outside of window
Looks imho ok ?
That also output from MiniGL version (where title pic shows fine):
Quote:
[os4_initialize] SDL 1.2.15 [os4timer_initialize] timer=0x6FF51050 [os4timer_initialize] ITimer=0x6FF9D400 [os4timer_Init] Initializing timer for process 0x6AF1D670 [os4timer_Init] Done [os4thread_initialize] Primary process 0x6AF1D670 [os4video_initialize] Device opened [os4video_CreateDevice] Creating OS4 video device [os4video_CreateDevice] Device created [os4video_VideoInit] Free video memory 195392512 [SDL_DestroyMutex] NULL mutex [os4video_CreateWMCursor] Creating cursor 16x16 [os4video_CreateWMCursor] cursor = 0x6B134010 [os4video_ShowWMCursor] Setting cursor 0x6B134010 [OS4_OpenAhiDevice] Device open [OS4_OpenAhiDevice] Got Interface [OS4_OpenAhiDevice] ahi_open = 1 [OS4_CloseAhiDevice] Aborting I/O... [OS4_CloseAhiDevice] Closing device [OS4_CloseAhiDevice] Deleting I/O request [OS4_CloseAhiDevice] Deleting message port [OS4_CloseAhiDevice] done closing [OS4_AudioAvailable] AHI is available [OS4_CreateDevice] Allocating device [OS4_CreateDevice] Clearing [OS4_CreateDevice] Initializing [OS4_CreateDevice] device = 0x6747D448 [OS4_OpenAudio] New format = 0x9010 [OS4_OpenAudio] Buffer size = 8192 [SDL_CreateSemaphore] Semaphore 0x674838B8 created [SDL_SYS_CreateThread] Creating child thread 0x67483578 with args 0x674838A0 [SDL_SYS_CreateThread] Child process 0x6C697540 (SDL thread 0x67483578) [RunThread] Running process 0x6C697540 (SDL thread 0x67483578) [os4timer_Init] Initializing timer for process 0x6C697540 [blockOnSem] Process 0x6AF1D670 blocked on semaphore 0x674838B8 (signals 0x100) [os4timer_Init] Done [blockOnSem] Process 0x6AF1D670 starts to wait for signals [SDL_SemPost] Process 0x6C697540 incrementing semaphore 0x674838B8 (count 0) [blockOnSem] Process 0x6AF1D670 wait over [blockOnSem] Process 0x6AF1D670 obtained semaphore [blockOnSem] Process 0x6AF1D670 decrementing semaphore 0x674838B8 (count 1) [OS4_OpenAhiDevice] Device open [SDL_DestroySemaphore] Destroying semaphore 0x674838B8 [OS4_OpenAhiDevice] Got Interface [SDL_DestroySemaphore] Done [OS4_OpenAhiDevice] ahi_open = 1 [os4video_SetCaption] Setting title to Cadog Adventures [os4video_SetCaption] Setting icon caption to Cadog Adventures [os4video_SetVideoMode] Requesting new video mode 640x480x32 [os4video_SetVideoMode] Requested flags: ANYFORMAT OPENGL RESIZEABLE [os4video_SetVideoMode] Current mode 0x0x32 [os4video_SetVideoMode] Current mode flags [os4video_SetVideoMode] Current hwdata 0x00000000 [os4video_SetVideoMode] Creating new display [os4video_SetVideoMode] Deleting old display [os4video_SetVideoMode] Calling CreateDisplay [os4video_CreateDisplay] Creating a 640x480x32 display [os4video_CreateDisplay] Window mode [os4video_CreateDisplay] Screen depth:32 pixel format:6 [initOffScreenBuffer] pixels 0x00000000, pitch 0f-screen buffer with rgbtype=6, hwSurface 1 [getBestWindowPosition] Visible screen: (0,0)/(1440x900) [openSDLwindow] Trying to open window at (395,194) of size (640x480) [os4video_SetVideoMode] Obtained flags: ANYFORMAT OPENGL RESIZEABLE display created [os4video_ShowWMCursor] Setting cursor 0x6B134010 [os4video_ResetCursor] Cursor image set [os4video_ShowWMCursor] Setting cursor 0x00000000 [os4video_ResetCursor] Cursor image blanked [os4video_CheckMouseMode] isMouseRelative=0 [os4video_EventHandler] Window active [os4video_CheckPointerInWindow] Pointer inside window [os4video_HandleEnterLeaveWindow] Pointer entered window
That also may very well be the way how i add "gl4es". On previous versions it just didn't show up, while now it is. For example, that line looks strange imho:
Quote:
[os4video_SetVideoMode] Obtained flags: ANYFORMAT OPENGL RESIZEABLE de] New display created
What it that "de]" thing, maybe just like some memory corruption happens because of way of how i add gl4es ?
Maybe we need at least ot just refactor it all at once , so to add properply mgl, ogles and gl4es there ..
I cannot spot difference in Cadog behaviour regardless which libSDL.a I use. Could you debug your side for difference? I want to know a) is there any difference in getFormats() function b) what are the surface parameters passed to GL. You could try something like:
printf("%d * %d * %d (%d), A %X, R %X, G %X B %X\n",
img->w,
img->h,
img->format->BitsPerPixel,
img->format->BytesPerPixel,
img->format->Amask,
img->format->Rmask,
img->format->Gmask,
img->format->Bmask);
I doubt issue is caused by "fix test sem" commit. It didn't touch any video file.
Serial log shows that something passed NULL pointer to DestroySemaphore(), and that our AHI code is strange, but not much else. Not sure what caused the print corruption, better keep the eye on it.
@Capehill In meantime doing what you ask about Beret (i.e. enabled debug only in surface.c and video.c), and then just run game, and on title screen just waiting a bit, then move mouse a bit, see the flickering/redrawing , then exit. And log looks like this:
For example if i go to the game itself, and stay without doing anything, then, probably one time per 12-15 second i see that flickered redrawing of bottom of screen.
Quote:
I cannot spot difference in Cadog behaviour regardless which libSDL.a I use. Could you debug your side for difference? I want to know a) is there any difference in getFormats() function b) what are the surface parameters passed to GL. You could try something like:
Do you mean in those 2 gl4es versions one of which works, and another one which didn't after "mem test" commit ? Or you mean 3 versions : 1 minigl one, 1 gl4es one where title pic shows fine, and 3st one where title pic didn't show up?
Quote:
I doubt issue is caused by "fix test sem" commit. It didn't touch any video file.
That issue feels strange and can be very easy that something going nasty in memory, just with "fix test mem" commit it shifts somehow, so it may cause trashed printf as well as may doing something else with memory which in end leads for no title picture. Or changes in "fix test mem" can cause some memory trashing somewhere, but in reality i just fear it me who do something (or not do) when adding gl4es in wrong way :)
Quote:
Serial log shows that something passed NULL pointer to DestroySemaphore()
Yep, but it the same for both minigl and gl4es versions, while in minigl one titlepic shows fine, but in gl4es one not anymore.
@Capehill Hmm, in log i see "DOUBLEFUF". I.e. "FUF" not "BUF". While passed SDL_DOUBLEBUF in source of game. But that can be just typo in prinfs ?
EDIT: found in SDL_os4video.c:
Quote:
if (flags & SDL_DOUBLEBUF) SDL_strlcat(buffer, "DOUBLEFUF ", 256);
So strlcat want FUF , not BUF :) But that probably related only to debuf output ..
And i also see in log: "Hardware blitting supportedC" , with some "C" at end. Is it ok ? Looks like garbage again, and there is also should be probably "src flags" prinfs as well, while i didn't see it..
Edited by kas1e on 2018/3/14 18:12:11 Edited by kas1e on 2018/3/14 18:19:27
Gosh, double-fuffering sounds fluffy. I hope it doesn't mean something nasty.
Let's start Cadog project on GitHub. That way we can add Amiga fixes and needed debug and we are on the same page all time. I added some code that cleans up the singleton class textures. Some VRAM 1 MB leak visible still.
Regarding Beret: I will prepare a separate, smaller double-buffering demo. We will use that to debug the flickering issue. We have different HW and different drivers so we cannot totally exclude those things. Maybe we should start a Beret project as well.
What are your serial port settings? Does serial debug usually work 100% OK?
Gosh, double-fuffering sounds fluffy. I hope it doesn't mean something nasty.
:) :)
Quote:
Let's start Cadog project on GitHub. That way we can add Amiga fixes and needed debug and we are on the same page all time. I added some code that cleans up the singleton class textures. Some VRAM 1 MB leak visible still.
Can you put it on your "Capehill's" github account (as you already modify something about) ?
Quote:
Regarding Beret: I will prepare a separate, smaller double-buffering demo. We will use that to debug the flickering issue. We have different HW and different drivers so we cannot totally exclude those things.
Yes, sure simpler test case will help.
Quote:
What are your serial port settings? Does serial debug usually work 100% OK?
To say truth, its "dumpdebugbuffer", not real serial cable. So after you ask it, i just do "dumpdebugbuffer >ram:1", and then notepad on it : and yes, i can see there is all corect after beret with debug running.
And when i running Cadog with debug, there is also no that "de]" thing once i do "dumpdebugbuffer >file" and then "notepad file".
It seems just console give me broken output from dumpdebugbuffer by some reassons. Like when "\n" is missed in prinfs, console just overwrite one line by another. But not so matter for now.
All it mean there is no trashing then (at least not for printfs), and i need to find what cause "no title picture drawing" in gl4es version of cadog after "timer-fix".
@Capehill Checked double-buffering example: that one too short by time to show issue. In beret flickering happens one time per 12-15 seconds. I.e. 12-15 seconds everything allright, then, some "redraws" lines can be visibly. I can't call it flickering, its like i can see redrawing of some parts, after some time, like something going wrong with VSYNC.
I modified your test case to 35 seconds instead of 5, and then, when second part runs, after 15 seconds i can see how black line draws in the middle and disappear. Then, after 5 or so seconds, 2 more. Then again about 10 seconds all allright.
It is probably not flickering at all, but something else. Like sometime i can see how VSYNC doing wrong. In test example it not very visibly, as not much of different data, but still, i can see black lines after 15 seconds.
If compare it with CRT monitors, the issue i see remind me that i can see "horisontal beam" sometime. Its not fast flickering, its like one time per some seconds i can see that something do not have time to redraw everything right, and i can see how it doing things a bit wrong.
And, btw, that what i have when i set 35 seconds in terms of FPS:
Seems very much slower, is it expected ? Maybe that can explain those issues with redrawing/flickering ?
Maybe its all about priorities ? I remember there was something like that when was choicen too low or too high priority of compositing code over system ones (sorry can't remember details).
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
