Image Map Image Map
Page 4 of 5 FirstFirst 12345 LastLast
Results 31 to 40 of 42

Thread: Sdltrs

  1. #31
    Join Date
    Jun 2013
    Location
    Melbourne, Australia
    Posts
    181

    Default

    Quote Originally Posted by Jenz View Post
    Please checkout the SDL2 branch: https://gitlab.com/jengun/sdltrs/-/tree/sdl2
    I built sdl2trs, but when I ran it I got a segmentation fault. After a bit of investigating I found that in trs_screen_init() the SDL_GetWindowSurface() call was returning NULL and therefore "screen" was set to NULL which caused the segfault when SDL_MapRGB() was called later on. I called SDL_GetError() and it returned "No hardware accelerated renderers available". I googled this error message and found that in the call to SDL_CreateRenderer() by replacing the flag 0 (which apparently defaults to SDL_RENDERER_ACCELERATED) with SDL_RENDERER_SOFTWARE, this fixed the problem. I don't currently know enough about SDL renderers to know whether this is a good solution or not.

    Quote Originally Posted by Jenz View Post
    lets you resize the window with the mouse ... at the moment these settings are not saved and some options reset the change ... that's why it still needs some work ...
    After getting the segmentation fault fixed, I added SDL_WINDOW_RESIZABLE and was able to get it to work. I like where this is heading, although the pixels can look odd at some sizes.

  2. Default

    Quote Originally Posted by gonk23 View Post
    SDL_GetWindowSurface() call was returning NULL and therefore "screen" was set to NULL which caused the segfault
    I should always check for failed functions ...

    Quote Originally Posted by gonk23 View Post
    SDL_CreateRenderer() by replacing the flag 0 (which apparently defaults to SDL_RENDERER_ACCELERATED) with SDL_RENDERER_SOFTWARE, this fixed the problem. I don't currently know enough about SDL renderers to know whether this is a good solution or not.
    In my understanding, SDL should give priority to hardware acceleration and fallback to software rendering, but "SDL_GetWindowSurface" seems to be the problem: it should not be used with the rendering API. Because of my laziness, all TRS-80 characters are still "software surfaces" (not "textures") that are displayed on the "screen surface", which is then transferred to the renderer as texture ("SDL_UpdateTexture"). Seems to work (mostly), but mixes the old API for "software surfaces" with new one for "textures" ... therefore a revision is needed ...

    Quote Originally Posted by gonk23 View Post
    I like where this is heading, although the pixels can look odd at some sizes.
    That is the reason why the "SDL_WINDOW_RESIZABLE" is not set by default ...
    Last edited by Jenz; May 31st, 2020 at 07:30 AM.

  3. Default

    Quote Originally Posted by gonk23 View Post
    although the pixels can look odd at some sizes.
    Please try this patch:
    Code:
    diff --git a/src/trs_sdl_interface.c b/src/trs_sdl_interface.c
    index f911323..79ea7ae 100644
    --- a/src/trs_sdl_interface.c
    +++ b/src/trs_sdl_interface.c
    @@ -1331,6 +1331,7 @@ void trs_screen_init(void)
           trs_sdl_cleanup();
           fatal("failed to create renderer: %s", SDL_GetError());
         }
    +    SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear");
       }
     
       if (texture)

  4. #34
    Join Date
    Jun 2013
    Location
    Melbourne, Australia
    Posts
    181

    Default

    I'm not seeing any difference when I resize the window with that patch, although I'm still using SDL_RENDERER_SOFTWARE, so I don't know if that affects it or not.

    Interestingly, with or without that patch, when I resize the window just after loading sdl2trs, the resized version looks great when I'm actually resizing it, however when I release the mouse button that's when the pixels end up looking odd.

  5. Default

    Quote Originally Posted by gonk23 View Post
    I'm still using SDL_RENDERER_SOFTWARE, so I don't know if that affects it or not.
    Please checkout the latest commit 5d9582e on the SDL2 branch: hopefully this will activate the hardware rendering on macOS ...

    Quote Originally Posted by gonk23 View Post
    however when I release the mouse button that's when the pixels end up looking odd.
    Maybe adding SDL_WINDOW_ALLOW_HIGHDPI to the SDL_CreateWindow flags will help ... can you send a screenshot?

  6. #36
    Join Date
    Jun 2013
    Location
    Melbourne, Australia
    Posts
    181

    Default

    I tested sdl2 branch commit 5d9582e and that works unmodified on macOS. Thanks!

    It must have also fixed the rendering problem on window resize because it looks great after I added the "SDL_WINDOW_RESIZABLE" and "SDL_HINT_RENDER_SCALE_QUALITY" patches to that commit.

    As a bonus, the macOS green circle window button allows it to go into full screen mode (without specifying the sdl2trs "-fullscreen" option) although it's obviously stretched on widescreen monitors.

  7. Default

    Quote Originally Posted by gonk23 View Post
    I tested sdl2 branch commit 5d9582e and that works unmodified on macOS. Thanks!
    You're welcome, testing and reporting is highly appreciated!

    Quote Originally Posted by gonk23 View Post
    I added the "SDL_WINDOW_RESIZABLE" and "SDL_HINT_RENDER_SCALE_QUALITY" patches to that commit.
    Added these changes also to latest SDL2 branch. No need for "SDL_WINDOW_FULLSCREEN_DESKTOP"?

    Quote Originally Posted by gonk23 View Post
    As a bonus, the macOS green circle window button allows it to go into full screen mode (without specifying the sdl2trs "-fullscreen" option)
    Doesn't "Alt-Enter" toggle full screen mode on macOS?

  8. #38
    Join Date
    Jun 2013
    Location
    Melbourne, Australia
    Posts
    181

    Default

    Yes, "Alt-Enter" (or "option-return" on the Mac) does work. Its effect depends on the build:

    (a) branch master 062bedc7 unmodified
    Goes into a fullscreen mode which takes over the Mac and doesn't allow switching to other apps. It stops rendering to the screen, although it keeps responding to keyboard and playing sound (e.g. if a game). Pressing "option-return" again will restore to window mode however real-time rendering is still broken.

    (b) branch master 062bedc7 with SDL_WINDOW_FULLSCREEN_DESKTOP
    It correctly goes into a proper macOS fullscreen mode which allows switching to other apps/screens. However it doesn't scale to fit the screen, i.e. it returns to scale x1, so you only see the display in the top-left of the screen.

    (c) branch sdl2 bd147276 unmodified
    Goes into a fullscreen mode which takes over the Mac and doesn't allow switching to other apps. However it does keep real-time rendering to the screen. The aspect ratio is correct. Pressing "option-return" again will restore to window mode and rendering keeps working, although it sometimes puts the window in the bottom left of the desktop.

    (d) branch sdl bd147276 with SDL_WINDOW_FULLSCREEN_DESKTOP
    It correctly goes into a proper macOS fullscreen mode which allows switching to other apps/screens. There aren't any rendering problems. It scales to fit the ENTIRE screen, even if it means the aspect ratio is incorrect (i.e. it appears stretched). Pressing "option-return" again will restore to window mode and rendering keeps working, and it always puts the window back to the same size/position that it was before going into fullscreen mode.

    So for macOS, I think it'll be better to use SDL_WINDOW_FULLSCREEN_DESKTOP, however it would be nice if it correctly scaled to both fill the screen AND keep the correct aspect ratio. Actually, keeping the correct aspect ratio would also be nice when resizing the window in window mode too.
    Last edited by gonk23; June 2nd, 2020 at 03:39 AM.

  9. Default

    Quote Originally Posted by gonk23 View Post
    (b) branch master 062bedc7 with SDL_WINDOW_FULLSCREEN_DESKTOP
    It correctly goes into a proper macOS fullscreen mode which allows switching to other apps/screens. However it doesn't scale to fit the screen, i.e. it returns to scale x1, so you only see the display in the top-left of the screen.
    This also happens on some Linux systems with the software renderer. SDL_WINDOW_FULLSCREEN changes the graphic resolution, SDL_WINDOW_FULLSCREEN_DESKTOP just "expands" the window to fill the entire screen. The master branch sticks to the software renderer to ensure backwards compatibility with SDL 1.2 for ancient platforms ...

    Quote Originally Posted by gonk23 View Post
    Actually, keeping the correct aspect ratio would also be nice when resizing the window in window mode too.
    Please checkout commit 12d0881 on the SDL2 branch: this should keep the aspect ratio of the TRS-80 screen when resizing, but so called "letterboxing" will occur ...

  10. #40
    Join Date
    Jun 2013
    Location
    Melbourne, Australia
    Posts
    181

    Default

    Quote Originally Posted by Jenz View Post
    Please checkout commit 12d0881 on the SDL2 branch: this should keep the aspect ratio of the TRS-80 screen when resizing, but so called "letterboxing" will occur ...
    Brilliant! This works well. The macOS native fullscreen mode (by clicking the green circle or pressing control-command-F) also works well.
    Last edited by gonk23; June 2nd, 2020 at 11:42 AM.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •