Login
Username:

Password:

Remember me



Lost Password?

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

Members: 0
Guests: 55

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



« 1 ... 3 4 5 (6) 7 8 »


Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 446
@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
   Report Go to top

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

Cadog: probably bug with compositing changes.

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.


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.

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

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4538
@Capehill
Build beret with non-debug version of SDL: while slowdowns gone, game is flicker much even with SDL_DOUBLEBUF :(

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

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 446
@kas1e

I just retried Beret, works well here, no flicker or slowdown. To understand slowdown I need full serial log.

   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4538
@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.

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

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 446
@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.

   Report Go to top

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

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 ..

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

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 446
@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.

   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4538
@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:

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)..


Edited by kas1e on 2018/3/14 11:43:40
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 446
@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.

   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4538
@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 ..


Edited by kas1e on 2018/3/14 13:54:02
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 446
@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",
  
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.

   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4538
@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_CreateDeviceCreating OS4 video device
[os4video_CreateDeviceDevice created
[os4video_VideoInitFree video memory 192389120
dev_open
(unitNumber=0) [Shell Process]
dev_close(unit_num=0) [Shell Process]
[
os4video_ListModesListing 32-bit screenmodes
[os4video_ListModesLooking for modes with format=6
[os4video_ListModesFound some
[os4video_ListModesListing 32-bit screenmodes
[os4video_ListModesLooking for modes with format=6
[os4video_ListModesFound some
[os4video_ListModesListing 16-bit screenmodes
[os4video_ListModesLooking for modes with format=10
[os4video_ListModesFound some
[os4video_ListModesListing 15-bit screenmodes
[os4video_ListModesLooking for modes with format=11
[os4video_ListModesLooking for modes with format=5
[os4video_ListModesFound no 15-bit modes in any pixel format
[os4video_ListModesListing 24-bit screenmodes
[os4video_ListModesLooking for modes with format=2
[os4video_ListModesLooking for modes with format=3
[os4video_ListModesFound no 24-bit modes in any pixel format
[os4video_ListModesListing 8-bit screenmodes
[os4video_ListModesLooking for modes with format=1
[os4video_ListModesFound some
[os4video_ListModesListing 32-bit screenmodes
[os4video_ListModesLooking for modes with format=6
[os4video_ListModesFound some
[os4video_SetVideoModeRequesting new video mode 800x600x32
[os4video_SetVideoModeRequested flagsHWSURFACE DOUBLEFUF FULLSCREEN 
[os4video_SetVideoModeCurrent mode 0x0x32
[os4video_SetVideoModeCurrent mode flags 
[os4video_SetVideoModeCurrent hwdata 0x00000000
[os4video_SetVideoModeCreating new display
[os4video_SetVideoModeDeleting old display
[os4video_SetVideoModeCalling CreateDisplay
[os4video_CreateDisplayCreating a 800x600x32 display
[os4video_CreateDisplayFullscreen
RadeonHD
.chip (0): DisplayPort outputs are currently not supported
[openSDLscreenScreen opened
[os4video_CreateDisplayScreen depth:32 pixel format:6
[os4video_CreateDisplayAllocating resources for double-buffering
[openSDLwindowTrying to open window at (0,0of size (800x600)
[
os4video_SetVideoMode] New display created
[os4video_SetVideoModeObtained flagsHWSURFACE DOUBLEFUF FULLSCREEN 
[os4video_AllocHWSurfaceAllocating HW surface 0x6501BC20 flags:SRCALPHA 
[os4video_AllocHWSurfaceTrying to create 720x720x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x6501BCA0 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 600x600x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x6501B998 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 800x600x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x6501BA40 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 800x600x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x6501BF00 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 480x480x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x6501BAE8 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 780x600x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x6501BE70 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 780x600x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x6501BB80 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 780x600x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x6501B6C0 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 780x15x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x67480E08 flags:SRCALPHA  depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 45x45x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x674816C8 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 300x150x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x6501BD48 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 500x200x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x6501BDE8 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 500x200x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x6501B8A8 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 300x150x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x6501B928 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 780x600x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x6501B7F8 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 780x600x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x67481770 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 780x600x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x67481938 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 780x600x32 bitmap (friend 0x67CF5728)
[
os4video_AllocHWSurfaceAllocating HW surface 0x674819B0 flags:SRCALPHA depth 24bytes 4bits 32
[os4video_AllocHWSurfaceTrying to create 780x600x32 bitmap (friend 0x67CF5728)
[
os4video_CheckHWBlitHardware blitting supportedC  dst flags:HWSURFACE PREALLOC 24bytes 4bits 32
[os4video_CheckHWBlitHardware blitting supportedC  dst flags:HWSURFACE PREALLOC 
[os4video_CheckHWBlitHardware blitting supportedC  dst flags:HWSURFACE PREALLOC 
[os4video_CheckHWBlitHardware blitting supportedC  dst flags:HWSURFACE PREALLOC 
[os4video_CheckHWBlitHardware blitting supportedC  dst flags:HWSURFACE PREALLOC 
[os4video_FreeHWSurfaceFreeing HW surface 0x6501B998
[os4video_FreeHWSurfaceFreeing bitmap 0x67088498
[os4video_FreeHWSurfaceFreeing HW surface 0x6501BA40
[os4video_FreeHWSurfaceFreeing bitmap 0x670883F8
[os4video_FreeHWSurfaceFreeing HW surface 0x6501B928
[os4video_FreeHWSurfaceFreeing bitmap 0x65853468
[os4video_FreeHWSurfaceFreeing HW surface 0x6501B7F8
[os4video_FreeHWSurfaceFreeing bitmap 0x658533C8
[os4video_FreeHWSurfaceFreeing HW surface 0x67481770
[os4video_FreeHWSurfaceFreeing bitmap 0x65853288
[os4video_FreeHWSurfaceFreeing HW surface 0x67481938
[os4video_FreeHWSurfaceFreeing bitmap 0x65853328
[os4video_FreeHWSurfaceFreeing HW surface 0x674819B0
[os4video_FreeHWSurfaceFreeing bitmap 0x658531E8
[os4video_FreeHWSurfaceFreeing HW surface 0x6501BC20
[os4video_FreeHWSurfaceFreeing bitmap 0x670885D8
[os4video_FreeHWSurfaceFreeing HW surface 0x6501BCA0
[os4video_FreeHWSurfaceFreeing bitmap 0x67088538
[os4video_FreeHWSurfaceFreeing HW surface 0x6501BF00
[os4video_FreeHWSurfaceFreeing bitmap 0x67088358
[os4video_FreeHWSurfaceFreeing HW surface 0x6501BAE8
[os4video_FreeHWSurfaceFreeing bitmap 0x670882B8
[os4video_FreeHWSurfaceFreeing HW surface 0x6501BE70
[os4video_FreeHWSurfaceFreeing bitmap 0x67088218
[os4video_FreeHWSurfaceFreeing HW surface 0x6501BB80
[os4video_FreeHWSurfaceFreeing bitmap 0x670880D8
[os4video_FreeHWSurfaceFreeing HW surface 0x6501B6C0
[os4video_FreeHWSurfaceFreeing bitmap 0x67088178
[os4video_FreeHWSurfaceFreeing HW surface 0x67480E08
[os4video_FreeHWSurfaceFreeing bitmap 0x67088038
[os4video_FreeHWSurfaceFreeing HW surface 0x674816C8
[os4video_FreeHWSurfaceFreeing bitmap 0x67087F98
[os4video_FreeHWSurfaceFreeing HW surface 0x6501BD48
[os4video_FreeHWSurfaceFreeing bitmap 0x67087EF8
[os4video_FreeHWSurfaceFreeing HW surface 0x6501BDE8
[os4video_FreeHWSurfaceFreeing bitmap 0x67087E58
[os4video_FreeHWSurfaceFreeing HW surface 0x6501B8A8
[os4video_FreeHWSurfaceFreeing bitmap 0x65853508
[os4video_VideoQuitIn VideoQuitthis 0x6A2648D0
[os4video_VideoQuitDeleteCurrentDisplay
RadeonHD
.chip (0): DisplayPort outputs are currently not supported
[os4video_DeleteCurrentDisplayClosing window
[os4video_DeleteCurrentDisplayFreeing double-buffering resources
[os4video_DeleteCurrentDisplayClosing screen
[os4video_VideoQuitChecking pubscreen
[os4video_FreeHWSurfaceFreeing HW surface 0x67478F48


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.


Edited by kas1e on 2018/3/14 18:21:26
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4538
@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
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 446
@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?

   Report Go to top

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

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".


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

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 446
@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
   Report Go to top

Re: SDL1 open issues
Home away from home
Joined:
2007/9/11 11:31
From Russia
Posts: 4538
@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
_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites
   Report Go to top

Re: SDL1 open issues
Not too shy to talk
Joined:
2007/7/14 20:30
From Lothric
Posts: 446
@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?

   Report Go to top

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

Perhaps the thing you are seeing is a some kind of tearing artefact?


Right ! Just can't find english words for before, but yes, tearing artefact is the right desription.

Quote:

Is VSYNC working on X5000 in general?


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:

CMPLENGTH=15
BOARDNAME=Radeon HD VERDE
VSYNCMIN=60
VSYNCMAX=60
HSYNCMIN=31000
HSYNCMAX=85000
MODE=640x480@60
MODE=800x600@60
MODE=1024x768@60
MODE=1280x720@60
MODE=1920x1200@60
MODE=1600x1200@60
DISABLEFAKENATIVE=Yes
INTERRUPT=Yes


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 ?

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


« 1 ... 3 4 5 (6) 7 8 »



[Advanced Search]


Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project