VOGONS

Common searches


First post, by truth_deleted

User metadata

I removed the window frame and decorations from DOSBox 0.74/SVN (use output=surface). Attached is the win32 binary for testing by users and also a patch to view the code. I likely removed desirable features from the SDL window in removing the window frame, but posters have asked for no frame, so any trade-off in features may be worthwhile. The two batch files in the attachment allow the docking of dosbox in the top left or center of the screen. These may be further edited by the user. Also, the console window is removed by the batch files, so this is the ideal way to run this dosbox version.

[Edit: updated the SDL.dll library file so that the DOSBox window is borderless and movable. Right-click on the taskbar button for DOSBox and choose "Move", then use the keyboard arrow keys to move the window. Press Enter when finished. Also, the attached SDL defaults to the windib video driver. The modification doesn't seem to work with directx.]

Attachments

  • Filename
    DosBox-noFrame-test.zip
    File size
    1.32 MiB
    Downloads
    195 downloads
    File comment
    DOSBox(0.74SVN)+noWindowFrame win32 binary
    File license
    Fair use/fair dealing exception
  • Filename
    noFrame.diff
    File size
    3.92 KiB
    Downloads
    113 downloads
    File comment
    Test patch to remove window frame in dosbox 0.74SVN
    File license
    Fair use/fair dealing exception
Last edited by truth_deleted on 2013-07-17, 01:04. Edited 2 times in total.

Reply 2 of 15, by truth_deleted

User metadata
ykhwong wrote:

This was discussed before. How can you move the window on the fly?
Re: Dosbox with no TitleBar?

I updated the parent post and attached binaries. The new version has a borderless window and the window can be moved on the fly.

[Old msg: Thank you for the reference to your past solution. I wonder if it is possible to bind four keys to move the window along the X and Y axes.]

Reply 3 of 15, by ykhwong

User metadata
Rank Oldbie
Rank
Oldbie

Thanks for the new binary. I like borderless window as it looks simple. I now can move the frameless window thanks to your updated instruction above though that's not that user-friendly.
I found SDL 2.0 RC implements SDL_GetWindowPosition/SDL_SetWindowPosition to handle window position while DOSBox is currently compatible with SDL 1.2 only. 😢

I found the following post which may help. Dunno if this will work under Windows.
http://devcry.heiho.net/2009/09/dragging-sdln … ess-window.html

Some other ideas for better accessibility:
- When moving mouse cursor into the window, NOFRAME flag will be immediately removed and the title bar will be displayed so that users can move the window. The title bar will be still alive for about 3 seconds right after the cursor leaves from the window.
- Dragging the window while pressing shift key will move the window.

Reply 4 of 15, by truth_deleted

User metadata
ykhwong wrote:
Thanks for the new binary. I like borderless window as it looks simple. I now can move the frameless window thanks to your updat […]
Show full quote

Thanks for the new binary. I like borderless window as it looks simple. I now can move the frameless window thanks to your updated instruction above though that's not that user-friendly.
I found SDL 2.0 RC implements SDL_GetWindowPosition/SDL_SetWindowPosition to handle window position while DOSBox is currently compatible with SDL 1.2 only. 😢

I found the following post which may help. Dunno if this will work under Windows.
http://devcry.heiho.net/2009/09/dragging-sdln … ess-window.html

Some other ideas for better accessibility:
- When moving mouse cursor into the window, NOFRAME flag will be immediately removed and the title bar will be displayed so that users can move the window. The title bar will be still alive for about 3 seconds right after the cursor leaves from the window.
- Dragging the window while pressing shift key will move the window.

Ykhwong, thank you for the excellent suggestions for connecting the mouse with the window position. I learned of a way to move the dosbox window with the mouse and using the binaries from the parent post. If the dosbox button in the taskbar is pressed with the right mouse button, then the Move item appears; once the Move item is pressed by a left mouse click, then press a keyboard arrow key a single time; the cursor should now change from the arrow type to the typical mouse cursor. This will allow the window to move by mouse movements. The next mouse click will then exit this mode.

Second, I attached another SDL.dll library file to this post; it can be placed among the files from the parent post. It provides full movement of the dosbox window via the mouse. It just requires the left mouse button held down and then the window will move with the mouse. This is an ideal setup, however, this will exclude any capturing of the mouse cursor inside dosbox. So, this second method will only be applicable to running software that is keyboard driven within dosbox. If mouse capability is required, then we would use the first method which involves the keyboard.

I extensively tested other options, too. These did not work as well as the above ways. However, it is possible to implement a thin or thick border around the window. The Windows API allows for several variants on the border types. I did also note that the output=opengl is working with the above setup, but the openglhq code is not yet patched with the SDL library.

Attachments

  • Filename
    SDL.zip
    File size
    124.63 KiB
    Downloads
    100 downloads
    File comment
    SDL.dll supports borderless/movable window
    File license
    Fair use/fair dealing exception

Reply 5 of 15, by ykhwong

User metadata
Rank Oldbie
Rank
Oldbie

I checked the last attachment and confirm that it is possible to move the window with convenience. 😀
Did you use Windows APIs to allow the mouse movement for SDL? Does it work on platforms other than Windows?

Reply 6 of 15, by truth_deleted

User metadata

Yes, both the mouse movement and borders were generated by the Window API (via the SDL code). Unfortunately, these changes are specific to the Windows windib code and are implemented by by the "CreateWindow(Ex)" function. The mouse movement feature is an undocumented function of this API and so it appears very difficult to extend its functionality; any mouse event over the window will result in detection of a titlebar, even though it is not present. This prevented the mouse from being fully captured by dosbox.

It is reported that Winamp uses the Windows API, but calls a function to hide the titlebar. This is another strategy specific to Windows. However, this may exclude the possibility of capturing the mouse inside the application, as in the above case. Other solutions involved reinitializing the window, whether at the SDL or the Windows API level.

Another working solution is to enable the "toolbar window" option where the titlebar is thin and the font size reduced. This would allow normal window functions but just reduce the titlebar size and remove the window decorations.

I was also thinking about the openglhq mode. It should be possible to have a setting for "aspect ratio" and then calculate the dimensions of the screen for use by the SDL environmental variable.

Reply 7 of 15, by ykhwong

User metadata
Rank Oldbie
Rank
Oldbie
truth5678 wrote:

The mouse movement feature is an undocumented function of this API and so it appears very difficult to extend its functionality; any mouse event over the window will result in detection of a titlebar, even though it is not present. This prevented the mouse from being fully captured by dosbox.

For the undocumented Windows APIs, you may refer to source code from ReactOS that has been noted for its information on them.
http://doxygen.reactos.org/d0/dcd/ntuser_2win … rce.html#l02930

Reply 8 of 15, by truth_deleted

User metadata
ykhwong wrote:
truth5678 wrote:

The mouse movement feature is an undocumented function of this API and so it appears very difficult to extend its functionality; any mouse event over the window will result in detection of a titlebar, even though it is not present. This prevented the mouse from being fully captured by dosbox.

For the undocumented Windows APIs, you may refer to source code from ReactOS that has been noted for its information on them.
http://doxygen.reactos.org/d0/dcd/ntuser_2win … rce.html#l02930

Thank you for the informative reference. From further code changes, I now believe that the client area can not be altered in size without calling CreateWindow. Also, I believe the above undocumented function for window-based mouse movement is not extensible and that the titlebar is linked to any mouse-based window movement (in dosbox).

Reply 9 of 15, by argenzul

User metadata
Rank Newbie
Rank
Newbie

Hi, DOSBox without frame a really cool feature. Many times I have become frustrated by the frame and wished for someone to remove it.

However it doesn't work when I try to play a game with VESA resolutions (e.g. 640x480) like Star Trek - A Final Unity. Perhaps it has to do with the operations involved in resizing the window?

Reply 11 of 15, by argenzul

User metadata
Rank Newbie
Rank
Newbie
truth5678 wrote:

Does Star Trek not work at all or does it work with a frame?

It does work in the original DOSBox 0.74 with a frame, except for a known issue with the dynamic core when you engage Romulan ships in battle (which is solved forcing a normal core). With your no-frame build, it simply crashes, leaving a completely clean stderr dump.

truth5678 wrote:

Did you try different output modes (dosbox.conf)?

I made sure the conditions were the same for both the original 0.74 I normally use and the no-frame build. Here's what happened with the no-frame build:

  • Surface simply crashes when I run the executable.
  • Opengl allows me to watch a cropped intro cinematic, since it didn't change the resolution, then crashes.
  • Openglnb does the same as Opengl, cropped cinematic with no change in resolution, then crashes.
  • Overlay at least has the courtesy to center the cinematic, but it's still cropped and then crashes.

Trying the same stuff with the official build gave me no problem.

Reply 14 of 15, by truth_deleted

User metadata

I tested a game with VESA mode support, Warcraft 2, and it runs with the patch. This suggests that the problem with the patch is not solely related to the VESA modes. However, I attached an updated patch to configure the dosbox window at 640x480 which should provide better VESA mode support. This patch is for current SVN code.

Attachments

  • Filename
    noFrame_480v.diff
    File size
    6.33 KiB
    Downloads
    107 downloads
    File comment
    Test patch #2 to remove window frame in dosbox 0.74SVN
    File license
    Fair use/fair dealing exception

Reply 15 of 15, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

Moving the topic to DOSBox Patches forum

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox
DOSBox SVN snapshot for macOS (10.4-11.x ppc/intel 32/64bit) notarized for gatekeeper