LoginLogin

Def codes for making codes

Root / General / [.]

randoCreated:
i know there has to be a way to create faster graphics(like a custom GPU). How come none of us compile our knowledge into the same project?
I've thought of this before. SmileBASIC is pretty limiting in speed. The graphics they give us are the fastest we're going to get.

https://www.youtube.com/watch?v=oHC1230OpOg maybe there is a way. Make an array:
DIM SCREEN[400,239]
'And then use it to store all
'for a line:
DEF LINE X,Y,X2,Y2
VAR X,Y
 WHILE 1
  X = 
 WEND

that would be a lot slower. Graphics in SB are already pretty fast anyway.

We're in a sandbox. We don't have direct memory management or addressing of the GPU so it's actually impossible. The graphics primitives we have are all we are given and we can't do anything better.

We're in a sandbox. We don't have direct memory management or addressing of the GPU so it's actually impossible. The graphics primitives we have are all we are given and we can't do anything better.
Except with hacks but what we have should be fine.

'JOIN AN ARRAY OF STRINGS TOGETHER
'STRING_ARRAY, DELIMITER
DEF JOIN$(S$,D$)
 IF !LEN(S$) THEN RETURN ""
 IF LEN(S$)==1 THEN RETURN S$[0]
 RETURN JOIN$(S$,D$)+D$+POP(S$)
END
Holy crap, that is a kind of recursion I never thought of before. Never even imagined it.

I just played some Fortnite(which uses UE4) and I noticed something: when you are far away from an object, the resolution is really low. Also, the triangle count in an object decreases. Maybe Simeon can (somehow) implement this in SIM.3D...

I just played some Fortnite(which uses UE4) and I noticed something: when you are far away from an object, the resolution is really low. Also, the triangle count in an object decreases. Maybe Simeon can (somehow) implement this in SIM.3D...
I think that's called mipmapping but I'm not sure...

I believe mipmapping only refers to reducing the resolution/detail of textures when they're far away, but why are you talking about this in this thread?

I just played some Fortnite(which uses UE4) and I noticed something: when you are far away from an object, the resolution is really low. Also, the triangle count in an object decreases. Maybe Simeon can (somehow) implement this in SIM.3D...
I think that's called mipmapping but I'm not sure...
That's called Level of Detail or LOD.

I believe mipmapping only refers to reducing the resolution/detail of textures when they're far away, but why are you talking about this in this thread?
It can become more relevant if someone posted DEFs for those. That is, if they'll take the time.

BDIALOG - Show a dialog box and wait for a button press. But that function already exists! It does, but it's terrible. The return values hardly make sense and you can only specify certain sets of buttons you want to accept (and the format is annoying too.) I figured I'd try to tame this function a bit.
pressed% = BDIALOG(message$, buttons%, title$, time%)

message$  '  Dialog box body text.
buttons%  '  Buttons you want to accept.
caption$  '  Dialog box title.
   time%  '  Time (seconds) until dialog closes (0 or FALSE to disable.)

pressed%  '  The button pressed by the user, or 0 if timed-out.
Some examples to help demonstrate the purpose of this function:
PRESS%=BDIALOG("PRESS A QUICKLY!",#A,"HURRY HURRY",1)
CHOICE%=BDIALOG("A for Game A, B for Game B?",#A OR #B,"Mode Select",FALSE)
Note that this is a user DEF so there are no optional arguments like the built-in DIALOG forms; you have to specify every value. Function Code
DEF BDIALOG(TEXT$,BTN%,TITLE$,TIME%)
 VAR BIT%,RES%
 
 'prepare button type bitmask
 IF BTN% AND &B0011110000 THEN INC BIT%,1
 IF BTN% AND &B0000001111 THEN INC BIT%,2
 IF BTN% AND &B1100000000 THEN INC BIT%,4
 BIT%=-BIT%
 IF !BIT% THEN RETURN 0  'exit if no valid choices
 
 REPEAT
  RES%=DIALOG(TEXT$,BIT%,TITLE$,TIME%)
  IF !RES% THEN
   'timed out
   RETURN 0
  ELSE
   'convert output into the
   'corresponding button bit
   RES%=1<<RES%-128
   IF RES% AND &B00001111 THEN
    RES%=RES%<<4
   ELSEIF RES% AND &B11110000 THEN
    RES%=RES%>>4
   ENDIF
   'return if the button pressed is acceptable
   RES%=RES% AND BTN%
   IF RES% THEN RETURN RES%
  ENDIF
 UNTIL FALSE  'forever/until we RETURN from this function
END
This function could be especially useful if wired up to a dialog menu builder or something like that. Just a building block for something more interesting. Note that you will get dialog flicker on some wrong/unaccepted presses. That's because the DIALOG built-in it's based on is bad.

This thread has got me thinking. We should have a thread like this (perhaps this very thread) where a user *asks* for a certain function and the community puts forth their methods and such. Then, all the solutions come together and fight to the death over their conciseness and feasibility. I've pulled a lot of useful stuff off this thread. Hell, it was quite like having a birthday; just getting a bunch of stuff I didn't know I wanted. I've thus integrated them into my own library, though there were times during my own coding endeavors when I needed a certain function and spent literally hours designing and debugging it. Some of those functions I've found here, too, like Simeon's string manipulation functions (actually, a great example). I'm aware that such a thread could defeat the purpose of having the user "learn for themselves," rather than being spoon fed the code and not know how or why it works. I believe our Programming Questions category has such a moral compass to it. Despite it, I think it would be less than harmful. Given the problem (desired function), people pool their knowledge to solve the problem, and we all walk away a little smarter.

Why don't you make the thread then?

This thread has got me thinking. We should have a thread like this (perhaps this very thread) where a user *asks* for a certain function and the community puts forth their methods and such. Then, all the solutions come together and fight to the death over their conciseness and feasibility. I've pulled a lot of useful stuff off this thread. Hell, it was quite like having a birthday; just getting a bunch of stuff I didn't know I wanted. I've thus integrated them into my own library, though there were times during my own coding endeavors when I needed a certain function and spent literally hours designing and debugging it. Some of those functions I've found here, too, like Simeon's string manipulation functions (actually, a great example). I'm aware that such a thread could defeat the purpose of having the user "learn for themselves," rather than being spoon fed the code and not know how or why it works. I believe our Programming Questions category has such a moral compass to it. Despite it, I think it would be less than harmful. Given the problem (desired function), people pool their knowledge to solve the problem, and we all walk away a little smarter.
we can use this thread for that if you like.

Why don't you make the thread then?
I would've, but I don't quite have any need to atm. I just put the idea of it out there to hear what response I'd get, and in the case someone else agrees and has something they'd like to figure out, they may start the thread.

I didn't realize SmileBASIC actually uses saturating math when going from floats to integers, so it was more difficult than expected, but I managed to improve the above functions a bit:
VAR I32=2147483648
VAR U32=4294967296

DEF BOUND(N)
 RETURN N-FLOOR((N+I32)/U32)*U32
END

DEF U_RSHIFT(A,B)
 A=BOUND(A)
 RETURN A>>B AND NOT (-1<<32-B)
END

'Unchanged from original
DEF ROTR32(A,B)
 A=BOUND(A)
 RETURN U_RSHIFT(A,B) OR A<<32-B
END
I think personally I'd stick to using integer variables as much as possible, and have BOUND(A) be something explicitly done when passing numbers in only when needed, rather than have it always be run in U_RSHIFT and ROTR32, but that's just my personal taste.
You don't need BOUND because SB already does that automatically when converting from float to int.

You don't need BOUND because SB already does that automatically when converting from float to int.
It does not, and I say as much in the post you quoted:
I didn't realize SmileBASIC actually uses saturating math when going from floats to integers, so it was more difficult than expected
The reason BOUND() is necessary is because float -> int conversions don't wrap around in SmileBASIC, they're capped to the minimum/maximum value of an int (when they don't outright give an overflow error, anyway). Not only that, neither MOD nor AND are helpful in trying to solve this problem. N MOD 4294967296 gives an overflow error, as the right-hand side must fit in a signed int. N AND &HFFFFFFFF does nothing whatsoever, because N is converted into an int with saturating math before the AND operation even happens. This is why BOUND() does not rely on any integer math. A demonstration:
VAR I32=2147483648
VAR U32=4294967296

DEF BOUND(N)
 RETURN N-FLOOR((N+I32)/U32)*U32
END

DEF TEST1(N)
 N=BOUND(N)
 RETURN N>>0
END

DEF TEST2(N)
 VAR N%=N
 RETURN N%>>0
END

DEF TEST3(N)
 RETURN N>>0
END

DEF TEST4(N)
 RETURN N MOD U32
END

DEF TEST5(N)
 RETURN N AND &HFFFFFFFF
END
Results:
?TEST1(2147483646) '=> 2147483646
?TEST1(2147483647) '=> 2147483647
?TEST1(2147483648) '=> -2147483648
?TEST1(2147483649) '=> -2147483647

?TEST2(2147483646) '=> 2147483646
?TEST2(2147483647) '=> 2147483647
?TEST2(2147483648) '=> Overflow in 0:14
?TEST2(2147483649) '=> Overflow in 0:14

?TEST3(2147483646) '=> 2147483646
?TEST3(2147483647) '=> 2147483647
?TEST3(2147483648) '=> 2147483647
?TEST3(2147483649) '=> 2147483647

?TEST4(2147483646) '=> Overflow in 0:23
?TEST4(2147483647) '=> Overflow in 0:23
?TEST4(2147483648) '=> Overflow in 0:23
?TEST4(2147483649) '=> Overflow in 0:23

?TEST5(2147483646) '=> 2147483646
?TEST5(2147483647) '=> 2147483647
?TEST5(2147483648) '=> 2147483647
?TEST5(2147483649) '=> 2147483647

You don't need BOUND because SB already does that automatically when converting from float to int.
It does not, and I say as much in the post you quoted:
I didn't realize SmileBASIC actually uses saturating math when going from floats to integers, so it was more difficult than expected
The reason BOUND() is necessary is because float -> int conversions don't wrap around in SmileBASIC, they're capped to the minimum/maximum value of an int (when they don't outright give an overflow error, anyway).
Oh, for some reason I assumed that was the desired behavior (obviously it's not, in this case)

Made a random number generator with a few inputs the stock RND function doesn't have
DEF RAND(SEED%, MAX%, NEGATIVE%)
 RAND%=(7989121*SEED%+356953) MOD MAX%
 IF !NEGATIVE%&&RAND%<0 THEN RAND%=RAND%*-1
 RETURN RAND%
 END
It works best if MILLISEC is used as the seed instead of an integer form of TIME$. For more randomness replace the hardcoded numbers with your own or just use the stock RND Edit: just realized RANDOMIZE has a seed input