`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.
- checks all remaining occurrences of the term 'qb64', some remain untouched, some are renamed according to context
- also added new logo for README.md
- this step does finalize the 'Phoenix Edition' re-branding
- replaced default icon image data, which is used, if _ICON is used w/o parameter, but no $EXEICON is specified either (see also Step 1)
- this step completes icon related changes
- int/src/icon.ico (replaced image but same name, dynamically created from given $EXEICON)
- int/src/icon.rc (updated but same name, dynamically created from given $VERSIONINFO)
- int/src/qb64.ico and src/icon.rc removed (not used anymore since dynamic creation was implemented)
- src/qb64.bas updated (rename comes in a later step)
- src/qb64.ico replaced and renamed
We shouldn't allow mutex lock/unlock to silently do nothing if NULL is
passed, as that is very likely a bug. Beyond that the Windows version
doesn't do this, so it's inconsistent as well.
This moves a lot of the preprocessor flags for what compiler/platform
we're using into a libqb-common.h header inside the libqb/include
folder. This gets included at the top of every libqb .cpp file, and is
intended to be fairly small, providing only necessary things like
_WIN32_WINNT (which needs to be defined before including <windows.h> or
friends).
The Buffer API implements an append-only buffer, where you can write to
the end or read from the beginning. Data that is read is discarded from
the buffer, and you can query the buffer to get the current amount of
data inside.
Internally the buffer API is implemented as a chain of separate buffers.
This is done to avoid having to resize the existing buffer, which is
expensive. We keep track of where the reading currently is, and discard
the internal buffers after all the data in them is read.
Completions are basically a oneshot flag, which provide a `wait()` call
that blocks until 'finish()' has been called on the completion.
The nice aspect of completions is that because it is a oneshot the order
does not matter - if 'finish()' is called before 'wait()' then 'wait()'
returns immediately. It makes the logic for waiting until a thread is
done finishing up some work easy to implement.
This adds generic APIs to libqb for handling thread's, mutex's, and
condition variables. On Linux and OSX these are implemented via the ones
provided by pthreads. On Windows they're implemented via the ones
provided by the Win32 API.
For compiling, the code itself is not conditional, but the Makefile
includes logic to decide which implementation to pick.
Note that it would have been nice to simply use std::thread and friends
from C++11, however using them on MinGW appears to be a bit messy. Since
using the Windows ones directly isn't that hard this was an easy compromise.
This sets up a few different flags we'll need for the conditional
compiling, and also sets the C++ standard to gnu++11, which effectively
just matches what we were implicitly using before.
Note: Many files were removed (not yet existing/empty pages). The parser will try to download them on demand and will auto-generate text for missing pages (eg. most _gl pages).
Note: Many files were removed (not yet existing/empty pages). The parser will try to download them on demand and will auto-generate text for missing pages (eg. most _gl pages).
searched.bin was added in error and should not show up when updating
./internal/source.
The symbol files are useless since the coresponding executable is not
something we preserve, and due to them changing practically every build
they result in unnecessary updates of ./internal/source
When building directly from the repo (either from a git clone or a
download of the zip of the repository) the version reported is very
misleading because it will not have a version label, suggesting it is
actually a 'release' version when in fact it could be anything.
The ./.ci/calculate-version.sh logic is already setup to delete an
existing ./internal/version.txt during a detected release build, so we
can just place one in the repositroy and it won't impact the versioning
of CI and release builds, but will show up when building locally.
Fixes: #63
Mostly old build scripts and helper files that are now covered by the
Makefile.
A notable deletion is the glew dll and lib files. These are unnecessary
because we compile `glew.c` directly rather than link against the dll or
lib copies we have.
Having windows call GetSystemMetrics without relying on glutGet, gets rid of the seg fault that can occur at program start up. screenicon was restored to it's previous state so that larger issues with it can be addressed at a future date.
Fixes the issue as brought up on the forums here: https://qb64phoenix.com/forum/showthread.php?tid=408
Also added a small set of logic so we don't end up inside an endless loop if the screen is hidden (via _SCREENHIDE), or if it doesn't exist for whatever reason.
This issue was fixed in 4d61ff79, but due to how ./internal/source is
updated the new ./internal/source files were compiled using a QB64
without the fix, producing files with the wrong quoting. Previously this
was worked around because the build process overwrote these files, but
the `Makefile` build requires them to be fixed.
./internal/source itself is fine, so it's easy enough to simply fix the
files by hand. Since ./internal/source now contains a compiled QB64 that
contains the fix from 4d61ff79 it's generated files will have proper
quoting and won't need to be manually updated.
Currently there is a bug where if a variable width font is in use and
text printed would exactly fit to the end of the row, it is instead
wrapped and printed on the next line.
Ex. You're printing a character that is 10 pixels wide, starting
from position 90 on an image that is 100 pixels wide. This should fix,
but instead your character will be printed on the next line.
The reason this happens is an off by one error, cursor_x (effectively
the X value passed to LOCATE) is one based even when using a variable
width font where cursor_x represents a pixel location. The location that
check if the next character can fit on the screen never handles the base
one, so it ends up treating the ending Y coordinate as one past where it
will actually end, which makes the code thing the print will go past the
edge of the screen.
To fix we simply subtract one before doing the comparison to give us the
actual ending pixel column.
There's no need for all colors to end up with a new prefix for use between $COLOR and $NOPREFIX.
The only conflicts we have are with _Red, _Green, _Blue, so this fix appends a NP_ to the front of the those three color names so they won't conflict with the command names. (NP_ for NoPrefix_)
internal/c/c_compiler no longer contains anything, so git will not
create it. This change makes setup_win.bat create the directory if it's
not already there.
* Create `$NOPREFIX`-friendly version of `color0.bi`
* Create color32_noprefix.bi
* add conditional for noprefix $color
* oh. it was that easy?
* Update CHANGELOG.md
* Update help files [ci-skip]
Co-authored-by: all-other-usernames-were-taken <74026992+all-other-usernames-were-taken@users.noreply.github.com>
Turns out QB64 promises to store all _FLOATs using 32 bytes.
I imagine that is how Galleon planned for eventually storing
larger floating point numbers, but, as it's been observed,
_FLOAT are actually `long double` variables, so they take up
16 bytes. This not a problem for regular variables, but it
does take a toll for arrays, as values are actually stored
as a sequence of 16-byte numbers.
This patch is a hack. But so is FLOAT right now.
