A quick fix, but providing `DEPENDENCY_CONSOLE_ONLY` when compiling
audio.cpp tells `common.h` to avoid pulling in `freeglut.h`, which fixes
the linking issue.
Fixes: #172
`sub__mousemove` is trying to use `x_scale`, `y_scale`, `x_offset`, and
`y_offset` to calculate where the mouse should be in the event the
window coordinates are different from the screen coordinates.
Unfortunately, all four of those variables are actually never set in the
program. The real scale values and offsets (in the event of
letterboxing) are stored in `environment_2d__` values. This change
switches `sub__mousemove` to simply use the correct values when
calculating the mouse position.
Because `x_scale` and `y_scale` are not used anywhere else I just
removed them completely. I wanted to remove `x_offset` and `y_offset` as
well but there are a few spots that make use of it. It must be a bug,
since they are never assigned values other than zero, but I'm not sure
if the correct fix for the other locations is to use the
`environment_2d__` value or do nothing, so I'm leaving them for now and
we can address them later.
Changing midiaudio.h will make it harder to incorporate new versions
into QB64-PE as they come out. To fix that I have reverted all the
changes to midiaudio.h and moved the few private parts we were using
into a separate 'filepath' API that's part of libqb.
This adds MIDI support to the language as a new unstable feature. There
are two new metacommands that come with this:
$Unstable: Midi
$MidiSoundFont: [Default|"filename"]
The $Unstable command is required to be able to use any of the other
commands, and just signifies that this is not a full part of the
language yet and may change in breaking ways before the API is
finalized.
The $MidiSoundFont command enables MIDI support in the compiled program,
and also specifies what sound font to use to play MIDI files. "Default"
will make use of the soundfont placed at
'./internal/support/default_soundfont.sf2', and otherwise a filename can
be specified to use any soundfont wanted.
In either case, the selected sound font is compiled into the executable
and then loaded at runtime.
Fixes: #115
DPI Awareness allows a program to tell Windows that it will handle
properly scaling itself for the screen's DPI. Thus when a program is DPI
Aware, it will always see the actual screen size. When a program is not
DPI Aware, then Windows will scale the program according to the
selection by the user, and the reported screen size will match the
scaled size rather than the actual screen size.
Commit 189cdb8e added logic to enable DPI Awareness on Windows, but it
was hidden behind a `WINVER` check. This meant it was not actually in
use because at the time QB64 did not set a `WINVER` high enough to
actually enable that code. As such all Windows versions of QB64
including v2.0.2 were not DPI Aware.
Much later-on, Commit 869e361e declared a `_WIN32_WINNT` of `0x0600`,
which seems to have also declared `WINVER` as the same and thus enabled
the DPI Awareness logic. As a consequence, QB64-PE programs no longer
get scaled even though they don't have a way to acquire the current DPI
to do proper scaling themselves.
Since the behavior change was unintentional and proper language support
is not there, we're considering the addition of DPI Awareness a bug. It
will be added back some time later with more language support to allow
it to be properly used.
We started defining `_WIN32_WINNT` a little while ago to express that we
require Windows Vista or above for support. This enables us to access
some Windows Vista-only APIs. The fact that `WINVER` also needs to be
defined was missed, and it seems that defining one means the other no
longer gets defined automatically as it did before. Thus we're simplying
now also defining `WINVER` the same as `_WIN32_WINNT`.
This fixes High-DPI awareness and a few other things that were gated
behind WINVER checks.