Phoenix Edition v3.1 released!

[Kernelpanic]

Good job again! Nullo problemo!

The bit rotations are similar to the shift operators, where is the concrete difference?

Rotate vs Shift (qb64phoenix.com) -- See if this helps explain the difference. 

Very well explained! And graphically too! 
It was already clear to me that ROR/ROL works like a kind of endless chain - but both shift and rotate of them should work the same way up to the end of the chain, right?

It's still easy with 8 bits, but what about 64 bits? A normal computer can no longer reach this limit, unless I can set this limit. So, eight bits is the limit. Anything beyond that will crash or disappear in a game.

[SMcNeill]

Good job again! Nullo problemo!

The bit rotations are similar to the shift operators, where is the concrete difference?

Rotate vs Shift (qb64phoenix.com) -- See if this helps explain the difference. 

Very well explained! And graphically too! 
It was already clear to me that ROR/ROL works like a kind of endless chain - but both shift and rotate of them should work the same way up to the end of the chain, right?

It's still easy with 8 bits, but what about 64 bits? A normal computer can no longer reach this limit, unless I can set this limit. So, eight bits is the limit. Anything beyond that will crash or disappear in a game.

8 bits is an _UNSIGNED _BYTE.
16 bits is an _UNSIGNED INTEGER.
32 bits is an _UNSIGNED LONG.
64 bits is an _UNSIGNED _INTEGER64.

Just set your variable type to an unsigned int64, and you can shift or rotate 64 bits freely as you want. 

[Gets]

I was able to make enough changes to my old programs to get them running. Overall performance seems to have improved enough for some things I wrote off as impossible to move into the realm of viability. and the new audio engine means I can abandon the horrible system I cobbled together out of the winmm library.

A couple of things I noticed with the sound is that SNDBAL doesn't appear to work(no sound change with wiki example), and that SNDPLAYCOPY doesn't appear to copy volume settings like it seemed to previously.

[mnrvovrfc]

Good job again! Nullo problemo!

The bit rotations are similar to the shift operators, where is the concrete difference?

Code: (Select All)

'Uebung mit Bitrotation - 5. Sept. 2022
'Aehnelt den Schiebeoperatoren

Dim As Long a, b

Print
Input "a: ", a
Input "b: ", b

'Verschiebt 1 Bit nach rechts. Entspricht: Zahl / 2
a = _RoR(a, 1)
Print
Print a

'Verschiebt nach links. Entspricht: Zahl * 2
b = _RoL(b, 1)
Print
Print b

'Vierfach des letzten Wertes (b X 4)
b = _RoL(b, 2)
Print
Print b

End

^
|
Try rewriting this program so it uses "_BIN$()", with zero-padding at front so you could see better what's going on. Do at least 32 interations and one bit at a time for an _INTEGER64.

Or otherwise:

Code: (Select All)

$console:only
dim c as _unsigned _integer64
dim as string see, zer
dim i as integer
zer = string$(64, 48)
c = 9223372036854775810
print c
for i = 1 to 65
    see = _bin$(c)
    see = "&B" + left$(zer, 64 - len(see)) + see
    print see
    c = _ROL(c, 1)
next
system

[Stuart]

I ran into a problem with sound files not being played as expected and found this to be the problem : 

The old audio backend would return 0 if the sound couldn't be loaded.
The new audio backend will return -1 if the sound can't be loaded.

This wouldn't be a major problem since the check for a valid handle could simply be changed to "IF h& > 0 THEN _SNDPLAY h&" -- however, any programs that were written with the previous (shorter) syntax of "IF h& THEN..." won't work like they used to.

It might be a good idea to make the new audio backend _also_ return a 0 instead of -1.


Also, in the Help File and/or Wiki : 

under _SNDOPEN it says "Returns a LONG soundHandle& value to the sound file in memory. A value less than one means the sound could not be loaded".  (This could mean 0 _or_ -1.)
Later it says "Always check the handle value returned is greater than zero before attempting to play the sound".

under _SNDPLAY it says "Make sure that the handle& value is not 0 before attempting to play it."
In the example code for checking a handle before playing is :  "IF h& THEN _SNDPLAY h&"

This would need to be edited if an invalid handle returns -1 instead of 0.

[a740g]

I ran into a problem with sound files not being played as expected and found this to be the problem : 

The old audio backend would return 0 if the sound couldn't be loaded.
The new audio backend will return -1 if the sound can't be loaded.

This wouldn't be a major problem since the check for a valid handle could simply be changed to "IF h& > 0 THEN _SNDPLAY h&" -- however, any programs that were written with the previous (shorter) syntax of "IF h& THEN..." won't work like they used to.

It might be a good idea to make the new audio backend _also_ return a 0 instead of -1.


Also, in the Help File and/or Wiki : 

under _SNDOPEN it says "Returns a LONG soundHandle& value to the sound file in memory. A value less than one means the sound could not be loaded".  (This could mean 0 _or_ -1.)
Later it says "Always check the handle value returned is greater than zero before attempting to play the sound".

under _SNDPLAY it says "Make sure that the handle& value is not 0 before attempting to play it."
In the example code for checking a handle before playing is :  "IF h& THEN _SNDPLAY h&"

This would need to be edited if an invalid handle returns -1 instead of 0.

Thank you for checking and reporting. This issue has been corrected in the latest QB64-PE commits. The next release of QB64-PE will include these fixes. The Wiki too will be updated and fixed soon.

[Stuart]

I ran into a problem with sound files not being played as expected and found this to be the problem : 

The old audio backend would return 0 if the sound couldn't be loaded.
The new audio backend will return -1 if the sound can't be loaded.

This wouldn't be a major problem since the check for a valid handle could simply be changed to "IF h& > 0 THEN _SNDPLAY h&" -- however, any programs that were written with the previous (shorter) syntax of "IF h& THEN..." won't work like they used to.

It might be a good idea to make the new audio backend _also_ return a 0 instead of -1.


Also, in the Help File and/or Wiki : 

under _SNDOPEN it says "Returns a LONG soundHandle& value to the sound file in memory. A value less than one means the sound could not be loaded".  (This could mean 0 _or_ -1.)
Later it says "Always check the handle value returned is greater than zero before attempting to play the sound".

under _SNDPLAY it says "Make sure that the handle& value is not 0 before attempting to play it."
In the example code for checking a handle before playing is :  "IF h& THEN _SNDPLAY h&"

This would need to be edited if an invalid handle returns -1 instead of 0.

Thank you for checking and reporting. This issue has been corrected in the latest QB64-PE commits. The next release of QB64-PE will include these fixes. The Wiki too will be updated and fixed soon.

You're welcome, and thanks for checking into it and letting me know the result/outcome @a740g.