LoginLogin

Dynamic multidimensional arrays

Root / Programming Questions / [.]

glennxsergeCreated:
SquareFingers#21
Yes, the scan for variable names can be thought of as a preprocessing stage. At the same time, all the DEF names are collected, and their parameters. There are many steps in the path between compiled and interpreted, it is not just one step with every language clearly on one side or the other. One thing I do know is that code is not executed directly from the 'slots'. If you type in the following code into slot 0, for instance: 
VAR Z=0
LOAD "PRG0:some program"
PRINT 1/Z
you will get Divide by zero in 0:3, and LIST ERR will bring you to line 3 of the current contents of slot 0 - which likely does not have a divide-by-zero error.
NeatNit#22
Doesn't RGB lose some of the data though The manual says something about using 5 bits per RGB value and 1 bit for alpha, but I haven't figured out where it was done - in the RGB function or the drawing function Insert question marks above where applicable, my phone is not having a good week.
glennxserge#23
Doesn't RGB lose some of the data though The manual says something about using 5 bits per RGB value and 1 bit for alpha, but I haven't figured out where it was done - in the RGB function or the drawing function Insert question marks above where applicable, my phone is not having a good week.
I see that the FONTDEF lists RGB as 5551 this is under console mode, but under the Graphics portion of the manual, RGB is specified as: RGB([transparency], r, g, b) and each element is 8 bits. So the color value stored is 32bit.
Avery#24
Data is lost when it is written and read from the graphics screen. RGB() itself allows all numbers between 0-255. The graphics screen is 5551, so transparency is on or off, without any "in between", and the color space is pretty much 0-31. You can see that the RGB() function doesn't do this by looking at the FADE command. You can specify a 0-255 transparency with RGB() in FADE. Also, it's easy to test. 
WHILE 1
A1=RND(256)
R1=RND(256)
G1=RND(256)
B1=RND(256)
C=RGB(A1,R1,G1,B1)
RGBREAD C OUT A2,R2,G2,B2
IF A1!=A2 THEN ?"X
IF R1!=R2 THEN ?"X
IF G1!=G2 THEN ?"X
IF B1!=B2 THEN ?"X
WEND
It generates four numbers between 0-255 and combines them into the C variable via RGB(), then separates them with RGBREAD. If any input and output number is unequal, an "X" is written on the graphics screen. To me it only displays X when I go above 255, which I expect. Hope this was helpful in understanding.
glennxserge#25
Thanks for the clarification, Coleslaw. Does this mean that what's seen by the user only represents the lower fidelity color, 0-31 (32,768 colors as opposed to 16,777,216)? Also, where do you find this kind of info? I didn't see it in any of the documentation. There's been a few moments in this thread already, where what seems like very esoteric information pops up from people like you and SquareFingers, and I'm itching to figure out where I can read up on it.
snail_#26
Yep, the actual graphics system is 15-bit color internally, even though it's represented logically as 32-bit to the user. This is why you aren't allowed to use transparency levels on a GRP.
pirate#27
Doesn't RGB lose some of the data though The manual says something about using 5 bits per RGB value and 1 bit for alpha, but I haven't figured out where it was done - in the RGB function or the drawing function Insert question marks above where applicable, my phone is not having a good week.
The graphics are displayed as 32bit but GRP files are always saved as RGBA5551.
SquareFingers#28
Also, where do you find this kind of info? I didn't see it in any of the documentation. There's been a few moments in this thread already, where what seems like very esoteric information pops up from people like you and SquareFingers, and I'm itching to figure out where I can read up on it.
That's what's frustrating - it's not in the documentation. There is no place to read up on it. And there should be. There are people on the planet who know, and are sure of, all these tidbits of esoteric information about the ways SmileBasic is - the people who made those ways. This information is certain, in some people's heads. It is possible that it could be certain for anyone who wishes to know - if the doc team did their job. But, for us to learn these esoterics, we have to explore, guess - and be lucky. Luck is a fine aspect to include for playing a game. For using a tool - not.
pirate#29
But, for us to learn these esoterics, we have to explore, guess - and be lucky
Poor documentation is the cornerstone of the smilebasic programming course. Now you're thinking with portals
12