I'm not able to reproduce it, but it might be something on my end. I do have my QB64 folder synced to a cloud, so one of the files updating in conjunction with resizing the window might screw it up. I usually pause it, but sometimes I forget.

My post was less a bug report and more a "If this happens to you here's what you can do".

It's happened to me twice now where if I resize the IDE by dragging the edges the IDE freezes with message "Resizing..." in the message area (no idea how to replicate the bug).

The first time I opened Task Manager, went to processes, and ended the QB64 Task. When I reopened the .bas I was not prompted to recover data, so I lost everything since my last save. No combination of ctrl+z'ing or opening other windows helped.

The second time I did a hard shutdown (hold the power button on your PC for 10 seconds). After rebooting and opening the .bas QB64 prompted me if I wanted to recover my data. The auto-save worked.

I couldn't find any info online, so just posting this in case it happens to someone else.

I saw that on the wiki, but I was unable to get it to work.
The blinking did stop, but for example COLOR ,9 is always COLOR ,1

Regarding having to release the source code, that refers to programs that use the built-in sound capabilities, due to the licensing of the sound libraries we use. From licenses/COPYING.txt:
Extra emphasis on the last part: It should be noted that providing source code is not the only way to meet the conditions of the LGPL (eg dynamic linking) but it is by far the easiest from a technical point of view at this current time.

How would one dynamically link to the sound library? I'm getting closer and closer to releasing one of my games commercially and I am also using the built-in sound. I never read the licenses before, but I just assumed by using ogg I would be in the clear.

One easy trick is to use 2 screens and work with both at the same time.

Code: QB64: [Select]

1. DisplayScreen = _NEWIMAGE(640, 400, 256)
2. CharacterScreen = _NEWIMAGE(80, 50, 0)
3. SCREEN DisplayScreen: _FONT 8
4. PrintBoth "Foo"
5.  
6.  
7. SUB PrintBoth (text$)
8.     _DEST CharacterScreen
9.     PRINT text$
10.     _DEST DisplayScreen
11.     PRINT text$
12. END SUB
13.  

Now, you can use SCREEN with the text screen (CharacterScreen), and retrieve your characters properly.

Interesting. I updated with my own variables.

_DEST is new to me; is it like a more flexible way of page flipping?
Also, on the code above, why is "Foo" printed twice, even though we're viewing SCREEN DisplayScreen? Maybe I'm missing something.

I liked the quote "Write games, not game engines". I've certainly been guilty of that a couple of times now.
Even though writing the game engines was a great learning experience, I have nothing to show from them. I regularly cannibalize code from them, but I could just as easily do that with a fully-written game.

I love making games in BASIC. I couldn't stand making a game in something like RPGmaker. Even an object-based language like vbasic loses a lot of the oomph for me. Only con is no Android functionality.

Edit: This post was a bug report regarding the SCREEN() Function, but as SMcNeil pointed out...

SCREEN 0 stores your ASCII character in memory, so it can always retrieve that value for you.  No other screen does this.

A graphical screen draws GRAPHICS onto the screen and has to compare pixel-by-pixel to guess at what the character is in any given space.  It can't tell you the difference in CHR$(0), CHR$(32), or CHR$(255).  If you draw a line above a period, it might read that as a colon or semi-colon.

I've dabbled in a few other iterations of BASIC, and the reason I never wanted to switch was because they all lacked a SCREEN() Function. It's one of the wonderfully unique aspects of qbasic/qb64. But...

I would argue that the worst limitation of qbasic/qb64's SCREEN 0 is being limited to 16 Colors (attributes) and worst of all 8 background colors (attributes). This limitation is something I've struggled with in my ASCII games for a long time. Would it be possible to have a way to up that limitation? 64 seems like a logical number (DAC). 256 would be better.

SCREEN 0 can already successfully load custom fonts (and scale them), and can use the SCREEN() function. Removing the COLOR limitations would make it perfect in my book.

My old post that details the issues with using SCREEN() in graphic modes is below...

Issue 1: In modes other than 0; using SCREEN() to find an ASCII character on a background other than COLOR ,0 results in a solid block (cc 219).

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 256): _FONT 8
2. COLOR 5, 1
3. PRINT "Hello World!"
4. PRINT SCREEN(1, 6); SCREEN(1, 7)
5. COLOR 5, 0
6. PRINT "Hello World!"
7. PRINT SCREEN(3, 6); SCREEN(3, 7)

Issue 2: In modes other than 0; Using SCREEN() after loading a custom font triggers an illegal function call.

Code: QB64: [Select]

1. SCREEN _NEWIMAGE(640, 480, 256)
2. F = _LOADFONT("cyberbit.ttf", 32, "monospace") 'replacing with F = 8 works fine
3. _FONT F
4. PRINT "Hello World!"
5. PRINT CHR$(SCREEN(1, 1))

I tested 256, 32, and SCREEN 12. With both FONT 8 and FONT 16

No, I changed all of the variables. Like I said, the SCREEN Function throws an error.
I get an illegal function call on line 5.

Could it be a glitch?

Edit: Ah, it is a glitch.
Using SCREEN 0 wile using a custom font works fine.
Using SCREEN _NEWIMAGE(,,256) without a custom font works fairly well (there's that non COLOR ,0 " " as block issue).
But, you can't do both SCREEN _NEWIMAGE(,,256) and a Custom Font and use SCREEN()