Phoenix Edition v3.1 released!

[SMcNeill]

An update that I'm happy to announce, with lots of changes for people to enjoy -- version 3.1 has been released!

https://github.com/QB64-Phoenix-Edition/...tag/v3.1.0 See GitHub link for full release notes. 

Enhancements
 - New audio backend using miniaudio
- Miniaudio and a few other libraries have replaced the OpenAL-based audio backend that was previously used. - This fixes licensing concerns with using OpenAL, which was LGPL licensed. - Newly supported formats include flac, mod, s3m, xm, it, rad
. - Image backend enhancements - Support for pcx images was added.
 - _LOADIMAGE was improved to support loading 256-color images.
 - Add _ROR & _ROL support. 

Bug Fixes
  - Use -no-pie on Linux, fixes running compiled executables from file browsers
  - Remove DPI Awareness on Windows, QB64 executables will properly scale based on the OS setting 


Full Changelog: https://github.com/QB64-Phoenix-Edition/...0...v3.1.0

So what's this mean for you guys, as our users?  

For starters, the image library was more or less replaced completely.  We now offer support for both PCX images and 256 color images with _LOADIMAGE.  Even more importantly, as far as most of you guys are concerned, I'm certain:  We now load images much faster than previously!  "How much faster", you ask?  That depends on the image type in particular, but I imagine nearly every type should see somewhere between a 20% - 50% reduction in load times.

We offer more image formats, and we load them faster than ever!  What's not to love about that??

On top of this change, the sound libraries were replaced and redone.  We no longer link to the evil library which required a LGPL License when in use.  You can now use sound and enjoy a more more lenient license.  (Read the license file for a fell breakdown and detail of everything, please.)  We've also expanded formats which we support with our sound library, and we should have corrected the issue with stereo sound only coming from a single monochannel speaker.

Linux users should no longer have the issues of QB64 programs not running if they click on them in the file explorer.

Windows users should no longer have issues with windows not scaling to match DPI Awareness settings on high resolution screens.

Everyone should now be able to enjoy the new _ROR and _ROL, which are used for bit rotation right and left.  (Rotate Right = RoR, Rotate Left = RoL).

Download can be grabbed from here: Release v3.1.0 · QB64-Phoenix-Edition/QB64pe (github.com)

[SMcNeill]

A quick screenshot of loading times with PNG images between the new version 3.1 and the old version 0.8.2 (which was what I had handy for testing, but still the same internals as 3.0)..

For 100 loads of a massive 3000x2229 PNG image:
v3.1 took 19.2 seconds.
v0.8 took 28.7 seconds.

That's an improvement of what?  Cut off about 1/3rd of the time to load the file 100 times, so that seems like a rather nice improvement on my machine!

---

For BMP files, this is the times I see for a 2560x1920 image:
V3.1 took 6.4 seconds.
V0.8 took 14.8 seconds.

Less than half the time to load BMP images with the new version under the hood.

[bplus]

Wow nice list of improvements. What is difference between shift left / right and rotate left /right?

[OldMoses]

Wow nice list of improvements. What is difference between shift left / right and rotate left /right?

shifts will drop bits from the end shifted toward. Rotate will carry those bits around to the opposite end.

[Stuart]

The new version is looking good; I haven't found any errors but it does seem to run noticeably slower (approx. 5% slower) than the previous version I was using (v0.8.2).

The speed is slower no matter which compiler options are specified for each version as long as the options are the same.

I personally find -Os to be faster than -O2 or -O3. 
From what I have read, -Os is basically the same as -O2 except that -Os also reduces the code size a little more.


The program I've tested is mainly math and string comparison/manipulation in SCREEN 0 -- no loading of graphics files...

Has anyone else tried a benchmark program to test for speed differences between v0.8.2 and v3.1.0 ??


More Info :  I'm using the 32 bit version of QB64pe on Windows Vista SP2.
Also,
The size of the .exe generated by v0.8.2 is 2165 KB.
The size of the .exe generated by v3.1.0 is 2243 KB.

[Coolman]

miniaudio seems to be statically linked to the executable. i tested with a code. the size of the program generated by version 3.0.0 is about 2,8 mo while the one generated by version 3.1.0 is about 3.1 mo. that said the executable won't have any dependency on it. that's good. thank you for integrating the -no-pie option. the other additions and modifications seem interesting. great job.

[bplus]

Wow nice list of improvements. What is difference between shift left / right and rotate left /right?

shifts will drop bits from the end shifted toward. Rotate will carry those bits around to the opposite end.

Thanks, OK left and right shifts mult or divide by 2, what does rotate do?

[SMcNeill]

Wow nice list of improvements. What is difference between shift left / right and rotate left /right?

shifts will drop bits from the end shifted toward. Rotate will carry those bits around to the opposite end.

Thanks, OK left and right shifts mult or divide by 2, what does rotate do?

It rotates the bits left or right in a circle.

For example, let's say my bits are &B10000001.

Rotate left once:
00000011   <-- see the 1 on the far left is now on the far right?  We rotated them in a circle.

Rotate left once:
00000110   <-- everything went to the left, with the last 0 being moved over to the right.


Think of it as a game map...  

SHL says you walk the hero left, until they fall off the edge of the map and die.

_ROL says you walk the hero left, until they suddenly walk off the edge and reappear on the right side of the map.

[Stuart]

miniaudio seems to be statically linked to the executable. i tested with a code. the size of the program generated by version 3.0.0 is about 2,8 mo while the one generated by version 3.1.0 is about 3.1 mo. that said the executable won't have any dependency on it. that's good. thank you for integrating the -no-pie option. the other additions and modifications seem interesting. great job.

I didn't test with v3.0.0, but the "old audio backend (LPGL)" wasn't changed until v3.1.0; and I can verify that it's what's slowing me down because when I choose to use the older, original backend I regain the lost 5% of time.  It might even be a fraction of a percent faster.

When the option to "Use the old audio backend (LPGL)" is turned on in the Compiler Options the .exe size is now 2168 KB which is 65 KB smaller than when the new backend for audio is used (but it's still 3KB larger than the 0.8.2 version -- which is probably due to the other fixes and enhancements).

I hope that this slow down can be fixed somehow because the program I have uses very short sounds for sound events, but if it ends up costing me 5% of speed loss then the sounds will have to go and not even be available as an option...

Thanks a lot for your response @Coolman -- it did lead me in the right direction of what to check for next.

[DSMan195276]

I hope that this slow down can be fixed somehow because the program I have uses very short sounds for sound events, but if it ends up costing me 5% of speed loss then the sounds will have to go and not even be available as an option...

Would you be able to give examples of the code that you find to be slower? I'm mostly interested in things like what you do with the sound handles and such. If we can pinpoint what exactly is slower then we could look at making some optimizations to those areas.