Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / hands on dark basic pro volume 1 - activity 6.3(help)

Author
Message
danctodd
14
Years of Service
User Offline
Joined: 31st Jul 2010
Location:
Posted: 23rd Oct 2011 23:18 Edited at: 23rd Oct 2011 23:30
This is the code I wrote, which is pretty similar to the books with just a for loop added to allow me to check 30 pixels foreground color properties instead of one.

The program only prints out "The pixel at x, y is not black." I know it is something to do with the book though because I commented my code out and ran the books and got the same error. I tried restricting it to fewer colored pixels on the screen or none and I still am facing this problem.
My hunch, which is just a hunch, is something needs to be changed here:
if point(x, y) = rgb(0,0,0)


Here is the code provided in the book:
HowDo
21
Years of Service
User Offline
Joined: 28th Nov 2002
Location: United Kingdom
Posted: 24th Oct 2011 10:45
here your code with a loop and mouse pointer and a few other bits added so you can see what the color is at the point of the mouse pointer.

if you hit a black pixel then it will say black or else it will show it rgb value.



Dark Physics makes any hot drink go cold.
Grog Grueslayer
Valued Member
19
Years of Service
User Offline
Joined: 30th May 2005
Playing: Green Hell
Posted: 24th Oct 2011 18:44 Edited at: 24th Oct 2011 18:44
Quote: "Here is the code provided in the book:"


That is SO annoying. You'd think the author would try to make code that would be a little more interactive when showing what the code does. HowDo hit the nail on the head when he thought it should of been following the mouse coordinates rather than some random place on the screen that the user can't confirm is actually a color or black.

danctodd
14
Years of Service
User Offline
Joined: 31st Jul 2010
Location:
Posted: 25th Oct 2011 01:06
Thanks a lot for that, HowDo. I'm going to spend a bit of time dissecting the code and figuring it out.
Grog Grueslayer: There are a few examples in the book that seemed like they were done the wrong way for me personally and that I found more useful ways of coding. Everyone has their way of doing something though.
zenassem
21
Years of Service
User Offline
Joined: 10th Mar 2003
Location: Long Island, NY
Posted: 25th Oct 2011 02:08 Edited at: 25th Oct 2011 03:05
Yeah the odds of getting a point to = rgb(0,0,0) is not good.

Someone please correct me if my math brain isn't cooked.

To get 1 component to be 0: is 1 in 256 or 1/256
(rounding up to keep it relative)
1/256 = .004
so the percentage likely hood is .4%

Assuming "actual" randomnees, getting all 3 components to be 0:
is (1/256)*(1/256)*(1/256) = or (1/256)^3
therefore a 1 in 16,777,216 chance??? which also ^-1 (inversed)
= 0.00000006
so the percentage likely hood (multiply x 100) is 0.000006%

so roughly the percentage of getting rgb values that "do not equal" rgb(0,0,0) is: 99.999994% of the time????

Just seems like lower odds than I anticipated

I know I am rounding to keep it relative,, but is that roughly the correct percentage that the rgb will Not be 0,0,0????

Your signature has been erased by a mod please reduce it to 600 x 120.
danctodd
14
Years of Service
User Offline
Joined: 31st Jul 2010
Location:
Posted: 23rd Nov 2011 04:13
I'm going to update this occasionally if I find any errors in this book. I've been doing it on a couple forums now for books I've taken to rereading. I think even small errors should be fixed, especially in a book that has multiple revisions and is meant for beginners.

In activity 3.8 of Hands on DarkBasic Pro, problem e, the instruction m# = no1/5 with no1 equaling 2 lists the answer as being m# = 0.4. Not a biggie but he states shortly before that to get the proper math from an integer equation and to store that in a real(float/double) variable requires at least one integer to be changed to a real number inside the equation.
m# = no1/5.0

Nothing big but I'm picky
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 23rd Nov 2011 07:47
Quote: "Nothing big but I'm picky"


And so you should be. One small oversight in a large program and it's all over *Insert SFX: BOOM!*

There's a very quick way around the float vs integer problem that saves you a little typing and that's to add a float return function to your program. The code below explains it in-depth since I have no clue what level you're on (I haven't read the Hands On books). Anyway, copy and paste it to your DBP and run it. It's fairly straightforward.



danctodd
14
Years of Service
User Offline
Joined: 31st Jul 2010
Location:
Posted: 23rd Nov 2011 13:50
Yes,this is fairly straightforward. Would be nice if an example like this was added to the book. Calling a function to effectively change the value to a float is a much faster way indeed. Thanks for the example
nonZero
13
Years of Service
User Offline
Joined: 10th Jul 2011
Location: Dark Empire HQ, Otherworld, Silent Hill
Posted: 23rd Nov 2011 16:18
You're welcome. Unfortunately, the books are more like verbose references and training manuals. They are there to teach you the BASICs (pardon the pun) and most will not teach you many of the "tips & tricks", primarily because there are so many ways to accomplish a task that it would be very hard to document. But you learn these "other ways of doing things" through trial, error, experience, accident, late night epiphanies, forums and occasionally sleep-deprived hallucinations. After writing your first program in a language, you'll generally find you start getting these "ideas" and then start experimenting with a decent success rate.

danctodd
14
Years of Service
User Offline
Joined: 31st Jul 2010
Location:
Posted: 23rd Nov 2011 19:36
I think the sleep-deprived hallucinations sound promising I know what you are talking about though.
I am really excited and can't wait understand DarkBasic Pro so I can have a tool for crafting in my arsenal.
danctodd
14
Years of Service
User Offline
Joined: 31st Jul 2010
Location:
Posted: 24th Nov 2011 03:36 Edited at: 24th Nov 2011 03:38
Separate post since this does not relate to my last post.

Here is my own edited version of activity 3.30 in the book which I believe helps to make things somewhat clearer.

danctodd
14
Years of Service
User Offline
Joined: 31st Jul 2010
Location:
Posted: 28th Nov 2011 01:04 Edited at: 28th Nov 2011 01:54
Just a quick question...
In the code provided below, shouldn't the screen width and height be listed with one value less? Isn't the range for a 800x600 screen 0-799 and 0-599? He mentions this the page before but then changes it in the example.
I've found quite a few errors now that I have reread the first part of the book.



No offense to the author of the hands on books but I see a lot of mistakes.
LBFN
17
Years of Service
User Offline
Joined: 7th Apr 2007
Location: USA
Posted: 28th Nov 2011 06:38
Bear in mind that that book was written in 2005. Anyway, you are correct on how the pixels are numbered. However, if the screen the user is using is larger than 800 X 600, say 1024 X 768 for example, it will not error. A better way to do it would be to check the screen's height and width, like this:



Also, you'll notice I locked / unlocked the pixels. This helps speed up drawing when using the DOT command. I put in an elapsed time counter so that you can see for yourself. Run the program and see what you get for elapsed time. Then REM out the lock / unlock pixels and see what you get. It is literally twice as fast on my computer 12 to 14 locked, 28 or so not locked.


danctodd
14
Years of Service
User Offline
Joined: 31st Jul 2010
Location:
Posted: 28th Nov 2011 22:14 Edited at: 28th Nov 2011 22:18
Thanks, LBFN. I'll take a closer look at the code in a little. Tired at the moment.

Listed in the ebook is this:
Printed September 2005
2nd Printing November 2005
3rd Printing January 2006
4th Printing November 2006
5th Printing February 2007
6th Printing September 2007
7th Printing February 2008
8th Printing September 2009 (with corrections)
9th Printing July 2010 (with corrections)
Just noticing I've found around 12 errors in the first part of the book. But there might of been a tight deadline or they wanted it out to the masses sooner. Or they didn't have too many people available to proof-read the whole entire book.

I am in no way saying I could write a better book. I am loving the book. I also bought the second because I am learning a lot from the material. I am just hoping to get all the errors fixed so I and others can have a solid step into programming.
This is coming to my mind:
"Practice does not make perfect. Only perfect practice makes perfect."
- Vince Lombardi
LBFN
17
Years of Service
User Offline
Joined: 7th Apr 2007
Location: USA
Posted: 29th Nov 2011 01:09
The book was a great source for me when I first started programming with DBP. I haven't hardly looked at it in years because I can generally find a solution to problems here on the forum. Even with some flaws, overall it is a very good source to learn from.


Login to post a reply

Server time is: 2024-11-24 00:04:30
Your offset time is: 2024-11-24 00:04:30