Return value from Var must be matching type
BlitzMax Forums/BlitzMax Beginners Area/Return value from Var must be matching type
| ||
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. |
| ||
if your type is TThisSprite then you can do thisGetViewPort(s:TThisSprite) s.ViewPortX#=... s.ViewPortY#=... end function |
| ||
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. |
| ||
Isn't it the setviewport command you have to change in max2d module? |
| ||
He wants to get the values, I assume on startup to set them to the actual value. |
| ||
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. |
| ||
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 |
| ||
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, 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. |
| ||
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 ... |
| ||
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 |
| ||
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. |
| ||
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. |
| ||
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. |
| ||
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. |