+- QB64 Phoenix Edition (https://staging.qb64phoenix.com)
+-- Forum: Official Links (https://staging.qb64phoenix.com/forumdisplay.php?fid=16)
+--- Forum: Announcements (https://staging.qb64phoenix.com/forumdisplay.php?fid=18)
+--- Thread: Phoenix Edition v3.1 released! (/showthread.php?tid=849)
RE: Phoenix Edition v3.1 released! - Kernelpanic - 09-06-2022
(09-05-2022, 11:25 PM)SMcNeill Wrote:(09-05-2022, 07:23 PM)Kernelpanic Wrote: 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.
RE: Phoenix Edition v3.1 released! - SMcNeill - 09-06-2022
(09-06-2022, 08:35 PM)Kernelpanic Wrote:(09-05-2022, 11:25 PM)SMcNeill Wrote:(09-05-2022, 07:23 PM)Kernelpanic Wrote: 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.
RE: Phoenix Edition v3.1 released! - Gets - 09-07-2022
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.
RE: Phoenix Edition v3.1 released! - mnrvovrfc - 09-08-2022
(09-05-2022, 07:23 PM)Kernelpanic Wrote: 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
Input "a: ", a
Input "b: ", b
'Verschiebt 1 Bit nach rechts. Entspricht: Zahl / 2
a = _RoR(a, 1)
Print a
'Verschiebt nach links. Entspricht: Zahl * 2
b = _RoL(b, 1)
Print b
'Vierfach des letzten Wertes (b X 4)
b = _RoL(b, 2)
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
systemRE: Phoenix Edition v3.1 released! - Stuart - 09-08-2022
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.
RE: Phoenix Edition v3.1 released! - a740g - 09-10-2022
(09-08-2022, 10:01 AM)Stuart Wrote: 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.
RE: Phoenix Edition v3.1 released! - Stuart - 09-10-2022
(09-10-2022, 07:10 PM)a740g Wrote:(09-08-2022, 10:01 AM)Stuart Wrote: 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.