MAMEWorld >> EmuChat
View all threads Index   Threaded Mode Threaded  

Pages: 1 | 2 |

dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Star Wars Arcade (SEGA, 1993): fixing model1 emulation
#351945 - 03/25/16 01:15 PM



Quote:


The model1 games include somewhere on the board a pair of dsps called TGPs, or MB86233. One is used for T&L, one is used for generalized math operations. The same structure exists in model 2a. The T&L program happens not to be a problem, we're experienced enough to be able to guess what it does and it doesn't seem to change per-game. The math dsp program changes per-game.

In the case of 2a, the math dsp program is uploaded by the main program. From there we've been able to understand how the dsp itself works (it's essentially undocumented otherwise). That made 2a working, and we found out that virtua racing expects essentially the same program than daytona usa.

For the other three games, otoh, we don't have the program. Nobody has even been able to find where in the pcb it is hiding, making decapping a chancy proposition. What is currently working in mame is the result of complete guesswork, see src/machine/model1.c. So if you want to see swa working, you need to continue the guesswork.

Some hints I can give:

- the understanding of the dsp and the use of the daytona program for vr happened *after* the guesswork happened. That means there may be clues about what the functions are supposed to do in the 2a programs
- there is a tgp-accessible rom that the program does lookups into. It was hooked up in vr before the daytona use (the track_* functions). It was not hooked up in swa/wingwar in no small part because someone has to find out which function is supposed to do the lookup in the first place. Only hint I have: acc_seti is probably track_select swa version in reality (which won't change much, there's only one "track" in swa, the parameter is always 0).




http://www.mameworld.info/ubbthreads/sho...amp;o=&vc=1


In that post there Olivier Galibert talks about some "guesswork". I'd like to try poking around, so any more info is welcome. Does this "guesswork" involve changing something in the ROM files, maybe trying to load some parts from a different game? Or is it about making changes in the source code only, and if so what parts of the code should I be looking at?



Olivier Galibert
Semi-Lurker
Reged: 09/21/03
Posts: 352
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#351946 - 03/25/16 02:17 PM


> what parts of the code should I be looking at?

mame/machine/model1.cpp

ftab_vf (virtua racing and virtual fighter) and ftab_swa (star wars arcade and wingwar) are table of functions implemented in the tgp by the program we do not have. The behaviour of every one of these functions is a guess done by observing what the main program does. Not only each one can be wrong, but in addition all of these named f are usually not implemented at all, lacking a guess on what they do. Only the number of inputs and outputs should be correct.

Have fun.

OG.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#351953 - 03/25/16 06:18 PM


Thank you kindly. I was hoping you'd be around, wonderful! Just before I start let me make sure I understand you correctly.


1. When you say ftab_swa, you are referring to this:

Code:


// Used in swa scene 1 and unemulated:
// f14
// f49_swa
// f15_swa

const struct model1_state::function model1_state::ftab_swa[] = {
{ &model1_state::fadd, 2 }, /* 0x00 */
{ &model1_state::fsub, 2 },
{ &model1_state::fmul, 2 },
{ &model1_state::fdiv, 2 },
{ nullptr, 0 },
{ &model1_state::matrix_push, 0 },
{ &model1_state::matrix_pop, 0 },
{ &model1_state::matrix_write, 12 },
{ &model1_state::clear_stack, 0 },
{ &model1_state::matrix_mul, 12 },
{ &model1_state::anglev, 2 },
{ &model1_state::f11, 9 },
{ &model1_state::normalize, 3 },
{ &model1_state::acc_seti, 1 },
{ &model1_state::f14, 4 },
{ &model1_state::f15_swa, 0 },

{ &model1_state::matrix_ident, 0 }, /* 0x10 */
{ &model1_state::matrix_read, 0 },
{ &model1_state::matrix_trans, 3 },
{ &model1_state::matrix_scale, 3 },
{ &model1_state::matrix_rotx, 1 },
{ &model1_state::matrix_roty, 1 },
{ &model1_state::matrix_rotz, 1 },
{ nullptr, 0 },
{ &model1_state::f24_swa, 7 },
{ nullptr, 0 },
{ &model1_state::transform_point, 3 },
{ &model1_state::fsin_m1, 1 },
{ &model1_state::fcos_m1, 1 },
{ &model1_state::fsinm_m1, 2 },
{ &model1_state::fcosm_m1, 2 },
{ &model1_state::distance3, 6 },

{ nullptr, 0 }, /* 0x20 */
{ nullptr, 0 },
{ &model1_state::ftoi, 1 },
{ &model1_state::itof, 1 },
{ &model1_state::acc_set, 1 },
{ &model1_state::acc_get, 0 },
{ &model1_state::acc_add, 1 },
{ &model1_state::acc_sub, 1 },
{ &model1_state::acc_mul, 1 },
{ &model1_state::acc_div, 1 }, // not used ?
{ &model1_state::xyz2rqf, 3 },
{ &model1_state::f43_swa, 3 },
{ &model1_state::matrix_sdir, 3 },
{ &model1_state::f45, 1 },
{ &model1_state::vlength, 3 },
{ &model1_state::f47, 3 },

{ nullptr, 0 }, /* 0x30 */
{ &model1_state::f49_swa, 6 },
{ &model1_state::f50_swa, 4 },
{ nullptr, 0 },
{ &model1_state::f52, 0 },
{ &model1_state::matrix_rdir, 3 },
{ nullptr, 0 },
{ nullptr, 0 },
{ &model1_state::f56, 7 },
{ &model1_state::f57, 0 },
{ &model1_state::matrix_readt, 0 },
{ &model1_state::acc_geti, 0 },
{ &model1_state::f60, 0 },
{ nullptr, 0 },
{ nullptr, 0 },
{ nullptr, 0 },
{ nullptr, 0 },

{ &model1_state::push_and_ident, 0 }, /* 0x40 */
{ nullptr, 0 },
{ &model1_state::catmull_rom, 13 }
};



2. What is the purpose of that number on the right side which seems to range from 0 to 13, is it worth trying or advisable at all to attempt changing this:

{ &model1_state::normalize, 3 },
{ &model1_state::acc_seti, 1 },

...into this, for example:

{ &model1_state::normalize, 5 },
{ &model1_state::acc_seti, 8 },


3. Does order of the entries matter, and is it known? In other words, is it worth trying or advisable at all to attempt changing this:

{ &model1_state::matrix_write, 12 },
{ &model1_state::clear_stack, 0 },

...into this, for example:

{ &model1_state::clear_stack, 0 },
{ &model1_state::matrix_write, 12 },


4. Or better yet, can you give me some example or pointers what kind of thing should I try experimenting with?


5. Considering Wing War seems to be working fine with just those implemented functions, would you say chances are Star Wars needs coding some new function to work properly, or perhaps just shifting existing things around could solve the problem?



By the way, in the Service Mode I ran the memory test and under TGP IC57 section it said "TGP TROUBLE". Maybe this testing program and the data against which it runs the test is accessible and holds useful information to figure this TGP thing out?



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#351990 - 03/26/16 04:40 PM


So far figured I should concentrate on functions f14, f15_swa, and vlenght, as they are called at least once per frame. Input arguments for f14 are xyz coordinates plus forth value which seems to be constant 50.399 number. vlenght is broken and it has to do something with collision detection and also with the flyby debris. In its current implementation vlenght uses values received by f14, and when these are disabled the flyby debris stays fixed and there is no collision, so the game does not lock up in the constant collision at the beginning but can actually be played further and I even completed the 1st stage. Its far from playable though as the camera rotates in the wrong direction, opposite to ship rotation. I hope some change of +/- sign would fix that, and then only collision detection remains, I guess.


Can someone tell me how can I get some kind of "frame-number" or something among those lines, so I can printf it next to other function variables in order to determine how many times per frame that function is being called?



drewcifer
One bad Mutha-(shut yo' mouth!)
Reged: 07/01/04
Posts: 427
Loc: Sweden
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352022 - 03/27/16 09:19 AM


> Can someone tell me how can I get some kind of "frame-number" or something among
> those lines, so I can printf it next to other function variables in order to
> determine how many times per frame that function is being called?

I would guess screen_update_model1() is called once per frame. As per this code in the machine config :

MCFG_SCREEN_UPDATE_DRIVER(model1_state, screen_update_model1)
MCFG_SCREEN_VBLANK_DRIVER(model1_state, screen_eof_model1)

Adding a counter in there would probably do what you want it to do. Or in the eof() function.

/Andrew



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: drewcifer]
#352026 - 03/27/16 02:35 PM


Progress! Managed to make camera follow the ship, that is to say cross-hair now stays centered on the screen in cockpit view. The bad news is I didn't really figure out how the game originally does it, instead I just used a large hammer and hacked it out. Nevertheless it's a great improvement for me as it is now much more enjoyable to test. Visually quite "playable", but not actually, as collision detection for the lasers is screwed and for the ship non-existent.


> Adding a counter in there would probably do what you want it to do. Or in the eof() function.
>
> /Andrew

Thanks. I found "end_frame(void)" in /video/model1.c and there I placed my counter reset. Having frame counter I was able to figure out that for each frame, after f14 function was called once, the second call to matrix_roty is for the camera. Then I simply made angle = -angle for that one particular call and now the camera follows the ship instead of going in opposite direction.



gregf
Ramtek's Trivia promoter
Reged: 09/21/03
Posts: 7090
Loc: southern CA, US
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352040 - 03/27/16 07:55 PM




Quote:




Progress! Managed to make camera follow the ship, that is to say cross-hair now stays centered on the screen in cockpit view. The bad news is I didn't really figure out how the game originally does it, instead I just used a large hammer and hacked it out. Nevertheless it's a great improvement for me as it is now much more enjoyable to test. Visually quite "playable", but not actually, as collision detection for the lasers is screwed and for the ship non-existent.


> Adding a counter in there would probably do what you want it to do. Or in the eof() function.
>
> /Andrew

Thanks. I found "end_frame(void)" in /video/model1.c and there I placed my counter reset. Having frame counter I was able to figure out that for each frame, after f14 function was called once, the second call to matrix_roty is for the camera. Then I simply made angle = -angle for that one particular call and now the camera follows the ship instead of going in opposite direction.





Other than SailorSat's great Model 1 game multi cab linking work, I believe the only previous update was done by RB.

http://rbelmont.mameworld.info/?m=201212


Good work in case it gets supported into MAME later.



R. Belmont
Cuckoo for Konami
Reged: 09/21/03
Posts: 9612
Loc: ECV-197 The Orville
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: gregf]
#352079 - 03/28/16 10:31 PM


> Other than SailorSat's great Model 1 game multi cab linking work, I believe the only
> previous update was done by RB.
>
> http://rbelmont.mameworld.info/?m=201212

That was just for audio though



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: R. Belmont]
#352096 - 03/29/16 03:28 AM


Significant progress!! Own lasers collision detection fixed, so now asteroids, tie-fighters and turrets can be shot regardless of the heading, where before collision point would be aligned with visual laser hit point only when flying along z-axis. It's quite playable now, there is just no collision detection with the environment.

Even better, this time I actually figured out something about inner workings of the game, namely that previously undefined function f15_swa sets up own ship rotation matrix.

For anyone who wants to see these changes in action I can upload windows binary or post source code.

I also have more information and some leads on how to tackle collision detection, even managed to get it working to some degree, but there are still far too many unknowns. On the bright side, it seems collision geometry is in place already and just needs defining where own ship is in relation to everything else. Olivier, I need your help for this, to put into perspective all the new info I have now.


Quote:


> That was just for audio though




Wasn't there some kind of MPEG patent issue, how did you get around that?



Olivier Galibert
Semi-Lurker
Reged: 09/21/03
Posts: 352
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352108 - 03/29/16 03:13 PM


> For anyone who wants to see these changes in action I can upload windows binary or
> post source code.

I'm obviously interested by the source code.


> I also have more information and some leads on how to tackle collision detection,
> even managed to get it working to some degree, but there are still far too many
> unknowns. On the bright side, it seems collision geometry is in place already and
> just needs defining where own ship is in relation to everything else. Olivier, I need
> your help for this, to put into perspective all the new info I have now.

Sure.

> > That was just for audio though
>
> Wasn't there some kind of MPEG patent issue, how did you get around that?

Patent expired :-)

OG.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352113 - 03/29/16 06:24 PM


I should mention I'm working on MAME 114 as I had that already set up and the latest build didn't want to compile for some reason I couldn't bother to look into, but I don't think that's going to be an issue for now. I will move to 171 as soon as I manage to compile, probably just need to download the latest building tools. Ok, here we go...


1. To disable collision detection I consulted MAME 113 where there is none and borrowed some code from it:

Code:

static void fdiv(void)
{
float a = fifoin_pop_f();
float b = fifoin_pop_f();

//use this old one, even if wrong
float r = !b ? 1e39 : a/b;
// float r = !b ? 0 : a * (1/b);

fifoout_push_f(r);
next_fn();
}

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

fifoout_push_f(sqrt(a*a+b*b+c*c));
next_fn();
}


This vlength implementation also makes more sense to me than the new one. I think it's used by collision detection to calculate distance from own ship to various environment objects. I don't think there needs to be any coordinate subtraction as own ship could very well be set at the origin for the whole collision detection calculation, and also they could have made it to receive six arguments if they wanted to calculate distances between two arbitrary points, plus such function already exist: "distance3". Out value has to be minimum 20,000 in order not to lock in constant collision at the beginning of the 1st stage, so this would do just as well: fifoout_push_f(20000); BUT not for the 2nd stage!


2. Grab X,Y,Z rotation angles of own ship/camera: INT16 QrotX, QrotY, QrotZ. I could not find a better way to obtain those angles than to hack them out of matrix_rot functions. For that I needed to know when one frame ends and the next one begins, then wait for the second call to matrix_rot after f14 function is called the first time. So I have counters: extern int QQ and int QZ. In ../video/model1.c function end_frame I reset QQ counter:


Code:

static void end_frame(void)
{
unsigned long i;
if((listctl[0] & 4) && (cpu_getcurrentframe() & 1))
listctl[0] ^= 0x40;

QQ= 0;
}


Then back in ../machine/model1.c function f14 I reset QZ counter and start counting calls to f14 with QQ counter:


Code:

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

QQ++;
QZ= 0;

next_fn();
}


Now, matrix_rot functions for this particular call to set up own ship/camera rotation are accessed in this order: _roty, _rotx, _rotz, therefore I increase QZ counter in _roty and finish grab operation with _rotz:


Code:

static void matrix_roty(void)
{
INT16 a;
float s;
float c;
float t1, t2;

a = fifoin_pop();

QZ++;
if(QQ == 1 && QZ == 2) QrotY= a;

s = tsin(a);
c = tcos(a);
t1 = cmat[6];
t2 = cmat[0];
cmat[6] = c*t1-s*t2;
cmat[0] = s*t1+c*t2;
t1 = cmat[7];
t2 = cmat[1];
cmat[7] = c*t1-s*t2;
cmat[1] = s*t1+c*t2;
t1 = cmat[8];
t2 = cmat[2];
cmat[8] = c*t1-s*t2;
cmat[2] = s*t1+c*t2;

next_fn();
}

static void matrix_rotx(void)
{
INT16 a;
float s;
float c;
float t1, t2;

a = fifoin_pop();

if(QQ == 1 && QZ == 2) QrotX= a;

s = tsin(a);
c = tcos(a);
t1 = cmat[3];
t2 = cmat[6];
cmat[3] = c*t1-s*t2;
cmat[6] = s*t1+c*t2;
t1 = cmat[4];
t2 = cmat[7];
cmat[4] = c*t1-s*t2;
cmat[7] = s*t1+c*t2;
t1 = cmat[5];
t2 = cmat[8];
cmat[5] = c*t1-s*t2;
cmat[8] = s*t1+c*t2;

next_fn();
}

static void matrix_rotz(void)
{
INT16 a;
float s;
float c;
float t1, t2;

a = fifoin_pop();

if(QQ == 1 && QZ == 2)
{
QrotZ= a;

//finish it here like this as there are more calls to
//_rotx and _rotz before QQ/QZ counters change
QZ= 99;
}

s = tsin(a);
c = tcos(a);
t1 = cmat[0];
t2 = cmat[3];
cmat[0] = c*t1-s*t2;
cmat[3] = s*t1+c*t2;
t1 = cmat[1];
t2 = cmat[4];
cmat[1] = c*t1-s*t2;
cmat[4] = s*t1+c*t2;
t1 = cmat[2];
t2 = cmat[5];
cmat[2] = c*t1-s*t2;
cmat[5] = s*t1+c*t2;

next_fn();
}


3. Finally, having now stored these three angles in QrotX, QrotY, and QrotZ, we can make function f15_swa like this (rotating backwards z->x->y is important in order to avoid "gimbal lock" type of problem):


Code:

static void f15_swa(void)
{
int i;
INT16 a;
float s;
float c;
float t1, t2;

// -- rot identity: reset rotation matrix,
//but leave position (cmat[9],cmat[10],cmat[11])
for(i=0; i < 9; i++)
cmat[i]= 0;

cmat[0] = 1.0;
cmat[4] = 1.0;
cmat[8] = 1.0;


// -- Z rotation
a = -QrotZ;

s = tsin(a);
c = tcos(a);
t1 = cmat[0];
t2 = cmat[3];
cmat[0] = c*t1-s*t2;
cmat[3] = s*t1+c*t2;
t1 = cmat[1];
t2 = cmat[4];
cmat[1] = c*t1-s*t2;
cmat[4] = s*t1+c*t2;
t1 = cmat[2];
t2 = cmat[5];
cmat[2] = c*t1-s*t2;
cmat[5] = s*t1+c*t2;

// -- X rotation
a= -QrotX;

s = tsin(a);
c = tcos(a);
t1 = cmat[3];
t2 = cmat[6];
cmat[3] = c*t1-s*t2;
cmat[6] = s*t1+c*t2;
t1 = cmat[4];
t2 = cmat[7];
cmat[4] = c*t1-s*t2;
cmat[7] = s*t1+c*t2;
t1 = cmat[5];
t2 = cmat[8];
cmat[5] = c*t1-s*t2;
cmat[8] = s*t1+c*t2;

// -- Y rotation
a= -QrotY;

s = tsin(a);
c = tcos(a);
t1 = cmat[6];
t2 = cmat[0];
cmat[6] = c*t1-s*t2;
cmat[0] = s*t1+c*t2;
t1 = cmat[7];
t2 = cmat[1];
cmat[7] = c*t1-s*t2;
cmat[1] = s*t1+c*t2;
t1 = cmat[8];
t2 = cmat[2];
cmat[8] = c*t1-s*t2;
cmat[2] = s*t1+c*t2;

next_fn();
}


That's it. I think you will agree it's a very nice improvement and hope it will give you motivation to solve the rest of the issues together. I also hope you, or someone, should be able to figure out how to obtain those rotation angles in more elegant way, perhaps by somehow locating where the call to those matrix_rot functions originates and then work out something from there. I tried reading inputs and outputs of many of those TGP functions but could not find any that would compare to those angles. I have more to say and lot more to ask, but I have to leave it at this for now.


By the way, I'm trying to make "tiny" compile with just those four model1 games, and get this message: "swa uses non-present CPU". This is what I have in tiny.mak:

Code:


CPUS += Z80
CPUS += V60
CPUS += 68000

SOUNDS += YM3438
SOUNDS += MULTIPCM
SOUNDS += DAC
SOUNDS += YM2151


...what CPU am I missing?



Ville Linde
Slacker
Reged: 05/09/04
Posts: 76
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352115 - 03/29/16 06:35 PM


>
> By the way, I'm trying to make "tiny" compile with just those four model1 games, and
> get this message: "swa uses non-present CPU". This is what I have in tiny.mak:
>

You can make a mini build with just the model1 driver: "make SOURCES=src/mame/drivers/model1.cpp REGENIE=1"



Osso1
Reged: 10/17/04
Posts: 200
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Ville Linde]
#352116 - 03/29/16 06:43 PM


if he updates to latest source..

EDIT: you'll also need mpeg_audio.cpp,so: make -j5 SUBTARGET=m SOURCES=src/mame/drivers/model1.cpp,src/devices/sound/mpeg_audio.cpp REGENIE=1

Edited by Osso1 (03/29/16 07:12 PM)



Formerly (un)known as hanamichi on the mameworld.info message boards.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Osso1]
#352150 - 03/30/16 07:15 AM


I'm on WinXP 32-bit, compile fails:

Converting src/mame/layout/wpc_an.lay...
...or/My Documents/Downloads/!SOURCE/m171/scripts/genie.lua:1291: attempt to cal
l a nil value
stack traceback:
...or/My Documents/Downloads/!SOURCE/m171/scripts/genie.lua:1291: in mai
n chunk
[C]: in upvalue 'builtin_dofile'
[string "premake = { }..."]:78: in function 'dofile'
[string "_WORKING_DIR = os.getcwd()..."]:41: in function '_premak
e_main'
makefile:861: recipe for target 'build/projects/windows/mamem/gmake-mingw32-gcc/
Makefile' failed
make: *** [build/projects/windows/mamem/gmake-mingw32-gcc/Makefile] Error 1
make: *** Waiting for unfinished jobs....
Converting src/mame/layout/fidel_csc.lay...



MooglyGuy
Renegade MAME Dev
Reged: 09/01/05
Posts: 1662
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352152 - 03/30/16 08:28 AM


> I'm on WinXP 32-bit, compile fails:
>
> Converting src/mame/layout/wpc_an.lay...
> ...or/My Documents/Downloads/!SOURCE/m171/scripts/genie.lua attempt to cal
> l a nil value
> stack traceback:
> ...or/My Documents/Downloads/!SOURCE/m171/scripts/genie.lua in mai
> n chunk
> [C]: in upvalue 'builtin_dofile'
> [string "premake = { }..."] in function 'dofile'
> [string "_WORKING_DIR = os.getcwd()..."] in function '_premak
> e_main'
> makefile recipe for target 'build/projects/windows/mamem/gmake-mingw32-gcc/
> Makefile' failed
> make: *** [build/projects/windows/mamem/gmake-mingw32-gcc/Makefile] Error 1
> make: *** Waiting for unfinished jobs....
> Converting src/mame/layout/fidel_csc.lay...

What happens if you take out the "-j5" part? And just how old is your PC?



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: MooglyGuy]
#352153 - 03/30/16 09:23 AM


Pretty old, Pentium D @ 3GHz and 2GB RAM. Haven't encountered a good enough reason to upgrade yet. Without -j5 it's basically the same error but different breaking point:

Converting src/mame/layout/lucky8.lay...
make[1]: Entering directory 'C:/Documents and Settings/Administrator/My Document
s/Downloads/!SOURCE/m171/src/devices/cpu/m68000'
Linking m68kmake...
Generating M68K source files...

Musashi v4.90 680x0, CPU32, and ColdFire emulator
Copyright Karl Stenerud and the MAME team.

Generated 1972 opcode handlers from 523 primitives
make[1]: Leaving directory 'C:/Documents and Settings/Administrator/My Documents
/Downloads/!SOURCE/m171/src/devices/cpu/m68000'
...or/My Documents/Downloads/!SOURCE/m171/scripts/genie.lua:1291: attempt to cal
l a nil value

stack traceback:
...or/My Documents/Downloads/!SOURCE/m171/scripts/genie.lua:1291: in mai
n chunk
[C]: in upvalue 'builtin_dofile'
[string "premake = { }..."]:78: in function 'dofile'
[string "_WORKING_DIR = os.getcwd()..."]:41: in function '_premak
e_main'
makefile:861: recipe for target 'build/projects/windows/mamem/gmake-mingw32-gcc/
Makefile' failed
make: *** [build/projects/windows/mamem/gmake-mingw32-gcc/Makefile] Error 1


Perhaps it's memory or console related. I downloaded the latest tools (msys32) and use win32env.bat. In any case it doesn't seem right it goes on to compile hundreds of those layout files when none of them, whatever they are, I think are needed for just those four model1 games.



Olivier Galibert
Semi-Lurker
Reged: 09/21/03
Posts: 352
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352154 - 03/30/16 09:59 AM


Errr, you have a '!' in your path? That may be fucking things up. I know it shouldn't, but I wouldn't be surprised if it does.

OG.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352157 - 03/30/16 12:30 PM Attachment: swa.zip 17 KB (11 downloads)



Quote:


> Errr, you have a '!' in your path? That may be fucking things up. I know it
> shouldn't, but I wouldn't be surprised if it does.
>
> OG.




That was it, what an eye!

Huge drawback with MAME 171 is that save-state doesn't work anymore. It works in the same run, but when I quit and start the game again it will not load but crashes with this message:

-----------------------------------------------------
Exception at EIP=0050FA59 (not found): ACCESS VIOLATION
While attempting to read memory at 00000008
-----------------------------------------------------
EAX=00000000 EBX=0B565A48 ECX=0F71D000 EDX=0F71D400
ESI=05B7EAF8 EDI=00000620 EBP=00000000 ESP=0022C910
-----------------------------------------------------
Stack crawl:
00000000: 0050FA59 (not found)


Having no save-state will considerably slow down testing. Someone please fix it! Anyway, I forgot to mention about the flyby debris or "star-field". When entering the first stage you can see it all grouped in a cube shape flying past on the left hand side, but if you reset the game (F3) then it will all be ok, for some strange reason. It can be made to work from the beginning without reset by setting fifoout_push_f(20000) in vlength function, but then upon entering the 2nd stage the ship will lock up in constant collision. Hopefully this gives you some clues about what is going on there.

Can you explain a bit the process of how did you go about making those TGP functions to begin with out of nothing? How did you get clues on what are they supposed to do? Did you use the debugger or what?

I attached source code with my changes for MAME 171.



Ville Linde
Slacker
Reged: 05/09/04
Posts: 76
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352167 - 03/30/16 03:11 PM


I didn't check the maths in great detail, but could f15 be something simple, like inverse of the current matrix?



SmitdoggAdministrator
Reged: 09/18/03
Posts: 16266
Send PM


May the Force be with you new [Re: dkongjr]
#352168 - 03/30/16 03:27 PM


Always



R. Belmont
Cuckoo for Konami
Reged: 09/21/03
Posts: 9612
Loc: ECV-197 The Orville
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352169 - 03/30/16 04:46 PM


> Perhaps it's memory or console related. I downloaded the latest tools (msys32) and
> use win32env.bat. In any case it doesn't seem right it goes on to compile hundreds of
> those layout files when none of them, whatever they are, I think are needed for just
> those four model1 games.

All of the layout files (and all of the disk/tape format files) compile regardless of what the actual target is. That's a choice Micko made, because it doesn't generally take long to build those.



Olivier Galibert
Semi-Lurker
Reged: 09/21/03
Posts: 352
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Ville Linde]
#352225 - 03/31/16 12:22 PM


> I didn't check the maths in great detail, but could f15 be something simple, like
> inverse of the current matrix?

Could be. Surprising if it's only in swa though. Also, the inverse of a rotation matrix is its transpose, and we don't currently have a transpose function, interestingly.

OG.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352323 - 04/02/16 06:52 AM


So, do you think you can improve or add on what I have done? Any suggestions on how to proceed from here?

Is it possible TGP functions can themselves call other TGP functions, like pop/push matrix for example?



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352456 - 04/04/16 02:53 PM


More progress! Collision detection with Imperial lasers and torpedoes working now. By some chance I actually had that working early on, but didn't pay attention as I didn't know there was a problem with it. When finally realized this invulnerability I had already lost track of my changes and it took me quite some time to trace back and find out what made it work. Contrary to what I said earlier vlength function does need coordinate subtraction, and this also fixes flyby debris problem:

Code:

static void vlength(void)
{
float a = fifoin_pop_f() - tgp_vr_base[0];
float b = fifoin_pop_f() - tgp_vr_base[1];
float c = fifoin_pop_f() - tgp_vr_base[2];

a = (a*a+b*b+c*c);
b = sqrt(a);
c = b - tgp_vr_base[3];

fifoout_push_f(c);
next_fn();
}


Regarding collision detection with the environment, when f60 function is set to output: 2,2,1 instead of 0,0,0 then on the second stage collision kind of works against the left wall and the floor, but with the right wall and the ceiling only from the outside?! With those same settings on the first stage collision is detected around center of the Star Destroyers, and at some seemingly random points (asteroids maybe?). Interestingly when function f24_swa is set to output 1 instead of 0 collision gets disabled. It's completely unclear to me what is going on, but at least I am narrowing down where to look at.





MooglyGuy
Renegade MAME Dev
Reged: 09/01/05
Posts: 1662
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352458 - 04/04/16 03:41 PM


Just so you know for the future, you can use -aviwrite rather than using screen-capture software. This will have the advantage of better video quality, no watermark, and direct-from-game audio so that people can't hear what's going on in the room around you.



Ville Linde
Slacker
Reged: 05/09/04
Posts: 76
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352479 - 04/04/16 05:37 PM


> Regarding collision detection with the environment, when f60 function is set to
> output: 2,2,1 instead of 0,0,0 then on the second stage collision kind of works
> against the left wall and the floor, but with the right wall and the ceiling only
> from the outside?! With those same settings on the first stage collision is detected
> around center of the Star Destroyers, and at some seemingly random points (asteroids
> maybe?). Interestingly when function f24_swa is set to output 1 instead of 0
> collision gets disabled. It's completely unclear to me what is going on, but at least
> I am narrowing down where to look at.

Sounds to me like f60 is used to return the result of a ray vs. plane intersection point in 3D coords.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Ville Linde]
#352497 - 04/04/16 09:26 PM



Quote:


Sounds to me like f60 is used to return the result of a ray vs. plane intersection point in 3D coords.




Yes, and when -2,2,1 is output instead of 2,2,1 then the ship collides with the right wall from inside the trench and with the left wall from the outside. But before the game gets there it obviously already knows where the wall and the ship is. This function just tells it which way to bounce the ship off, and it's kind of side effect it actually triggers collision reaction, that is loss of shield/energy beside the bounce, as this reaction, it seems, could be activated from the main function which calculated the ship intersects a wall in the first place.

In any case, the problem is there are no any input arguments to this function. I could get the ray from the ship's rotation matrix, but what plane, where does the function get this info from? Just like f15_swa that sets up camera rotation matrix and has no any input arguments, where does it get rotation angles from? I don't know where to even begin looking, don't know what is there to look at. Without Olivier there is only so much I can do by stabbing around in the dark. I only hope I dug up enough info so he can make sense of it and finally complete what he started a decade ago.



Olivier Galibert
Semi-Lurker
Reged: 09/21/03
Posts: 352
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352500 - 04/04/16 10:55 PM


So, I've added transpose, filled in some gaps using the daitona code as a reference.

Collision goes:
- load_base of the ship position and size
- vlength with every object, subtract its size, see if it's negative (biggest object is 20K, hence the limit you see)

If the vlength test goes negative, then:
- transform two points from the ship in the object space (or the other way around)
- call f49_swa with the two points and an index (around 0x9c0), three times. Probably refers to the tgp data roms
- if one f49_swa answers 0, then there is collision

If there is collision:
- two points computed by f49_swa are looked up (with f57 and f60)
- compute some stuff with them, not sure what yet, but the code is theorically all there if the points are correct

So, f49_swa is critical right now. I need to have a look at the roms. Please keep experimenting, your results are quite interesting.

OG.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352524 - 04/05/16 11:18 AM


It's good to know you are working on it. So close, you can do it... just do it!




There was a strange change going from 113 to 114 in functions: normalize, distance3, xyz2rqf, col_testpt, and distance:

sqrt(a*a+b*b+c*c)

...turned into:

(a*a+b*b+c*c)/sqrt(a*a+b*b+c*c)


Code:

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

1. float n = sqrt(a*a+b*b+c*c);
2. float n = (a*a+b*b+c*c)/sqrt(a*a+b*b+c*c);

fifoout_push_f(a/n);
fifoout_push_f(b/n);
fifoout_push_f(c/n);
next_fn();
}


I'm not sure how that fits in the game logic as I don't notice any practical difference in neither of the four games, but the second, that is current, implementation I'm pretty sure is mathematically wrong.



Ville Linde
Slacker
Reged: 05/09/04
Posts: 76
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352527 - 04/05/16 01:23 PM


> I'm not sure how that fits in the game logic as I don't notice any practical
> difference in neither of the four games, but the second, that is current,
> implementation I'm pretty sure is mathematically wrong.

That's just redundant. They produce the same result.



jonwil
Lurker
Reged: 10/06/03
Posts: 453
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352528 - 04/05/16 01:28 PM


Has running trojans on an actual Star Wars Arcade board been considered?
For example if we know or think that a function is doing a particular operation (say matrix transpose or vector length) you could run that function with various known inputs and see what the outputs look like and use that to reverse engineer the math involved.

I am not 100% sure but I believe such tricks were used to simulate some of the SNES custom DSP chips before those chips were subsequently read out and properly emulated and I see no reason it couldn't be used to help with Star Wars Arcade.



Olivier Galibert
Semi-Lurker
Reged: 09/21/03
Posts: 352
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: jonwil]
#352529 - 04/05/16 02:33 PM


> Has running trojans on an actual Star Wars Arcade board been considered?
> For example if we know or think that a function is doing a particular operation (say
> matrix transpose or vector length) you could run that function with various known
> inputs and see what the outputs look like and use that to reverse engineer the math
> involved.

Can we borrow your star wars arcade cabinet then?

OG.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Ville Linde]
#352530 - 04/05/16 02:46 PM


> That's just redundant. They produce the same result.

Ay! At least I was correct to say it's strange.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352531 - 04/05/16 03:21 PM


> So, I've added transpose, filled in some gaps using the daitona code as a reference.
>
> Collision goes:
> - load_base of the ship position and size
> - vlength with every object, subtract its size, see if it's negative (biggest object
> is 20K, hence the limit you see)
>
> If the vlength test goes negative, then:
> - transform two points from the ship in the object space (or the other way around)
> - call f49_swa with the two points and an index (around 0x9c0), three times. Probably
> refers to the tgp data roms
> - if one f49_swa answers 0, then there is collision
>
> If there is collision:
> - two points computed by f49_swa are looked up (with f57 and f60)
> - compute some stuff with them, not sure what yet, but the code is theorically all
> there if the points are correct
>
> So, f49_swa is critical right now. I need to have a look at the roms. Please keep
> experimenting, your results are quite interesting.
>
> OG.

I think you are meaning to say f24_swa instead of f49_swa. f24_swa is the one with 7 input arguments, six floats and one integer (index). Index of what by the way? Also, have you considered those six floats instead of two points could be a ray and a plane?


Anyway, f49_swa has constant input:
50 50 248 -248 192 -192
50 50 20 -20 20 -20

...until it changes to:
50 50 248 -248 192 -192
50 50 80 -80 80 -80

The change occurs and lasts eleven frames when a new torpedo target is acquired (yellow bracket), and then it goes back to usual. Speaking of which, there is a bug with this targeting system and also spawning/moving of Tie fighters. Target acquisition system should release a target at some point when outside of field of view, but it doesn't always. And then to make it worse these locked-on Tie fighters either move or re-spawn at very far distance away. So first you can't use torpedoes on nearby targets when all three target locks are taken, and second you can't approach these far away Tie's to take them down and complete a level.



R. Belmont
Cuckoo for Konami
Reged: 09/21/03
Posts: 9612
Loc: ECV-197 The Orville
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: jonwil]
#352535 - 04/05/16 05:15 PM


> Has running trojans on an actual Star Wars Arcade board been considered?
> For example if we know or think that a function is doing a particular operation (say
> matrix transpose or vector length) you could run that function with various known
> inputs and see what the outputs look like and use that to reverse engineer the math
> involved.

Working SWA boardsets are hard to find, and I don't think any of the common multi-targetable assemblers support V60/V70.



AaronGiles
Galaxiwarrior
Reged: 09/21/03
Posts: 1334
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: R. Belmont]
#352545 - 04/05/16 06:59 PM


> Working SWA boardsets are hard to find, and I don't think any of the common
> multi-targetable assemblers support V60/V70.

I wrote a v60/v70 assembler a while back. Charles and I used it for some System 32 RE. I'll see if I can find the sources and put them on GitHub.



Ville Linde
Slacker
Reged: 05/09/04
Posts: 76
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352547 - 04/05/16 07:00 PM


> I think you are meaning to say f24_swa instead of f49_swa. f24_swa is the one with 7
> input arguments, six floats and one integer (index). Index of what by the way? Also,
> have you considered those six floats instead of two points could be a ray and a
> plane?

Plane equation uses 4 parameters. But you could make a ray from 2 points.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352548 - 04/05/16 07:15 PM


Post deleted.

Scrap that. Six floats input arguments to f24_swa define two vectors starting at the center of an object and going to one point at the back of own ship and the the other in front of it. This could be used to hack out collision with asteroids, but what we really want and absolutely must have for more complex geometry is the seventh input argument, the index, which ought to be pointing to more precise geometry definition, like a plane or bounding box.

Edited by dkongjr (04/05/16 10:42 PM)



Olivier Galibert
Semi-Lurker
Reged: 09/21/03
Posts: 352
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352554 - 04/05/16 10:39 PM


> TGP f24_swa: -200.91, -578.05, -1498.84 | -198.68, -555.76, -1406.55

After study of the code, I can tell you these are the previous and current coordinates of the ship after changing to a basis relative to the asteroid. Definitively a collision function.

> If f24_swa outputs any number below or above zero then function f60 will not be
> called and there will be no collision.

The test is zero-or-not-zero, and if not zero the actual value is unimportant. It's a pure "is there a collision" flag. The question is a collision with what.

OG.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352556 - 04/05/16 11:17 PM


I just deleted that post, your reply was not there when I started editing.


Quote:


After study of the code, I can tell you these are the previous and current coordinates of the ship after changing to a basis relative to the asteroid. Definitively a collision function




They seem to be two vectors.

Aproaching:
*** f24_swa: 1686.60, 1544.03 (1493.63)
*** f24_swa: 1544.03, 1401.53 (1351.13)
*** f24_swa: 1401.53, 1259.15 (1208.75)
*** f24_swa: 1259.15, 1116.95 (1066.55)
*** f24_swa: 1116.95, 975.02 (924.62)
*** f24_swa: 975.02, 833.51 (783.11)
*** f24_swa: 833.51, 692.69 (642.29)
*** f24_swa: 692.69, 553.10 (502.70)
*** f24_swa: 553.10, 416.01 (365.61)
*** f24_swa: 416.01, 285.07 (234.67)
*** f24_swa: 285.07, 174.69 (124.29)
*** f24_swa: 174.69, 144.32 (93.92)

Moving away:
*** f24_swa: 144.32, 228.49 (178.09)
*** f24_swa: 228.49, 353.06 (302.66)
*** f24_swa: 353.06, 488.01 (437.61)
*** f24_swa: 488.01, 626.66 (576.26)
*** f24_swa: 626.66, 767.00 (716.60)
*** f24_swa: 767.00, 908.25 (857.85)
*** f24_swa: 908.25, 1050.02 (999.62)
*** f24_swa: 1050.02, 1192.13 (1141.73)
*** f24_swa: 1192.13, 1334.45 (1284.05)
*** f24_swa: 1334.45, 1476.92 (1426.52)


There I print out: sqrt(a*a+b*b+c*c), sqrt(d*d+e*e+f*f). The number in the brackets is the distance from vlength function, which is always smaller than the second number by 50.4 (tgp_vr_base[3] from f14). You can see the first number is larger on approach and smaller than the second one when moving away, so I conclude the first vector points to behind of own ship and the second in front. The same happens when going through a Star Destroyer.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352558 - 04/05/16 11:45 PM


Vectors, coordinates... in either case there is something strange about it. The distance between the two points decreases with the distance from an object.

Approaching:
*** f24_swa: 1644.60, 1505.12 (139.48)
*** f24_swa: 1505.12, 1366.46 (138.67)
*** f24_swa: 1366.46, 1228.87 (137.58)
*** f24_swa: 1228.87, 1092.72 (136.15)
*** f24_swa: 1092.72, 958.57 (134.15)
*** f24_swa: 958.57, 827.35 (131.22)
*** f24_swa: 827.35, 700.65 (126.70)
*** f24_swa: 700.65, 581.44 (119.21)
*** f24_swa: 581.44, 475.33 (106.11)
*** f24_swa: 475.33, 393.03 (82.30)
*** f24_swa: 393.03, 351.67 (41.36)

Moving away:
*** f24_swa: 351.67, 365.44 (-13.78)
*** f24_swa: 365.44, 429.04 (-63.60)
*** f24_swa: 429.04, 524.64 (-95.60)
*** f24_swa: 524.64, 638.02 (-113.38)
*** f24_swa: 638.02, 761.29 (-123.27)
*** f24_swa: 761.29, 890.36 (-129.07)
*** f24_swa: 890.36, 1023.03 (-132.67)
*** f24_swa: 1023.03, 1158.08 (-135.04)


Number1= sqrt(a*a+b*b+c*c)
Number2= sqrt(d*d+e*e+f*f)
Number3= (Number1 - Number2)



Olivier Galibert
Semi-Lurker
Reged: 09/21/03
Posts: 352
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352559 - 04/05/16 11:45 PM


> You can see the first number is larger on approach
> and smaller than the second one when moving away, so I conclude the first vector
> points to behind of own ship and the second in front. The same happens when going
> through a Star Destroyer.

I guess I haven't been clear enough. The first vector is the ship relative position at the previous frame, the second at the current frame. The distance diffence is due to the time difference.

OG.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352560 - 04/05/16 11:53 PM


> I guess I haven't been clear enough. The first vector is the ship relative position
> at the previous frame, the second at the current frame. The distance diffence is due
> to the time difference.
>
> OG.

I see now.



R. Belmont
Cuckoo for Konami
Reged: 09/21/03
Posts: 9612
Loc: ECV-197 The Orville
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352589 - 04/06/16 05:57 PM


> The test is zero-or-not-zero, and if not zero the actual value is unimportant. It's a
> pure "is there a collision" flag. The question is a collision with what.

Presumably they call something to set a bounding cube or similar for the object to be collided before calling this function?



Olivier Galibert
Semi-Lurker
Reged: 09/21/03
Posts: 352
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: R. Belmont]
#352596 - 04/06/16 07:48 PM


> > The test is zero-or-not-zero, and if not zero the actual value is unimportant. It's
> a
> > pure "is there a collision" flag. The question is a collision with what.
>
> Presumably they call something to set a bounding cube or similar for the object to be
> collided before calling this function?

Didn't see anything obvious in the megabytes of logs. There is a 7th parameter, an integer, which I just managed to understand, it refers unsurprisingly to the tgp data rom. Now I need to implement a ray/quad intersection, joy :-)

OG.



Traso
MAME Fan
Reged: 01/15/13
Posts: 2687
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352624 - 04/07/16 05:37 AM


> Also, the inverse of a rotation matrix is its transpose, and we don't currently have a transpose function, interestingly.
>
> OG.


Ooooo, Webern comes to mind.


First I've seen this thread, and just last night I was looking up this game for the first time. Weirdo....



Scifi frauds. SF illuminates.
_________________

Culture General Contact Unit (Eccentric)



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352643 - 04/07/16 11:42 AM


> Didn't see anything obvious in the megabytes of logs. There is a 7th parameter, an
> integer, which I just managed to understand, it refers unsurprisingly to the tgp data
> rom. Now I need to implement a ray/quad intersection, joy :-)
>
> OG.

Great, good luck! All I can say about it is that this 7th parameter, the index, likely refers to more than just one quad, possibly a bounding box. Asteroids have one index, Star Destroyers have six.

If f24_swa returns zero then functions f60, f57, and f45 are called. However, if f60 doesn't return something other than 0,0,0 there will be no actual collision, and if it does then additionally function f11 will be called. What f60 outputs seem to be a vector pointing at which way to bounce the ship off. Have no idea what f57, f45 and f11 are for, but it seems collision detection could work to a large degree even without them.



Ville Linde
Slacker
Reged: 05/09/04
Posts: 76
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352653 - 04/07/16 05:28 PM


> If f24_swa returns zero then functions f60, f57, and f45 are called. However, if f60
> doesn't return something other than 0,0,0 there will be no actual collision, and if
> it does then additionally function f11 will be called. What f60 outputs seem to be a
> vector pointing at which way to bounce the ship off. Have no idea what f57, f45 and
> f11 are for, but it seems collision detection could work to a large degree even
> without them.

You probably need point of impact for visuals, which could be f57 then.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Ville Linde]
#352658 - 04/07/16 09:04 PM


f57 translates own ship if collision reaction is triggered, and f60 is not just bounce off vector and collision reaction trigger, it's more.



Pic 1.
Super Star Destroyer trench, just a reference for the next two images.


Pic 2.
f60 is set to output (70,1,1) while f57 is set to output (0,0,0). After collision I'm moved to the right outside the trench. But this is not due to force of the bounce, rather that's where the left wall actually is now, as far as collision is concerned. In other words, if I set f60 to output (1,1,1) I can come really close to it before colliding, but with (5,1,1) for example the collision plane comes about half way inside the trench. So, f60 triggers collision reaction, decides which side of the collision plane is inside and which is outside, and also determines the distance of the collision plane relative to some point like object center, or something like that.


Pic 3.
f60 is set to output (1,1,1), but f57 is set to output (7000,0,0). So I could come really close to the left wall before colliding and after collision I was translated to the right outside the trench about the same distance as in previous scenario. Thing to note here is that units are different, what is 70 for f60 is 7000 for f57. Or so it would seem.



Olivier Galibert
Semi-Lurker
Reged: 09/21/03
Posts: 352
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352664 - 04/07/16 11:16 PM


I implemented a little something, have fun.

OG.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352666 - 04/08/16 12:10 AM


Woohooo! Don't be a tease now, show us the code and tell us how did you go about figuring it out. Gimme, gimme, gimme!



Olivier Galibert
Semi-Lurker
Reged: 09/21/03
Posts: 352
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352677 - 04/08/16 08:17 AM


The code is in the git, where else?

OG.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352679 - 04/08/16 01:11 PM


Marvelous, significant progress!

So f15 is just an inverse of the current matrix, good call Ville Linde. So far I can suggest a few changes that will make second stage playable, but it's hard to tell are they really on the right track.

int_point, former f60:

Code:

	float x= m_tgp_int_px;
float y= m_tgp_int_py;
float z= m_tgp_int_pz;

float n= sqrt(x*x + y*y + z*z);

fifoout_push_f(x/n);
fifoout_push_f(y/-n);
fifoout_push_f(z/n);


This seems to be unit vector. Note I reversed y-axis sign since testing on the second stage collision with the floor and ceiling looks to be happening from the outside.


int_normal, former f57:

Code:


fifoout_push_f(m_tgp_int_px);
fifoout_push_f(m_tgp_int_py);
fifoout_push_f(m_tgp_int_pz);


This seems to be "where to bounce?" translating function. For proper implementation I think it needs incident angle turned around normal into reflection vector somewhere along which path will be translation point.


Next step to making it work I think should be rendering collision geometry so we can actually see what are we dealing with and whether the data is loaded correctly. I'll try now to print out the data from intercept (f24_swa) function and import it in some 3d modeling software. You could perhaps make it render in the game itself.



jonwil
Lurker
Reged: 10/06/03
Posts: 453
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352682 - 04/08/16 02:23 PM


Just wanted to applaud the people doing the work on all this. I know a fair bit about the math required for 3D games from work on various game engines but this stuff is even going over my head...



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352699 - 04/08/16 06:32 PM



Quote:


I implemented a little something, have fun.

OG.



Can't make sense of the data that intercept (f24_swa) function is gathering. It looks like it reads 19 quads just for an asteroid, which doesn't have that many polygons even in its graphical representation. That doesn't seem right. But without really knowing what is going on I don't see how can I be of any help. If you would explain a bit your new code, what you learned, and what you still don't know, that would be most enlightening.



Olivier Galibert
Semi-Lurker
Reged: 09/21/03
Posts: 352
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352701 - 04/08/16 07:05 PM


> Can't make sense of the data that intercept (f24_swa) function is gathering. It looks
> like it reads 19 quads just for an asteroid, which doesn't have that many polygons
> even in its graphical representation. That doesn't seem right. But without really
> knowing what is going on I don't see how can I be of any help. If you would explain a
> bit your new code, what you learned, and what you still don't know, that would be
> most enlightening.

The tgp has a 32-bit wide data rom (built from 4 interleaved byte roms) connected to it. It's called user2 in the rom section of the driver. That's where the data is. All addresses point to 32-bits values, so 1 points to byte offset 4, 2 to 8, etc in case you look in a hex editor.

The first value is at address 0x10. It's 0x30, and that's the address of the indexation table.

So you go to 0x30 + 2*index. There you find two values, a count and an address. The count is a count of quads, the address is the start of the quad info. There are 2537 (0x9e9) entries

Each quad info takes 17 values:
- Four points, (x, y, z) coordinates for each (-> 12 values)
- The four coefficients of the plane equation. The first three are normed, so they're the normal to the plane. (-> 4 values)
- One integer I don't understand which is either 0, 1 or 2.

I checked the four points where always in the plane described by the plane equation, so that's cool. Drawing the quads in the 3d view is going to be hard because intercept is called with points in object coordinates. You're gonna have to build some kind of 3d model - collision model(s) table.

OG.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352724 - 04/08/16 11:22 PM


> - One integer I don't understand which is either 0, 1 or 2.

When flying over large horizontal plane (Death Star) this number is always 1. When going through Super Star Destroyer trench in stage two, this number varies between 0 and 1. However, at the end of the second stage when facing that head on wall with a shrinking opening, some numbers 2 pop out as well. So 0 is for a plane perpendicular to x-axis, 1 is for a plane perpendicular to y-axis, and 2 for a plane perpendicular to z-axis. Or so it would seem.

Have no idea of what use is that having all the planes and normals defined already. On the other hand, I see the problem with passing through objects without collision is not always to blame f60 (int_point) for, due to wrong sign/vector direction defining falsely front/back face, but f24_swa (intercept) also fails to send off zero when it should have, so if everything else in f24_swa (intercept) is correct, then this three-value integer must, after all, be crucial in some way.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352725 - 04/09/16 12:03 AM




Collision test run on the second stage with those changes I posted earlier on. Collision with the floor is working perfectly, every time. Unfortunately it doesn't work so well in the first part of the second stage where the floor is not so flat and collision is all messed up.

Speaking of messed up collision, it occurs to me now that mysterious three-value integer could be able to solve it. For example, when flying along the trench in the second stage there are some polygons on the walls that could be hit head on, but it would not be good this wall to bounce the ship backwards, we want to bounce left or right, so this number could maybe be overriding plane/normal definition.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352818 - 04/10/16 07:50 PM


More info uncovered. Remaining issues:

1. collision detection and reaction
2. torpedo lock-on system (f50_swa)
3. semi-autopilot ship/torpedo speed (f47)
4. darth vader ship movement/spawning
5. invulnerability of dart's escort tie fighters
6. crash after shooting the reactor core
7. freeze after entering high score initials
8. cockpit radar display shows nothing (../video/model1.cpp)
9. missing flashing red when 0 shield (../video/model1.cpp)


- Issue 2.
f50_swa is geometry culling function. First three inputs are xyz coordinates, fourth input is size. If f50_swa outputs negative number, marking an object is behind/outside field of view, the object will not be drawn. For tie fighters, if output is between 0 and 671, full polygon model will be drawn, if between 672 and 28671 low polygon model will be drawn, and if larger than 28671 it will not be drawn.

Additionally, when objects are marked as behind/outside FOV, by outputting negative number, it makes torpedo target acquisition system to release their target lock. I managed to implement this by using values from f14 for own ship position coordinates, but it is only working for tie fighters on stage 1 and stage 3. On stage 2 and for some objects on stage 3 it does not work properly, as if their position is in a different coordinate system.


- Issue 3.
I call "semi-autopilot" what happens when entering stage 1 and stage 3, when there is limited maneuverability and speed can not be adjusted. Second output of function f47 controls the speed for these sequences, which should be around 200 for stage 1 and around 170 for stage 3. This function also has impact on own torpedoes, in which case second output should be 0 or some very low number, otherwise torpedoes will not be hitting their targets but end up circling around them. Have no idea what the first output is for.

I can force this to work good enough, but can not implement it properly as I do not see any relation between inputs to this function and what should be the output. Only when entering stage 3 does the second input relate to what should be the second output (speed). Unfortunately this is not the case for own torpedoes and entrance to stage 1. Even more strange, for stage 1 this function is called many times, unlike stage 3 when it is called only once per frame.



Olivier Galibert
Semi-Lurker
Reged: 09/21/03
Posts: 352
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352850 - 04/11/16 10:42 AM


> - Issue 3.
> I call "semi-autopilot" what happens when entering stage 1 and stage 3, when there is
> limited maneuverability and speed can not be adjusted. Second output of function f47
> controls the speed for these sequences, which should be around 200 for stage 1 and
> around 170 for stage 3.

No time right now, but quick info: the parameters passed at the first call of f47 in the frame in stage 1 is the inter-frame displacement of the ship (aka dx, dy, dz).

OG.



Ville Linde
Slacker
Reged: 05/09/04
Posts: 76
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352859 - 04/11/16 07:45 PM


> 8. cockpit radar display shows nothing (../video/model1.cpp)

They are being rendered, but obscured by the cockpit tilemap.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Ville Linde]
#352862 - 04/11/16 08:36 PM


> They are being rendered, but obscured by the cockpit tilemap.

Yeah, and I can isolate radar display drawing by commenting out case 2: in tgp_render function, so it doesn't get rendered, but didn't manage to isolate it the other way around so to only render radar display after cockpit bitmap. The important thing is the radar display is separate from the rest in some way, so I think for Olivier it would be easy to fix.



Ville Linde
Slacker
Reged: 05/09/04
Posts: 76
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352864 - 04/11/16 08:50 PM


> > They are being rendered, but obscured by the cockpit tilemap.
>
> Yeah, and I can isolate radar display drawing by commenting out case 2: in tgp_render
> function, so it doesn't get rendered, but didn't manage to isolate it the other way
> around so to only render radar display after cockpit bitmap. The important thing is
> the radar display is separate from the rest in some way, so I think for Olivier it
> would be easy to fix.

Or there's a priority flag somewhere in the polygon structure or color tables.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#352865 - 04/11/16 09:40 PM


Got it!!! Collision, it's working!



It turns out f60 (int_point) needs to output either (+/-1,0,0), (0,+/-1,0), or (0,0,+/-1), and that's where your mystery three-value integer comes in play. Let me explain with the code, f24_swa (intercept) function:

Code:


// store that number in Qunk variable
// adr++; // 0, 1 or 2...
Qunk= tgp_data[adr++];


// replace x1,y1,z1 with x2,y2,z2
// think it works better for f57 (int_normal)
// which uses these coordinates for bounce translation
ix = x2 + dx*t;
iy = y2 + dy*t;
iz = z2 + dz*t;

// this is the main part here
if(cp == 0 || cp == 4)
{
m_tgp_int_px = ix;
m_tgp_int_py = iy;
m_tgp_int_pz = iz;

collX=collY=collZ= 0;

if(Qunk == 0)
{
if(dx<0)
collX= 1;
else
collX= -1;

m_tgp_int_px+= 900*collX;
}
else
if(Qunk == 1)
{
if(dy<0)
collY= 1;
else
collY= -1;

m_tgp_int_py+= 900*collY;
}
else
if(Qunk == 2)
{
if(dz<0)
collZ= 1;
else
collZ= -1;

m_tgp_int_pz+= 900*collZ;
}


ret = 0;
adr -= 17;
break;
}


I only show differences. So if Qunk is 0 (plane perpendicular to x-axis), then f60 (int_point) function should output either (-1,0,0) or (1,0,0). If Qunk is 1 (plane perpendicular to y-axis), then f60 (int_point) function should output either (0,-1,0) or (0,1,0). And if Qunk is 2 (plane perpendicular to z-axis), then f60 (int_point) function should output either (0,0,-1) or (0,0,1). I also increase m_tgp_int_px/py/pz for 900 units to increase bounce distance, although the whole bounce reaction is likely handled some other way, but for now that works well enough.


f60 (int_point) and f57 (int_normal):

Code:


static void f60(void)
{
fifoout_push_f(collX);
fifoout_push_f(collY);
fifoout_push_f(collZ);

next_fn();
}

static void f57(void)
{
fifoout_push_f(m_tgp_int_px);
fifoout_push_f(m_tgp_int_py);
fifoout_push_f(m_tgp_int_pz);

next_fn();
}



Now, there are still some little problems. For stage 2 I had to make collZ positive for both dz<0 and dz>0 or the ship would collide with something at the very entrance of stage 2 when autopilot disengages, possibly the wall behind. But after the ship moves a bit from the starting point then it's all good. Another problem is with asteroids, sometimes collision triggers only after the ship has already went through it. Also, sometimes the ship manages to go through walls despite the bounce, which can be helped by increasing bounce distance, however large bounce distance is not good for narrow corridors and tunnels in the final stage as it can bounce the ship outside through the opposite wall.



joey35car
MAME Fan
Reged: 02/07/07
Posts: 968
Loc: Oak Lawn Il USA
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352876 - 04/12/16 12:46 AM


Nice job.






dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352961 - 04/13/16 07:40 PM



Quote:


It turns out f60 (int_point) needs to output either (+/-1,0,0), (0,+/-1,0), or (0,0,+/-1), and that's where your mystery three-value integer comes in play. Let me explain with the code, f24_swa (intercept) function:




Actually, not really. Proper fix it seems for OG's original code is just to swap around int_point (f60) and int_normal (f57) functions:

Code:


{ &model1_state::f56, 7 },
{ &model1_state::int_point, 0 },
{ &model1_state::matrix_readt, 0 },
{ &model1_state::acc_geti, 0 },
{ &model1_state::int_normal, 0 },


That makes collision work perfectly. So scrap what I wrote in the previous post, which strangely worked pretty well, but even more strange the elusive three-value integer and its purpose then still remain a mystery.



R. Belmont
Cuckoo for Konami
Reged: 09/21/03
Posts: 9612
Loc: ECV-197 The Orville
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352966 - 04/13/16 09:33 PM


> Actually, not really. Proper fix it seems for OG's original code is just to swap
> around int_point (f60) and int_normal (f57) functions:
>
> { &model1_state::f56, 7 },
> { &model1_state::int_point, 0 },
> { &model1_state::matrix_readt, 0 },
> { &model1_state::acc_geti, 0 },
> { &model1_state::int_normal, 0 },
>
> That makes collision work perfectly. So scrap what I wrote in the previous post,
> which strangely worked pretty well, but even more strange the elusive three-value
> integer and its purpose then still remain a mystery.

Interesting. So the game plays correctly with this change?



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: R. Belmont]
#352967 - 04/13/16 10:34 PM


> Interesting. So the game plays correctly with this change?

That's only a small change on top of many other changes Olivier submitted to the github a week ago. It concerns only collision detection, while other changes also addressed ship/camera rotation and implementation of quite a few previously unknown/undefined functions.

With this change the game is very much playable and collision seems to work correctly, apart from this:



I managed to find those two spots on stage 2 where I can reliably pass through the wall. Also, sometimes it is possible to pass through asteroids without triggering collision. Other than that it works great, and it would be hard to notice those problems in a regular gameplay, so perhaps these issues exist in the actual game as well.



Master O
Yes, Even Parodius Music
Reged: 11/20/06
Posts: 1181
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352974 - 04/14/16 04:44 AM


> > Interesting. So the game plays correctly with this change?
>
> That's only a small change on top of many other changes Olivier submitted to the
> github a week ago. It concerns only collision detection, while other changes also
> addressed ship/camera rotation and implementation of quite a few previously
> unknown/undefined functions.
>
> With this change the game is very much playable and collision seems to work
> correctly, apart from this:
>
>
> I managed to find those two spots on stage 2 where I can reliably pass through the
> wall. Also, sometimes it is possible to pass through asteroids without triggering
> collision. Other than that it works great, and it would be hard to notice those
> problems in a regular gameplay, so perhaps these issues exist in the actual game as
> well.

Good thing you didn't work on this game in the early days of MAME.

The rom kiddies would've been out in full force bothering you 24/7 with "when's it gonna be done? CAN I PLAYZ IT NAO?!"



"Note to Noobs:

We are glad to help you but simply posting that something does not work is not going to lead to you getting help. The more information you can supply defining your problem, the less likely it will be that you will get smart-alec replies.

C.D.~"



MooglyGuy
Renegade MAME Dev
Reged: 09/01/05
Posts: 1662
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352992 - 04/14/16 01:41 PM


> With this change the game is very much playable and collision seems to work
> correctly, apart from this:

Just a friendly reminder that if you use MAME with the -aviwrite parameter and supply a filename, it will log out an uncompressed AVI with correct audio, which you can then encode and upload to YouTube. No need to have a watermarked video where your microphone is live.



R. Belmont
Cuckoo for Konami
Reged: 09/21/03
Posts: 9612
Loc: ECV-197 The Orville
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#352996 - 04/14/16 05:02 PM


> That's only a small change on top of many other changes Olivier submitted to the
> github a week ago. It concerns only collision detection, while other changes also
> addressed ship/camera rotation and implementation of quite a few previously
> unknown/undefined functions.

I am, of course, aware

> With this change the game is very much playable and collision seems to work
> correctly, apart from this:

> I managed to find those two spots on stage 2 where I can reliably pass through the
> wall. Also, sometimes it is possible to pass through asteroids without triggering
> collision.

Probable real-game bugs. Missing collisions are something of a plague of polygonal games, to the point where it's possible in Amnesia: The Dark Descent to boost yourself up above the world and walk over it, bypassing all the monsters, bosses, and jumpscares. Speedrunners have a lot of fun with that, of course.

Anyway, really neat. I'm glad you (and OG and Ville) were able to figure things out and make the game finally playable!



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: R. Belmont]
#352998 - 04/14/16 05:57 PM


> I am, of course, aware

I shouldn't have said "OG's original code" when I was referring only to his recent github submission. I thought I better explain so someone don't think just that one trivial change could have made it playable even a decade ago.


> Probable real-game bugs. Missing collisions are something of a plague of polygonal
> games, to the point where it's possible in Amnesia: The Dark Descent to boost
> yourself up above the world and walk over it, bypassing all the monsters, bosses, and
> jumpscares. Speedrunners have a lot of fun with that, of course.

I've contacted a few people on youtube who have videos of the actual game to confirm.


> Anyway, really neat. I'm glad you (and OG and Ville) were able to figure things out
> and make the game finally playable!

It's very fortunate Olivier is still around. I can just hack things out and stumble on some new info, but only he can make real sense of it and produce proper implementation.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: MooglyGuy]
#352999 - 04/14/16 06:22 PM


> Just a friendly reminder that if you use MAME with the -aviwrite parameter and supply
> a filename, it will log out an uncompressed AVI with correct audio, which you can
> then encode and upload to YouTube. No need to have a watermarked video where your
> microphone is live.

I can't record with MAME 172 as the game runs at only 50% speed on my computer. I'm using MAME 115 which doesn't have that option. Also, recording directly to mp4 saves time.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#353012 - 04/15/16 03:50 AM


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



Ziggy100
MAME Fan
Reged: 06/14/08
Posts: 288
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Master O]
#353022 - 04/15/16 10:23 AM



Quote:


Good thing you didn't work on this game in the early days of MAME.

The rom kiddies would've been out in full force bothering you 24/7 with "when's it gonna be done? CAN I PLAYZ IT NAO?!"




Which would of been pointless as PC's in those days would have only been able to run it a 10fps.



LensLarque
MAME Fan
Reged: 02/19/08
Posts: 96
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#353023 - 04/15/16 11:47 AM


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

Awsome !

(hey that RPTV looks so mint *jealous*)



> MAME isn't about playing the games anyway.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#353034 - 04/15/16 11:35 PM


6. crash after shooting the reactor core
7. freeze after entering high score initials

I have absolutely no idea how to approach solving these two issues. Any info about how to narrow down the cause and location of the problem, what file(s) to look at, is welcome.



Master O
Yes, Even Parodius Music
Reged: 11/20/06
Posts: 1181
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Ziggy100]
#353035 - 04/15/16 11:42 PM


> Good thing you didn't work on this game in the early days of MAME.
>
> The rom kiddies would've been out in full force bothering you 24/7 with "when's it
> gonna be done? CAN I PLAYZ IT NAO?!"
>
> Which would of been pointless as PC's in those days would have only been able to run
> it a 10fps.

That simple fact wouldn't have deterred them, I can assure you...



"Note to Noobs:

We are glad to help you but simply posting that something does not work is not going to lead to you getting help. The more information you can supply defining your problem, the less likely it will be that you will get smart-alec replies.

C.D.~"



R. Belmont
Cuckoo for Konami
Reged: 09/21/03
Posts: 9612
Loc: ECV-197 The Orville
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#353219 - 04/19/16 07:39 PM


> 6. crash after shooting the reactor core
> 7. freeze after entering high score initials
>
> I have absolutely no idea how to approach solving these two issues. Any info about
> how to narrow down the cause and location of the problem, what file(s) to look at, is
> welcome.

Does MAME itself crash, or just the game resets or something?



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: R. Belmont]
#353268 - 04/20/16 12:49 AM


> Does MAME itself crash, or just the game resets or something?

MAME crashes with this message:

-----------------------------------------------------
Exception at EIP=00419B60 (not found): ACCESS VIOLATION
While attempting to read memory at 0EF3025E
-----------------------------------------------------
EAX=0CE20020 EBX=1021FD28 ECX=0A431000 EDX=01001A01
ESI=010C811F EDI=07DEE060 EBP=02745180 ESP=0022C840
-----------------------------------------------------
Stack crawl:
02745180: 00419B60 (not found)



Haze
Reged: 09/23/03
Posts: 4617
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#353269 - 04/20/16 01:00 AM


the rendering code doesn't like bad data
http://mametesters.org/view.php?id=6123

maybe the game is sending bad data for a frame?



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#353300 - 04/20/16 12:08 PM


Did you know?





I am quite surprised to discover various sections of Star Destroyers can be destroyed. I couldn't manage to destroy them all in one go, and I wonder if then it would be destroyed completely. In any case, what an amazing game! C'mon, let's fix those few little bugs still left.



Roman
Regular
Reged: 09/21/03
Posts: 1514
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#353301 - 04/20/16 12:55 PM


are the improvements limited to Star Wars or do other model1 games have (visual) improvements?



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Roman]
#353303 - 04/20/16 01:23 PM


> are the improvements limited to Star Wars or also other model1 games?

Not quite sure, but I think additions so far have no impact on the other three games. They seem to be fine as they are.



Olivier Galibert
Semi-Lurker
Reged: 09/21/03
Posts: 352
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#353308 - 04/20/16 04:06 PM


> > are the improvements limited to Star Wars or also other model1 games?
>
> Not quite sure, but I think additions so far have no impact on the other three games.
> They seem to be fine as they are.

I suspect the collision changes have an impact on wingwar though.

OG.



R. Belmont
Cuckoo for Konami
Reged: 09/21/03
Posts: 9612
Loc: ECV-197 The Orville
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Haze]
#353310 - 04/20/16 04:38 PM


> the rendering code doesn't like bad data
> http://mametesters.org/view.php?id=6123
>
> maybe the game is sending bad data for a frame?

dkong: could you try the changes SailorSat suggests there and see if it improves things?



John IV
IV/Play, MAME, MAMEUI
Reged: 09/22/03
Posts: 1634
Loc: Snohomish, WA, USA
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: Olivier Galibert]
#353312 - 04/20/16 05:24 PM


There are also those headband/belt artifacts that move around on the ground in Virtua Fighter's attract mode.



john iv
http://www.mameui.info/



R. Belmont
Cuckoo for Konami
Reged: 09/21/03
Posts: 9612
Loc: ECV-197 The Orville
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: John IV]
#353317 - 04/20/16 09:15 PM


> There are also those headband/belt artifacts that move around on the ground in Virtua
> Fighter's attract mode.

Right, the animated submodel support, most likely. I imagine that could be fixed by a similar process to what we saw here if someone's up for it.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: R. Belmont]
#353318 - 04/20/16 09:35 PM



Quote:


dkong: could you try the changes SailorSat suggests there and see if it improves things?




I have already tried changing "switch(type & 15)" to "switch(type)" and see no difference regarding the crash or otherwise. He also mentions some "check", but I don't know what is he talking about. In any case, whatever he did, wouldn't those changes already be included in the MAME source code?



R. Belmont
Cuckoo for Konami
Reged: 09/21/03
Posts: 9612
Loc: ECV-197 The Orville
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#353320 - 04/20/16 10:20 PM


> dkong: could you try the changes SailorSat suggests there and see if it improves
> things?
>
> I have already tried changing "switch(type & 15)" to "switch(type)" and see no
> difference regarding the crash or otherwise. He also mentions some "check", but I
> don't know what is he talking about. In any case, whatever he did, wouldn't those
> changes already be included in the MAME source code?

SS is a "she", and those changes obviously aren't included or I wouldn't have asked you to try them :-)

(Also, that MAMETesters entry would be closed if the changes were integrated).



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: R. Belmont]
#353324 - 04/21/16 12:39 AM


Ok. By the way, I just tried running this game with MAME 172 on 3.4GHz Pentium 4, and it runs at ~50% speed just as with my 3Ghz Pentium D. What kind of hardware does it take to run this game at full speed?

On the other hand, with MAME 115 the game can run at 150% speed and more on those computers. In 115 there was no MPEG audio implemented yet, so is it possible the slowdown is solely due to that, or what else?



R. Belmont
Cuckoo for Konami
Reged: 09/21/03
Posts: 9612
Loc: ECV-197 The Orville
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#353379 - 04/22/16 05:16 PM


> Ok. By the way, I just tried running this game with MAME 172 on 3.4GHz Pentium 4, and
> it runs at ~50% speed just as with my 3Ghz Pentium D. What kind of hardware does it
> take to run this game at full speed?

A CPU manufactured in the last decade helps. NetBurst, brrrrrrrrrr

That said, MPEG audio should be about the same CPU load as playing an MP3, and I don't recall that being all that stressful during that era.



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#353627 - 04/28/16 10:35 AM


Very strange. So I found several ways to avoid MAME crash after shooting the reactor. In file "../video/model1.c", function "push_object":

Method 1a:

Code:


if(poly_adr == 0x1229f8)
return;

if(poly_adr == 0xc417)
return;

if(poly_adr == 0x1d)
return;


Method 1b:

Code:


if(tex_adr == 0xc67d8eb3)
return;

if(tex_adr == 0x4000c440)
return;

if(tex_adr == 0xc000c40e)
return;



Looking at (tex_adr, poly_adr) parameters function "push_object" is called with, it seems the cause of the problem happens back in function "tgp_render", case 1, when zz == 1 and push_object's first argument "readi(list+2)", that is "tex_adr", is out of bounds. Comparing it with other calls before the crash, the last one when the crash happens sticks out like a sore thumb:
---------------------- END FRAME
50053, 198cdd
4f870, 190e1d
478df, c9612
478ea, c97a9
4fb18, 193eee
478d8, c9550
478de, c95e3
502f7, 19b676
c67d8eb3, 1229f8


Method 2:

Code:


// cquad.col=(r<<10)|(g<<5)|(b<<0);


I find it a bit strange that commenting out this line would also prevent the crash. But what is really very strange is this 3rd way to avoid the crash...


Method 3:

Code:


printf("blahblah-blahblahblah...\n");
fclip_push_quad(0, &cquad);


So this just slows down the game before "fclip_push_quad" call, and MAME does not crash. It's as if this function runs in a thread that uses some values from some place which are updated by some code running in another thread, and it's like these two threads need to be synchronized or this function will pull out garbage values when accessed before they are made ready by the other thread. Or something among those lines. I do not see what else could explain this weirdness.


In any case, unfortunately, apart from avoiding the crash none of these methods really solve the problem as the game then enters never-ending loop where the camera goes out of the cockpit circling around the ship while the reactor chamber keeps exploding. Olivieeeeer!!



dkongjr
MAME Fan
Reged: 03/25/16
Posts: 45
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#353636 - 04/28/16 04:26 PM


Woohoo! Now we can see the credits.



So to avoid the crash I use this in file "../video/model1.c", function "push_object":

Code:


if(tex_adr == 0xc67d8eb3)
return;

if(tex_adr == 0x4000c440)
return;

if(tex_adr == 0xc000c40e)
return;


...and then to "unlock" the ship, to make it go towards the exit, function f43_swa needs to change:

Code:


static void f43_swa(void)
{
float a = fifoin_pop_f();
int b = fifoin_pop();
int c = fifoin_pop();

if(activecpu_get_pc() == 0xd83b4)
{
//-- end game autopilot
b= 1;
c= 900;
}
else
{
//-- enemy torpedo, activecpu_get_pc() == 0xe91c2
a=b=c= 0;
}

fifoout_push_f(a);
fifoout_push_f(b);
fifoout_push_f(c);
next_fn();
}


This function is also called when enemy torpedoes pop out, in which case output (0,0,0) that is current implementation seems fine, but most likely it really is not. And certainly is not fine for end-game autopilot, so I plugged some arbitrary values to do the job for that case. For proper implementation I will need to study the actual game video recordings to find out how enemy torpedoes really behave, and then I guess the same algorithm will apply to both enemy torpedoes and the end game autopilot.

I have to say I am disappointed to see the game ends there. I really wanted it to star over with increased difficulty, and was hoping there might be some new stuff to see, some changes in AI, or something. Ahhh.



uman
MAME Fan
Reged: 04/15/12
Posts: 365
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: dkongjr]
#353666 - 04/29/16 01:12 AM


Congratulations. Big thumbs up from my side. GG WP .



lettuce
MAME Fan
Reged: 07/30/06
Posts: 21
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: uman]
#353833 - 05/02/16 04:14 PM


Does anyone know what the region code is for this game?, Sega Model 2 boards had codes to change the region. This game does appear to have English voices in the sound test menu so the mode to switch to English must be available somehow??



terminento
MAME Fan
Reged: 05/10/16
Posts: 7
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: lettuce]
#354107 - 05/10/16 05:29 PM


Hi! I'm pretty new to this so this might come off as a noob question. Thrilled as I was after seeing the progress that has been made with Star Wars Arcade, I went to the official mame page and got version 0.173. However, no matter which rom I used, the emulator kept telling me that I'm missing files. I tried these very same roms with a way older version of mame, and, even though the game didn't work properly, it did load.
Has the rom been redumped? Am I missing some kind of bios file or something?



MooglyGuy
Renegade MAME Dev
Reged: 09/01/05
Posts: 1662
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: terminento]
#354110 - 05/10/16 05:52 PM


> Hi! I'm pretty new to this so this might come off as a noob question. Thrilled as I
> was after seeing the progress that has been made with Star Wars Arcade, I went to the
> official mame page and got version 0.173. However, no matter which rom I used, the
> emulator kept telling me that I'm missing files. I tried these very same roms with a
> way older version of mame, and, even though the game didn't work properly, it did
> load.
> Has the rom been redumped? Am I missing some kind of bios file or something?

http://docs.mamedev.org/usingmame/commonissues.html

"It is not unusual for the ROMs to change for a game between releases of MAME. Why would this happen? Oftentimes, better or more complete ROM dumps are made, or errors are found in the way the ROMs were previously defined. Early versions of MAME were not as meticulous about this issue, but more recent MAME builds are. Additionally, there can be more features of a game emulated in a later release of MAME than an earlier release, requiring more ROM code to run."



terminento
MAME Fan
Reged: 05/10/16
Posts: 7
Send PM


Re: Star Wars Arcade (SEGA, 1993): fixing model1 emulation new [Re: MooglyGuy]
#354112 - 05/10/16 06:07 PM


Thanks for the quick reply. I won't be asking for the updated rom because I know that's against the forum rules, but could you guys at least pinpoint me in the right direction? Because, so far, google hasn't been my friend, and since I only want to play this one game, I don't feel like downloading several gigabytes of entire romsets and update packs just for this one.

Edited by terminento (05/10/16 06:09 PM)


Pages: 1 | 2 |

MAMEWorld >> EmuChat
View all threads Index   Threaded Mode Threaded  

Extra information Permissions
Moderator:  redk9258, URherenow, Tafoid 
0 registered and 50 anonymous users are browsing this forum.
You cannot start new topics
You cannot reply to topics
HTML is enabled
UBBCode is enabled
Thread views: 17515