Why is this acting so weird? (GRRLIB related)

/*===========================================
        GRRLIB (GX version) 3.0 alpha
        Code     : NoNameNo
        GX hints : RedShade

        Template Code (Minimum Requirement)
============================================*/
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include "GRRLIB/GRRLIB.h"

#include "gfx/p1body.h"
#include "gfx/p1crosshair.h"
#include "gfx/Untitled.h"

#define PI 3.14159265

Mtx GXmodelView2D;


int main(){
    u8 *tex_p1body=GRRLIB_LoadTexture(p1body);
    u8 *tex_p1crosshair=GRRLIB_LoadTexture(p1crosshair);
    u8 *tex_Untitled=GRRLIB_LoadTexture(Untitled);
   
    float p1rot=0;
    int p1x=240;
    int p1y=240;
	int p1shooting = 0;
	int slow = 0;

	static int shotfromx;
	static int shotfromy;
	static int shoottox;
	static int shoottoy;
		
	static int bulletx;
	static int bullety;
			

    VIDEO_Init();
    WPAD_Init();

    GRRLIB_InitVideo();
    GRRLIB_Start();

	WPADData *wPadp1;
	WPAD_Init();
	WPAD_SetDataFormat(0, WPAD_FMT_BTNS_ACC_IR);
	WPAD_SetVRes(0, 640, 480);

    while(1)
	{
		wPadp1 = WPAD_Data(0);
        WPAD_ScanPads();
        u32 wpaddownp1 = WPAD_ButtonsDown(0);
        u32 wpadheldp1 = WPAD_ButtonsHeld(0);
	  
	  GRRLIB_DrawImg(p1x, p1y, 132, 132, tex_p1body, p1rot, 1, 1, 255 );
	  
	  
	  	if (wPadp1->ir.valid)//Calculates rotation of body according to pointer position. Works OK as far as I can tell.
			{
			GRRLIB_DrawImg(wPadp1->ir.x, wPadp1->ir.y, 48, 48, tex_p1crosshair, wPadp1->ir.angle, 1, 1, 255 );
			p1rot = (atan2(p1y - wPadp1->ir.y, p1x - wPadp1->ir.x) * 180 / PI) - 90;
			}
\
			
		if (p1shooting == 1)
			{
			
			if (slow == 2) //slows bullet movement down a bit
				{
				bullety=((shotfromy - shoottoy)/(shotfromx - shoottox) * bulletx + shotfromy);//y=mx+b
				//if (shotfromx < shoottox) bulletx++; <- Using an if/else statement like this causes the bullet not to be shown at all?
				//else bulletx--;
				bulletx++;
				}
			
			GRRLIB_DrawImg(bulletx, bullety, 64, 64, tex_Untitled, p1rot, 1, 1, 255 );
			
			slow++;
			if (slow > 2) slow = 0;
			
			if (bulletx == shoottox) p1shooting = 0;
			}

		
        GRRLIB_Render();


			//////////////////////////////p1 movement/////////////////////////////////
		if (wpadheldp1 & WPAD_BUTTON_UP) p1y-=3;
		if (wpadheldp1 & WPAD_BUTTON_DOWN) p1y+=3;
		if (wpadheldp1 & WPAD_BUTTON_LEFT) p1x-=3;
		if (wpadheldp1 & WPAD_BUTTON_RIGHT) p1x+=3;

		
		if (p1x>560) p1x=560;
		if (p1x<0) p1x=0;
		if (p1y>400) p1y=400;
		if (p1y<0) p1y=0;
		
		if (wpaddownp1 & WPAD_BUTTON_A && p1shooting == 0) //Grabs current player and pointer positions for use in the shooting code block
		{
		shotfromx = p1x;
		shotfromy = p1y;
		shoottox = wPadp1->ir.x;
		shoottoy = wPadp1->ir.y;
		
		bulletx = shotfromx;
		bullety = shotfromy;
		
		p1shooting = 1;
		}
		
		if (wpaddownp1 & WPAD_BUTTON_B) p1shooting = 0; //Use this to cancel out of shooting if it gets stuck.

        if (wpaddownp1 & WPAD_BUTTON_HOME) exit(0);
		
		
		
		
	}
	
	
    return 0;
}

Basically, I'm trying to make a simple tanks-like game. I had planned on being able to rotate and fire in any direction, but the method I'm using is giving me problems. As you can see, I used a simple y=mx+b equation, but the on-screen results are pretty ugly. The bullet will only move at certain angles, spawn at a random points on the screen, or just not show up at all. Anyone know what's wrong?

<-- source and dol

The first thing that stands out is that you are always moving the bulletx by 1 instead of calculating the amount that this should change in a similar way to how you are calculating bullety

Also the biggest thing I can see is that all your variables are integers and you are performing floating point type operations on them, this will result in truncation and hence some of the strange things that you are seeing.

I think that you would be better off calculating the bullet changes for both x and y when you create the bullet then you only have one set of calculations + no if statements because these changes could be positive or negative. Alternatively, you already have the angle of the target from the tank so you can use this to move the bullet using pre-calculated sine and cosine tables for the derive the x and y changes

You should also move the target and bullet left and up by half the size of the image so that the middles are the same



Edited 5 time(s). Last edit at 01/03/2009 06:11PM by JustWoody.

Thanks for the tips. I changed those static ints to floats, and it's working much better now, at least enough so that I can see what else is going wrong and take steps toward fixing it. I had assumed equations involving decimals would be fully calculated out and THEN truncated to an integer if necessary, but apparently, that's not the case. This is my first coding project, so I guess simple mistakes like that are bound to happen...

No problem Couchy, I hope the project goes well.

I know this would be better suited for the GRRLIB forum, but that place is dead, so...

while(1)
{
  if (wPadp1->ir.valid) 
	{
	GRRLIB_DrawImg(wPadp1->ir.x - 24, wPadp1->ir.y - 24, 48, 48, tex_p1crosshair, wPadp1->ir.angle, 1, 1, 255 );
	float p1rot = (atan2(p1y - wPadp1->ir.y, p1x - wPadp1->ir.x) * 180 / PI);
	float ldotx = cos(p1rot - 1.5707964) * 33; // 1.5707964 = 90 degrees in radians
	float ldoty = sin(p1rot - 1.5707964) * 33;
	float rdotx = cos(p1rot + 1.5707964) * 33;
	float rdoty = sin(p1rot + 1.5707964) * 33;
        GRRLIB_DrawImg(p1x - 33, p1y - 33, 66, 66, tex_p1body, p1rot, 1, 1, 255 );
        GRRLIB_DrawImg(ldotx + p1x - 24, ldoty + p1y - 24, 48, 48, tex_p1crosshair, wPadp1->ir.angle, 1, 1, 255 );
        GRRLIB_DrawImg(rdotx + p1x - 24, rdoty + p1y -24, 48, 48, tex_p1crosshair, wPadp1->ir.angle, 1, 1, 255 );
	}
}

What I'm trying to do here is draw two points on either side of a square to represent that square's hitbox. I wanted to make them account for the square's rotation by having them rotate in sync with it. I know this isn't really vital for a square, but I plan on having rectangles that do the same thing. What happens here is that for every tiny rotation of the square, the hitpoints do about ten laps around it. The hitpoints move around in a circle around the square as they should, just way, way too fast. Is there any way I can get them in sync?

	float p1rot = (atan2(p1y - wPadp1->ir.y, p1x - wPadp1->ir.x) * 180 / PI);
	float ldotx = cos(p1rot - 1.5707964) * 33; // 1.5707964 = 90 degrees in radians
	float ldoty = sin(p1rot - 1.5707964) * 33;
	float rdotx = cos(p1rot + 1.5707964) * 33;
	float rdoty = sin(p1rot + 1.5707964) * 33;

sin() and cos() expect their parameter to be in radians, not degrees - so drop the conversion after the call to atan2()

Ok, I created another variable for the dot positions that's the same as p1rot with the conversion lopped off, and it works beautifully now. Kudos, you guys are life savers! (game savers?) Anyway, it looks to be all downhill from here. :)