So I tried this new improved division code I created in the pi routine Jack provided, and wow, a 700% speed improvement! That makes it 500%+ faster than that same pi routine running with Treebeard's string math.

From the pi thread, I commented about the improvements...

"Basically what I did was to shortcut zero and 1 divisors, chop out leading zeros in small decimal numbers making less digits to calculate, estimate the mult loop by using just the first one or two digits of the divisor and the dividend or remainder so it usually only takes two tries to get the right multiplier before subtracting to obtain the remainder and, of course, working with chunks of numbers with multiplication and subtraction in the long division process.

I knew it would be faster, I'm just amazed it's so much faster.

Now I'm wondering how much faster it could be if I switched from string concatenation to fixed string replacement? I did that once with a c keyboard WP routine (about the only complicated C/C++ prog I've ever written) and the speed increase was pretty impressive. Converting for string math might be a bit of a challenge, and if too many conditions need to be added, it might end up being a push."


So this code was added to that pi routine, but you can try the it out here as a divison calculator by inputting a dividend and divisor. It will validate input, but I left out my conversion of scientific notation to numerical expresion for this demo, so don't input SI.

It has a variable named: BETATEST%. Set it to ZERO to avoid all the screen notes, SLEEP between loops, and just get the results. I kept betatest% = -1 for this demo, to show the divison steps in progress.

Increase or decrease the limit&& variable to control the number of digits displayed. Note: for this demo, I did not include my rounding routie to round the last digit displayed.

So while my previous string routine was accurate for large numbers, this routine is looking to be both accurate and fast. I think it's fast enough now to be to calculate numbers with several hundreds of digits to sevreral hundreds of places almost instantaneously!

As for beta testing, that's another workhorse in the making. I will need to try some huge numbers out on n online precison calculator later. Of course if anyone spots any bugs, let me know, and I'll look into it. Maybe soon I can bump this baby up to a work in progress.

Thanks to Jack for getting me motivated to look further into this project.

Don't look at this too long.

This code can be used in adventure games or any other type of game or app. It makes random looking hills on the screen and when you press the Space Bar it makes different looking ones. I was experimenting with graphics. You can also change the PSET _RGB32 color to blue if you wish to make water waves instead. Just replace the last 0 with the c and the c with a 0.  

The below snippet will show the amount of RAM your computer currently has installed.

If only because I have a habit of checking for a newer version I came across 3.0, which became 3.1  I was on 0.8.2  Only today I got 3.1 almost a week after first release.

A nice feature/option to check once a week or month for a newer version and inform the user on startup.  There isn't even a check for update in the IDE.

the wiki says that the size of _Float is 32 bytes, is that correct? https://qb64phoenix.com/qb64wiki/index.p...able_Types
(I know that padding is needed for alignment but the size should be at most 16 bytes)

First off, greetings! Nice to see some familiar names on here after the whole QB64 nuking fiasco.

Still working on my game (Scrapship) and just recently started learning about sprite sheets.

I have a program that can create sprite sheets (Texturepacker), but now that I have a sprite sheet, I'm not sure how I would implement it in QB64/PE.
Below is little pic of the sprite sheet I currently have.




Has anyone done any work with sprite sheets in QB64 before or am I walking into uncharted territory?

Side note: I am not using any libraries or game engines, strictly QB64 code.

exclude duplicates

Over the past week I've been on a trigonometry quest to better understand the math needed for degree, radian, and vector math for my tutorial. The previous tutorial was lacking in this area and I'm changing that.

I've been using a routine written by Galleon back in 2009 to rotate a sprite using trig and _MAPTRIANGLE. I thought I would see if I could rewrite it using new commands that have come out since then like _HYPOT, _ATAN2, _D2R, etc..

The code below is my attempt at this, and it works. But still not nearly as efficient as Galleon's. I have marked Galleon's lines of code and my lines of code with REM statements, ' ******* RITCHIE and ' ******* GALLEON.

I've stared and stared at his lines 59, 60, 70, and 71 (Galleon's calculations) and I'll be damned if I can make sense of them. Could someone please explain to me how his lines of code achieve the same thing I'm doing? What am I missing here?

This might be one of those things that "everyone knows," but I missed the memo. Is there any way to input a string variable which includes commas?

For example, in NMEA 0183 "sentences," all field delimiters are commas. Of course, one option is to change all commas to something else, like semicolons or just spaces. Which I have done, and then afterwards replaced that delimiter with a proper comma.

Is there any way I could input the actual NMEA string as one variable, then in the next step split out each character? I didn't see anything about this limitation in the wiki.

Here is an example of a NMEA 0183 GLL sentence, from a GPS receiver (identified by GP), which provides geo position, UTC time, and "mode," always in ASCII:

$GPGLL,3953.88008971,N,10506.75318910,W,034138.00,A,D*7A

The last two characters, after the * character, are the XOR-based checksum, as two hex characters.

Some background: 
I'm working on some C code to read separate input from 2 or more USB mice plugged into the PC. That will be its own EXE file (unless it should be a DLL or something?), and when called, it looks for command line parameters. If no command line param is sent, it just returns the count of how many mice are connected to the system Else the command line parameter contains the index of the mouse to return input from, and it returns 2 numbers dx and dy, maybe just the two numbers separated by a comma, e.g. "{dx},{dy}".

I know the SHELL command can be used to call an external EXE from QB64, and theoretically you should be able to pipe the output of the EXE to a file, and read that from QB64. This is a very rudimentary method to get the two programs talking, and it seems like a very inefficient way to do it. Moreover, it doesn't seem to be working - the SHELL command in the test program doesn't seem to be redirecting the output correctly to a file, I am seeing a file not found error.

Would anyone have any ideas about a better way to do this, or even why the SHELL command isn't piping the output to a file?

Below is my QB64 program, followed by the external C program it is calling, which can be compiled to EXE using QB64 using included the batch file. (The attached ZIP has the precompiled EXEs and the source.)

Any help appreciated!

Attached Files

  qb64_talk_to_another_exe.zip (Size: 657.73 KB / Downloads: 29)