Something small I was working on to go with my home weather system:

Is it "safe" to exit  a subroutine while in a While/Wend loop inside the Sub, or does this cause problems with things like the Stack or "memory leak" etc? 

Needed a palette editor for another 256 color mode program screen so I wrote this program.  This makes use of dialog commands, the mouse, and simple keyboard commands.  Loads and save the palette files as a simple data file. Also saves out the palette as lines of basic code.   

EDIT: added commands to copy and paste individual colors cells.

I'm really enjoying the QB64pe IDE but do have one request/suggestion. Hopefully this is the correct forum for this.

I'm working on quite a big project. Not a HUGE project but quite a large one nevertheless. It's just crept over 3000 lines and is becoming quite cumbersome to navigate. I've experimented with splitting sections off into BM/BI files but it feels quite a clunk way of handling things when I'm working on the codebase as a whole and it isn't really suitable to be segmented into standalone libraries.

What would make life a lot easier would be if I could collapse functions, sections, regions, etc.

Anyway, that would be my suggestions but I would also like to comment that it really is a very nice IDE to use. My original intention had been to look for Notepad++, VS Code, etc. plug-ins but there really is no need as it does exactly what's needed as is. Congrats to all the devs involved.

A while back I started a discussion on determining frames rates within other frame rates here:

https://staging.qb64phoenix.com/showthread.php?tid=1107

The method I came up with for Pac-Man I thought was quite clever. Turns out not so much. Not only is it ugly (string manipulation) but it only worked for one global frame rate. If another global rate was needed the entire set of strings need to be recreated. Ugly, yes, but functional for the game.

I have a project I'm working on that needs the ability to have the global FPS change at any time but still have the ability to know when lower frame rates change within that global frame rate, in real time. So, while investigating (and pulling my hair out for an hour) my son walks up and asks, "What ya doing?"

I explain to him what I'm trying to accomplish. He listens, says "huh?", then wanders off. Ten minutes later he came back with a super simple solution! (He's autistic on the Asperger's scale and his mind amazes me)

The code below contains a function called FrameChange that can report lower frame rates within a global frame in real time, even if the global frame rate changes. Now I have to go back to my Pac-Man code and put this in place of my ugly solution. His solution is so freaking simple.

I was working collisions of spiders and 2 spiders going in same direction or nearly so needed collision code different from spiders coming head on or perpendicular to each other.

So how do I tell if spiders are going in same direction or nearly so, say their headings are within 30 degrees of each other or not?

Just subtract the angles right? Or take the ABS of the difference right?

Well what if one has a heading of 0 degrees and the other a heading of 350 degrees the difference is 350, I am wanting 10 degrees so make 0 360 instead, easy right?

So now what if one was x and the other y when do I know to add 360? like with 0.

I came up with a function AngleDifference to handle this because this issue has come up before but it seems kind of clunky. I think the time before I used Major and Minor arc differences, two answers to angle difference. This time one answer but again seems cluncky.

I won't show my code because I don't want to bias someone coming up with maybe a more elegant solution which I suspect exists.

So if you can do it in a line or 2 I'd be interested.

Recently, I added a level editor to my game project.  In this level editor, I included a "playhead" tool, similar to what you would see in a video or audio editing program - so when you hit "play level" from the editor, with the playhead set, it would invisibly simulate the level up to that point as fast as possible, then you'd start playing from the playhead.  This is a very useful thing in my level design process, since it means I don't have to watch minutes of level go by while I'm tweaking a later part.

However, I noticed the simulation was taking almost as long as actually playing the level up to where the playhead was.  I ran a visible frame counter during the simulation and discovered it was only about 30% faster.

At the time I chalked this up to poor design on my part, maybe some inefficiencies in my code, and looked into it a little bit, but didn't find anything conclusive.  To boost the simulation speed a bit, I copied the main gameplay loop and stripped it down to bare essentials, only what the simulation would need.  To my surprise, it was now running EVEN SLOWER than before.

So I started commenting out pieces of the simulation loop, to see how it affected the time.  Nothing made a difference - the position updates, the level script check, collision detection, background scrolling, very mysterious.  So I took the loop, with everything but the actual frame counter commented out, and still, no difference, it was running just as slowly.  Good news - those chunks of code are actually super fast!  But how could the frame counter be causing so much slowdown that it was running under 60 loops per second?  It's just a PRINT statement with a variable plugged in.

Well, when you've eliminated every other possibility, whatever remains, however unlikely, must be true.  Below the PRINT statement was a SUB call: display_screen.  Here it is:

Here is my FreeBASIC port of Pipecom! Right now, I've only converted the Windows portion. The Linux portion will be a bit tougher to do. I am a newbie with FreeBASIC as I just got started so the code might be not that great. However, it works just the same as the QB64 code.

So following recent updates of Windows, the inpubox$ command still functions but it got ugly:



The system doesn't draw the input box neatly and it hides the values in the input box. 

Is there a way to fix this from inside a QB64 program or at a higher level in windows?  I'm not using the latest released build of QB64 has this already been addressed?