Posts: 740
Threads: 104
Joined: Apr 2022
Reputation:
14
(10-28-2022, 02:15 AM)vince Wrote: I like how you impose functionality on constants, truly a mad scientist
Do you mean the color values? I don't recall exactly why, I must have tried using constants and something didn't work for an unsigned long, or whatever type the rgb colors need, and it didn't work, and after deliberation, someone suggested just using a function, which worked fine. So in that case not so much a mad scientist as just needing to get it to work. But I've done much bigger kludges, the digital equivalent to duct tape & redneck tech, that would earn the title of mad scientist. These days I try to keep a low profile and stay out of trouble! ;-O
Posts: 4,020
Threads: 181
Joined: Apr 2022
Reputation:
225
10-28-2022, 05:32 PM
(This post was last modified: 10-28-2022, 05:37 PM by bplus.)
(10-28-2022, 03:48 AM)madscijr Wrote: (10-28-2022, 02:15 AM)vince Wrote: I like how you impose functionality on constants, truly a mad scientist
Do you mean the color values? I don't recall exactly why, I must have tried using constants and something didn't work for an unsigned long, or whatever type the rgb colors need, and it didn't work, and after deliberation, someone suggested just using a function, which worked fine. So in that case not so much a mad scientist as just needing to get it to work. But I've done much bigger kludges, the digital equivalent to duct tape & redneck tech, that would earn the title of mad scientist. These days I try to keep a low profile and stay out of trouble! ;-O
Yeah something got broke using color constants, now if you use the &H... way you need to suffix a number with _Unsigned long symbol.
eg
const white = &Hffffffff ' nope!
const white = &Hffffffff~& ' OK
Was this fixed? I just tested and point values matched
Code: (Select All) Screen _NewImage(800, 600, 32)
Const white = &HFFFFFFFF ' nope!
Const white2 = &HFFFFFFFF~& ' OK
PSet (10, 10), white
PSet (20, 20), white2
Print Point(10, 10) = Point(20, 20)
Hmm... I am sure as soon as I need to depend on it in real app, it will screw up, unless someone can confirm it was fixed.
b = b + ...
Posts: 740
Threads: 104
Joined: Apr 2022
Reputation:
14
10-28-2022, 06:58 PM
(This post was last modified: 10-28-2022, 07:45 PM by madscijr.)
(10-28-2022, 05:32 PM)bplus Wrote: (10-28-2022, 03:48 AM)madscijr Wrote: (10-28-2022, 02:15 AM)vince Wrote: I like how you impose functionality on constants, truly a mad scientist
Do you mean the color values? I don't recall exactly why, I must have tried using constants and something didn't work for an unsigned long, or whatever type the rgb colors need, and it didn't work, and after deliberation, someone suggested just using a function, which worked fine. So in that case not so much a mad scientist as just needing to get it to work. But I've done much bigger kludges, the digital equivalent to duct tape & redneck tech, that would earn the title of mad scientist. These days I try to keep a low profile and stay out of trouble! ;-O
Yeah something got broke using color constants, now if you use the &H... way you need to suffix a number with _Unsigned long symbol.
eg
const white = &Hffffffff ' nope!
const white = &Hffffffff~& ' OK
Was this fixed? I just tested and point values matched
Code: (Select All) Screen _NewImage(800, 600, 32)
Const white = &HFFFFFFFF ' nope!
Const white2 = &HFFFFFFFF~& ' OK
PSet (10, 10), white
PSet (20, 20), white2
Print Point(10, 10) = Point(20, 20)
Hmm... I am sure as soon as I need to depend on it in real app, it will screw up, unless someone can confirm it was fixed.
Aha, thanks. I do seem to vaguely recall seeing this being discussed a while back.
Maybe I'll convert the color functions to constants eventually, for now it works so I'll leave it as functions!
Would using constants instead of functions improve performance in QB64 or QB64PE?
Posts: 4,020
Threads: 181
Joined: Apr 2022
Reputation:
225
"Would using constants instead of functions improve performance in QB64 or QB64PE?"
My guess is yes definitely because functions take more time to call and process, though the sleep you would lose is negligible.
b = b + ...
Posts: 740
Threads: 104
Joined: Apr 2022
Reputation:
14
(10-28-2022, 09:26 PM)bplus Wrote: "Would using constants instead of functions improve performance in QB64 or QB64PE?"
My guess is yes definitely because functions take more time to call and process, though the sleep you would lose is negligible.
I had to ask because another thing I vaguely sort of recall was a thread about how the way constants were implemented, they performed worse than functions. Man, this was back on the old .org site and my brain is probably confused.
It's true I won't lose sleep - I'll lose less leaving it alone knowing it'll work and not having to worry whether there is any funny stuff going on with constants maybe having issues with unsigned long types.
We'll revisit this later on!
Posts: 1,554
Threads: 59
Joined: Jul 2022
Reputation:
52
If the function doesn't have to do a really expensive calculation, then calling it in a 64-bit operating system wouldn't be as pensive as doing it under MS-DOS. Try checking out one of the last "Steve mods" for QB64 v0.954 SDL, with its impressive building on "CONST". I only wanted to go as far as:
Code: (Select All) CONST QU$ = CHR$(34)
CONST PIE = ATN(1) * 4
CONST DEADBEEF2 = &HDEADBEEFDEADBEEF
Also be glad we don't have to go even further decorating constants like must be done in C, because the C compiler could generate silly warnings because the programmer didn't type-cast something or didn't put "UL" or alike at the end of a number phrase.
Another thing is the mind-boggling C++ code that QB64PE generates only to initialize some variable. It does not rely on the preprocessor for anything, not even for something declared "CONST" in BASIC code.
Posts: 740
Threads: 104
Joined: Apr 2022
Reputation:
14
(11-04-2022, 11:59 PM)mnrvovrfc Wrote: If the function doesn't have to do a really expensive calculation, then calling it in a 64-bit operating system wouldn't be as pensive as doing it under MS-DOS. Try checking out one of the last "Steve mods" for QB64 v0.954 SDL, with its impressive building on "CONST". I only wanted to go as far as:
Code: (Select All) CONST QU$ = CHR$(34)
CONST PIE = ATN(1) * 4
CONST DEADBEEF2 = &HDEADBEEFDEADBEEF
Also be glad we don't have to go even further decorating constants like must be done in C, because the C compiler could generate silly warnings because the programmer didn't type-cast something or didn't put "UL" or alike at the end of a number phrase.
Another thing is the mind-boggling C++ code that QB64PE generates only to initialize some variable. It does not rely on the preprocessor for anything, not even for something declared "CONST" in BASIC code.
Wow... I am glad! LoL
As long as it's easy and works and is compatible with most people use, so that it runs out of the box, I'm happy!
I mean, look at the code for the game I just posted, it's got "rapid application development" written all over it! I mean, I try not to make too much spaghetti code, but I like getting something working fast. C just does not fit that mindset.
Posts: 371
Threads: 30
Joined: Jul 2022
Reputation:
25
Hi Madscjr
a very notable work...also if it is in progress
I'm very interested to the section in development...I'm talking about Layers stuff.
Posts: 740
Threads: 104
Joined: Apr 2022
Reputation:
14
11-08-2022, 12:25 PM
(This post was last modified: 11-09-2022, 02:15 AM by madscijr.)
(11-08-2022, 10:17 AM)TempodiBasic Wrote: Hi Madscjr
a very notable work...also if it is in progress
I'm very interested to the section in development...I'm talking about Layers stuff.
Thanks Tempodi, work on this continues in the game here
Multi-Spacewar!
I haven't worked the vector graphics engine into the main game, but soon...
|