MAKE_SPRITE rotation problem

[Guest mgipson]

I have a problem with MAKE_SPRITE.According to the panel SDK the order of the transforms is:1. Rotate, based on SOURCE_VAR_0.2. Scale, based on TEXTURE_SCALE_X and TEXTURE_SCALE_Y.3. Transpose, based on SOURCE_VAR_X and SOURCE_VAR_Y.What seems to happen is that the transposes are rotated as well before being applied. If I rotate and apply a transpose just in Y the sprite is also drawn with some X offset.I don't want this to happen for this particular gauge, I want the sprite to rotate and then simply move up and down with no side to side transpose at all.Does anybody know of a simple way to do this?

[glassman2005 0]

I'm no expert amidst the company in this forum, but I had a similar problem that I resolved by changing the sprite dimensions to be exactly square (the mask can be any shape you want, but the sprite had to be square). The rotation will happen around the "center" that you define in the macro, but if your sprite isn't square, it will rotate strangely. Also double-check your mask and center coordinates in the macro. They are both expressed as coordinates relative to the full gauge background.

[n4gix 4,947]

In addition to what was written in the previous reply, make sure that you either pass as arguments, or include each of the X, Y and O values to all three callbacks... (Note: "rwert" means "rword" or more simply, "return" in English) ;)FLOAT64 FSAPI ATD_callback2( PELEMENT_SPRITE pelement){FLOAT64 rwertX=pelement->source_var_x.var_value.n;FLOAT64 rwertY=pelement->source_var_y.var_value.n;FLOAT64 rwertO=pelement->source_var_0.var_value.n;if ( ATTITUDE_CAGE_BUTTONvar.var_value.n == 0 ) { rwertO = ATTITUDE_INDICATOR_BANK_DEGREESvar.var_value.n ; rwertY = ATTITUDE_INDICATOR_PITCH_DEGREESvar.var_value.n ; } else { rwertO = 0 ; rwertY = 0 ; } if ( panel_lights == 1 ) { HIDE_IMAGE(pelement) ; } else { SHOW_IMAGE(pelement) ; }return rwertX;}FLOAT64 FSAPI ATD_callbackS2( PELEMENT_SPRITE pelement){FLOAT64 rwertY=pelement->source_var_y.var_value.n;FLOAT64 rwertX=pelement->source_var_x.var_value.n;FLOAT64 rwertO=pelement->source_var_0.var_value.n;if ( ATTITUDE_CAGE_BUTTONvar.var_value.n == 0 ) { rwertO = ATTITUDE_INDICATOR_BANK_DEGREESvar.var_value.n ; rwertY = ATTITUDE_INDICATOR_PITCH_DEGREESvar.var_value.n ; } else { rwertO = 0 ; rwertY = 0 ; } if ( panel_lights == 1 ) { HIDE_IMAGE(pelement) ; } else { SHOW_IMAGE(pelement) ; }if ( rwertY > 20 ) { rwertY = 20 ; } if ( rwertY < -20 ) { rwertY = -20 ; } return rwertY;}FLOAT64 FSAPI ATD_callbackST2( PELEMENT_SPRITE pelement){FLOAT64 rwertY=pelement->source_var_y.var_value.n;FLOAT64 rwertX=pelement->source_var_x.var_value.n;FLOAT64 rwertO=pelement->source_var_0.var_value.n;if ( ATTITUDE_CAGE_BUTTONvar.var_value.n == 0 ) { rwertO = ATTITUDE_INDICATOR_BANK_DEGREESvar.var_value.n ; rwertY = ATTITUDE_INDICATOR_PITCH_DEGREESvar.var_value.n ; } else { rwertO = 0 ; rwertY = 0 ; } if ( panel_lights == 1 ) { HIDE_IMAGE(pelement) ; } else { SHOW_IMAGE(pelement) ; }return rwertO;}

[Guest mgipson]

Thanks for the info guys. My problem with the MAKE_SPRITE was not that I could not get it to work, I could not get it to do what I wanted it to. I wanted the sprite to rotate and then move just in the Y axis. If you try this with make sprite it just does not work as it always moves the sprite in the X axis as well, even if the X callback is returning 0. It moves rotates the Y axis as well before applying the Y offset. The make sprite macro seems to be made for a standard ADI and not the type I was making. I went ahead and made it in GDI+ instead!

[n4gix 4,947]

>Thanks for the info guys. My problem with the MAKE_SPRITE was>not that I could not get it to work, I could not get it to do>what I wanted it to. I wanted the sprite to rotate and then>move just in the Y axis. If you try this with make sprite it>just does not work as it always moves the sprite in the X axis>as well, even if the X callback is returning 0. It moves>rotates the Y axis as well before applying the Y offset. The>make sprite macro seems to be made for a standard ADI and not>the type I was making. I went ahead and made it in GDI+>instead!Actually, the MAKE_SPRITE works just fine if the arguments are passed properly. I've used it for years, as have many, many others to animate any possible combination of movement using the X, Y or O axes...But, it is good that you have solved the problem another way... ;)

[Guest mgipson]

MAKE_SPRITE does work, but nobody could help me with getting a sprite to rotate and then just move on the Y axis. Can this be done? Simply passing in 0 for the X argument does not work.See the screengrab for the effect that I want. The airplane sprite has been rotated and then moved up just in the Y axis.

[n4gix 4,947]

What you want to accomplish is precisely how I've coded dozens of horizon indicators. The horizon rises and falls vertically (y axis) and rotates on the O axis.If you posted the exact code you've tried, including the callbacks, someone might be able to spot the problem. As it is, we're all working in a vacuum... ;)I can assure you that the code below will only pitch the horizon up/down and rotate around the O axis. It will not wobble back and forth on the X axis... ;) Note carefully that all parameters are stated in all three callbacks, instead of being passed from the calling function. The only callback that required limits is the pitch axis callback to prevent the horizon from scrolling offscreen...MAKE_SPRITE(ATD_Sprite2,ATD_Rec1,&ATD_ElementList7b,ATD_fail,IMAGE_USE_ERASE | IMAGE_USE_TRANSPARENCY | BIT7,0,0,0,125,129,1.0,1.0,MODULE_VAR_NONE, ATD_cb2,0,MODULE_VAR_NONE,ATD_cbS2,1.42222222222222,MODULE_VAR_NONE,ATD_cbST2,-1)PELEMENT_HEADERATD_ElementList7[] = {&ATD_Sprite2.header,NULL};/////////////////////////////////////////////////////FLOAT64 FSAPI ATD_cb2( PELEMENT_SPRITE pelement){FLOAT64 rwertX=pelement->source_var_x.var_value.n;FLOAT64 rwertY=pelement->source_var_y.var_value.n;FLOAT64 rwertO=pelement->source_var_0.var_value.n;if ( ATTITUDE_CAGE_BUTTONvar.var_value.n == 0 ) { rwertO = ATTITUDE_INDICATOR_BANK_DEGREESvar.var_value.n ; rwertY = ATTITUDE_INDICATOR_PITCH_DEGREESvar.var_value.n ; } else { rwertO = 0 ; rwertY = 0 ; } if ( panel_lights == 1 ) { SHOW_IMAGE(pelement) ; LIGHT_IMAGE(pelement) ; } else { HIDE_IMAGE(pelement) ; } return rwertX;}/////////////////////////////////////////////////////FLOAT64 FSAPI ATD_cbS2( PELEMENT_SPRITE pelement){FLOAT64 rwertY=pelement->source_var_y.var_value.n;FLOAT64 rwertX=pelement->source_var_x.var_value.n;FLOAT64 rwertO=pelement->source_var_0.var_value.n;if ( ATTITUDE_CAGE_BUTTONvar.var_value.n == 0 ) { rwertO = ATTITUDE_INDICATOR_BANK_DEGREESvar.var_value.n ; rwertY = ATTITUDE_INDICATOR_PITCH_DEGREESvar.var_value.n ; } else { rwertO = 0 ; rwertY = 0 ; } if ( panel_lights == 1 ) { SHOW_IMAGE(pelement) ; LIGHT_IMAGE(pelement) ; } else { HIDE_IMAGE(pelement) ; } if ( rwertY > 20 ) { rwertY = 20 ; } if ( rwertY < -20 ) { rwertY = -20 ; } return rwertY;}/////////////////////////////////////////////////////FLOAT64 FSAPI ATD_cbST2( PELEMENT_SPRITE pelement){FLOAT64 rwertY=pelement->source_var_y.var_value.n;FLOAT64 rwertX=pelement->source_var_x.var_value.n;FLOAT64 rwertO=pelement->source_var_0.var_value.n;if ( ATTITUDE_CAGE_BUTTONvar.var_value.n == 0 ) { rwertO = ATTITUDE_INDICATOR_BANK_DEGREESvar.var_value.n ; rwertY = ATTITUDE_INDICATOR_PITCH_DEGREESvar.var_value.n ; } else { rwertO = 0 ; rwertY = 0 ; } if ( panel_lights == 1 ) { SHOW_IMAGE(pelement) ; LIGHT_IMAGE(pelement) ; } else { HIDE_IMAGE(pelement) ; } return rwertO;}

[Guest mgipson]

'What you want to accomplish is precisely how I've coded dozens of horizon indicators.'But it isn't! This horizon indicator works differently from any other that I have seen. Using the above code makes the airplane sprite behave like the horizon indicator on the default Cessna. If you think about how that works the pitch bars always run through the center of the indicator, usually through some fixed aircraft symbol. On this ADI that is not the case. The center of the sprite used on the Cessna ADI is 0 pitch, center of the pitch bars. If you pitch and then roll you will notice that the X axis center of the sprite is no longer in the X axis center of the indicator. The center of the sprite has been translated in the X axis by the make sprite routine. If you look at the screenshot I provided you can see that the center of the sprite must not move away from the center of the indicator. I probably didn't make it clear enough in my earlier posts, it is the center of the sprite that gets moved because make sprite applies the Y translation after it has carried out the rotation and it takes that rotation into account. I want the sprite to be rotated and then translated in the Y axis as if the rotation had not taken place.I have attached 2 screenshots to show what happens to the center of the sprite on the default Cessna and what I need to happen for this ADI.

[n4gix 4,947]

OK, I see more clearly what it is you want to accomplish.Actually, in the case of the Cessna ADI, there is no X axis translation at all. What you see is the effect caused by the X & Y axes being "rotated" around the O axis...If you've solved the problem with GDI+, then this discussion is moot, but for sake of completeness (in case someone else needs this solution), here is how I would "solve" the problem.In order to compensate for the rotation of the X & Y axes such that the image will only translate vertically, you would need to apply the same variable to the X axis as you have the Y axis, calibrated such that any lateral movement caused by rotation of the coordinate system by the O axis is nulified.If pitch shifts the acft symbol "up" 20 pixels, and bank angle rotates the coordinate system 20

[Guest mgipson]

You certainly would have to work out the value for 'Q' and apply that to the X translation in make sprite. Also the Y value would need changing as well. If you wanted the sprite to move down 20 pixels the value would have to be increased to take into account the fact that the movement happens after the rotation. I didn't spend much time on this before as I had to get the gauge done. It should be possible with some trig to get the effect I want. I will go back and get it working when I have time and post the results here.

[n4gix 4,947]

>You certainly would have to work out the value for 'Q' and>apply that to the X translation in make sprite. Also the Y>value would need changing as well. If you wanted the sprite to>move down 20 pixels the value would have to be increased to>take into account the fact that the movement happens after the>rotation. I didn't spend much time on this before as I had to>get the gauge done. It should be possible with some trig to>get the effect I want. I will go back and get it working when>I have time and post the results here.Yes, after I had posted the illustration it occurred to me that one would need a pseudo-Y correction (call it "R") as well, but I had already uploaded the image and had to move on.In any case, the "missing piece of the puzzle" was that the X,Y coordinate system rotates with the O axis... ;)Sorry to have been such a dunce the first time around. I've abandoned complex bitmap gauges months ago and haven't looked back much since... ;)