Building this as an addition to Sam-Clip

So I start typing away at this itty bitty program when all of a sudden, bam! The crazy IDE eats a piece of my code. Well Jane, I look at the screen and say, "Hey! Why'd you eat a piece of my code?" Now the I-D-E, it can't talk back to me, especially with it's mouth all full of my code, but it just goes to show you, Jane, it's always something...

Try and type then press Enter...

I was messing around with radians and ended up making this.   Cheers.

I'm finishing up a Pac-Man clone. The game runs at 60 frames per second just like the original. During game play the speed of both Pac-Man and the ghosts are modified by level events and by advancing to higher levels. The speed of these objects is adjusted in 5% increments resulting in a loss of 3 frames per second per 5% loss:

100% = 60FPS (the fastest any object travels)
95%  = 57FPS (60 * .95)
90% = 54FPS (60 * .9)
85% = 51FPS (60 * .85)
...
...
40% = 24FPS (60 * .4) (the slowest any object travels - ghost in the tunnel on level 1)

The usual way I adjust speeds in games is to use MOD and skip frames when the outcome is 0 (zero):

IF Frames MOD 20 THEN ... (every 20th frame will be skipped resulting in 95% or 57FPS)
IF Frames MOD 10 THEN ... (every 10th frame will be skipped resulting in 90% or 54FPS)
IF Frames MOD 5 THEN ... (every 5th frame will be skipped resulting in 80% or 48FPS)
..
.. Etc.

This can also be done in reverse for lower frame rates:

IF Frames MOD 20 = 0 THEN ... (all but three frames will be skipped resulting in 3FPS)
IF Frames MOD 10 = 0 THEN ... (all but six frames will be skipped resulting in 6FPS)
..
.. And so on

My problem is that neither of these methods will yield 85%(51FPS), 60%(36FPS), 55%(33FPS), 45% (27FPS), and 40%(24FPS) all of which I need.

There must be a simple formula I am overlooking to use within a 60FPS loop:

Object.FPS = 24
Frame = 0
DO
    _LIMIT 60
    Frame = Frame + 1
    ( If Object.FPS multiplied by some magical number= current frame then draw it ... formula here)
LOOP

I know I could set up individual frame counters for every object and skip, say, every 9th frame to achieve 85%. However, the original Pac-Man arcade machine had 16K of ROM and 2K of RAM and I can't imagine this was the procedure used with such limited space.

I also realize that I could simply use single precision numbers for x,y and add the percentage ( x! = x! + .85  : 85% for instance ) to get the desired outcome, but again, using single precision values in that era would have been a no-no given the speed over head.

How did those early programmers do this with Integers? Is there a formula I'm overlooking? Help me Obi-Wan math wizards, you are my only hope. I've stared at this for far too long now. My brain hurts.

Just for the giggles.  BAM-first version that I'll tweak later, if any tweaks needed, to get working in QB64PE.

I've got the buttons setup (including button color change on hover) and a little sound effect when pressing and depressing a button.

A few hours of work left, so sneak peek:

• View the source code
  
• Run the program
  

This is, in my opinion, one of those essential keywords that everyone should know and make use of.

What is it?  Keyclear is the simple command which clears the keyboard buffers for us.

How does one use it?  Just call _KEYCLEAR where your program would need to clear the buffers at.

Example of the command:

Screen Filler Zakraska

Zakraska.bas program fills screen with dots
by dividing field into a 4x4 section or arbitrarily
and better sides of field of multiples of small sections

Row under label 3:
rotating row checks condition and repeats itself

Dot is placed strictly in an empty place and field is filled in 100%
and there are also counters of points not set and a time counter

Results:
2x2 = 2 seconds & 27ooo repetitions for 25ooo points
4x4 = 5 seconds & 65ooo repetitions for 25ooo points
8x8 = 15 seconds & 95ooo repetitions for 25ooo points
16x16 = 55 seconds & 135ooo repetitions for 25ooo points
32x32 many seconds & many repetitions for 25ooo points

Field is filled in by 100%



Conclusion: random control is real

This is a simple demo for SCREEN 0, but someone could work up a graphics counterpart easily enough...

I cannot create an account with Github because it goes against my pride, and some web browsers cannot handle well content of that site. Therefore this very bored user will bore you further with creating a thread just to offer even more opinions that might not be wanted...

If you want to "visit" the issue just drop into the address blank of your web browser:

s://github.com/QB64-Phoenix-Edition/QB64pe/issues/NUMBER

Purposely beheaded so it's not "clickable," and "NUMBER" should be the number shown after pound-sign below.

#233
I support this; just make release (middle) number padded with zero but not make it obvious to the programmer because some code exists that would test for "0.5.0", for "3.2.0" and it's only the beginning. For "3.2.0" case "internally" test for "3.02.0". In fact do it for "03.02.00" in case this programming system could reach version 10!

#219
One fault is that some users like "small" terminal windows, while a typical dialog could require at least 100 characters across. It would be impossible to predict when an user maliciously resizes that window to smaller size to see if the user program crashes. Would have to stick to low-bit characters to draw the dialog. I've discovered "ANSI" codes for coloring not reliable on some "terminal emulators" of Linux distros. This was from using a library called "Lua-term" which allowed simple output to the terminal with coloring and positioning, by using Lua code.

#212
Have "_RESULT" keyword, a lot like Pascal/Delphi, as alternative to "_RETVAL". I resist "EXIT FUNCTION" more than "EXIT SUB", I think it's a retarded way to break out of a function early, and there is too much code already which keeps using function name on LHS which is bad form. This new keyword should put an end to it at least for new programs.

#211
I support this. However, instead of lame-ass keywords from Visual Basic, as alternative how about a compiler option for it? I would like the short-circuit evaluation to be absolute if I choose.

#206
(To the one who opened this issue: ) You would have to change your way of thinking about this. If the concept of MAK file is insisted on you must rearrange your "project" so there is only one main program, and the other BAS files then become BI to be included into the main program. Each "main program" in "slave" BAS files should be put into their own "SUB's" to be called in a desired order by the only true main program. Otherwise each BAS file is destined to be compiled into a separate executable file, without relation to one another. This could be a pain because "CHAIN" and "COMMON SHARED" weren't meant to be used in 32-bit and 64-bit environment where security has some emphasis.

#187
On the Linux side you guys might want to talk to "angros47" that Italian guy who did an audio/MIDI playback library for Freebasic.

#30
This is one of my longest requests.

"A Karnaugh map reduces the need for extensive calculations by taking advantage of humans' pattern-recognition capability. It also permits the rapid identification and elimination of potential race conditions."

I was not familiar with this, I only happened to see a news article about its inventor, who died just this week. 

But it looks like just the kind of thing the folks here might find interesting!