Regen for Linux and Windows

[tetsuo55]

Hi,

There is an option in Regen to take unfilitered screenshots .

Stay safe,

AamirM

I can't use regen in the office (but i do have access to imaging tools to do some tests on the image)

[SmartOne]

Not really . Its already pretty much there. Most of the things in my core are 100% binary accurate (sin values for example) with the real thing. Other things are based on the docs (which turn out to be wrong sometimes).

That makes me feel good.

I cracked this problem as well now . Ain't I cool or what .</shameless brag mode>

So does that.

[King Of Chaos]

Hehe, good work on finding the Spider-Man issue. Might want to check Maximum Carnage too.

[SmartOne]

Hehe, good work on finding the Spider-Man issue. Might want to check Maximum Carnage too.

Wow, AamirM must own a lot of games.
Wouldn't want to do anything illegal.

(Joke. I don't care.)

[King Of Chaos]

Well, a flash cart would come in handy for testing like this actually.

[AamirM]

Hi,

I can't use regen in the office Sad (but i do have access to imaging tools to do some tests on the image)

Here is one.

Waiting for your CRT simulator .

Hehe, good work on finding the Spider-Man issue. Might want to check Maximum Carnage too. Wink

Did you notice any problem with that? Cause I didn't.

stay safe,

AamirM

[King Of Chaos]

Nope. But I'll play both games later today just in case (damn they're fun, aren't they?).

[SmartOne]

Well, a flash cart would come in handy for testing like this actually.

I have a flash cart from Tototek. You suggesting that using a flash cart is always legal?

[King Of Chaos]

Hey, just wondering since you have a Tototek cart, are you able to make recordings from the real hardware of some of the music? Could help a lot in testing.

[SmartOne]

I could make recordings when I'm home. I'll probably be at college until Thanksgiving.

I don't quite understand the importance of recordings, because they introduce a lot of other variables that you have to consider.

Crappy Genesis components that affect the sound.
Noise. (from cables, connections...)
Sampling?
Human ear.
Human perception of what is heard.

Why not just go by the docs as much as possible? But then there's errors...

[tetsuo55]

Hi,

I can't use regen in the office Sad (but i do have access to imaging tools to do some tests on the image)

Here is one.

Waiting for your CRT simulator .

The theoretical part of the CRT simulator is all done now, now i have to get some help actually programming it.

Can you tell me the exact pixelclock for the genesis?

[Gil_Hamilton]

I could make recordings when I'm home. I'll probably be at college until Thanksgiving.

I don't quite understand the importance of recordings, because they introduce a lot of other variables that you have to consider.

Crappy Genesis components that affect the sound.
Noise. (from cables, connections...)
Sampling?
Human ear.
Human perception of what is heard.

Why not just go by the docs as much as possible? But then there's errors...

Because the effect of the components is often an expected part of the system behavior.
If I recall, it was actually a problem with NES emulator sound for a while, because the real hardware generates uncommonly round square waves, so the "ideal system" the emulators modeled just didn't sound right.


Of course, on the other hand...
Different Genesises... Genesii... MegaDrives behave differently, so it becomes a case of WHICH imperfect real-world implementation you want to model. And it may be that the right one to model varies with game. Obviously older games assume the first-gen system, but later games could assume any of a number of variants.
And for the "Mark 1" systems there's differences between the multi-out on the back and the horrible horrible headphone port on the front...

[odditude]

the horrible horrible headphone port on the front...

which, sadly, was the only way to get stereo sound without a hardware mod...

[Gil_Hamilton]

the horrible horrible headphone port on the front...

which, sadly, was the only way to get stereo sound without a hardware mod...

True.

Mine's hooked up that way right now.
Genny 1 patched through a SegaCD2.

I HAVE a Genny2, but

1. don't have a video cable for it, just an RF modulator. Though I DID find a source for that damned mini DIN8 they use, so it's just a matter of busting out the soldering iron and charring my fingertips.

2. It has a lousy signal encoder that makes everything look like overcompressed JPEGs. Which is why just buying a new cable seems like a bad idea. I want RGB out so I can bypass the encoder. And I don't have the outlets to get a 32x JUST for the encoder.

[SmartOne]

Because the effect of the components is often an expected part of the system behavior.

That's partially what I used to think. Now I know emulators that truly aim for accuracy go by the documented specs and/or nitty gritty hardware tests that reveal exact numbers.

Kega Fusion is this. That's why it sounds better that a real Genesis. (Yes, I know it's not 100%, but it's pretty close.)

I think simulating crappy components (I don't know much about electronic engineering, but for example how the YM2612 is so close to the PPU that you get video noise in the sound) should NOT be the aim of accurate emulators. At most this simulation should be an option decided by the user. Like an NTSC filter.

[Gil_Hamilton]

Because the effect of the components is often an expected part of the system behavior.

That's partially what I used to think. Now I know emulators that truly aim for accuracy go by the documented specs and/or nitty gritty hardware tests that reveal exact numbers.

Kega Fusion is this. That's why it sounds better that a real Genesis. (Yes, I know it's not 100%, but it's pretty close.)

I think simulating crappy components (I don't know much about electronic engineering, but for example how the YM2612 is so close to the PPU that you get video noise in the sound) should NOT be the aim of accurate emulators. At most this simulation should be an option decided by the user. Like an NTSC filter.

So you're saying that on the Atari 7800, Tower Toppler should look like this:


And not this:


Same game, same system. One's a photo of a TV, the other is a screen cap from an emulator that doesn't support color artifacting. Though an s-video-modded 7800 does the same thing.

This is a great visual illustration of the developers making assumptions about hardware imperfections.
Tower Toppler uses tweaks to fool the TV into thinking there's actually color there and not a big pile of vertical bars(as I recall the trick, it involves tuning the width and spacing of the bars so that it looks like the color burst signal, and then relying on the TV's comb filter to improperly read it that way).

Sonic the Hedgehog does a similar trick with the waterfalls in the first stage of the first game. They're supposed to blur into a transparent layer, not be a mess of lines.

[AgetianMereu]

Yeah, it's exactly what I was talking about when I said that building a perfect emulator of a system, in our case Sega Megadrive, is indeed a difficult task. The thing is - we're not talking about emulation of standalone Megadrive components, such as 68000, YM2612, Z80, or something else. These components are joined together into a system, called Sega Megadrive, and operate as a part of the system. While it's entirely possible that a certain minor thing, such as some extra noise or whatever, may be dependent on a specific build of the Megadrive or the use of crappy capacitors or whatever else there may be (and as such can, and should, be totally disregarded during the emulation), it can be totally expected that certain side effects (usually UNdocumented, as opposed to the stuff in the docs) take place because the components are joined into a system in this specific way, or on the specific way the system outputs video onto the screen, or on something else like that. As demonstrated by Gil Hamilton, such side effects may sometimes be actually expected by the games, too, in order to produce specific visual or audio output.

Therefore, in my humble opinion of course, emulating a system (e.g. Sega Megadrive) is not equal to the mere emulation of the standalone components. Actually, for every emulator that strives to be as close to the hardware as possible, it's important to take those undocumented side-effects into consideration, since some games may be partially dependent on them. Of course, it's always possible to say "hey, but the emulator *does* emulate the Sega Megadrive components correctly per the documentation", but if the game just doesn't look or doesn't sound like it did on the real hardware, then it's an imperfection of the emulation core, not the perfection).

Actually, Gil Hamilton's screenshot-and-photo demo is very demonstrative: generally it's one and the same thing, and the individual components such as the CPU and stuff may even be emulated properly by the demonstrated emulator, but if the side effects such as color artifacting are not supported, the game just doesn't look right. And if the game doesn't look right, it's not a perfect emulator of the Atari 7800 system (IMHO).

EDIT: P.S. Haven't found anything to report yet.. tried only a couple games for now. Regen is awesome!

- Agetian

[AgetianMereu]

A little report here: in Regen, the 'Sonic jumping' sound in Sonic the Hedgehog (W) (REV00) [!] has very low volume, not sure if it's normal, can't remember how it was on the real hardware... in Kega Fusion it's louder, but once again, I'm not sure how exactly it should sound since I can't remember, although the louder one sounds more normal to me (I think it used to be louder on the real thing, too)

EDIT: Dunno guys, maybe I'm just hearing things. I keep playing them one after the other (in Kega and in Regen) and by now they sound almost identical to me, maybe a little less volume in Regen, but it might as well be subjective. Can someone else listen to it?.. I'm afraid I don't quite understand it myself by now

- Agetian

[AgetianMereu]

Sonic the Hedgehog does a similar trick with the waterfalls in the first stage of the first game. They're supposed to blur into a transparent layer, not be a mess of lines.

Yeah, speaking of which, the TV RF mode in Kega Fusion looks sooo much like the good ol' Megadrive on my old and not-so-high-quality CRT TV

Speaking of Sonic btw, here's another report: Sonic the Hedgehog (W) (REV00) [!] flickers badly on the waterfall scene in Zone 1 Act 3, GSX saved state included here. I don't recall it ever flickering there on the real hardware, while in Kega Fusion it flickers a bit but not that bad... Sorry if it's VDP-related (not sure, but could easily be). In order to see the flickering, load the saved game and try running (in any direction), keep an eye on the background waterfalls.

Oops, not sure how the attachments work on this board, so I uploaded the saved state to Megaupload, here's the link:
http://www.megaupload.com/?d=NPEW4GV0

- Agetian

[tetsuo55]

Well said AgetianMereu, excelent example Gil_Hamilton.

This is my personal biggest dissapointment in emulation which is why i spent so much time researching CRT simulation.

We musn't forget that each part of the genesis can be emulated this includes the dac's and other stuff. however discrete emulation is very cpu intensive

[King Of Chaos]

I think it's possibly because of the sprite limit. Try disabling the sprite limit and see if it still occurs. Since it happens in Kega too to an extent kinda suggests that to me. I haven't tested it yet, but I will in a bit.

[AgetianMereu]

OK, here's what my testing has shown so far:

In Regen, the waterfalls in Zone 1 Act 3 of Sonic the Hedgehog (W) (REV00) [!] flicker quite badly - see saved game in my post above; btw, for some reason I can't reload my saved state file - it just won't load (it loads up corrupted - I can't play after I load the saved state).

However, in Kega Fusion, turning off "Filtering" in the video menu and turning off all video plugins ("Normal" mode) produces exactly the same effect (it flickers exactly as badly as it does in Regen).

Turning on "Filtering" in Kega Fusion helps reduce the flickering, but it's still there.

Turning on the TV modes (especially RF) in Kega Fusion reduces the flickering practically to zero, you can only see a bit of it on the score messages up top (practically not noticeable).

Therefore, it seems like the behavior in both Kega Fusion and Regen is correct, and the flickering is reduced only in case some heavy-duty filtering with TV emulation is applied (so, the lack of flickering on real hardware is probably just a side effect of filtering or whatever you call it on a real CRT screen, too, because as I said, I don't remember Sonic the Hedgehog ever flicker on the real Megadrive when I played it).

EDIT: Turning on the NTSC filter in Regen and reducing the level of Sharpness to 0 (in order to try and achieve a similar effect to the Kega Fusion's RF mode where the nearby pixels get sorta blended together) does NOT prevent flickering, it still flickers, just a little bit differently.

- Agetian

[AamirM]

Hi,

Well, tomorrow is my Power electronics paper so I haven't read all the posts above except the last few ones.

@AgetianMereu:

This is not a problem with VDP or anything. This part of the game is relying on TV's behavior to remove the flickering you see. Blargg's NTSC filter plugin can remove it if you select S-video from that. And about the savestates, due to some limitations, you need to let the game run for (uptil sonic title screen in case of this game) to make the savestate work properly otherwise you'll get corrupted screen. And I'll see the sonic sound problem. Thanks for reporting.

stay safe,

AamirM

[AgetianMereu]

Thanks a lot for all your hard work, AamirM, and sorry to bother you with stuff that may be obvious or not a bug at all... I'll try the S-Video mode, thanks for the tip! Good luck with your Power electronics paper!

EDIT: S-Video mode sure did the trick! Awesome! Speaking of the Sonic the Hedgehog low volume problem, as I keep playing I'm quite positive that the volume of the jumping sound may be a little low compared to how it should be, so yeah, thanks in advance for investigating it.

I'll keep an eye open for other problems that may be out there.

- Agetian

[SmartOne]

What I said was exactly correct. Take a moment to refresh yourself:

Because the effect of the components is often an expected part of the system behavior.

That's partially what I used to think. Now I know emulators that truly aim for accuracy go by the documented specs and/or nitty gritty hardware tests that reveal exact numbers.

Kega Fusion is this. That's why it sounds better that a real Genesis. (Yes, I know it's not 100%, but it's pretty close.)

I think simulating crappy components (I don't know much about electronic engineering, but for example how the YM2612 is so close to the PPU that you get video noise in the sound) should NOT be the aim of accurate emulators. At most this simulation should be an option decided by the user. Like an NTSC filter.

Where we disagree are the priorities of accurate emulation (emulation theory, if you will.)

The #1 priority of an accurate emulator is to produce the raw output of the system before hindrances.

Then, if the developers of the emulator wish, they might add additional code that simulates what the output "would actually have been" with system quirks and display simulation. Kega Fusion does this. It has RF and CRT modes, does it not? They are optional modifications. Are they 100% accurate? I don't think they are. Maybe I'm wrong here. (I'll admit that they do look pretty good. ...As far as RF can look "good." )

Further, a plugin system can be implemented to allow for both developers and end-users to add any more "system quirks" as they see fit.

By this strategy, everyone's goals can be met. But the #1 priority needs to be raw accuracy.