Blitz seems crap at percentages

-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0\|530\|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Blitz -> Blitz seems crap at percentages
Thu, 11 Nov 2010, 10:50
steve_ancell	Been trying to get Blitz3D to find a percentage of GraphicsWidth(), based on MouseX(), I know I did it years ago, but that part of my brain seems to have gone rotten. The real maths should obviously be "(howFar / howWide) * 100" but according to Blitz3D, is it f*k! Any ideas? Graphics 1280, 1024 SetBuffer BackBuffer() Repeat Local x = GetX() Cls Text 0, 0, x DrawPointer() Flip Until KeyHit(1) End Function DrawPointer() Rect MouseX(), MouseY(), 2, 2, True End Function Function GetX() Return (MouseX() / GraphicsWidth()) 100 End Function --v
Thu, 11 Nov 2010, 11:02
shroom_monk	The default data type in Blitz for numbers is integers, not floats, so (howFar / howWide) * 100 is interpreted as: 1) howFar / howWide = x; but x is a float, and I want an int! Hence I must round it! 2) rounds value to 0 or 1 3) I must now multiply this by 100! 4) multiplies the 0 or 1 by 100 There are 2 ways around this. Either multiply by 100 first, then divide, or use floats. -=-=- A mushroom a day keeps the doctor away... Keep It Simple, Shroom!
Thu, 11 Nov 2010, 11:07
Hotshot	here that work but i guess it isnt somethings you looking for Graphics 1280, 1024 SetBuffer BackBuffer() Global x,y Repeat Cls Text 0 ,0 ,"X = "+x Text 0 ,20,"Y = "+Y DrawPointer() Flip Until KeyHit(1) End Function DrawPointer() X=MouseX():Y=MouseY() Rect x, y, 2, 2, True End Function --v
Thu, 11 Nov 2010, 11:07
steve_ancell	shroom_monk I already tried floats, no joy there either. I'll try the first of what you suggested. Cheers Bud
Thu, 11 Nov 2010, 11:11
steve_ancell	@Hotshot Cheers for having a go but that's not quite what I'm looking for, that just returns the current mouse position. I'm after something that returns the mouse position as a percentage of the width or height of the screen.
Thu, 11 Nov 2010, 11:22
steve_ancell	@shroom_monk Yeah, multiplying by 100 first seems to work. It may only reach 99 percent, but that's good enough. Cheerz matey Here be the codez: Function GetX() Local x# x# = (MouseX() * 100) / GraphicsWidth() Return x# End Function --v
Thu, 11 Nov 2010, 11:23
Jayenkai	Up, THEN down (a*100)/b Gets rid of 95% of float vs int issues -=-=- ''Load, Next List!''
Thu, 11 Nov 2010, 11:30
steve_ancell	@Jay I think that may be the same as what shroom suggested. It also seems to work OK without the # sign, here's the revised proggie: \|edit\| I still don't get why it maxes at 99 percent though \|edit\| Graphics 1280, 1024 SetBuffer BackBuffer() Repeat Local x = GetX() Local y = GetY() Cls Text 0, 0, x + ":" + y DrawPointer() Flip Until KeyHit(1) End Function DrawPointer() Rect MouseX(), MouseY(), 2, 2, True End Function Function GetX() Local x x = (MouseX() * 100) / GraphicsWidth() Return x End Function Function GetY() Local y y = (MouseY() * 100) / GraphicsHeight() Return y End Function --v
Thu, 11 Nov 2010, 11:36
steve_ancell	Actually, I just realized why it maxes at 99, MouseX() never reaches 1280, it reaches 1279. What a plonker do I feel! Here's how I should have done it: Function GetX() Local x x = (MouseX() * 100) / (GraphicsWidth() - 1) Return x End Function Function GetY() Local y y = (MouseY() * 100) / (GraphicsHeight() - 1) Return y End Function --v Cheers for your help guys
Thu, 11 Nov 2010, 12:07
steve_ancell	Just found a simpler way, by use of the Float command. Damn I'm good ! Function GetX() Local x x = (MouseX() / Float(GraphicsWidth())) * 100 Return x End Function Function GetY() Local y y = (MouseY() / Float(GraphicsHeight())) * 100 Return y End Function --v
Fri, 12 Nov 2010, 03:30
waroffice	seems like such a simple thing to have problems with doesnt it. This sort of thing I could spend days figuring out and end up turning my PC off and going to the pub.
Fri, 12 Nov 2010, 08:09
JL235	I'm sorry if this comes across negatively, but this is not that difficult a problem. Shroom also pointed out the solution in his post. When you use languages which are more explicit about what types your using (like Java or C#) then you tend to become more aware about this kind of issue. You'll end up being able to solve this within 30 seconds of spotting it.
Fri, 12 Nov 2010, 08:26
Jayenkai	I had to completely rethink ALL my maths the day I tried out coding for the ye-olde Windows Smartphone v1 crapola. It was TERRIBLE at this stuff. It was mostly due to the ARM processor, and I've since held on to those math rules whilst doing DS stuff, and even on more recent Blitz and iPod dev. If you go up first, it's SO much better on the processor. If you can avoid divisions entirely, it's even better.. And if you can wrangle your code to do bitshifting rather than multiply/divide, you're going to find everything running that much quicker. I know, it's a QuadCore, it shouldn't matter. But it's the little things that count. -=-=- ''Load, Next List!''
Fri, 12 Nov 2010, 09:09
JL235	That only matters if it's slow for your PC, or if it's code that will be executed millions of times a frame. Otherwise your writing less readable code for no real performance gain. Lots of coders claim you should always use doubles instead of floats, but on many modern CPUs doubles are actually faster.
Fri, 12 Nov 2010, 09:29
steve_ancell	JL235 I'm sorry if this comes across negatively, but this is not that difficult a problem. Shroom also pointed out the solution in his post. I don't see this as negative, it's my own bloomin' fault for not coding regularly. No offense taken Bud
Fri, 12 Nov 2010, 10:11
steve_ancell	Decision made... I will stick with Shroomie and Jay's solution, because the code looks a lot cleaner and easier to remember.