Return value from Var must be matching type

BlitzMax Forums/BlitzMax Beginners Area/Return value from Var must be matching type

sswift

(Posted 2006) [#1]

GetViewport(ThisSprite.ViewportX#, ThisSprite.ViewportY#, ThisSprite.ViewportWidth#, ThisSprite.ViewportHeight#)

This won't work.

How do I work around this, without crating four new variables which are ints just for the sake of getting the values back from the function, and then assigning them to by floats?

If you're wondering why I use floats, it's because it makes sense to. If you want to increase the size of a viewport over time, then you may want to add fractional bits to the size each frame, and why should you have to store those somewhere else? That's silly.

I suppose I could access some type in Max directly to get the values without using intermediate vairables, but that's a bit rediculous, not not neccessarily safe.

Unless someone has a clever solution here, I guess you can chalk this up as another reason Var is a sucky concept.

assari

(Posted 2006) [#2]

if your type is TThisSprite then you can do this

GetViewPort(s:TThisSprite)
  s.ViewPortX#=...
  s.ViewPortY#=...
end function

Dreamora

(Posted 2006) [#3]

There does not seem to be a solution as BM somehow refuses to implicitely cast it.

Nor works int( ... ), var int( ... ), varptr int( ... ) and others.
Var is no sucky concept just not fully implemented as other ideas mark borrowed from C#, Eiffel and Java.

tonyg

(Posted 2006) [#4]

Isn't it the setviewport command you have to change in max2d module?

Dreamora

(Posted 2006) [#5]

He wants to get the values, I assume on startup to set them to the actual value.

Haramanai

(Posted 2006) [#6]

Don't forget that BMax it's Open Source for it's users.
Open the Max2D.BMX file.
In there you will find a Type TMax2DGraphics
delete the Private in Line 61.
Make the Mods.
Then you will have the gc Type that it is TMax2dGraphics Type. you can get the values from the fields of the gc don't change them directly but only throu the functions.

tonyg

(Posted 2006) [#7]

So it's the not the definition of the viewport that needs changing just the type of variable returned?
SSwift, and you don't want to write a simple function out of principle?

Function getviewport_float(x# Var,y# Var, w# Var,h# Var)
  GetViewport(x1,y1,w1,h1)
  x#=Float(x1)
  y#=Float(y1)
  w#=Float(w1)
  h#=Float(h1)
End Function

sswift

(Posted 2006) [#8]

The type in Max2D is private by default too? Man this sucks.

Changing it isn't an option. Then anyone who uses this system would have to change it, and if I ever reinstall max, my code breaks.

I guess I have no choice but to do the retarded thing and create temporary variables to hold the data so I can convert it to float after. The only other option is to give up using floats for the viewport.

Why the hell did they have to go and make that private?

sswift

(Posted 2006) [#9]

"SSwift, and you don't want to write a simple function out of principle?"

I know I can do that. I just think it's dumb I should have to. I'm not going to bother making a wrapper funciton like that though, that's overkill. I'm just gonna make some temporary local vars in the function I need to get the values in I guess.

But I guess you could say yes, it's the principle of the thing.

What would be really great is if they'd fix var so that you can cast the return value to different types. It's absurd that you can't stick an int into a float.

Dreamora

(Posted 2006) [#10]

Sadly we have not all sources, otherwise we could shorten the languages list of incapabilities *starting with VAR problems, strong typed ENUMs and the like*. The modules themself are only seldom the problem ...

Haramanai

(Posted 2006) [#11]

It is very easy to put some functions inside the Max2D file like the functions MouseX() and MouseY() and get what you wand.
Just look at the funtion GetOrigin inside the Max2D

TomToad

(Posted 2006) [#12]

sswift, GetViewPort returns nothing. What is happening here is that you are passing GetViewPort pointers to memory where your variables are stored. Then GetViewPort modifies the variables directly through the pointers. GetViewPort expects those pointers to point to Ints. If it tried to modify anything else, then the results would end up corrupt. Might even corrupt other memory if the pointer points to less memory than the function expects.
The only solution would be for Mark to write a function for every possible type that someone would want to pass. That would be a waste of time and space when 99.9% of the programmers out there only want Ints.
This is not a Blitz only thing either. All languages behave this way when passing pointers.

Dreamora

(Posted 2006) [#13]

Not really. Numerics are implicitely casted or can be casted at all to be accepted by Ref. But it seems like in BM its not possible, even if you use varptr ( int ( somefloat#)) it fails although it should work theoretically.

tonyg

(Posted 2006) [#14]

I'm not going to bother making a wrapper funciton like that though, that's overkill.

except you can add it to a 'doitmyway.mod' and make it part of your standard BlitzMax command set.

TomToad

(Posted 2006) [#15]

Dreamora. No, it shouldn't work. When you cast a variable like int(somefloat#), it's not the variable being converted, but rather the value inside the variable. You can't create a reference to that value since the value isn't stored anywhere.
Now if you were to do

local SomeInt:Int = Int(SomeFloat)
Local SomePtr:Int Ptr = Varptr SomeInt

That would work because now the converted value is being stored somewhere that can be referenced.
Some languages, such as c++, do allow you to cast pointers of one type to pointers of another. For instance

Float *Float_ptr;

DoSomething((int *)Float_ptr);

However, if the function DoSomething writes to the area pointed to, it will be as an Int and not a Float. The results will be corrupted. Typically type pointers will be cast when a function deals with the raw data and not with actual values.