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).
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?
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.
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:
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?
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?
> 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 :
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.
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.
> 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
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?
> 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?
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:
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:
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):
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:
> > 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"
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...
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:
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.
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.
> 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.
> 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.
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.
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.
> 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.
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.
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.
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.
> 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.
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.
> 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.
> 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?
...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.
> 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.
> 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.
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.
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.
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
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.
Vectors, coordinates... in either case there is something strange about it. The distance between the two points decreases with the distance from an object.
> 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.
> 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.
> 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?
> > 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 :-)
> 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.
> 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.
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.
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.
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.
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.
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...
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.
> 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.
> - 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.
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.
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.
> - 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).
> 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.
> > 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.
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;
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.
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.
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:
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.
> 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?
> 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.
> > 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.
> 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.
> 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!
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.
> 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.
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();
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
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:
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.
> 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.
> 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?
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.
> > 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.
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?
> 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).
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?
> 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.
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...
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!!
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.
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??
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?
> 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?
"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."
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.
Index 
Threaded 
Star Wars Arcade (SEGA, 1993): fixing model1 emulation
Reply
[Re: 
.
