Here's a good game:

[SMcNeill]

What's wrong with this code?

Code: QB64: [Select]

1. $LET TOGGLE = FALSE
2.  
3.  
4.  
5. 'DEFLNG A-Z
6. SCREEN _NEWIMAGE(640, 480, 32) 'A default screen, the size specified.
7.  
8. P = _PIXELSIZE: IF P = 0 THEN P = 2 '0 is a designation for text screens, which use 2 bytes per character for memory storage
9. ScreenSize = _WIDTH * _HEIGHT * P
10. Frames = 48 'In our animation
11. UncompressedStringSize = Frames * ScreenSize 'the total size needed to store all the animation images, uncompressed (Should be about 48 MB)
12. UncompressedString$ = SPACE$(UncompressedStringSize) 'a placeholder for the whole animation, uncompressed.
13. SingleScreen$ = SPACE$(ScreenSize) 'a placeholder for a single screen worth of info
14.  
15. f = _LOADFONT("OLDENGL.TTF", 32)
16. IF f THEN _FONT f
17.  
18. DIM m AS _MEM
19. m = _MEMIMAGE(0)
20.  
21.  
22. $IF TOGGLE = TRUE THEN
23.     UncompressedString$ = ""
24. $END IF
25.  
26. FOR i = 1 TO 48 'let's draw a cheesy animation demo
27.     LOCATE 1, 400 - i * 8
28.     PRINT "Steve is Awesome."
29.     _MEMGET m, m.OFFSET, SingleScreen$ 'Get one screen of information
30.     $IF TOGGLE = TRUE THEN
31.         UncompressedString$ = UncompressedString$ + SingleScreen$
32.     $ELSE
33.         MID$(UncompressedString$, (i - 1) * ScreenSize + 1, ScreenSize) = SingleScreen$ 'And put it in the proper place for storage
34.     $END IF
35.     _LIMIT 10
36. NEXT
37.  
38.  
39. PRINT
40. PRINT "Press <ANY KEY> to view the cheesy animation."
41.  
42. SLEEP 'and now a pause so we can restore our animation
43.  
44. CLS
45. FOR i = 0 TO 47
46.     temp$ = ""
47.     temp$ = MID$(UncompressedString$, i * ScreenSize + 1, ScreenSize)
48.     _MEMPUT m, m.OFFSET, temp$
49.     _LIMIT 10
50. NEXT
51.  

Cobalt was wanting some advice on how to compress and store an animation in a single string over here: https://www.qb64.org/forum/index.php?topic=1444.msg106409#new

Working up a demo for him wasn't that much work, using the zlib libraries as the compression tool, but it did end up giving me one odd glitch which I can't explain at all.  Take a look at the code above and see if you can figure out what the BLEEP breaks it.

First, run it as is, and you'll see that it works as intended.  We capture the screen info 48 times, and save it into a single string, which we later use to help reproduce our cheesy animation.

Then, change the TOGGLE value to TRUE (first line of code), and run it again.  Notice how the results are completely different after the lucky 13th frame.

Now, what the BLEEP is broken???

****************************

When TOGGLE is FALSE (works), we preallocate the memory for the whole string and replace each screen of information manually.

When TOGGLE is TRUE (bugged), we start with a blank string and then simply add each new screen's data to that string.

The end result should end up with both methods generating the exact same string, but obviously something is different once we get around frame 14, or so.

So here's the game -- See if you can figure out WTH is wrong with the second method, and explain it to us.  First one to solve the mystery gets bragging rights and a highlighted "Best Answer" on this topic! 

Play now, and YOU can be a big wiener!!

[bplus]

What's wrong with this code?

Code: QB64: [Select]

1. $LET TOGGLE = FALSE
2.  
3.  
4.  
5. 'DEFLNG A-Z
6. SCREEN _NEWIMAGE(640, 480, 32) 'A default screen, the size specified.
7.  
8. P = _PIXELSIZE: IF P = 0 THEN P = 2 '0 is a designation for text screens, which use 2 bytes per character for memory storage
9. ScreenSize = _WIDTH * _HEIGHT * P
10. Frames = 48 'In our animation
11. UncompressedStringSize = Frames * ScreenSize 'the total size needed to store all the animation images, uncompressed (Should be about 48 MB)
12. UncompressedString$ = SPACE$(UncompressedStringSize) 'a placeholder for the whole animation, uncompressed.
13. SingleScreen$ = SPACE$(ScreenSize) 'a placeholder for a single screen worth of info
14.  
15. f = _LOADFONT("OLDENGL.TTF", 32)
16. IF f THEN _FONT f
17.  
18. DIM m AS _MEM
19. m = _MEMIMAGE(0)
20.  
21.  
22. $IF TOGGLE = TRUE THEN
23.     UncompressedString$ = ""
24. $END IF
25.  
26. FOR i = 1 TO 48 'let's draw a cheesy animation demo
27.     LOCATE 1, 400 - i * 8
28.     PRINT "Steve is Awesome."
29.     _MEMGET m, m.OFFSET, SingleScreen$ 'Get one screen of information
30.     $IF TOGGLE = TRUE THEN
31.         UncompressedString$ = UncompressedString$ + SingleScreen$
32.     $ELSE
33.         MID$(UncompressedString$, (i - 1) * ScreenSize + 1, ScreenSize) = SingleScreen$ 'And put it in the proper place for storage
34.     $END IF
35.     _LIMIT 10
36. NEXT
37.  
38.  
39. PRINT
40. PRINT "Press <ANY KEY> to view the cheesy animation."
41.  
42. SLEEP 'and now a pause so we can restore our animation
43.  
44. CLS
45. FOR i = 0 TO 47
46.     temp$ = ""
47.     temp$ = MID$(UncompressedString$, i * ScreenSize + 1, ScreenSize)
48.     _MEMPUT m, m.OFFSET, temp$
49.     _LIMIT 10
50. NEXT
51.  

Cobalt was wanting some advice on how to compress and store an animation in a single string over here: https://www.qb64.org/forum/index.php?topic=1444.msg106409#new

Working up a demo for him wasn't that much work, using the zlib libraries as the compression tool, but it did end up giving me one odd glitch which I can't explain at all.  Take a look at the code above and see if you can figure out what the BLEEP breaks it.

First, run it as is, and you'll see that it works as intended.  We capture the screen info 48 times, and save it into a single string, which we later use to help reproduce our cheesy animation.

Then, change the TOGGLE value to TRUE (first line of code), and run it again.  Notice how the results are completely different after the lucky 13th frame.

Now, what the BLEEP is broken???

****************************

When TOGGLE is FALSE (works), we preallocate the memory for the whole string and replace each screen of information manually.

When TOGGLE is TRUE (bugged), we start with a blank string and then simply add each new screen's data to that string.

The end result should end up with both methods generating the exact same string, but obviously something is different once we get around frame 14, or so.

So here's the game -- See if you can figure out WTH is wrong with the second method, and explain it to us.  First one to solve the mystery gets bragging rights and a highlighted "Best Answer" on this topic! 

Play now, and YOU can be a big wiener!!

I get a change of color when TRUE  i = 15

Now fixed by uncommenting DEFLNG A-Z, also added i display and commented out CLS and fixed a print line :D
TRUE works now same as FALSE

Code: QB64: [Select]

1. $LET TOGGLE = TRUE
2.  
3.  
4.  
5. DEFLNG A-Z
6. SCREEN _NEWIMAGE(640, 480, 32) 'A default screen, the size specified.
7.  
8. P = _PIXELSIZE: IF P = 0 THEN P = 2 '0 is a designation for text screens, which use 2 bytes per character for memory storage
9. ScreenSize = _WIDTH * _HEIGHT * P
10. Frames = 48 'In our animation
11. UncompressedStringSize = Frames * ScreenSize 'the total size needed to store all the animation images, uncompressed (Should be about 48 MB)
12. UncompressedString$ = SPACE$(UncompressedStringSize) 'a placeholder for the whole animation, uncompressed.
13. SingleScreen$ = SPACE$(ScreenSize) 'a placeholder for a single screen worth of info
14.  
15. f = _LOADFONT("OLDENGL.TTF", 32)
16. IF f THEN _FONT f
17.  
18. DIM m AS _MEM
19. m = _MEMIMAGE(0)
20.  
21.  
22. $IF TOGGLE = TRUE THEN
23.     UncompressedString$ = ""
24. $END IF
25.  
26. FOR i = 1 TO 48 'let's draw a cheesy animation demo
27.  
28.     LOCATE 1, 400 - i * 8
29.     PRINT "Mark is Awesome."
30.     _MEMGET m, m.OFFSET, SingleScreen$ 'Get one screen of information
31.     $IF TOGGLE = TRUE THEN
32.         UncompressedString$ = UncompressedString$ + SingleScreen$
33.     $ELSE
34.         MID$(UncompressedString$, (i - 1) * ScreenSize + 1, ScreenSize) = SingleScreen$ 'And put it in the proper place for storage
35.     $END IF
36.     _LIMIT 10
37. NEXT
38.  
39.  
40. PRINT
41. PRINT "Press <ANY KEY> to view the cheesy animation."
42.  
43. SLEEP 'and now a pause so we can restore our animation
44.  
45. 'CLS  < doesn't make a difference
46. FOR i = 0 TO 47
47.     LOCATE 5, 1: PRINT i: _DELAY .3
48.     temp$ = ""
49.     temp$ = MID$(UncompressedString$, i * ScreenSize + 1, ScreenSize)
50.     _MEMPUT m, m.OFFSET, temp$
51.     _LIMIT 10
52. NEXT
53.  

[SMcNeill]

Now fixed by uncommenting DEFLNG A-Z, also added i display and commented out CLS and fixed a print line :D

I noticed that using a DEFLNG made a difference (which is why I left it in there, remarked out as I did).  The question is, WHY the heck does it make a difference??

One method simply adds information to a string as we go along, the other simply modifies segments of a massive pre-allocated string as it does its stuff.

Why should a DEFLNG affect anything?  What's the glitch and why isn't my poor brain sorting this issue out for me??  :P

[SMcNeill]

Here's the glitch -- it's some sort of issue with the math giving different results.

Code: QB64: [Select]

1. ScreenSize& = 640 * 480 * 4
2. ScreenSize = 640 * 480 * 4
3.  
4. i& = 0: i = 0
5. DO UNTIL i& = 48
6.     value1&& = i& * ScreenSize& + 1
7.     value2&& = i * ScreenSize + 1
8.     PRINT i&; ")", value1&&, value2&&
9.     i& = i& + 1: i = i + 1
10.     IF i = 14 THEN BEEP
11.     SLEEP
12. LOOP
13.  

An integer times an integer plus one gives different results than a single times a single plus one -- even though all the values are integers and there's no overflow occurring anywhere!

/sigh

This is the type of glitch that a programmer spends FOREVER trying to track down and sort out, only to later realize -- much to their frustration -- that it's not something they're responsible for.  Math should be math, but sometimes apparently it's not! 

[bplus]

Remember the default is Single Precision and any math done with that leaves rounding errors specially division. So don't have nice clean integers that I suppose Memory Functions would expect. So .99999999999 becomes 0 if something is expecting an integer.

[SMcNeill]

Remember the default is Single Precision and any math done with that leaves rounding errors specially division. So don't have nice clean integers that I suppose Memory Functions would expect. So .99999999999 becomes 0 if something is expecting an integer.

I don’t think, in this case, that it’s a rounding error.  I think we’ve just exceeded the lower precision limits of a SINGLE here. 

After all, SINGLE, by its very nature, has inherent limitations.

1.2E+98 is a valid single number, but adding 1 to it an infinite number of times will never change it to become 1.3E+98.  We just simply don’t have the precision to track that minute increment with that size exponent — and I think that’s what the glitch is with the code above.  We’ve simply exceeded the precision limits of a single, so that +1 is lost and that throws the _MEM address off by that byte.

[bplus]

OK your precision theory seems to be confirmed with this test:

Code: QB64: [Select]

1. $LET TOGGLE = TRUE
2.  
3. _DEFINE A-Z AS DOUBLE  '<<< has more precision than single
4.  
5. 'DEFLNG A-Z
6. SCREEN _NEWIMAGE(640, 480, 32) 'A default screen, the size specified.
7.  
8. P = _PIXELSIZE: IF P = 0 THEN P = 2 '0 is a designation for text screens, which use 2 bytes per character for memory storage
9. ScreenSize = _WIDTH * _HEIGHT * P
10. Frames = 48 'In our animation
11. UncompressedStringSize = Frames * ScreenSize 'the total size needed to store all the animation images, uncompressed (Should be about 48 MB)
12. UncompressedString$ = SPACE$(UncompressedStringSize) 'a placeholder for the whole animation, uncompressed.
13. SingleScreen$ = SPACE$(ScreenSize) 'a placeholder for a single screen worth of info
14.  
15. f = _LOADFONT("OLDENGL.TTF", 32)
16. IF f THEN _FONT f
17.  
18. DIM m AS _MEM
19. m = _MEMIMAGE(0)
20.  
21.  
22. $IF TOGGLE = TRUE THEN
23.     UncompressedString$ = ""
24. $END IF
25.  
26. FOR i = 1 TO 48 'let's draw a cheesy animation demo
27.     LOCATE 1, 400 - i * 8
28.     PRINT "Steve is Awesome."
29.     _MEMGET m, m.OFFSET, SingleScreen$ 'Get one screen of information
30.     $IF TOGGLE = TRUE THEN
31.         UncompressedString$ = UncompressedString$ + SingleScreen$
32.     $ELSE
33.         MID$(UncompressedString$, (i - 1) * ScreenSize + 1, ScreenSize) = SingleScreen$ 'And put it in the proper place for storage
34.     $END IF
35.     _LIMIT 10
36. NEXT
37.  
38.  
39. PRINT
40. PRINT "Press <ANY KEY> to view the cheesy animation."
41.  
42. SLEEP 'and now a pause so we can restore our animation
43.  
44. CLS
45. FOR i = 0 TO 47
46.     temp$ = ""
47.     temp$ = MID$(UncompressedString$, i * ScreenSize + 1, ScreenSize)
48.     _MEMPUT m, m.OFFSET, temp$
49.     _LIMIT 10
50. NEXT
51.  

If it were an Integer versus Float problem it would still not work.

...and YOU can be a big wiener!!

  :D


Actually this is good lesson, that increments of 1 can be distinguished only to a certain point with Single type because of it's precision though it's range is so much greater.

Code: QB64: [Select]

1. WHILE i <> i + 1
2.     i = i + 1
3.     PRINT i
4. WEND
5. PRINT "Nope this is NOT an infinite loop! See where it stopped:"
6. print using "###,###,###.0000" ;i
7.  

[TempodiBasic]

Yes
I can affirm AWESOME!
Yes Steve is Awesome, but only if I change from OLDENGL.TTF to LUCON.TTF.

[TempodiBasic]

Bplus your mod has an error
now Mark is AWESOME and
OLDENGL.TTF doesn't work  in PC where it isn't.

[TempodiBasic]

I find more visible this:

Code: QB64: [Select]

1. PRINT "Nope this is NOT an infinite loop! See where it stopped:"
2. VIEW PRINT 2 TO 24
3. WHILE i <> i + 1
4.     i = i + 1
5.     PRINT i
6. WEND
7. PRINT USING "###,###,###.0000"; i
8.  
9.  

but about the issue
Single vs Long Integer , is the foundation  in the QB64 code (definition of type of data) or in C/C++ basis (definition of correspondent type of data in C/C++)?