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.

DarkBASIC Professional Discussion / What am I doing wrong?!?! (global udt variables - weird results)

Author
Message
Neuro Fuzzy
19
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 14th Mar 2011 12:32 Edited at: 14th Mar 2011 12:33
So... I have this program... It's kind of odd, and an approximation of a fractal - from "The Fractal Geometry of Nature". So... It's hard to tell what's going on.

My problem is that I have global, user defined types, being used as vectors. The only thing I do to these vectors is average them, or set them to one of three vectors. However, I get points OUTSIDE the triangle defined by these three vectors - points that are impossible to get by just averaging three points! HOW?! I'm pretty sure I'm somehow mistreating global user defined type variables... but... I don't see how. Are user defined types passed by reference?
Here's the code:


Also, there is one line setting a global vector to zero, however, it shouldn't ever be called (It's in case I pass a 0 address into the function on accident), and removing it doesn't change the program at all.

[edit]
also, I think this is similar to the cause of many problems I've had with dbp... ones that I finish (or so I think), can't get to run, port to C++ or something, and have it run perfectly :\

Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 14th Mar 2011 14:03
Can you reproduce the problem with a shorter piece of code?
Van B
Moderator
23
Years of Service
User Offline
Joined: 8th Oct 2002
Location: Sunnyvale
Posted: 14th Mar 2011 18:13
Perhaps it's an issue with your Vector2 type - that could be conflicting with the vector commands. Maybe change that to t_vector2 or something just to eliminate that.

Also, this command:

retvec1=p1

It looks like your trying to set a typed variable directly, but I don't think that actually works - really you might well be setting one null variable to another in this case. I am sure you would have to do something like this:

retvec1.x = p1.x
retvec1.y = p1.y

Wheras in C++ it can pobably work how you have it, setting a pointer rather than data for example.

Health, Ammo, and bacon and eggs!
Green Gandalf
VIP Member
21
Years of Service
User Offline
Joined: 3rd Jan 2005
Playing: Malevolence:Sword of Ahkranox, Skyrim, Civ6.
Posted: 14th Mar 2011 21:16 Edited at: 14th Mar 2011 21:31
Quote: "but I don't think that actually works "


Yes it does.

Quote: "Perhaps it's an issue with your Vector2 type "


I wondered about that - but the compiler accepts it and works in simple cases. I think the problem lies elsewhere so it would definitely help to have short simple code showing the same problem.

Edit The following very simplified version of your code computes the averages correctly.

Neuro Fuzzy
19
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 14th Mar 2011 22:15
I think it might have something to do with the code being a recursive mess... but I'm still not totally sure what I could do to isolate the problem :\

IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 14th Mar 2011 23:24
How about rewriting all of those allocs, peeks and pokes in a pseudo-OO way. Frankly all of that pointer arithmetic is confusing and hides what you are trying to do - I certainly find it confusing.

Try using something like this for a start (untested):


Diggsey
20
Years of Service
User Offline
Joined: 24th Apr 2006
Location: On this web page.
Posted: 15th Mar 2011 03:07
You can save on the number of functions you need by having generic read and write functions for each type and specify the offset using a constant, ie:


[b]
Neuro Fuzzy
19
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 21st Mar 2011 13:50 Edited at: 21st Mar 2011 13:50
Hmm... I'll definitely do that in the future.

Anyways, I applied the same concept, and wrote some C++ code, and got it working first compile, so now I'm certain the problem is either
(A) Some misconception I have about DBPro or
(B) A bug in DBPro

I still have no clue though...

If you're wondering WHAT I'm doing, I wrote up some stuff about it on my website (pictures I've made are at the bottom of that page) aaand on the forums (2nd to last post)

IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 21st Mar 2011 15:07
or (C) some bug in your code.

There are so many address calculations in there that I have no idea what's going on for a large portion of the time - that's why you should try to encapsulate your memory accesses.

Neuro Fuzzy
19
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 21st Mar 2011 16:11
I get that it's unclear, but the problem is: vectors being averaged and coming out with impossible results. Since I never set any value of any vector to something read from memory, I think that's a separate thing from the bug. In other words, "I know I'm probably overlooking something, but I don't think memory access is the issue" (A programmer's famous last words )

IanM
Retired Moderator
23
Years of Service
User Offline
Joined: 11th Sep 2002
Location: In my moon base
Posted: 21st Mar 2011 22:21
But you are writing to memory - could be that you are overwriting the odd vector here and there.

Now I'm not saying that's what the problem is, but as that's the most unclear part of the code, that's what I'd target first. Wrapping it up in functions would allow you to at least put in a standard check that you aren't writing memory out of bounds of the allocated memory.

Neuro Fuzzy
19
Years of Service
User Offline
Joined: 11th Jun 2007
Location:
Posted: 30th Mar 2011 02:55 Edited at: 30th Mar 2011 10:03
[edit]
:\
nevermind...

Login to post a reply

Server time is: 2026-07-16 21:36:03
Your offset time is: 2026-07-16 21:36:03