The border color parameter to PAINT is optional, but sub_paint was not
handling that case. What it should do in that situation is keep painting
until it finds pixels that are not the same color as the original
starting pixel was. Instead it would simply assume border color was
valid and paint until it finds color zero (the default parameter value
when it's not provided).
This was originally reported in QB64Official/qb64#2, and Walt
(@TheJoyfulProgrammer) fixed it in QB64Official/qb64#38. Functionally
this is the same change, however I'm checking `passed & 4` to see
whether a border color was provided rather than `bordercol == NULL`.
The later has problems if the provided bordercolor is zero, which is
allowed since zero is a valid color. The `passed` argument indicates
which of the function arguments were actually provided in the QB64
source that called PAINT.
Additionally, along with the `while (true)` loop that Walt changed I
went ahead and removed the duplication of the sections for each
direction. We now just use a couple of arrays to determine which
direction we're checking and loop over all 4.
`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.
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.
- 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
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.
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.
In order to allow $DEBUG to work with programs that call CLEAR, the connection handle used to connect to the IDE is locked by default and cannot be CLOSEd. With this change, the debuggee itself can now unlock the handle and close the link.
This change adds the Program Files and Program Files (x86) folder specifications to the `_DIR$()` function.
`Print _Dir$("program files")
Print _Dir$("program files x86")`
Where the previous bug would only return the console's image size when an image was passed, the new bug made it only ever return 80 for `_Width` and 25 for `_Height` when it should be returning the console's image size if there is no value passed and it is the `_Source`, which it is if we are in a `$Console:Only`.
Here is a code block that demonstrates the bug being fixed:
```Option _Explicit
$Console
Screen _NewImage(640, 480, 32)
_Dest _Console
Width 120, 5
_Dest 0
Print "Hello world"
Print _DesktopWidth, _DesktopHeight
Dim As Long i: i = _NewImage(1280, 720, 32)
Print _Width, _Height
Print _Width(0), _Height(0)
Print _Width(_Console), _Height(_Console)```
When opening a file for random access, if the LEN is not supplied, it defaults the length correctly, but does not allocate the buffer correctly. The code should reference the record_length in the file struct.
2 changes here:
line 13062: When opening a file for random access, if the LEN is not supplied, it defaults the length correctly, but does not allocate the buffer correctly. The code should reference the record_length in the file struct.
Changes in lines 15798-15853: When printing text to the screen, carriage returns in the text are ignored. In sub_file_print, the code for printing to the screen is modified to honor carriage returns.
Fixes a bug that would make QB64 return the incorrect size monitor/desktop size when the resolution is scaled. Also, the last fix I added that set `_Source` to `_Console` automatically caused an issue with `_Width` and `_Height`, causing them to return only the console's image dimensions rather than the image that is passed.
Done for the sake of retrocompatibility. Although those symbols are simply ignored, as the type is determined by the variable types given at the respective READ statements.
Before we strip off the requirements (like "monospace" and such), we should first see if the font exists on the drive, since we call the routine recursively looking for it.
- Changes CFont to sub__consolefont and func_CInp to func_cinp, in alignment with the rest of libqb/qbx.
- Adds stubs to all new console functionality, so we can still ship for other OSes with no bigger issues.
- Adds new keywords to syntax highlighter.
