No clear reason to do this, given the SDL code path in the call to
SDL_WaitEvent, but initializing at startup adds no overhead and
was reported to help some debugging activities.
New sim_video APIs have been added to make it possible for a simulator
to open multiple windows. Two slightly updated functions are:
t_stat vid_open_window (VID_DISPLAY **vptr, DEVICE *dptr, const char *title, uint32 width, uint32 height, int flags);
Like vid_open, but return a dynamically allocated VID_DISPLAY struct
and return it in *vptr.
t_stat vid_close_all (void);
Close all currently opened windows.
In addition, these new functions correspond completely to the old set
of sim_video functions, except the first argument is a VID_DISPLAY
pointer: vid_close_window, vid_map_rgb_window, vid_draw_window,
vid_refresh_window, vid_set_cursor_window, vid_show_video_window,
vid_is_fullscreen_window, vid_set_fullscreen_window,
vid_set_cursor_position_window.
There are two separate running contexts that provide video capabilities:
1) Video event processing threads created on the fly as needed
2) Video events must be run in the context of the initial thread in
a process. In this context simulation and SCP runs in a created
thread and when video activities are enabled needed activities
are passed back to the primary thread to be handled.
As mentioned in #873, there didn't appear to be a problem at runtime,
but the formal definition suggests SDL_InitSubSystem and its cleanup
should be called. It is likely that, as a vestige of SDL 1.2,
SDL_OpenAudio is doing this under the covers. No harm adding it.
All interesting simh host platforms have long supported libSDL2
functionality which wasn't the case when sim_video was initially
implemented. The mixed API set significantly complicates maintaining
and extending sim_video, hence this explicit effort to remove
the vestiges of the old libSDL API.
Whilst working on a new video device I ran into a few problems with the
LKxxx keyboard and I noticed there are already some open issues against
the keyboard and mouse devices. These changes should resolve#320 and
may help with #272 (although I think that is an SDL issue). I've tested these
changes with VWS, UWS and DECwindows with both captured and
uncaptured input modes.
When PNG support is available, both .png and .bmp screenshots can be
generated based on the file extension specified by the user on the SCREENSHOT
command. If no extension is specified, then a PNG format screenshot will be
produced.
Reworked all priority adjustment code to leverage a new
sim_os_set_thread_priority API which is coded to use pthreads or OS
priority adjustment APIs as necessary.
These changes facilitate more robust parameter type checking and helps
to identify unexpected coding errors.
Most simulators can now also be compiled with a C++ compiler without
warnings.
Additionally, these changes have also been configured to facilitate easier
backporting of simulator and device simulation modules to run under the
simh v3.9+ SCP framework.
Using SDL2 the draw operations are performed in a separate thread and thus the data must be cached while the request is passed to the separate thread while control returns to the caller.
