DOOM Enemy Behavior?
-
- Posts: 111
- Joined: Sun Feb 14, 2021 6:29 pm
- Has thanked: 1 time
- Been thanked: 5 times
Re: DOOM Enemy Behavior?
Not sure if this helps but i get pretty simular behavior between sd2snes and mister my sd2snes is on the most recent firmware - i always just figured it was how this game was on the snes as im used to playing it on my amigas.
Re: DOOM Enemy Behavior?
Check out the video a few posts up at https://youtu.be/Tzc3e-W6z78.lordoftime79 wrote: ↑Sat Aug 28, 2021 8:41 pm Not sure if this helps but i get pretty simular behavior between sd2snes and mister my sd2snes is on the most recent firmware - i always just figured it was how this game was on the snes as im used to playing it on my amigas.
Are enemies bothering to shoot at you from range with any frequency or displaying their 'hurt' animation frames upon being shot when you play the SNES version in MiSTer? Those things happen in the SNES version (and the Amiga, for that matter), but no one in this thread seems to be seeing that for SNES in the current MiSTer release.
Re: DOOM Enemy Behavior?
Can confirm that through an original model SD2SNES, enemies shoot at you a ton on the highest level in Episode 3. They do virtually nothing on MiSTer. Definitely some sort of edge case broken in there.
- LamerDeluxe
- Top Contributor
- Posts: 1239
- Joined: Sun May 24, 2020 10:25 pm
- Has thanked: 887 times
- Been thanked: 284 times
Re: DOOM Enemy Behavior?
WinUAE is more accurate than the MiniMig core as well, when it comes to racing the beam, which is easily noticeable in the game Hybris. I created a ticket for this a while ago.
- MISTerMark
- Posts: 13
- Joined: Thu Sep 17, 2020 3:28 pm
- Has thanked: 1 time
- Been thanked: 3 times
Re: DOOM Enemy Behavior?
On the topic of Doom, Fabiens Black Book is worth a read.
Can read the pdf for free -
https://fabiensanglard.net/gebbdoom/
Can read the pdf for free -
https://fabiensanglard.net/gebbdoom/
Re: DOOM Enemy Behavior?
Is it definitely not a ROM issue? Most people myself included don't rip their own carts, the same dodgy ROM could get picked up a few times. Never even thought to play the SNES version of Doom because... Well let's be honest it is pants whether it plays correctly or not
Re: DOOM Enemy Behavior?
aberu wrote: ↑Fri Aug 27, 2021 3:11 pmTo be fair, they said they compared to bsnes, which bsnes is the most accurate and compatible thing out there in terms of software emulators. Shortly before Near passed away... they went over how the Super FX implementation on the MiSTer is not as accurate as it is in bsnes currently.darksakul wrote: ↑Fri Aug 27, 2021 1:51 pm And when the only comparisons are to software emulation, yes I will discount the accuracy reports.
What software emulation was used, what version, what settings.
Anyone got their FX Pak Pro flash cart with the rom warmed up and running on a Snes or Super NT.
Better yet the real cart. It's irrelevant how a Software emulator performs compared to FPGA unless the same dev worked on both.
I've also done test rom comparisons using basically all known test roms out there and there are a number of tests, a few of them low-level math associated, that the MiSTer core doesn't pass but both real hardware and bsnes do pass. The only one fixed since I did this was the test that was failing in the beavis and butthead issue awhile ago on github.
I was asking questions because I wasn't sure what they were talking about. Real hardware comparisons are better, yes, but bsnes is as close to real hardware as you are gonna get in terms of compatibility. bsnes is more compatible and more accurate than the MiSTer SNES core, you can objectively measure this with all of the test roms yourself if you don't believe me. It takes awhile, but you may learn something from it. And that's not a jab at the MiSTer core, the MiSTer core is like 99.9% there basically... bsnes took well over a decade of pioneering work that the MiSTer SNES core has benefited from.
Also a romcart will not be sufficient if your goal is to only compare to real hardware, as that is an FPGA implementation of the SuperFX 2, and not the real thing. I have found hardware reimplementation bugs in Mega Everdrive Pro that is not fixed, for instance.
Everybody cool off a bit, no need to get mad at each other right now. We are a buncha nerds, it's okay.
This is definitely one of the biggest issues I have with the MiSTer community, many have drunk the koolaid (is that the saying?) that FPGA means accurate, a premise passed around here and by many a YouTuber, when in reality FPGA and software emulation can be as accurate or inaccurate as one another. They achieve exactly the same thing, they just do it differently.
Re: DOOM Enemy Behavior?
FPGA or software emulation is only as precise as the implementation allows it to be?
If i ever were to create a core it'd probably not be very accurate in the sense of timing(s).
Then again, there are quite some artists in here that dilligently keep working on cores and provide them free to their community, even when there are some entitled pricks around here and there.
If i ever were to create a core it'd probably not be very accurate in the sense of timing(s).
Then again, there are quite some artists in here that dilligently keep working on cores and provide them free to their community, even when there are some entitled pricks around here and there.
-
- Core Developer
- Posts: 547
- Joined: Sun May 24, 2020 9:30 pm
- Has thanked: 20 times
- Been thanked: 145 times
Re: DOOM Enemy Behavior?
As I had mentioned on the discord, even if the Doom enemy behaviour is different, this information is not actionable, except to the original author(s) of DOOM. In its current state, this amounts to something like "somewhere in the tens-to-hundreds of millions of instructions executed in this 10-second section of gameplay, *SOMETHING* doesn't look right."
In the event that this is due to an imperfection in the system's behaviour, it would need further refinement in order to boil it down to a more specific and repeatable scenario. For example, a CPU instruction.
In the event that this is due to an imperfection in the system's behaviour, it would need further refinement in order to boil it down to a more specific and repeatable scenario. For example, a CPU instruction.
-
- Top Contributor
- Posts: 1321
- Joined: Thu Jun 11, 2020 2:31 am
- Has thanked: 15 times
- Been thanked: 213 times
Re: DOOM Enemy Behavior?
@dshadoff Couldn't disagree more strongly. It's fully actionable to the author of the core, or anyone else who wants to gain an equivalent level of understanding of said core.
That doesn't mean it wouldn't help to have access to original hardware for comparison, but it's more common than not that core authors solve bugs from nothing more than a behavioral description they can reproduce. This is exactly such a case.
That doesn't mean it wouldn't help to have access to original hardware for comparison, but it's more common than not that core authors solve bugs from nothing more than a behavioral description they can reproduce. This is exactly such a case.
-
- Core Developer
- Posts: 547
- Joined: Sun May 24, 2020 9:30 pm
- Has thanked: 20 times
- Been thanked: 145 times
Re: DOOM Enemy Behavior?
Being a core author, I know what is actionable and what isn't. A specific glitch on a hardware interrupt is, but a vague statement isn't.rhester72 wrote: ↑Fri Sep 03, 2021 7:56 pm @dshadoff Couldn't disagree more strongly. It's fully actionable to the author of the core, or anyone else who wants to gain an equivalent level of understanding of said core.
That doesn't mean it wouldn't help to have access to original hardware for comparison, but it's more common than not that core authors solve bugs from nothing more than a behavioral description they can reproduce. This is exactly such a case.
You need breakage which is much more out-of-bounds and immediately recognizeable... Or a core author who knows the inner working of that specific piece of software, and a boatload of time on their hands to decide to do the 100-million cycle deep dive.
Hint: they are rare.
Or, maybe you think that the only reason it isn't getting solved is because developers are lazy.
-
- Top Contributor
- Posts: 1321
- Joined: Thu Jun 11, 2020 2:31 am
- Has thanked: 15 times
- Been thanked: 213 times
Re: DOOM Enemy Behavior?
@dshadoff Kinda done with your Negative Nancy routine, so I'm just going to stop replying. It's pointless. I've gone through this with you on two prior subjects with exactly the same result.
All others: Sorry for the noise, won't happen again.
All others: Sorry for the noise, won't happen again.
Re: DOOM Enemy Behavior?
Exactly, FPGA!=accuracy just by being FPGA. BSNES accuracy only got to the point it is now thanks to ten+ years of hard work by Near (rip).MostroW wrote: ↑Fri Sep 03, 2021 6:30 pm FPGA or software emulation is only as precise as the implementation allows it to be?
If i ever were to create a core it'd probably not be very accurate in the sense of timing(s).
Then again, there are quite some artists in here that dilligently keep working on cores and provide them free to their community, even when there are some entitled pricks around here and there.
If ever I say to myself why can't these sorts of issues be fixed. I think, "think of all the people versed in C etc, of those who have an interest in gaming, of those who are interested in retro, and of o those who have the ability, time or willingness to work an an emulator. Now take that idea and apply it to FPGA... Probably a fraction of a fraction of the C guys, how can we expect fixes yesterday"
Most of all I can't do it myself so who am I to complain
Re: DOOM Enemy Behavior?
i dabble a bit in stuff, i dive in and try to make sense of things as good as i can, depending on the available information on the internet.
from what i've understood and correct me if i'm mistaken but software emulators are still single threaded/core applications where all events get handled top to bottom in a sequential order.
whereas in fpga implementation everything is happening in parallel and one chip halting doesn't necessarily halt the whole system but might introduce weird behaviour if interpreted incorrectly.
so i gather from that, that either there must be a 100% complete documentation on chip(s) behaviour or reverse engineering, which i think was also done for bsnes when they decapped and used a electron microscope to prod certain chips right?
and i can only imagine that there still might be the chance that some operations could potentially be missed, and in this case there were only 3 games that actually used this version of the chip.
this all goes way over my head, but i respect the people that take the time, effort, money to make these things happen, this can be all but easy.
from what i've understood and correct me if i'm mistaken but software emulators are still single threaded/core applications where all events get handled top to bottom in a sequential order.
whereas in fpga implementation everything is happening in parallel and one chip halting doesn't necessarily halt the whole system but might introduce weird behaviour if interpreted incorrectly.
so i gather from that, that either there must be a 100% complete documentation on chip(s) behaviour or reverse engineering, which i think was also done for bsnes when they decapped and used a electron microscope to prod certain chips right?
and i can only imagine that there still might be the chance that some operations could potentially be missed, and in this case there were only 3 games that actually used this version of the chip.
this all goes way over my head, but i respect the people that take the time, effort, money to make these things happen, this can be all but easy.
-
- Top Contributor
- Posts: 1311
- Joined: Mon Jul 06, 2020 9:37 pm
- Has thanked: 634 times
- Been thanked: 308 times
Re: DOOM Enemy Behavior?
I don't think there are that many people working on development of the MiSTer. There are endless things they could spend their time on. They are not employed by anyone to do MiSTer development, and therefore they get to pick and choose what they spend their time on. As end users, we can point out problems and request features all day long, but we can't expect anything to be done about it. I don't think it hurts to point out issues, and if a developer has interest in looking into those issues, they might get fixed. If not now, maybe someday. I have an electrical engineering degree from the 90's and might have a chance at learning how to contribute someday if I decide to spend the time to dive into it. If I did, I would fix the issues and implement the features that I have requested first and go from there. Most likely this Doom fix would never come from me since I would be more interested in creating an Apple IIGS core, fixing the Apple II core (wrong colors, etc), adding color to the Mac core, adding working SNAC support to the Atari 2600 and 7800 cores, etc. Meanwhile, I will just enjoy what we do have and continue submitting suggestions and issues as I find them. I am ok with that and don't expect anything.
- aberu
- Core Developer
- Posts: 1192
- Joined: Tue Jun 09, 2020 8:34 pm
- Location: Longmont, CO
- Has thanked: 247 times
- Been thanked: 411 times
- Contact:
Re: DOOM Enemy Behavior?
Absolutely right.dshadoff wrote: ↑Fri Sep 03, 2021 6:38 pm As I had mentioned on the discord, even if the Doom enemy behaviour is different, this information is not actionable, except to the original author(s) of DOOM. In its current state, this amounts to something like "somewhere in the tens-to-hundreds of millions of instructions executed in this 10-second section of gameplay, *SOMETHING* doesn't look right."
In the event that this is due to an imperfection in the system's behaviour, it would need further refinement in order to boil it down to a more specific and repeatable scenario. For example, a CPU instruction.
I think the most logical place to look is to fix the LMULT on the Super FX 2 (GSU2A or GSUA2 i think it's called?) bug that we found by running the GSUTEST rom. LMULT is used 143 times in the DOOM source code, and it's used in the enemies files which I assume have their behavior coded into them. Even if this doesn't fix it, it fixes one of the last few test roms that isn't working which works on both bsnes and the real SNES.
birdybro~
-
- Core Developer
- Posts: 547
- Joined: Sun May 24, 2020 9:30 pm
- Has thanked: 20 times
- Been thanked: 145 times
Re: DOOM Enemy Behavior?
This is certainly a good place to start - any test which passes on the original hardware but fails on MiSTer is a potential lead. You can run the same set of tests against another emulator, and try to narrow it down (and it looks like some effort has been put into this). If there are any emulators which show the enemy AI properly, you could narrow it down further by understanding which tests pass on that emulator but fail on MiSTer.aberu wrote: ↑Sat Sep 04, 2021 12:12 amAbsolutely right.In the event that this is due to an imperfection in the system's behaviour, it would need further refinement in order to boil it down to a more specific and repeatable scenario. For example, a CPU instruction.
I think the most logical place to look is to fix the LMULT on the Super FX 2 (GSU2A or GSUA2 i think it's called?) bug that we found by running the GSUTEST rom. LMULT is used 143 times in the DOOM source code, and it's used in the enemies files which I assume have their behavior coded into them. Even if this doesn't fix it, it fixes one of the last few test roms that isn't working which works on both bsnes and the real SNES.
But the above also assumes that a test has been created (and put into a test ROM) which detects the scenario at play here. The tests which exist today may or may not describe this scenario - a new test may need to be invented.
In any case, there is no harm in correcting the core for the tests which fail... this would at least probably correct some other misbehaviour in another game. These are the types of things I was referring to above, where I mentioned something "actionable". Those tests - provided there exists some description of what behaviour is expected - are very actionable, as they describe precise scenarios with minimal code. Very repeatable, very clear whether the fix "works" or not.
- aberu
- Core Developer
- Posts: 1192
- Joined: Tue Jun 09, 2020 8:34 pm
- Location: Longmont, CO
- Has thanked: 247 times
- Been thanked: 411 times
- Contact:
Re: DOOM Enemy Behavior?
Basically the math of the LMULT test is off. On the last test the result should be FFFF and instead it is F800 (or F080, I can't remember exactly). So some kind of 32-bit signed integer math is off. I hate that I don't know how to fix this stuff...dshadoff wrote: ↑Sat Sep 04, 2021 12:25 am This is certainly a good place to start - any test which passes on the original hardware but fails on MiSTer is a potential lead. You can run the same set of tests against another emulator, and try to narrow it down (and it looks like some effort has been put into this). If there are any emulators which show the enemy AI properly, you could narrow it down further by understanding which tests pass on that emulator but fail on MiSTer.
But the above also assumes that a test has been created (and put into a test ROM) which detects the scenario at play here. The tests which exist today may or may not describe this scenario - a new test may need to be invented.
In any case, there is no harm in correcting the core for the tests which fail... this would at least probably correct some other misbehaviour in another game. These are the types of things I was referring to above, where I mentioned something "actionable". Those tests - provided there exists some description of what behaviour is expected - are very actionable, as they describe precise scenarios with minimal code. Very repeatable, very clear whether the fix "works" or not.
birdybro~
- aberu
- Core Developer
- Posts: 1192
- Joined: Tue Jun 09, 2020 8:34 pm
- Location: Longmont, CO
- Has thanked: 247 times
- Been thanked: 411 times
- Contact:
Re: DOOM Enemy Behavior?
There has been a new commit from @srg320 to fix the LMULT test rom from PeterLemon not passing. I tested it out and confirmed that the LMULT test works and every single other GSU instruction works, so at least that is put to rest!
However the behavior is the same in DOOM still. So the problem lies somewhere else.
However the behavior is the same in DOOM still. So the problem lies somewhere else.
birdybro~
Re: DOOM Enemy Behavior?
Could it possibly be the rom dump itself?aberu wrote: ↑Sun Sep 05, 2021 5:23 pm There has been a new commit from @srg320 to fix the LMULT test rom from PeterLemon not passing. I tested it out and confirmed that the LMULT test works and every single other GSU instruction works, so at least that is put to rest!
However the behavior is the same in DOOM still. So the problem lies somewhere else.
But i imagine a incorrect rom dump wouldn't load at all let alone show incorrect behaviour?
Re: DOOM Enemy Behavior?
A bad ROM dump could certainly cause unintended behavior, but I don't think that's the case here. I'm using a no-intro version on both the MiSTer and SD2SNES, and also tested the same ROM in bsnes just for sanity's sake while getting the checksum.
sha256: d45e26eb10c323ecd480e5f2326b223e29264c3adde67f48f0d2791128e519e8
sha256: d45e26eb10c323ecd480e5f2326b223e29264c3adde67f48f0d2791128e519e8
- aberu
- Core Developer
- Posts: 1192
- Joined: Tue Jun 09, 2020 8:34 pm
- Location: Longmont, CO
- Has thanked: 247 times
- Been thanked: 411 times
- Contact:
Re: DOOM Enemy Behavior?
Unlikely to be a bad rom dump as the user who made a video earlier was using the same rom for testing on the mister and testing in the sd2snesMostroW wrote: ↑Sun Sep 05, 2021 10:02 pmCould it possibly be the rom dump itself?aberu wrote: ↑Sun Sep 05, 2021 5:23 pm There has been a new commit from @srg320 to fix the LMULT test rom from PeterLemon not passing. I tested it out and confirmed that the LMULT test works and every single other GSU instruction works, so at least that is put to rest!
However the behavior is the same in DOOM still. So the problem lies somewhere else.
But i imagine a incorrect rom dump wouldn't load at all let alone show incorrect behaviour?
birdybro~
Re: DOOM Enemy Behavior?
I am surprised to see that no one mentioned that the source code of the SNES port of DOOM was released and is available for people to look at . It might help out figuring out the AI enemy behaviour issues on the Mister. The code is available at https://github.com/RandalLinden/DOOM-FX
-
- Posts: 172
- Joined: Sun Mar 07, 2021 12:28 pm
- Has thanked: 31 times
- Been thanked: 48 times
Re: DOOM Enemy Behavior?
It seems the issue has been identified and a tentative fix has been made in the GitHub ticket:
https://github.com/MiSTer-devel/SNES_Mi ... -991713641
Initial reports suggest it works. @John198X can you confirm?
https://github.com/MiSTer-devel/SNES_Mi ... -991713641
Initial reports suggest it works. @John198X can you confirm?
-
- Posts: 157
- Joined: Sun Aug 30, 2020 12:04 am
- Has thanked: 98 times
- Been thanked: 46 times
Re: DOOM Enemy Behavior?
I just did a test with SNES_unstable_20211214_5a9e.rbf and seems to work on my end. Only tested the part from my video.
- aberu
- Core Developer
- Posts: 1192
- Joined: Tue Jun 09, 2020 8:34 pm
- Location: Longmont, CO
- Has thanked: 247 times
- Been thanked: 411 times
- Contact:
Re: DOOM Enemy Behavior?
Yup, it seems to be resolved, I was very happy to see this edge case ironed out!
birdybro~