I find it troublesome when someone releases a program for a certain console, but targeting only a specific version of that console, alienating everyone else who owns a different version.

This part concerns me more than anything. This demo fails to run on 30% of original model PAL Mega Drives, and 5% of model II Mega Drives. That is ... not good at all.

If an emudev invests the effort to perfectly emulate this, then their emulator now doesn't represent 30% of the original PAL hardware consoles in existence.

If this were the only demo ever made, that might be acceptable. But what happens when someone makes another demo that doesn't work on another 40% of consoles? Then another dev makes one that doesn't run on a different 40% of consoles?

Eventually you'll end up in a position where it's impossible to run all of these demos at the same time.

It was always critical to me in making my SNES test ROMs, that every one worked on every console. And if I found something that was revision specific, I'd special case that in the code. But said test had to have a 100% pass rate on a specific hardware revision.

If this demo breaks on a real system, then I could have a 100% accurate to said console emulator, and the demo still wouldn't run. But because of the notoreity of this, people are still going to use it as a benchmark to see how 'accurate' a given Genesis emulator is.

I mean, we already have emudevs scrambling to support it in full :P

Quote:

And about PCE ???

I like the PC Engine. It's like a super-clocked Nintendo with a nicer PPU and without all the mapper chaos.

I'm a little uneasy about the VCE's modesetting registers that let you control the video rendering in -way- too much detail, but mostly because I don't have real hardware to run Chris' demo on and emulate how the registers behave properly, and the documentation on them is garbage that hasn't been improved since the '90s.

But for the most part, it's not too bad.

The SuperGrafx should not have existed. And you'll have to ask me about the PCE-CD later, as I don't support that yet.

And then there's Brazil, which occupies a huge portion of that map, and despite being lumped together with the other PAL countries, actually uses PAL-M. The name of that standard is very deceiving, because PAL software doesn't work on our consoles, and our TV's don't support PAL video. PAL-M timing is compatible with NTSC timing, so we always used NTSC software on consoles that output NTSC-compatible video but with different color encoding. NTSC was even widely used in Brazil in rental VHS tapes (maybe as a crude form of copy protection, since most VCRs couldn't record NTSC? I don't know...).

There are PAL-M C64s, they are called "Drean" which was the name of the Argentinean company that made and sold them. This gives the follow sets

I read Oziphantom's comment as implying that the scene would think a Commodore 64 modded to output PAL60 or PAL-M is "not real".

Oh, I see... Well, I guess it's OK to include features in an emulator replicating mods that can be done on hardware, but developers targeting these special "modes" should know that their audience will be severely cut down due to the fact that most people can't or won't mod their hardware.

The point of making a 60hz PAL but with 63 clocks rather than 65 clocks was "not real" - and it would be to make the emulator experience better as if you view something that scrolls at 50hz on a 60hz machine it is going to be jerky. Adding Drean support helps this but doesn't help the vast library of existing games.

Want 72 Vblank lines on NTSC? Force blank 17 lines from the top and the bottom of the display. This reduces you to 190 active display lines.

Yes, it's lower. Yes, it'll be letterboxed. But is it the end of the world to have a 256x190@60hz demo instead of a 256x224@50hz demo that most of the world can't even watch at its proper refresh rate? You are trading refresh rate for scanlines.

If I saw Overdrive 2 running at 190p/60hz instead of 224p/50hz, I would not have felt any less impressed by it.

If you are VBlank bound and can put up with the general unwashed of the USA bitching how there is a bar there, and how it shouldn't... also see US Gamers VS Sony over the 1080P vs 960(980?)P debarkle. If you are CPU bound then adding more VBlank won't help you. If you are CPU and VBlank bound it will make it worse.

Take that out, and ... I still don't know why you'd be comparing land mass for a TV standard. Population density is what matters for a popularity contest. Pragmatism is what matters for compatibility. PAL may or may not win on the former, but NTSC wins on the latter.

This part concerns me more than anything. This demo fails to run on 30% of original model PAL Mega Drives, and 5% of model II Mega Drives. That is ... not good at all.

If an emudev invests the effort to perfectly emulate this, then their emulator now doesn't represent 30% of the original PAL hardware consoles in existence.

Well there are two ways of looking at it I feel. Your way is there is "a MD" or "a SNES" which is the perfect SNES that runs all software 100% and is perfect. However their are different hardware revisions and each one will change gates, rise/fall times, timing issues etc and so the true SNES emulator doesn't emulate a SNES but lets one choose "SNES NTSC r1", "SNES NTSC r2", "SNES PAL r2", "SNES Jr"(these are just example names, I don't know the exact revisions of the MB/chips etc ) etc and then it will emulate how that specific machine does things, rather than the concept of the machine.

No big surprises, no headaches (and no mode 7 or column scrolling.... )

I agree, no fancy hardware effect(without tricks) . But it' a real pleasure to code for, except i'am not a big fan of segmented memory .

Quote:

I'm a little uneasy about the VCE's modesetting registers that let you control the video rendering in -way- too much detail, but mostly because I don't have real hardware to run Chris' demo on and emulate how the registers behave properly, and the documentation on them is garbage that hasn't been improved since the '90s.

Sorry about opening this whole PAL vs NTSC can of worms. I really only wanted to point out that regardless of what TV system you grew up with you're likely sitting in front of a fixed 60Hz panel right now (unless you're reallyfancy), and so are most people that stumble on a video of the latest demo or homebrew online. So especially amazing full framerate effects as those in Overdrive 2 will suffer the framerate conversion (which was demonstrated in this thread with the ill-advised assertion that the rotozoomer didn't run at full framerate).

That said, demos for old platforms are almost 100% targeted at PAL machines so I can certainly see why you wouldn't want to break that tradition. But then again, most of my demoscene friends still watch their 50Hz demos on 60Hz screens and it hurts my brain every time...

Yeah, I mean if people want to say the Genesis is a better hardware design, then I guess they're entitled to their opinions, but ... I've emulated both now, and my opinion is that even though the SNES is also rough, it's far saner overall than the Genesis.

Wow, i really wonder how you can make that assumption. The only problem you have with the MD is the VDP control port command format which all make sense for backward compatibility, and that is something you can hide with a simple macro in any programming language.Everything else is quite straight forward: linear memory access, scrolling tables in VRAM, clean sprite tables, versatile VRAM configuration, single video mode with all features available at once (if we forget the compatibility modes as mode 4 for SMS), FIFO VDP port allowing delayed access, VDP accessible during active period...From a programmer point of view the MD hardware is *much much* saner than the SNES one and even from a hardware point of view there is no debate. Of course you have some pits to know about each hardware but honestly there is much more way to screw up your program on the SNES than on MD, the simple fact you can't access the PPU during the active period without corrupting something show the difference between the 2 systems.

Take that out, and ... I still don't know why you'd be comparing land mass for a TV standard. Population density is what matters for a popularity contest. Pragmatism is what matters for compatibility. PAL may or may not win on the former, but NTSC wins on the latter.

I'm not going to step into the debate on NTSC vs PAL (I don't care), but it seems silly to try using population as a means of justifying NTSC or PAL. If you absolutely have to pick one or the other, and if you were absolutely trying to reach the widest audience, it makes sense to go with which region potentially has the most access to the hardware. Sega sold far more NTSC units than PAL, something just under 3:1. Adding that some Genesis units are still being produced and sold in Brazil (we're counting PAL-M as basically part of the NTSC group, right?) the numbers might be closer to 4:1. So if it's a numbers game people want to argue, population isn't the best factor, at least certainly not the deciding one.

That said, the fact that the demo is basically a PAL exclusive doesn't bother me. I haven't touched my real Genesis in years, and the only CRT in my house is sitting in basement (with spiders!) so I'm in no condition to check it out even if I had a flashcart. As long as I can see it on YouTube (which is how I see the majority of demos anyway, except for Game Boy ones) or an emulator eventually plays it, that's dandy. If neither of those were viable options, then I'd be sad.

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum