MAMEWorld Forums - EmuChat - Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation

1. Function f47 - autopilot speed/own torpedo something

https://www.youtube.com/watch?v=PLwvVmx3XxQ
https://www.youtube.com/watch?v=EX82HhCRfVU

Upon careful investigation of these two videos... It turns out while the cockpit gauge shows only speeds up to 200 units, the actual speed can be much greater, which can be deduced from increased length of the flyby debris lines.

Code:


static void f47(void)
{
	float a = fifoin_pop_f();
	float b = fifoin_pop_f();
	float c = fifoin_pop_f();

//-- own torpedo: c= 0.0
//-- entrance stage 1: c= 427 -> 110
//-- entrance stage 2: c= 51 -> 1427 -> 70 -> 925 -> 105

//-- entrance stage 3: maybe complex, like c= -(a+b+c)?
	if(activecpu_get_pc() == 878671) 
		c+= 140;

	fifoout_push_f(0); //unknown
	fifoout_push_f(c); //speed

	next_fn();
}

I am now confident the second output for own torpedoes as well as for speed upon entering stage 1 and 2 is just the third input "c". For entrance to stage 3 this is not the case, but c+140 is kind of close enough. Oddly, for entrance to stage 4 this function is not used. All things known and unknown considered I think at this point this is satisfactory implementation.

2. Function f50_swa - geometry culling/target lock release

Code:


static float Lx, Ly, Lz;
static float Qx, Qy, Qz;
static void f14(void)
{
	tgp_vr_base[0] = fifoin_pop_f();
	tgp_vr_base[1] = fifoin_pop_f();
	tgp_vr_base[2] = fifoin_pop_f();
	tgp_vr_base[3] = fifoin_pop_f();

//-- grab own ship coordinates
	if(activecpu_get_pc() == 818922)
	{
		Lx= Qx;
		Ly= Qy;
		Lz= Qz;

		Qx= tgp_vr_base[0];
		Qy= tgp_vr_base[1];
		Qz= tgp_vr_base[2];
	}

	next_fn();
}

static void f50_swa(void)
{
	float DST, x,y,z, x1,y1,z1;

	float a = fifoin_pop_f();
	float b = fifoin_pop_f();
	float c = fifoin_pop_f();
	float d = fifoin_pop_f();

	x1= a-Qx;
	y1= b-Qy;
	z1= c-Qz;

	DST= sqrtf(x1*x1 + y1*y1 + z1*z1);
	x1= x1/DST;
	y1= y1/DST;
	z1= z1/DST;

	x= Qx-Lx;
	y= Qy-Ly;
	z= Qz-Lz;

	DST= sqrtf(x*x + y*y + z*z);
	x= x/DST;
	y= y/DST;
	z= z/DST;

//-- dot product: heading * bearing vector
	DST = x1*x + y1*y + z1*z; 

	if((a+b+c) != 0 && d>35 && d<62 && DST < 0.5) 
		DST= -1; else DST= 1;

	fifoout_push_f(DST);
	next_fn();
}

Not knowing better I hack out current (Qx,Qy,Qz) and previous (Lx,Ly,Lz) own ship coordinates from function f14. In function f15_swa, dot product of own heading vector and bearing vector to the object currently evaluated will give us a number from -1 to 1, where -1 means the object is directly behind, 1 means it is directly in front, and 0.5 means it is just a little bit outside field of view.

The reason my previous implementation was not working on stage 2 and for some objects on stage 3 is because their coordinates are (0,0,0) which I guess means they are not meant to be processed at all, hence objects are now skipped unless "(a+b+c) != 0".

This implementation is not concerned with culling any geometry, but only to make torpedo target acquisition system release target lock from tie fighters that move out of FOV, hence objects are skipped unless "d>35 && d<62", which is size range or some kind of ID for tie fighters.

3. ../driver/model1.cpp - throttle input

From those two videos and Genesis 32X port of this game it looks like throttle input should be auto-centering at the middle. Since IPT_PEDAL seems unable to do that I redefine it as IPT_AD_STICK_Z:

PORT_BIT( 0xff, 128, IPT_AD_STICK_Z ) PORT_MINMAX(28,228) PORT_SENSITIVITY(100) PORT_KEYDELTA(16) PORT_REVERSE