Vector 2d type..

BlitzMax Forums/BlitzMax Programming/Vector 2d type..

matibee

(Posted 2009) [#1]

Hi all,

Can someone point me to a proven 2d vector type from the archives? There's a lot of stuff in there and it's not too easy to search, even then I'd still like a recommendation. If it's mixed in with other types like 4x4 matrices and 3d vectors that's fine I'll need them eventually.

I'd like to work along with the 'conventional wisdom' from day one and when I see methods like Add replacing overloaded operators I see there's a big chance of me making fugly code that won't grow with future needs (minib3d being one).

So which one do you use?

Cheers
Matt

plash

(Posted 2009) [#2]

My duct series has a vector module (2d and 3d), but the version on Github is out-dated.
I'll edit this post with a link when I get it up (FileFront is down for maintenance).

EDIT: http://files.filefront.com/ductvector+v02zip/;13913121;/fileinfo.html

Wiebo

(Posted 2009) [#3]

I use this one: http://mauft.com/open-source/blitzmax
I really like it!

matibee

(Posted 2009) [#4]

Thanks for the input. I've spotted some errors and omissions though; (I'm not being critical, it's great to find people willing to share code, I'm trying to be helpful :) )

There's an error in both sources in allowing a vector to be divided by another vector (either as a vector or as a set of individual function arguments). Vectors can only be divided by a scalar.

Plash; Your SubtractParamsNew doesn't return a a new vector, and a few asserts (as used in Wiebo's example) would probably make more sense than commenting the fact functions don't check for null's. If I go with your source I'll ammend it and send back to you for your consideration.

Thanks again.

All in all, though, do you think we will ever see basic operator overloading in bmax? "+ - / * :+ :- :/ :* < >" would be an awesome start, and surely not too difficult to define and allow ;)

Warpy

(Posted 2009) [#5]

I don't think operator overloading's ever likely to happen. Mark just doesn't seem interested in it, it would be a lot of work to add.

plash

(Posted 2009) [#6]

a few asserts (as used in Wiebo's example) would probably make more sense than commenting the fact functions don't check for null's.

The module was wrote for speed, not for keeping you in line. I never had any problems with Null vectors before, so I never needed to add it.

Vectors can only be divided by a scalar.

By a scalar do you mean this?

Method DivideParams(scalar:Float)
	
	If scalar <> 0
		
		m_x:/scalar
		m_y:/scalar
		
	End If
	
End Method

matibee

(Posted 2009) [#7]

Hey Plash: Yes that division operation is correct. If you google "vector division" it comes up with articles such as this; http://www.mcanv.com/qa_vdq.html

The asserts don't effect release build speed as they're only compiled into debug builds. It could save a lot of head-scratching (which quickly turns into head-banging!) if you captured any dodgy input. Besides;
"Assert(vec)" is much less typing than "about: Warning: This will not check if @vec is Null!" ;) It helps others trying to use and understand the code too. If Bmax bombs out at the assert, it's easy to understand why.

Warpy: I'm sure lots of other C++ migrants have campained for op. overloads so I don't want to start again, I wondered (with being new here) if it's something planned. It'd be a shame to code around all these Add/Multiply functions if the next version of BMax suddenly supported it :)

Cheers guys

plash

(Posted 2009) [#8]

The asserts don't effect release build speed as they're only compiled into debug builds.

Well, I certainly did not know that.

I'm sorting out my repo on Git atm.. I should have the new version up soon.

Question: Should not only vec <-> vec operations, but also divisions use an Assert for errors?

matibee

(Posted 2009) [#9]

Just use Asserts where the user (another coder) could pass null, or other obvious (and avoidable) invalid arguments like out of bounds indices into an array. Assert'ing out divide by zero's isn't recommended. With physics sims etc, there's plenty of times a value will decrease to zero - and they're not always 100% repeatable (in a playable game world anyway). The done thing is to handle it in exactly the way you are doing.

If you did put in an assert, then the code user would have to;

if ( myfloat <> 0 )
  vector = v.DivideParamsNew( myfloat )
else
  vector = v.Copy()
end if

So you've basically saved him from doing that around every one of your divide functions (which is a very good thing).

plash

(Posted 2009) [#10]

Here is duct on GitHub: http://github.com/komiga/duct/tree/master

If you don't have Git, you can just hit the download button near the top of the page (downloads as a .zip or .tar).
You might have a few build errors because of an issue with the tilemap module, so the best solution would probably be to just remove it (not only a strange encoding issue, but the code also requires some modifications to brl.glmax2d).

EDIT: I made some modifications to the repo, now it should compile the whole thing without having to remove the tilemap module.