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
TuneNet forum
Unsatisfactory Software forum
Bottom
Previous Topic
Next Topic|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 6:52
#101 |
|---|---|---|
|
Just can't stay away
 
Joined:
2007/7/14 21:30 From Lothric
Posts: 1065
|
@kas1e
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. Edited by Capehill on 2018/3/14 7:16:35
|
|
 
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 8:23
#102 |
|---|---|---|
|
Home away from home
 
Joined:
2007/9/11 12:31 From Russia
Posts: 6324
|
@Capehill
Quote:
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:
With only replacing that: screen = SDL_SetVideoMode(SCR_WIDTH, SCR_HEIGHT, SCR_BPP, SDL_FULLSCREEN ); on that: screen = SDL_SetVideoMode(SCR_WIDTH, SCR_HEIGHT, SCR_BPP, SDL_FULLSCREEN | SDL_DOUBLEBUF|SDL_HWSURFACE); 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: DEBUG_CFLAGS = -DDEBUG But probably it should be like this: export debug ifeq ($(debug), no) DEBUG_CFLAGS = else DEBUG_CFLAGS = -DDEBUG endif So then we can do "make -f makefile.amigaos4 debug=no" to build non-debug version. |
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 8:33
#103 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6324
|
@Capehill
Build beret with non-debug version of SDL: while slowdowns gone, game is flicker much even with SDL_DOUBLEBUF :( |
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 8:42
#104 |
|---|---|---|
|
Just can't stay away
Joined:
2007/7/14 21:30 From Lothric
Posts: 1065
|
@kas1e
I just retried Beret, works well here, no flicker or slowdown. To understand slowdown I need full serial log. |
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 8:53
#105 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6324
|
@Capehill
As for slowdowns: it was because of SDL build with debug, as you only addd "-DDEBUG" to makefile, while should be: export debug ifeq ($(debug), no) DEBUG_CFLAGS = else DEBUG_CFLAGS = -DDEBUG endif 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. |
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 9:00
#106 |
|---|---|---|
|
Just can't stay away
Joined:
2007/7/14 21:30 From Lothric
Posts: 1065
|
@kas1e
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. |
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 9:05
#107 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6324
|
@Capehill
Quote:
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:
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 .. |
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 11:06
#108 |
|---|---|---|
|
Just can't stay away
Joined:
2007/7/14 21:30 From Lothric
Posts: 1065
|
@kas1e
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. |
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 11:20
#109 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6324
|
@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). That why i ask before that maybe the way i add gl4es in version from adtools now different with new version, and i need to add something else ? See how i add it there: http://www.amigans.net/modules/xforum ... id=109850#forumpost109850 Quote:
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).. Edited by kas1e on 2018/3/14 11:43:40
|
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 12:56
#110 |
|---|---|---|
|
Just can't stay away
Joined:
2007/7/14 21:30 From Lothric
Posts: 1065
|
@kas1e
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. |
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 13:21
#111 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6324
|
@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:
Looks imho ok ? That also output from MiniGL version (where title pic shows fine): Quote:
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:
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 .. Edited by kas1e on 2018/3/14 13:54:02
|
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 17:20
#112 |
|---|---|---|
|
Just can't stay away
Joined:
2007/7/14 21:30 From Lothric
Posts: 1065
|
@kas1e
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 %Xn",
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. |
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 17:51
#113 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6324
|
@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:
[os4video_CreateDevice] Creating OS4 video device
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:
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:
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:
Yep, but it the same for both minigl and gl4es versions, while in minigl one titlepic shows fine, but in gl4es one not anymore. Edited by kas1e on 2018/3/14 18:21:26
|
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 17:54
#114 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6324
|
@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:
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 |
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 19:28
#115 |
|---|---|---|
|
Just can't stay away
Joined:
2007/7/14 21:30 From Lothric
Posts: 1065
|
@kas1e
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? |
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/14 22:34
#116 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6324
|
@Capehill
Quote:
:) :) Quote:
Can you put it on your "Capehill's" github account (as you already modify something about) ? Quote:
Yes, sure simpler test case will help. Quote:
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". |
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/15 7:58
#117 |
|---|---|---|
|
Just can't stay away
Joined:
2007/7/14 21:30 From Lothric
Posts: 1065
|
@kas1e
After some hassle, both projects are now on Github. https://github.com/capehill/cadog https://github.com/capehill/beret Double-buffering example http://capehill.kapsi.fi/sdl/sdl_doublebuffer.c Edited by Capehill on 2018/3/15 8:40:37
|
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/15 10:30
#118 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6324
|
@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: Single-Buffering: 4172 FPS. Double-Buffering: 116 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). Edited by kas1e on 2018/3/15 11:01:00
|
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/15 12:09
#119 |
|---|---|---|
|
Just can't stay away
Joined:
2007/7/14 21:30 From Lothric
Posts: 1065
|
@kas1e
With Sam440/M9 the numbers are like 1000 FPS for single-buffer and 60 FPS for double-buffer, it's in VSYNC. It uses an OS-supported double-buffering mechanism ( https://github.com/AmigaPorts/SDL/blob ... os4/SDL_os4surface.c#L617 ). Your 116 FPS sounds odd in many ways. Perhaps the thing you are seeing is a some kind of tearing artefact? Is VSYNC working on X5000 in general? |
|
|
|
||
|
|
Re: SDL1 open issues |
Posted on: 2018/3/15 12:21
#120 |
|---|---|---|
|
Home away from home
Joined:
2007/9/11 12:31 From Russia
Posts: 6324
|
@Capehill
Quote:
Right ! Just can't find english words for before, but yes, tearing artefact is the right desription. Quote:
Probably should. But if double buffer should be 60fps, but give 116 for me , then probably tearing effect we se are about that ? I checked my monitor tooltype just in case, and have that: Quote:
Looks ok imho.. I am on RadeonHD 3.4 driver, but just in case i also checked RadeonHD driver 2.22 : same result. What version of graphcs.library / radeonhd drivers / and whatever else we may need to compare there you use ? |
|
|
|
||
Top