DOOM Enemy Behavior?

[lordoftime79]

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.

[John198X]

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.

Check out the video a few posts up at https://youtu.be/Tzc3e-W6z78.

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.

[Sarge]

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.

[Jegriva]

I own the original PAL cartridge, played it on UV skill, and I can feel too the enemy behavior being less prone to shoot on the MISTer.

[LamerDeluxe]

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]

On the topic of Doom, Fabiens Black Book is worth a read.
Can read the pdf for free -

https://fabiensanglard.net/gebbdoom/

[Blitzwing]

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

[Blitzwing]

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.

To 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.

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.

[MostroW]

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.

[dshadoff]

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.

[rhester72]

@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.

[dshadoff]

@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.

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.
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.

[rhester72]

@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.

[dshadoff]

Would be great to see how you fix it. Looking forward to it.

[Blitzwing]

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.

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).

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

[MostroW]

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.

[thorr]

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]

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.

Absolutely right.

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.

[dshadoff]

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.

Absolutely right.

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.

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.

[aberu]

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.

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...

[aberu]

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.

[Sarge]

Bummer. Well, I'm sure as the core gets more accurate, it will all get sorted out. Thanks to everyone that works on these cores!

[MostroW]

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.

Could it possibly be the rom dump itself?
But i imagine a incorrect rom dump wouldn't load at all let alone show incorrect behaviour?

[Sarge]

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

[aberu]

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.

Could it possibly be the rom dump itself?
But i imagine a incorrect rom dump wouldn't load at all let alone show incorrect behaviour?

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 sd2snes

[Jegriva]

Maybe RAM values at startup?

[SkinnyV]

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

[AtomicShroom]

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?

[Stupid Dufus]

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]

Yup, it seems to be resolved, I was very happy to see this edge case ironed out!