PureBasic Survival Guide
> expressions are evaluated left to right
They still are, but higher priority parts will come first, however typing is depending on the sequence of processing.
>> types never change 'downwards'
> ; Type changes downwards from float to long here
> ; V
> q.q = 2*(92/8.+5)
> Debug q
Nope, perhaps I should rephrase this. PB is using a certain type to store the result. That 'result' type is not downgraded.
> ; And here V
> Debug 2*(92/8.+5)
So what happens here is:
2 -> result type is long
* ( ... ) -> () have higher prop, step through them
92 -> we stay on long
8.0 -> up to float
I checked the other examples as well, but it is still the same. The type in which is calculated goes only up, not down, until assigned to a var.
> Only the return type of a function can force a typechange.
Although overloaded it does change the type, read my original description carefully.
> a.f = 3
> b.l = 1 + 2 / a.f
>
> Notice the mathematic priority! It's NOT going to do something like ( 1 +
> 2 ) / 3 but it does 1 + ( 2 / 3 ). However, it will not start with typing a
> float as it still works from left to right.
Well, it's going to start with the left side...
1 -> stay a long
2 / a.f -> process as a block
/ -> result stays a long
/ a.f -> result is a flow
= -> we turn the result into the requested type, in this case a long
> Here, the 1 will acutally be treated as a float although you give the
> impression that that will not happen. Why?
No, it's not a float, it's a long, and stays a long until the / a.f is hit.
> Because: 2/a.f is a float, and when you add a constant and a float the
> result is a float. Also, the result of the entire expression is a float
> because if the 1 was a long it would be converted. It would be faster to
> add after the division because that would make the convertion more
> efficient, but the result is the same, the integer at 1 will be converted to
> a float.
Well, exactly not. The 1 itself is not turned into a float. It is stored as a long, then converted to a float the moment it hits the / a.f.
They still are, but higher priority parts will come first, however typing is depending on the sequence of processing.
>> types never change 'downwards'
> ; Type changes downwards from float to long here
> ; V
> q.q = 2*(92/8.+5)
> Debug q
Nope, perhaps I should rephrase this. PB is using a certain type to store the result. That 'result' type is not downgraded.
> ; And here V
> Debug 2*(92/8.+5)
So what happens here is:
2 -> result type is long
* ( ... ) -> () have higher prop, step through them
92 -> we stay on long
8.0 -> up to float
I checked the other examples as well, but it is still the same. The type in which is calculated goes only up, not down, until assigned to a var.
> Only the return type of a function can force a typechange.
Although overloaded it does change the type, read my original description carefully.
> a.f = 3
> b.l = 1 + 2 / a.f
>
> Notice the mathematic priority! It's NOT going to do something like ( 1 +
> 2 ) / 3 but it does 1 + ( 2 / 3 ). However, it will not start with typing a
> float as it still works from left to right.
Well, it's going to start with the left side...
1 -> stay a long
2 / a.f -> process as a block
/ -> result stays a long
/ a.f -> result is a flow
= -> we turn the result into the requested type, in this case a long
> Here, the 1 will acutally be treated as a float although you give the
> impression that that will not happen. Why?
No, it's not a float, it's a long, and stays a long until the / a.f is hit.
> Because: 2/a.f is a float, and when you add a constant and a float the
> result is a float. Also, the result of the entire expression is a float
> because if the 1 was a long it would be converted. It would be faster to
> add after the division because that would make the convertion more
> efficient, but the result is the same, the integer at 1 will be converted to
> a float.
Well, exactly not. The 1 itself is not turned into a float. It is stored as a long, then converted to a float the moment it hits the / a.f.
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
@blueznl:
This response to Trond's code is a little confusing.
Using a lengthy breakdown, here goes:
This example is the same as the Trond's example for a quad result except the result would be downgraded to a quad for storing in q. It also results in 32 but it should be 33 according to your explanation.
If I have misunderstood the process please correct me.
Code: Select all
> ; And here V
> Debug 2*(92/8.+5)
So what happens here is:
2 -> result type is long
* ( ... ) -> () have higher prop, step through them
92 -> we stay on long
8.0 -> up to float
The code results in the value 32 when it should be 33 according to your description. It should only result in 32 if it was downgraded somewhere in the process.blueznl wrote:I checked the other examples as well, but it is still the same. The type in which is calculated goes only up, not down, until assigned to a var.
Using a lengthy breakdown, here goes:
Code: Select all
Debug 2*(92/8.+5) ;original expression
Debug L*(L/F +L) ;using types
Debug L*(F/F +L) ;92 upgraded to 92.0
Debug L*(F +L) ;Result of 92.0/8.0 =11.5
Debug L*(F +F) ;5 upgraded to 5.0
Debug L* F ;Result of 11.5+5.0=16.5
Debug F* F ;2 upgraded to 2.0
Debug F ;Result of 2.0*16.5=33.0
Debug L ;33.0 downgraded to 33 for DEBUG output
If I have misunderstood the process please correct me.
No, you're right, but there is something very annoying going on...
PB 3.94:
Debug 2*(92/8.+5) returns 33
PB 4.10 Beta 2
Debug 2*(92/8.+5) returns 32
FRED PLEASE! Tell us what you changed...
Edit: looks like things in 4.10 are again as expected...
PB 3.94:
Debug 2*(92/8.+5) returns 33
PB 4.10 Beta 2
Debug 2*(92/8.+5) returns 32
FRED PLEASE! Tell us what you changed...
Edit: looks like things in 4.10 are again as expected...
Last edited by blueznl on Mon Nov 26, 2007 5:35 pm, edited 1 time in total.
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
Okay, people. Small update of the PureBasic survival guide is up. 's a little more detail on how strings occupy memory, a section on files, and a few touchups. I'm now looking at the fancy new 4.10 to see if there is anything I can add to the nowadays extensive PB help files Anything new will be in red, as usual.
So, in effect, it's a Survival Guide for 4.00 about to be updated to 4.10? Uh, guess so then...
The link:
http://www.xs4all.nl/~bluez/datatalk/purebasic.htm
Have fun!
So, in effect, it's a Survival Guide for 4.00 about to be updated to 4.10? Uh, guess so then...
The link:
http://www.xs4all.nl/~bluez/datatalk/purebasic.htm
Have fun!
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
I'm working on a new update, now that the 4.xx breed gets better and better.
Some small sections have been redone (a piece on the debugger, for example) but there's still a lot to do.
Are there any special requests? (... of such a low level that I am able to answer them )
Oh, the link...
http://www.xs4all.nl/~bluez/datatalk/purebasic.htm
Some small sections have been redone (a piece on the debugger, for example) but there's still a lot to do.
Are there any special requests? (... of such a low level that I am able to answer them )
Oh, the link...
http://www.xs4all.nl/~bluez/datatalk/purebasic.htm
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
Latest version just upped. Now includes a new page on the debugger.
Find it here:
http://www.xs4all.nl/~bluez/datatalk/pure11.htm#top
Find it here:
http://www.xs4all.nl/~bluez/datatalk/pure11.htm#top
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
New version just went up. Now includes a section on threads and some other small improvements.
http://www.xs4all.nl/~bluez/datatalk/pu ... #6_threads
http://www.xs4all.nl/~bluez/datatalk/pu ... #6_threads
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
good work.
Some things worth noting maybe:
On the Debugger/Profiler you wrote that enabling the profiler may slowdown the program.
This is not really an issue. The slowdown caused by the profiler is very small.
Adding a couple of dynamic breakpoints probably causes more slowdown than that.
On CreateMutex() vs. CreateMutex_() Your description makes it sound as though they are totally interchangable.
You should maybe add though that locking an API mutex (being an interprocess communication object)
is dead slow compared to the PB ones (critical sections), so it is not really suited for pure thread synchronisation.
Some things worth noting maybe:
On the Debugger/Profiler you wrote that enabling the profiler may slowdown the program.
This is not really an issue. The slowdown caused by the profiler is very small.
Adding a couple of dynamic breakpoints probably causes more slowdown than that.
On CreateMutex() vs. CreateMutex_() Your description makes it sound as though they are totally interchangable.
You should maybe add though that locking an API mutex (being an interprocess communication object)
is dead slow compared to the PB ones (critical sections), so it is not really suited for pure thread synchronisation.
quidquid Latine dictum sit altum videtur
Thanks. Good to know at least someone knowledgable is reading it I will make the changes...
... updated.
... updated.
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
Some small updates. Updated the 'downloadable' version as well.
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
Debug 2*(92/8.+5) returns 33.0 here in PB 4.20blueznl wrote:No, you're right, but there is something very annoying going on...
PB 3.94:
Debug 2*(92/8.+5) returns 33
PB 4.10 Beta 2
Debug 2*(92/8.+5) returns 32
FRED PLEASE! Tell us what you changed...
Edit: looks like things in 4.10 are again as expected...
That was fixed quite some time ago, I think you're replying to a very old message
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
Another update.
- FTP
- Sprites http://www.xs4all.nl/~bluez/datatalk/pu ... nd_screens
I've added as much to sprites as I could, but I'm stuck, either by my own lack of understanding, or by PB's limitations or bugs. I hope to find out soon
- FTP
- Sprites http://www.xs4all.nl/~bluez/datatalk/pu ... nd_screens
I've added as much to sprites as I could, but I'm stuck, either by my own lack of understanding, or by PB's limitations or bugs. I hope to find out soon
Last edited by blueznl on Wed Aug 27, 2008 1:13 am, edited 1 time in total.
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )
- Kaeru Gaman
- Addict
- Posts: 4826
- Joined: Sun Mar 19, 2006 1:57 pm
- Location: Germany
the limit to the screensize is important for 2D sprites that will be clipped.The following applies to all sprite commands:
* the size of the sprite should be smaller or equal to the screen
* 'standard' sized sprites are preferred (16x16 32x32 64x64 128x128 256x256)
more modern hardware displays bigger sprites without problems when not clipped,
some even have no problems when clipping.
the (2^n)² limitation ONLY applies for sprites used for textures for CreateSprite3D,
normal 2D Sprites can have any size you like.
newer hardware can use textures in (2^x)*(2^y), some hardware can even use textures at any size.
sprite textures used to create Sprite3Ds may be bigger than the screen.
afaik Grafics Cards of the Generation of the GForce4 can use 2048² textures, newer Hardware can use up to 4096².
oh... and have a nice day.
Thanks, Kaeru, I have to think of a good way to include this information.
( PB6.00 LTS Win11 x64 Asrock AB350 Pro4 Ryzen 5 3600 32GB GTX1060 6GB)
( The path to enlightenment and the PureBasic Survival Guide right here... )
( The path to enlightenment and the PureBasic Survival Guide right here... )