Pi-in-the-Sky Graphics Demonstration Program (with 3D)

[johnno56]

Well, I loaded all the images into Gimp, and found that all the images were assigned to the same colour profile. "RGB workspace". Which means that the "missing images", in QB64 1.4, are probably not caused by the images themselves. Sorry I couldn't be more helpful...

J

[bplus]

Yeah the windmill load is working fine all the way through this:

Code: QB64: [Select]

1. _TITLE "checkImageLoad& test" 'b+ 2020-04-10   in Pi-In-The-Sky folder
2.  
3. CONST xmax = 800, ymax = 600
4. CONST WindX% = 550, WindY% = ymax - 294, WindHeight% = 280
5. SCREEN _NEWIMAGE(xmax, ymax, 32)
6.  
7. tempImg& = checkImageLoad&("windmill.png")
8. 'PRINT windmill&
9.  
10. 'tempImg& = _LOADIMAGE("windmill.png", 32) 'Windmill must not occlude flowers or be occluded by spotlight beam
11. DIM CMem AS _MEM
12. CMem = _MEMIMAGE(tempImg&)
13. WHILE COff < CMem.SIZE
14.     IF _MEMGET(CMem, CMem.OFFSET + COff + 3, _UNSIGNED _BYTE) < 230 THEN _MEMPUT CMem, CMem.OFFSET + COff + 3, 0 AS _UNSIGNED _BYTE 'Alpha
15.     COff = COff + 4
16. WEND
17. _MEMFREE CMem
18. _PUTIMAGE (WindX%, WindY%)-(WindX% + CINT(WindHeight% * _WIDTH(tempImg&) / _HEIGHT(tempImg&)), WindY% + WindHeight%), tempImg&
19. _FREEIMAGE tempImg&
20.  
21.  
22. 'this function shuts down a program if an image file isn't loaded
23. FUNCTION checkImageLoad& (file$)
24.     IF _FILEEXISTS(file$) THEN
25.         hdl& = _LOADIMAGE(file$)
26.         IF hdl& = -1 THEN CLS: PRINT file$ + " can't be loaded.": SLEEP: END ELSE checkImageLoad& = hdl&
27.     ELSE
28.         CLS: PRINT file$ + " does nor exist.": SLEEP: END
29.     END IF
30. END FUNCTION
31.  
32.  

Something must be getting lost after the _PUTIMAGE, this is just before the start of the main loop.

[Qwerkey]

The oddity of the v1.4 image display errors is even stranger than we may have thought.  Compare the two images of Pi-in-the-Sky where the spotlight and beam are displayed.  Not only are the beehive and windmill missing, but the spotlight is in the wrong place.  Remember that there is nothing different in the code, only the version of QB64.

 

 

The position of the spotlight is set by two constants LampX% & LampY% which end up with incorrect values in v1.4.

The code (same in both versions) to set CONST values is from lines as follows:

Code: QB64: [Select]

1. CONST False = 0, True = NOT False, XScreen% = 1100, YScreen% = 800, ZOffset% = -620, PiConst! = 4 * ATN(1)
2. CONST PiSizeLess1% = 499, PiDisp% = 100, SunSize%% = 500, AmblinHalf%% = 50
3. CONST Zeta! = 0.07 * PiConst!, RBee% = 120, CBee% = 80, ABee! = -4 * CBee% / (RBee% * RBee%)
4. CONST BeeEntX% = -350, BeeEntY% = -250, HiveWidth% = 1009, HiveHeight% = 589, BWidth% = 350, HX1% = 0 - 50 - (XScreen% / 2)
5. CONST HY1% = 300 - (YScreen% / 2), HX2% = HX1% + BWidth%, HY3% = HY1% - (BWidth% * HiveHeight% / HiveWidth%)
6. CONST FountX% = -128, FountY% = -230, G! = 0.01, ZBow% = ZOffset% + 100
7. CONST ZodHeight% = 70, ZodWidth% = ZodHeight% * 300 / 240, ZRad! = 12 * ZodWidth% / (2 * PiConst!) 'Can't use CINT() here
8. CONST SpotRad% = 80, SpotInc! = 2 * PiConst! / 100, LampX% = XScreen% - 50, LampY% = YScreen% - 220
9. CONST QB64X% = 300, QB64Y% = 50, UFOHalfX% = 150, UFOHalfY% = 60, UFORad% = 700
10. CONST Iota! = -0.23 * PiConst!, Wind% = 150, WindX% = 550, WindY% = YScreen% - 294, WindHeight% = 280
11. CONST MillBombX1% = WindX% + 17, MillBombY1% = WindY% + 8, SailX% = 44, SailY% = -154

LampX% & LampY% are set from the Screen dimesions, constants XScreen%&, YScreen% as:
CONST LampX% = XScreen% - 50, LampY% = YScreen% - 220

In v1.4 LampX% has value 1100: should be 1050.  LampY% has value 800: should be 580.
What is happening is that they get values XScreen% and YScreen% respectively.  The program forgets to take off the given values.

This must be some bug in v1.4?

I will continue to hunt down the differences for the beehive and windmill errors.

[Petr]

That's a really very nice program!

[Qwerkey]

Well, I'll be jiggered!  The v1.4 imaging problems are entirely due to CONST errors - I already mentioned the Spotlight position error.  The table gives  v1.3 and 1.4 values of the program CONST variables.  Where a calculation is involved, v1.4 sometimes gives incorrect values (a selection of CONSTs is given):

CONST Name    V1.3 Value         V1.4 Value         Difference
False                0                       0                      0
True                 -1                     -1                      0 (True & False are OK!)
XScreen%        1100                 1100                  0
YScreen%        800                   800                    0
HX1%              -600                 -600                   0
HY1%              -100                 -100                   0
HX2%              -250                 -250                   0
HY3%              -304                  -100                  -204
LampX%          1050                 1100                 -50
LampY%          580                   800                   -220
Iota!                -0.7225663       -0.7225664        0.0000001 (just rounding error)
Wind%            150                   150                    0
WindX%           550                   550                   0
WindY%           506                   800                   -294
WindHeight%   280                   280                    0
MillBombX1%   567                   567                    0
MillBombY1%   514                   808                    -294

The CONST variables HY3%, LampX%, LampY%, WindY% & MillBombY1% (all involved in position values for the affected images) are not calculated correctly in v1.4.

This is by no means the first time that I've run into problems with CONST.  I would be grateful if someone of skill would check to see if I have been doing something wrong - please check the code given in the Code Box of Reply #17.  I believe that I have not broken any CONST rules.  v1.4 work perfectly if the affected CONSTs are changed to standard variables.

At least there is only 1 problem to be solved.

[STxAxTIC]

I haven't had opportunity to spit this controversial opinion lately but now's as good as any:

F-o-c-k CONST.

CONST may as well be a DATA statement. We have variables, we know how to use them. That system is constantly checked for error and has been proven to be quite stable.

Here on the other hand we have CONST, with a completely different math subsystem, and has been nothing but trouble for years.

I say we lock CONST at the QB45 standard and never look back. Good thing I'm not a dev though, as this would probably step on some sensitivities out there.

Oh and I can see the responses coming, mostly on Discord, so let me just say this early and here - Just because something is sometimes useful, is NOT an argument. (This is the logic of mentally-ill hoarders.) All the stuff CONST does is redundant to our other tools and should be nerfed down to something that behaves without error.

[Qwerkey]

Well, I have learnt a new verb at any rate:

nerf; verb - informal US
verb: nerf; 3rd person present: nerfs; past tense: nerfed; past participle: nerfing; gerund or present participle: nerfing

    cause to be weak or ineffective.

And we have also learnt its gerund!

[Qwerkey]

... we have CONST, with a completely different math subsystem, and has been nothing but trouble for years.

A completely different math subsystem.  Really?  I like CONST, but I've always assumed that a CONST is exactly like a standard variable except that you can't change its value.  Does it need to be more complicated that that?  Again, I seem to have been using something about which I know nothing.

[luke]

A completely different math subsystem.  Really?  I like CONST, but I've always assumed that a CONST is exactly like a standard variable except that you can't change its value.  Does it need to be more complicated that that?  Again, I seem to have been using something about which I know nothing.

It basically has its own parser in the compiler that evaluates expressions entirely independently of regular maths, and has caused no end of annoyances.

[Qwerkey]

It basically has its own parser in the compiler that evaluates expressions entirely independently of regular maths, and has caused no end of annoyances.

What am I saying???  A CONST can't be exactly like a standard variable as it has keep its value in all SUBs and FUNCTIONs.  One of these days, I'm sure that Fellippe will bar me from the site for stupidity!

[FellippeHeitor]

While ripping off Steve's system doesn't become consensus, could you tell me if using one line for each const (instead of a sequence of comma-separated consts) fixes it?

With v1.4 we did add Steve's upgraded const evaluator, and those issues seemed to have been fixed, but we hadn't stress-tested it as you have with your code, @Qwerkey

Please let me know.

[Qwerkey]

OK.  I'll do them one line at a time and let you know.

[SMcNeill]

I'd thought 1.4 had corrected the CONST issues -- it certainly simplified the internal processes -- and I'd love to dig extensively into the root of the issue, but my bleeping PC is still down.   I called a guy last Friday about ordering a new powersupply and fixing it, and haven't heard squat back yet on it because of -- you know -- the coronavirus!!  Shipping takes forever.  Nobody is working.  At this rate, I may be back up and running by Christmas!!

If so, I'll try and take a look into the internals sometime before New Years.   /sigh

[Qwerkey]

I tried the code with one CONST statement per line.  Still the same problem, so it's not the commas on the CONST statement line which are the problem.

[FellippeHeitor]

That already steers us in a more accurate direction. Thanks for that.