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.
> 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.
Most of the sites that you find that offer "loose" ROM sets are probably going to be out of date, but if you concentrate on Googling for sites along with the relevant MAME version (0.173), you might have better luck.
Also, there are sites that have torrents for all of the ROM sets in 0.173, and I can't think of a torrent program that I've used in the past five years that hasn't let you individually pick-and-choose which files in the torrent you actually want to download. Grab the torrent, deselect all, select swa.zip and you're good to go.
The most likely reason why your ROM set is out of date in this particular instance is that I'm pretty sure the MPEG audio ROMs for Star Wars Arcade were added later than when the original ROM set was added, and so those would be the files that MAME is reporting as missing.
I hope this helps, don't hesitate if you have any other questions. You seem like a decent fellow, so I'm happy to help.
Thanks a lot! You were incredibly helpful! It was interesting to know that it is probably the music files that are missing. I'll let you know if I find the updated rom.
Thanks for your help, MooglyGuy. Arg...! I'm about to give up! I feel so close, yet so far! I found this one rom in .7z format, suposedly for 0.172. It weights 11,8 MB, and contains these 21 files:
I have 21 files, unlike older roms that only have 13 files. Also, mpr-16514.bin and mpr-16515.bin are supposed to be the mpeg files. I tried the .7z both with 0.173 and 0.172, didn't work. I tried unzipping it and pasting the whole folder with the files in it inside the roms folder, didn't work. I tried rezipping the file into zip format using winrar with the default options, didn't work. Am I still missing files? What am I doing wrong? Because at this point, it's either a miracle or I'll blow the dust off my old 32x cartridge and play that version instead. Thanks in advance, fellas!
You are missing "epr-15112.17". It's network related, to connect two Wingwar or Virtua Racing games. Don't know why is it required to run swa.
Note that not all the changes I proposed here have been included, namely:
1. fix for torpedo lock-on system (without it the game will be harder and often it will be impossible to complete 1st and 3rd stage)
2. fix for autopilot/own torpedo speed (without it torpedoes will take longer to hit the target, ship controls will lock in the trench when entering stage 3)
3. fix for reactor chamber crash (without it you will not be able to see the end game credits)
4. fix for proper speed control (without it speed will not auto-center as it should)
By the way, I suggest to use mouse, it's much better than using keyboard.
Thanks! I investigated that particular file and found a package with the rom for the chip. It was incredibly useful, because once I put it iside the rom folder, Virtua Racing started working too (my first impulse was getting my hands on a Virtua Racing rom then extract the file from there, but it turned out the VR rom was missing the network chip file as well). It is true that the changes you made haven't been implemented yet, and thus I suffered a crushing defeat at the hands of the Empire, LOL, yet still, it was great to be able to fly around and shoot down some ties instead of automatically imploding for no reason. It was also great to listen to J. Williams music in the background. After so many years, this arcade gem is finally getting some MAME love, and that is always a good thing.
Here's hoping your changes will be implemented in future releases, you did a great work.
Also, I would like to thank you as you were incredibly friendly and helpful, both here and in the youtube comment section for the video of the full run of the game. Even if the changes haven't been implemented just yet, thanks to your advice now people can know what specific piece of the puzzle they are missing, ad thus, have the correct rom ready for the moment torpedoes lock on and that chamber doesn't become a trap for the heroes of the rebellion, ha ha ha!
4. fix for proper speed control (without it speed will not auto-center as it should)
Wouldn't the auto centering be handled physically with the machines controller? It's basically a large, vertical-only analog stick. Or does it only center in the current MAME when you push the opposite direction?
> > Note that not all the changes I proposed here have been included > > Can you sum them up in a new thread? I'm a little lost at that point... > > OG.
Post #353012 and #353636. I'm not sure if a new thread is really necessary, or if there is anything I can do to make it more clear or useful for you to make a proper implementation. Let me know.
> LOL! Well he asked a stupid question, got an appropriate answer
I see. All respect has been lost and this has at this point nothing to do with a helpful community. Instead it has turned in an weird place full of morons. I've never been disrespectful but since I don't feel comfortable anymore, I'll say this with full sincerity: FCK U VERY MUCH!!!! Enough is enough... I quit here
Please, don't get upset. Most people on this thread have been incredibly polite and useful so far, save for one or two infortunate comments. There are worse things in life to get worked over with, I think. Let us not turn this thread into an internet flame war.
As Dkongjr has said, the issues right now are torpedoes not locking on (the reticle does, but the torpedoes don't track their target. Their speed is way too slow, so even in a straight line they take too much timw to hit a static target. You can get trapped in the final reactor chamber of the death star, and the speed lever doesn't autocenter.
If you tried Star Wars Arcade in the past in MAME, though (and I mean DISTANT past), you'll recall the ship imploding because of collision issues at the start of the game, as well as there beign no music in the background. With the latest version (, 0.173 at the time of writing this), you can at least fly around and shoot ties with the regular lasers, and the music is there in all it's glory.
> > Note that not all the changes I proposed here have been included > > What's the reason ?
Because they're not how the machine actually worked. dkongjr has been incredibly lucky with his "circuit bending" and then having OG/Ville translate that to actual math thus far; some patience will likely yield equally good results.
> Will these model1.cpp changes translate into potential improvements in the original > VF emulation?
No. Original VF's issues with the disconnected hair and stuff are different TGP commands, likely for submatricies. Someone motivated with a grasp of 3D math could probably figure something out in a similar way though.
I thought your name looked familiar. Then I realized you were one of the devs for the Modeler emu 15 years ago. NICE!
Bart and Ian are doing great work on Model3 over at Supermodel, and they recently got a hold of a Model3 SDK that has really helped them solve some of the more obscure lighting and rendering issues. I realize the systems aren't the same, but perhaps some of the logic may help with Model1 over time.
Just a thought. Anyway - I'm just glad Model1 is getting attention at all. VF was a pioneer for future 3D fighting games, so any improvement to it's parent system's emulation is a good thing.
> I realize the systems aren't the same, but perhaps > some of the logic may help with Model1 over time.
No, they're completely different. Model 1 and early revs of Model 2 are fairly similar, but Model 1 and 2 and Model 3 are totally different how they work. Model 1 and 2's architecture is closest to the Sony PS2, while Model 3 works more like a modern PC video card.
> > Will these model1.cpp changes translate into potential improvements in the original > > VF emulation? > > No. Original VF's issues with the disconnected hair and stuff are different TGP > commands, likely for submatricies. Someone motivated with a grasp of 3D math could > probably figure something out in a similar way though.
I wonder if they do some simple rope physics on the TGP.
Lol. I do appreciate the PS2 analogy, though. It illustrates much more clearly to an end user (like myself) why model1 has been such a mystery after all this time.
I DO have one more question that isn't VF-oriented per say. VF PC was released by AM2 in 1996, just 3 years after the arcade release in 1993. And while there are minor differences (player selection menu graphics, BGM) the game looks and feels exactly like the original during regular gameplay. Yes, you need to select the "classic" graphics from a hidden settings menu, but then port becomes shockingly faithful. The fact that AM2 released this port so close to the original tells me that AT THE VERY LEAST they still had access to the original software/SDK/hardware to make the PC version.
I'll get to the point - I recall that another port of an arcade game series (I want to say one of the CAVE shmups on xbox360? I know it WASN'T the Taito series, which I realize runs on a modified WinXP format) essentially led to the decoding of the original roms, as a shell had basically been built around the rom to get it to run in a PC (ok...360 console) environment. Is there any chance that the "VF PC" software may contain hints to model1's functions? Yes, I'm grasping at straws, but it's not a totally outrageous idea. Even at the start of a match, the PC-version characters will often dance too quickly for a second before being throttled to the correct speed - perhaps the shell (emu?) isn't throttling the original code properly for that second or two?
Even the layout of the software on the disk is odd. Character models are in one folder, levels in another, sounds in another, BGM is recorded mix-mode on the game disk itself, etc. And it doesn't really install anything to run - just a shortcut. The executable itself is TINY by modern standards. The disk is kind of laid out the way an older rom is. ANY chance this could provide input to the emulation?
I own the software and would happy to send the original, LEGAL disk to a dev if I thought it would help.