Various code questions
#1
I have a few assorted pieces of code that I don't really understand, and I'm wondering if anyone can help explain or break down what the code means.


1) 

Code: (Select All)
variable~&(1)

I know the & symbol means long integer, but is "~" part of the variable name or is this part of the variable type?



2)
Code: (Select All)
Do: _Limit 10
Loop Until Len(InKey$)

Obviously the point of this is "press a key to continue" but the code is not familiar to me.   Do followed by :  is a new one, and I'm not sure what _Limit 10 is doing on this line.
Additionally "Loop Until" is normal stuff but having Len(Inkey$)  afterward isn't something I've seen before.   Is this some advanced efficient coding?     These two lines as they appear are a bit over my head.


3)
Code: (Select All)
_MemCopy m1, m1.OFFSET, m1.SIZE To m0, m0.OFFSET

This can be found in the wiki, and it says:
The _MEMCOPY statement copies a block of bytes from one memory offset to another offset in memory.

This purpose of this isn't clear to me.   Is it just a quicker copying method (as opposed to setting up loops to copy an array) or is there some other advantage?
Also I have no idea what the OFFSET is doing.    The wiki says it's about memory blocks so this seems like a more advanced coding/theory (beyond my level of experience)


4)  
Code: (Select All)
While _MouseInput: Wend


This is probably obvious to everyone here but I'm a bit lost.   The wiki shows the Wend statement on a completely different line, so if you have this all on one line, what is happening?
The code I'm referring to has a comment at the end (While _MouseInput: Wend ' clear)  so the intent is to clear....but how this works to clear is what I'm wondering.   


5)
Code: (Select All)
m2Dn = _MouseButton(2) ' button 2 processing
If m2Dn Then ' Btn 2 down

This is straightforward enough, but what's unclear to me is the IF statement:

If m2Dn then

I have never seen this before, where the IF THEN does not have an equation between them.    Example:

If m2Dn>1 then
if m2Dn=0 then

I'd definitely like to understand how this works.


Thanks!
Reply
#2
The "squiggle" just after variable name means "_UNSIGNED". For this reason, which causes confusion, I don't advocate type sigils any longer and would like QB64 to get with the times about function declaration heading (such as "FUNCTION foo(parameters) AS _UNSIGNED _INTEGER64" instead of "FUNCTION foo~&&(parameters)").

The loop including "_MOUSEINPUT" is often used to drain out the mouse message queue, which is very important because this programming system doesn't have something like found in Purebasic, about handling keyboard and mouse input. The routine to deal with the mouse in QB64 are almost quick and dirty. That's why it's more difficult to check for mouse button press then release, to keep track of mousewheel and a few other things than while programming an ordinary Windows application on Purebasic.

"_LIMIT" is helpful to bring down the CPU usage of programs. Without it, your program would be intolerable to other people, even if one of them has an 8-core system. Oh well LOL I don't know about that really. Many programs written for M$QB and Qbasic rely on ordinary "FOR...NEXT" loops to delay program run, which is needed in an arcade game so the enemies don't go too fast on the player. That was good while computers were built with Intel's older processors like 8086. After systems became 32-bit and 64-bit the programming language loops became too blinding fast to use a "FOR... NEXT" arrangement.  The alternative to "_LIMIT" is "_DELAY" but it could be another PITA trying to get precise input from the user and he/she doesn't lose patience.

If you're not an "advanced" programmer you shouldn't be discussing anything about the "_MEM" gang. IJS.
Reply
#3
Let me answer these for you, as they all seem fairly straightforward.

1) & is the type symbol for LONG.  ~ is the type symbol for UNSIGNED.  So variable~&(1) is an array of _UNSIGNED LONG type, and you're referencing the first element in it.  

2) The : here is simply syntax for a multi-line statement.  It's basically counted the same as a new line.   For example:

x = 1: y = 2 

The above would be the exact same as: 

x = 1 
y = 2

You're just putting the 2 statements on the same line to reduce "code sprawl" and scrolling.  You'll see the use of : a lot when dealing with pixel coordinates and such, where it just makes sense to keep the two variables together as much as possible.

As for the loop:

DO
    _LIMIT 10
LOOP

This is simply a limit on the number of times that the loop can run in a second.  The limit here says, "Don't run the loop more than 10 times per second", so you're freeing up resources and not running a high CPU usage while just waiting for the user to press a key.

...  UNTIL  LEN(INKEY$) -- The LEN statement is to determine the LENGTH of something.  In INKEY$, the result it returns is going to be "" (a set of quotes with nothing between them), which would have a length of 0 characters/bytes.  When the user presses any key, INKEY$ would record the key pressed (Say "A" if you hit the A key), and the length would no longer be zero.

LOOP UNTIL LEN(INKEY$) says to basically repeat the loop until the user hits some key.   In combination with the rest of the code here, it says to just repeat the loop a maximum of 10 times per second, and wait for the user to press a key.  It's a CPU efficient pause in the program -- nothing more complex than that!  Wink
Reply
#4
#3) This is generally a way to efficiently copy one variable or block of memory to another. Where we see this used the most is if we want to copy ArrayA() over into ArrayB() for whatever reason. Now, we could write code such as:

FOR i = LBOUND(ArrayA) TO UBOUND(ArrayA)
ArrayB(i) = ArrayA(i)
NEXT

But the above would copy one element at a time until it copied the whole array. The _MEMPUT as you have shown it, would copy the *whole* array all at once from ArrayA to ArrayB, with one pass, making it a whole lot faster and more efficient.
Reply
#5
#3 -- WHILE _MOUSEINPUT: WEND

Our mouse information is stored in a array that updates a couple of bazillion times per second. (Maybe not that fast, but it certainly seems like it sometimes!) As we normally don't run our program loops at this insane rate, we end up using the above to clear the mouse input buffer until we just deal with the most relevant information for us.

For example, scroll the mouse to the right for 1 second. You might have a whole series of movement updates:

mouseX at 123
mouseX at 123.1
mouseX at 123.3
mouseX at 123.4
mouseX at 123.6
mouseX at 123.8
mouseX at 124
mouseX at 124.1
mouseX at 124.3
mouseX at 124.4

Now, if you've got a _LIMIT 1 in your program, you're only going to run your main loop one time per second. The above has 10 mouseX positions where it moved across the screen in that one second. Are you going to spend 10 seconds trying to process all of those events?? Or are you going to simply say, "Hey! Where the heck was the mouse when the program loop processed?"

While _mouseInput: Wend says to toss out the intermediate mouseX/Y positions and only deal with the current one. We don't need to know when it changed a half a pixel -- we just need to know where it was at when the main loop processed, and whether the user has hit the button or not since the last loop.
Reply
#6
#5 is a basic TRUTH check. In BASIC, **everything** tends to break down to a simple TRUE or FALSE type evaluation. If a variable, or the result of an action, gives a value of ZERO, we consider that to be FALSE. Anything else is considered TRUE.

Let's take a look at IF x > 3 THEN....

x > 3 is a simple math statement that gives us two results. (Don't believe it? Just try a little PRINT x > 3 and change the value of x a few times.) IF x is less than or equal to 3, it returns a value of ZERO, which is <FALSE>. If x is greater than 3, it returns a value of -1, which is <TRUE>. This true/false value determines whether we process that IF statement or not.

Now, let's take a look at IF X THEN....

X is a simple variable. In this case, we don't have to do anything with it, except look up its value to know our results. If X is 0, then the result is FALSE. Anything else is TRUE.

So, in the case of the following:
m2Dn = _MouseButton(2) ' button 2 processing
If m2Dn Then ' Btn 2 down

m2Dn gets its value based on the state of the right mouse button. (Mouse Button 2) If the button is down, the value is -1. IF the button is up, the value is 0.

IF m2Dn THEN .... If m2Dn is <TRUE>, then we process the code inside the IF condition. Otherwise, we don't. In this case, the only true value we can get is -1, and we only have it when the button is down. The statement basically says, "IF the right mouse button is down THEN..."
Reply
#7
I'm not what I would call an "advanced" programmer, but I've successfully used _MEM commands. It's powerful stuff, but not especially complex. You just have to control the numbers correctly or weird stuff will happen.

Steve laid out a pretty good series of tutorials on the subject, starting here:

https://www.youtube.com/watch?v=l0iwjGhBhhc

It's what got me started. Definitely take some time to play with it, and you won't be sorry.
DO: LOOP: DO: LOOP
sha_na_na_na_na_na_na_na_na_na:
Reply
#8
(08-17-2022, 04:55 PM)OldMoses Wrote: I'm not what I would call an "advanced" programmer, but I've successfully used _MEM commands. It's powerful stuff, but not especially complex. You just have to control the numbers correctly or weird stuff will happen.

Steve laid out a pretty good series of tutorials on the subject, starting here:

https://www.youtube.com/watch?v=l0iwjGhBhhc

It's what got me started. Definitely take some time to play with it, and you won't be sorry.

This video seems great but on my screen it's blurry.   360p is the max so I can't read the text clearly.   I can sort of assume in a lot of cases but his other videos are HD so it seems like it's just this one.   Or maybe it's just youtube.  I'll check it again later.   Cheers.

Edit: He actually says in MEM video 2 that he upgraded the resolution.
Reply
#9
It was just the first video. When I started, I was trying to keep bandwidth usage down on them, but I quickly learned from user feedback that was unacceptable. From #2 on, they all are HD resolution (and took *FOREVER* to upload and share). I don't think you'll have any issues with screen resolution after the first. ?
Reply
#10
(08-17-2022, 06:35 PM)SMcNeill Wrote: It was just the first video.  When I started, I was trying to keep bandwidth usage down on them, but I quickly learned from user feedback that was unacceptable.  From #2 on, they all are HD resolution (and took *FOREVER* to upload and share).  I don't think you'll have any issues with screen resolution after the first.  ?

Video 2 is perfect.   Excellent info, I really appreciate the examples being applied while explaining this MEM topic.   Thank you for doing this.
Reply




Users browsing this thread: 2 Guest(s)