We've been called out

https://www.youtube.com/watch?v=OeGdJk5zb6c

7:41 - "This concludes our Mega Drive journey. We hope it has been enjoyable. Looking forward to some proper "Super Nintendo" competition :^)"

Are we just gonna take this lying down?

I grabbed out a calculator, and for full screen affine mapping I got ~4 cycles per pixel at 30fps 256x224. How the hell? Maybe did some rendering during non intensive parts.

Okay, the "mode-7" looks like it has a vertical striped pattern and horizontal striped pattern that has the colors added together, so it would be able to add 8-pixel colors at once, but I still need to think about how the striped patterns were rendered.

First, like most console demos I've seen, this is for the PAL Mega Drive, not the NTSC Mega Drive/Genesis.
Second, packed pixels and variable increment make DMA fills somewhat more practical.
Third, you're correct that from other 8- and 16-bit demos I've seen, less CPU-intensive effects involve a lot of prerendering to VRAM (64 KiB) and WRAM (64 KiB).
Fourth, a lot of it might be prerendered, compressed, and streamed to the VDP like "Bad Apple" or the Sonic 3D Blast intro. Flat colors compress well.

It would be pretty funny if some of it is prerendered, just like the Elix demo.

It's a shame demos aren't indicative of real world performance. I don't know why almost no demos are made with any sort of interactibility; how do I know if those space coulds are prerendered or not? Would it have been that difficult to implement scrolling by pressing the D pad? And yes, I know not all demos are like this, such as Stef's excellent Star Fox demo, but why aren't they all like this?

I'm just saying, I'll be more impressed when I finally see a beat em up game on either the SNES or the Genesis with 8 good sized and well animated characters onscreen.

And yes, I'm still working. And yes, it's still been a pain in the ass for me. I need to just get things done and worry about any kind of optimizations that are contained within only one routine later.

Honestly, if a demo for the Megadrive wasn't comparable to an Amiga 500 (OCS) demo, I wouldn't think it was noteworthy.

The ROM is 8MB (or 64 megabits) so that "mode 7" style pattern is probably pre-rendered, with some compression.

Quick question: did any of the rev.1 S-CPUs make it into the first batches of PAL consoles?

A lot of things that look like pre-rendering in order to achieve the blending effects are (ab)use of the VDP Debug Register; one configuration of them can produce a logical AND-like effect:

Their message is very ambiguous.

They're either meaning they expect someone to make a demo for the SNES as 'impressive' as their Mega Drive demo, or (given the emudev taunt right next to it,) they're implying that they intend to make a demanding SNES demo themselves to screw with emudevs.

If the former, just display a picture that uses more than 9-bit color :P
Everyone knows the Genesis' 68K CPU runs circles around the SNES' 65816.

If the latter, bring it on ;)
I won't be as much of a pushover as the Genesis emulation scene has been.
(Still hoping that one of these years someone as talented as blargg will come along and get the YM2612 cycle-accurate too. But we still don't even have a perfect understanding of the SN76489, so good luck with that.)

How am I supposed to know if this demo doesn't use an enhancement chip if it doesn't run in emulators?

Give me the animation cels, and I'll see if I can figure out how a demo might work. But I think there's a good reason that beat-em-ups don't have 7 enemies at once, which I'll take to another topic.


Put it on a cartridge that doesn't have an enhancement chip and run it on a PAL Mega Drive.

Come to think of it, we could show competition by making our demo for NTSC with "60 > 50" writing all over the place. We could do the "mode 7" stuff with actual mode 7 and the plasma stuff with subtractive blending and/or offset per tile (the equivalent of VSRAM on the Genesis).

The point of a demo, in the scene sense, has pretty much always been to sacrifice the generality required of interactivity so that you can make it as visually and technically impressive as possible. Also, because you're often writing a demo to win at a compo, spending time and energy trying to make something interactive and robust doesn't make a lot of sense - it's being projected on a screen in front of dozens of people and running on its own.

Titan is a well-respected group; they wouldn't risk their reputation by breaking the rules of the compo and misleading people about the tech their demo used.

http://www.pouet.net/prod_nfo.php?which=69648

They've already mentioned the cart/mapper used (the same mapper Super Street Fighter II uses) and there's a short list of existing flashcarts it can be run on.

Well that was no ComaLand... Apart from the 3D flying I've basically seen all those type of effects on the C64.

The Mode 7 mode is easy, it repeats, so all you have to do is repeat a char square and then plot a piece of it into the chars. yes, lots of look up tables, pile of speed code but nothing that is too crazy. To do the rotate about the X you basically line crunch/line double your way down to get the compressed/expanded effect, which we could do in HDMA

The 3D part, you don't plot a bitmap, that would be crazy(Does the MD even have a bitmap mode?). Any large block of single colour is just a 8x8 tile right? So then you just need to worry about the tiles that are on the colour edge. There will be N combinations for the most part, when you get to the background parts, the further away the less pixels that change. So you put the edge cases in some chars, then you keep a bunch of tables which tell you which char you need for whatever camera angle. Then you use the 68K grunt to draw the spaceship, there will be a pile of optimised 68K 3D code from their Amiga demos, again lots of fancy lookup tables, speed code etc I mean we can get a wire frame that is about that may vertices on a C64, filling it shouldn't be that hard to do with the 68Ks grunt. You could probably do the background angle changes with clever pallet set-ups, then you put near ground objects on their own "plane" which you use to shift it around, letting the solid green grass fill in the gap as you just have to update its tiles and not the Screen Defs. Then the ship is plotted in Sprites.
If you want to see how some of the effects work the C64 versions are document here http://codebase64.org/doku.php?id=base:demo_programming

PAL machines are the best versions, NTSC is for lamers Just think how much better looking games we could have had if people made proper PAL versions...

i agree

Do you mean, scaling/rotating a smaller bitmap, then "stamping" it multiple times around the screen? How does it zoom into the pixels?

Ah the 2nd roto-zoomer, I was thinking the "tartan" one.
Yeah so you have the one bitmap that you rotate/have tables of it rotated. Then you make speed code to render it in the zoom level you want.
So you things like

which gives you 2x2 mode Then the smaller code you have some code that does

Then for smaller you make tables that hold the colours pre packed into a byte so you can just use a lookup table to load the value and store 2,3,4 "pixels" in one write.
Basically the effect is very carefully chosen patterns, with nice look-up tables and then a pile of speed code generators to do the plotting. It might do pallet changes down the screen to also make the pattern look like it is changing when it is the same "bits", also you might be able to use X and Y scroll registers to dupe a line or slide a line around to give it a new look and mask the sides of the shape with some sprites so you don't see the wavy edge.
Again this is just speculation, I don't really know the MD hardware but this is the kind of crap we pull on the C64. Zomming chessboard, NAH, 8 char-sets pre-set with data and we change the charset each line to be the one we want with the right edges stored in it The you shift the Y Scroll to choose the right "row" in the char-set you have chosen.

There was talk about using 2 layers as frame buffers for even an odd pixels, and dma-ing pixels vertically. I think it blits stripes of pixels using dma, to perform horizontal scaling and vertical shearing, and uses raster tricks to do vertical scaling and horizontal shearing.

Like this?

My idea wouldn't work because there wouldn't be enough dma for 2 layers, even in PAL.

@Oziphantom, I'm still confused. Wouldn't there need to be so many prerendered tiles of different scroll values, and scaling rotation amounts that you might as well just prerender the whole thing?

Guys, you're freaking hilarious and just absolutely full of it. The salt level in this thread is insane.

The allegations are hilarious. Custom chip? Prerendering? Playing an animation? This is not the SNES and we most definitely don't need half a dozen Super FX, DSP or other helper chips to do something useful. Just grab a calculator and you'll end up with ~350 bytes per frame. Sorry, not even the best engineers on this planet would compress an 8 minute 320x224 (in one scene even more than that) 50fps video down to that. If you do not believe us and if you are actually as technically well versed as you guys claim - Disassemble our ROM, top our 3.5 years of research, reverse engineering and development. Actually do something impressive instead of making empty claims and trying to downplay our efforts with baseless accusations. The pouet thread has a GIF file showing step by step how our vector renderer works, for example.

This thread is full of people saying "The SNES could do this and that with ease." - Back up your shit, please And let's also not forget that between our platforms the one that dared to have a "demo" released that was actually pure FMV was the SNES. (Don't get me wrong Ferris, I loved your work )

I think there's a very good reason why absolutely nothing technically impressive has come out of the SNES homebrew / demo scene in 27 years, sans the recent efforts by elix.



Yeah this is one thing I wish the MD scene had. One of the main purposes of ODII was to finally push emulator developers to try and catch up with your work (could we bribe you to come to our side some day? )

Also yeah this was meant as a callout to the SNES homebrew/demo community. Been a while since we've heard from you. (We do have a few SNES nuts in our group but we're not planning on doing anything with the system.)

@Oziphantom: There are many reasons why MD demos or console demos in general will never reach the quality of effects you get on C64 and Amiga. (Tiles vs. Linear bitmap / bitplanes /etc., video memory not being mapped to the CPU address bus, closedness and unknownness of many parts of the systems, memory size, lack of good dev environments and/or emulators (ok a non issue for snes i guess) and most importantly those platforms having a 30+ year head start.) - but again let me just ask you to attempt something like this before calling our efforts trivial.



Are you literally trolling? The Amiga is a computer designed for things like this. It has a ton of custom chips devoted to fast graphics, overhead-less digital sound and 512KB+ of memory - oh, and it isn't tilebased.

Just the one part where it keeps zooming and rotating into that Mandelbrot pattern. That's the one part I can't figure out.




https://www.youtube.com/watch?v=w6niMlZzoUY

That features 8 tiny characters, and the potato-video makes it difficult to tell how well animated they are.

I might as well get started on a multiple zooming checkerboards demo as fast as possible.

At which point I shall congratulate you that you have replicated one effect in isolation.

I would love to make a demo showing off what the SNES could do, but I'm more than busy enough already making my own game for it.

If someone else wants to spearhead one though I'll make time to contribute in some way.

@Oerg886: Regardless of hardware, the lack of anything very noteworthy on the SNES (psychopathicteen is getting there though) is in part due to the state of disarray the SNES development community is in. You could argue this is in part due to hardware (at least because of how difficult it is to deal with; I'll tell you any day of the week that the Genesis is better designed, except for only having 64 color entries), but I could also tell you that the demo scene is far more popular in Europe (hell, this demo in particular is for PAL systems, although that may only be due to increased time for updating vram), where the Genesis/MD is more popular too.

I don't think anyone was arguing about full FMV, but it is true that in a demo like this, things can be much more hardcoded than they can be in a game, (as a lame example, I could create a raycaster with walls with that have 1 pixel columns prerendered at different heights. You could get away with this in 10 second raycasing demo that only shows 4 wall textures, but you're not going to see that in a full fledged game) which is why I'd rather the work put into these demos be showcased in a homebrew instead. New assets don't even need to be made if it's a port. SNES and Genesis both can look much better with better vram management for large, well animated sprites and other unconventional things (like the system of dynamically changing sprite colors I'm trying to come up with, or doing the near impossible task of occluding sprites like psychopathicteen briefly suggested.)

This is not an only anti Genesis/MD demo thing. (Certainly no one said the SNES could do better; I'm not trying to discredit you.) I openly stated I wasn't impressed by elix's demos (I don't have anything personal against him) in an older thread, which aren't even in the same dimension as this one. Smash It in particular doesn't look any better than a regular SNES game; it's just a bunch of Mode 7 with HDMA.

You can download it here: http://gra.dforce3000.de

(another video)

Specifically talking about the launch Amiga, not the later ones.

It's a 68k at the same speed, with (because of your choice of large cart) usually less memory available (albeit, per your complaint, more memory dedicatable to the graphics processor). Any reliance on computrons should be comparable between the two, and any substantial differences will be due to the hardware support.

Sure, the OCS has the copper function (but OD2 tentatively seems to not rely on many raster effects) and seventy-gazillion DMA channels (but OD2 streams most of the soundtrack from ROM). And despite the A500's support from its coprocessors, OD2 looks as good as a top-tier A500 demo. With better pacing ... much better.

Regardless, I will definitely enjoy reading whatever technical writeups show up as they come out.

When the SNES and the Genesis are involved, its more like "technical" writeups.

Oh whoops, I seem to have misinterpreted what you said.

Sawwy ^^"

Higan is an impressive emulator, to be sure - but it's not perfect, not when you're trying crazy stunts. I've broken it a few times already while messing around with the PPU, and so far as I'm aware none of the cases in which that happened work perfectly yet.

Mid-scanline BGMODE write handling is much better than it was before v095; better than real hardware in fact (real hardware has worse garbage, and can't quite perfectly mask it with sprites). DMA direct colour actually works better in older versions that get mid-scanline scroll changes wrong, though every version shows the picture one scanline late for some reason. (I was actually able to debug and test a case that only showed up on other people's consoles, because bsnes v072 happened to work the way theirs did.) HDMA OBSEL writes (for OBJ data offset) had the wrong timing last I checked (v097), but for obvious reasons HDMA isn't how you should do that particular stunt...


There's a MD emulator in higan. It's not very far along yet, but it's coming.

...

Anybody know if there are PAL 1/1/1 units? It could be useful to be able to use DMA and HDMA at the same time, and if it's for a demo there's no need for it to work on NTSC...

I, for one, salute our Alien Overdrives.

It's a nice and impressive demo. Good SNES (& PCE) coders shouldn't go red with rage or call foul upon seeing it, but rather say 'good show' and keep working on making their own routines better. Who gives a shit about console wars from 25 years ago, anyway? You've all got enough dough now to own both, right?

There's no such thing as "better than real hardware"! "Lack of glitches" isn't what makes an emulator good, the "presence of glitches similar to those of the real hardware" is.

Different people have different definitions of a "good" emulator. Some prefer accuracy, such as homebrew developers. Others prefer enhancements of various sorts.

I'm not calling it "trivial", just explaining that the trick is coming up with ways to limit the number of calculations you do with clever lookup tables and pallet effects. Coming up with these that both work and are pretty is an "Art", not trivial. But I probably also suffer from C64 snobbery as in the C64 world when an effect is "just speed code" we tend to just be "oh you make some tables and do some speed code - yah" as we now focus more on discovering more hardware tricks or ways to combine tricks, or limiting ourselves to 256B or 4K.. Amazingly we are still finding them 30 years later XD

You don't pre-render, you build the screen out of lookups into the tables, chars etc, but clever setup of the tables, chars allows you to greatly reduce the number of calculations you need to do. The trick is not remove doing any maths, but to find ways to reduce as much maths as possible. Have a look at http://codebase64.org/doku.php?id=base:twisters_x-rotators_and_waving_carpets it is the only one with pictures and C code to help explain the type of tricks better sadly there is not one that covers a bitmap zoomer.

I understand that. But surely it's clear what I meant? Changing BGMODE mid-scanline, for the purpose of juxtaposing BG graphics in two different modes on the same scanline, works better in higan v095+ than on real hardware, in much the same way that sending graphics to VRAM during active display works better in ZSNES than on real hardware. (Okay, maybe that's a bit extreme...)

I suppose a creative 'scener could come up with a use for the garbage pixels. So far, though, whenever anyone's tried it, the mode switch has been the singular goal and the garbage an unfortunate side effect.

...

I'm a bit late with this, but Overdrive 2 is a most impressive demo. I do hope the SNES community rises to this challenge eventually...

That's the exact analogy I'd use! You don't normally want the emulator to show cleaner results for a special trick than the hardware does, you want the emulator to behave the SAME, ideally. If you use inaccurate emulation as a reference point, you're just making higan/zsnes/nesticle programs rather than programs for the actual consoles.


I agree! the more the better!

Can you post a picture of what you mean? Lookup tables can mean anything. The "codebase64.org" doesn't help because I already know how all those tricks work.

Cool demo. I like the music a lot (because it sounds so atypical for Mega Drive).

If you want to compete, remember that even the best code does not seem all that impressive (to most audiences) without good design, graphics and audio to complement it.

Don't worry, that's probably the highest compliment you can get. But if it makes you feel any better, I believed this was running on a stock Genesis :)



Everyone knows the Genesis CPU is significantly superior to the SNES CPU. Just like the SNES PPU runs circles around the Genesis' VDP. The sound chips are a wash, based on personal preference.

The SNES vs Genesis fight ended 25 years ago :P

I wrote an SNES emulator first, because it has the vastly superior library of commercial releases. At least for the genre I care about most (JRPGs). But there are still great Genesis games (Shining Force I&II, Phantasy Star IV, etc), so I wrote a Genesis emulator too.

Enjoy both systems for what matters: the actual games that were released for them :D





I don't really have the ten years of my life to invest into researching the system as thoroughly.

Plus, a lot of what made bsnes so great were all the people that helped me along the way. Most of those people were into Nintendo consoles more, and many are now gone :(

There's some really great Genesis emudevs too, but I think their efforts are kind of overshadowed by how far behind Genesis emulation still is.

Probably about a year out from even attempting to work on things like the VDP test registers and 128K VRAM mode, sorry.



It's because of what I said above: the SNES CPU is much less capable of computations for software-rendered effects. And it's also less fun to program for than a 68K. Yet it has a very strong PPU compared to the Genesis.

As a result, you have commercial titles that are absolutely gorgeous like Tales of Phantasia, Bahamut Lagoon and Star Ocean. SNES games don't have to rely on undocumented VDP test registers to pull off translucency.

So yeah, add all that up and it's no surprise Genesis tech demos are more impressive. As you said, the best trick on the SNES is to use FMV, eg Super Road Blaster.



... the SNES feels like a coherent, custom-fit design.

The Genesis feels like someone went on a shopping spree at the computer parts store.

Just look at the -batshit insane- format you have to use to send commands and write to the VDP memory or set register values. That is not an elegant design: it's a "how can we glue these two disparate components into a working system?" design.

Look at all the ways you can deadlock the Sega Genesis by doing "disallowed things." There was only one known CPU crash on the SNES, it was tricky to do (DMA right as HDMA started), and was fixed in revision 2.

The big problem was that Nintendo was classic Nintendo, the same Nintendo they've always been, with their "innovative uses for withered technology" motto, and they kneecapped the SNES in the CPU department. If Nintendo had thrown in a fast 68K CPU and fast RAM, nobody would be having these SNES vs Genesis discussions.



I got all of your demos to run. The only one that doesn't work now is your palette RAM DMA, because fixing that throws off timings in other games.

I need those timing numbers for PPU fetches from jwdonal, because I've reached the end of what I could work out using pure software analysis.



Everyone here knew what he meant :)

The garbage on the SNES is due to more state being latched longer than it is in higan.

I have the SNES PPU designed in such a way that these changes would be trivial ... but only if we knew what they were. It's vastly too difficult (for me) to build test cases and try to turn garbage pixels on the screen into concrete understandings of what was being latched at what cycle.

If I can at least get the VRAM fetch timings from jwdonal, then I will at least have a *start* for trying to eke out this information from specially crafted test ROMs.

It was running on a stock PAL Mega Drive. To the best of my knowledge, all Genesis systems are NTSC, and with the demoscene primarily confined to mainland Europe, demos like this tend to be PAL exclusive.


Including or excluding the creation of new games for them in 2017?


So in other words, the Genesis looks more like a PC, and it is the master in the computing speed race.


Or a "how can we have a machine that runs games from this generation and the previous generation?" The format resembles that of the Master System, which in turn resembles that of the TMS9918 series VDP in the TI-99/4A, CreatiVision, ColecoVision, and SG-1000.


Some of that might be tradition: 68000 systems are more likely to assert /BERR than 65816 systems are to assert /ABORT. When the 68000 came out, workstations and servers were moving toward memory protection rather than just letting programs run by one user of a time-sharing system stomp all over those run by another, while 65816 systems were either upgrades for 6502 systems (CMD SuperCPU for Commodore 64), backward-compatible successors to 6502 systems (Apple IIGS), or systems where backward compatibility with a previous 6502 platform was considered at least at the early design phase even if ultimately discarded (Super NES).

Or are there ways to lock a Genesis so hard that it can't even call the bus error handler? At least the 68000 can reset the Z80 in a Genesis; the same can't be said for the 65816 and SPC700 in a Super NES.

All the oddities of VDP access and weird scattering of bits in registers stems directly from TMS and SMS VDP.

Example from my work in progress VDP doc (MD - SMS - TMS) :


And as far as lock up conditions go, they only happen if you access 8th and 9th MByte (no !DTACK generated in hardware), when accessing ranges of unused addresses in VDP space (10th and 11th MByte), when you make the VDP give you a read or write and you do the opposite (no !DTACK generated then) and when you set up DMA registers and don't do a DMA but a regular access instead (VDP seems to barf entirely in that case, I am still investigating this behaviour).

!BERR is tied high in MD, bus error will never happen. On Neo Geo there's a jumper to trigger a bus error manually.

Yes, because the VDP controls DTACK... :/

I just found out the rotozoom effect was at 12.5 fps, not 25 fps. Oh! That makes more sense now.

What are you talking about? The fractal rotozoomer is running at 50 fps.

Absolutely amazing demo, quite possibly the best stuff ever to grace a stock mc68k machine (in addition to obviously being a top contender for best console demo ever). To all the armchair critics pulling the tired "well done but nothing technically impressive" card, there is only one response.

I'm eagerly awaiting the promised technical write-up! As for SNES coders stepping up to the challenge... Most active coders seem to be busy with (original) game projects/engines and (commercial) game translations/hacks, so the best bet for new demoscene activity at the moment is probably an influx of talent from other platforms who is looking for a new challenge. I was hoping that the ending tease was indicative of precisely that, but that wasn't the case I suppose...

No, it's 12.5 fps. I downloaded the video from youtube and did some frame by frame in virtual dub, and it's 12.5 fps. Some parts run at 50 fps, but this part is too CPU intense.

Whatever source you're using is giving you an incorrect impression: all the zoomers are running at 50fps.

In fact, the only parts that seem to not be running at 50fps seem to be the actual 3d rasterizers... those seem to be 12-16fps depending on scene complexity.

The fractal zoomer is 50fps.

So is there a video I can download where it does run at 50fps? The demo can't run on emulators.

Well, yeah, they all run, but there are still little niggles:

The CGRAM DMA trick, in addition to the timing issue you mention, also shows the picture one scanline lower than it should. This is true of every version of bsnes/higan I've tried. With the test image I used, there's a brown line on the top of the screen (representing the tail end of the image that got written at the end of the previous frame), and the bottom line is missing. This has been proven not to happen on real hardware.

The BGMODE change now works, which is awesome. But as noted, the garbage is different, and if I want to be able to tell if obvious glitch pixels are visible through the sprite mask I have to use my real SNES, because in higan the masking is perfect.

Using HDMA to change OBJ table locations is probably ridiculously timing-sensitive, because it's interrupting OBJ data fetch. I wrote an ill-advised test program that I suspect only worked because it only used one sprite, and the switch happens one line late in higan compared to my real SNES. First Try by Magical does the same thing, and it seems to work perfectly in higan but shows some minor glitching on real hardware. (Fortunately it is entirely possible to do this glitch-free simply by writing during the active line, when the PPU is busy with OAM and BG data. Dunno why Magical didn't think of this...)

Then there was that stupid stunt I pulled back when I was learning how IRQs work, where I tried to line up the end of forced blank by polling the counters instead of redirecting the IRQ. I got much more permissive behaviour in higan than on real hardware; I couldn't get the screen to reliably turn on during HBlank on my real SNES, and it showed sliver-based behaviour where higan was pure dot. If this has been fixed, I missed it.

https://www.youtube.com/watch?v=gWVmPtr9O0g

The video on Oerg866's own channel shows the rotozoomers clearly at 50 FPS as long as you're watching it at 720p (YouTube doesn't support 50fps video at lower resolutions).

I downloaded the video from that channel and it showed up as 12.5 FPS during that part.

What prevents Oerg866 from making the video available through a means other than Google's YouTube service?

To make it difficult to analyze effects.

If you're able to download a (apparently inferior) copy of the video from YouTube, what's preventing you from just watching the video as intended in the actual YouTube player?

And are you seriously suggesting that Oerg866 is intentionally using YouTube's low-FPS video encoding to stop people from analyzing a demo when the ROM itself is publicly available? Come on.

I have a hard time telling the difference between framerates. Plus if I manage to download a 50fps version I can see if there's any short cuts.

My laptop's CPU is too slow, and my laptop's display is too small, to watch 1280x720 pixel high-motion video in real time. In addition, I haven't been able to discover a frame-stepping feature through the YouTube player's user interface.

I just downloaded a program called "4k downloader" which is supposed to support high framerate videos such as 50 or 60 fps. I hope it works.

Pause the video, and the keys , and . will step frames backward and forward.

Wow, I just wasted half an hour downloading this stuff.

This suggestion is totally out there, and it doesn't make sense when the demo ROM is available for downloading.

I was joking about "intentionally making it difficult to analyze."

But the hardware to run the demo ROM correctly is not widespread in the anglophone world. People with English as a first language in industrialized countries that use or formerly used NTSC, such as the United States and Canada, greatly outnumber people with English as a first language in industrialized countries that use or formerly used PAL, such as Great Britain, Ireland, Australia, and New Zealand.

tl;dr: Americans don't have a PAL Mega Drive.

You don't need to download any programs, just use http://youtubemultidownloader.com and be sure to get the 720p version. Some times I also use http://www.clipconverter.cc if the other site doesn't show all formats for whatever reason. YouTube does offer low frame rate versions at 720p too, so resolution alone doesn't guarantee a high frame rate.

EDIT: just tested clipconverter.cc and it shows high and low frame rate versions of the video. Pick the one mislabeled as "60fps", which should be the 50fps version. Then click "download" to specify that you don't want to convert the video, just download it as is, and then click "start".

Oh my fxcking god. Never have I seen a nickname ring true in so many ways.

Here you go.

http://mdscene.net/.stuff/what2.mp4

On a different note - My poor CPU is busy reencoding the entire demo for something more suited for uploading (the original was a 11GB ProRes file ...)

Aren't Sega consoles easily mod'able to 50/60fps?

They are, but for starters 'Muricans commonly use composite video for watching and modding the console to 50Hz output does not correctly adjust the color burst frequency for the signal so your picture will be in black and white (It's neither NTSC50 nor PAL )

I'm just going to say it's probably shifting tiles around from the previous frame, and occasionally rendering a unique frame when things get too distorted.

You know absolutely fuckall

Do you know how it works then?

?????!??!?!

I'm part of the programming team, of course I know how it works.

Then how does it work?

Wait for the write-up.

Okay. I'll look forward to it.

In request for a picture of the effect in demo https://www.youtube.com/watch?v=fBI08KppjuE the rotating zooming Mandelbrot can be seen as so in memory
The yellow staggered lines are the screen plots, its triple buffered. The large blue area is the speed code to plot it. The green pattern below it is the Pattern table that holds the "image" math constant look ups. You can see that the char set ( bottom right ) is basically a pattern set of each of the possible colour combinations, this makes it a pattern lookup table. So the maths pattern table holds the index and calculations needed to do the zoom and rotation look ups, which then gets fed into the speed code which then does the plotting.
A lot more primitive than the MD version of cause.

I'm trying to convince the C64 demo coders they need to "defend the architecture and step up to make a SNES demo", not going to well at the moment.

Not sure if this is still a MD VS SNES piss fight, or if it is more a PAL VS NTSC cry session..

Is it shame you don't get a cart... that must be terrible... *cough* Chrono Trigger *cough* Super Mario RPG *cough* Kirby s Dreamland 3 *cough*

For what started out as a callout to friendly competition, there is indeed a surprisingly high amount pissfighting here.
I get why psycopathicteen's scepticism (which I'm sure is hyperbolic anyway) can rub you the wrong way, but Oerg866 also seems like he's trying to provoke some adversity that doesn't need to be there. Most people here are impressed by the demo, and the thread was even started tongue in cheek like "these guys are right, the SNES dev community has been passive for way too long". I'm sure everyone would love to see more activity towards opening up the SNES for all kinds of development, something primarily hindered by a lack of both documentation and community, I guess.

I'm not really a part of this community, but just drop in irregularly and lurk a lot to pick up good programming tips, but it's my impression here that people are equally interested in all kinds of "old school" video game programming. Even though the community is called "nesdev", that doesn't mean there needs to be any kind of Nintendo bias among the users.



Howver, it's ridiculously easy to mod a 50/60hz switch to a MegaDrive/Genesis. I'm guessing it's not really as useful when you already have a 60hz machine, but I would never use one that doesn't have it.

By the way, most of us Europeans who live in countries where English isn't the first language, are still somewhat able to communicate in your silly language. Are the North Americans really such a large majority on this forum?

Here is a 50fps capture of the entire demo: http://mdscene.net/.stuff/od2_h264.mp4

I'm certainly impressed that they made a special effect that I can't figure out. I mean, 3d polygons can be optimized by masking out 8 pixels at once, but I can't tell how you would manage 8 textured pixels at once, unless you're mostly shifting tiles, and even then is tough to do because shifting by a pixel takes 14 cycles on the 68000, and shifting by 2 pixels requires 8-bit moves because of word alignment.

Video memory isn't mapped to processor address space. You have to do all reads and writes through a port, or if you do DMAs you still have to wait for that to complete - so always imagine a massive overhead on top of all graphics calculation.

Then all your hard work produced a rolling black and white picture.

How easy is it to mod a TV to accept a modded console's output? TVs sold in the United States typically aren't specifically advertised as multi-system compatible.


I was born and continue to live in the United States. I am disappointed that there was no substantial demoscene in my country.

Are you sure about this? I admit I don't know a lot about consumer TVs, but pretty much any CRT TV sold here since around the mid 90s (not counting cheap-ass knockoff brand 14" VCR-combo products), or maybe even earlier, supports both 50hz and 60hz TV signals - I don't think they did that to accomodate people who liked to import video games, I imagine it was just cheaper to produce tubes that could be reused across continents, but that's pure speculation on my part.
If "newer" CRT TVs in USA or Canada don't share the same kind of compatibility, that's pretty baffling to me.

Either way, ya'll need to get PVMs or similar high-end monitors. Those bastards will eat anything, including the absolutely all-important RGB video signal you guys were robbed of.

> Or a "how can we have a machine that runs games from this generation and the previous generation?" The format resembles that of the Master System, which in turn resembles that of the TMS9918 series VDP in the TI-99/4A, CreatiVision, ColecoVision, and SG-1000.

In that case, dropping backward compatibility with the Famicom was probably the smartest thing Nintendo did. I never even met anyone who owned a Power Base Convertor. Only ever ran into one person that owned a Master System, and only had two games for it.

> At least the 68000 can reset the Z80 in a Genesis; the same can't be said for the 65816 and SPC700 in a Super NES.

That, and they didn't connect the IRQ signal. Heck, if they made the IRQ re-enable the IPLROM, then they could've used $fffe for the IRQ vector as well, and it'd essentially be an SMP CPU reset. Although I'd prefer to have both a reset command and external IRQ events for SMP code.

But bar none, my most hated thing about the SMP was just the way it pretended to not be a 6502 with those weird Intel-like mnemonics. "mov a,#$ff"? Who are you trying to kid, Sony?

> Well, yeah, they all run, but there are still little niggles:

Yeah, it's far from perfect.

The main problem is I can't just make blind changes to run your demos. The changes I make to the SNES core are almost entirely reserved to when I know for certain said change is correct. And like I said, there's no possible way for me to figure these things out from pure software, which is what I am limited to.

Look at my, er well ... everyone's Game Boy cores. Every other week there's new information on how some behavior works. And every god damned time I implement these new behaviors, they break a dozen commercial titles that worked previously. And then, without fail, more information comes out two weeks later to contradict the old information.

My entire GB core is a wrecked mess now that glitches even on standard titles. Nobody has a clue how interrupts actually work and get masked on that system. Ask four GB emudevs and get six different answers.

I know better than to just "get games working" on the SNES, but unfortunately I didn't follow my own rules on the Game Boy. I wanted to get a video player homebrew title running, and the grand irony is that now even that homebrew title doesn't run anymore.

> For what started out as a callout to friendly competition

Was the callout friendly, really? If so, the coders right now must feel like this :P

Maybe I'm just way too naive?

Does it use any kind of tile pattern recycling? Does it use sprites at all? Does it use raster effects? Does it use undocumented behavior such as changing x scroll values during active display? Does it toggle between 256 mode and 320 mode depending on how close it's zoomed in?

It looks like you're from the US, and thankfully game companies sometimes remember that the world is more than just your country. I couldn't afford a Power Base Converter as a kid, but I did eventually get a Master System a couple of years after my Genesis and had lots of fun with it. Nowadays I find it very convenient that I can play Genesis and SMS games on the same console using a Flash cart, so I'm sure there are people who appreciate the backwards compatibility.

I also find it surprising that you think the SNES is significantly better designed than the Genesis... I don't code for either machine (so forgive me if what I'm saying is stupid), but I read forums about both and the Genesis sounds reasonably straightforward, while the SNES has that maddening banking/mirroring scheme that feels totally 8-bit, a sound chip with a huge bandwidth bottleneck, a thousand video configurations that affect how you can/can't use VRAM, a CPU that changes speed depending on what memory it uses... I mean, I love the feel of a lot of SNES games, but whenever I consider trying to code for the system, the things I mentioned above end up putting me off.

When I was a kid I wanted an NES and my parents got me an SMS instead, because it was cheaper due to its lower popularity.

Anyhow, I think this demo is great. I've been thinking of ideas for an NES demo for years, but I'm not sure if it'll ever get priority among the stuff I want to do. I've always admired the demoscene, but as a Canadian it's never been a local thing for me.

I also think the Genesis is by far better designed. Essentially no weird quirks, things "just work", no bending over backwards to get something standard working. This is from a high-level dev POV, I mostly write C with a rare touch of asm on it. I haven't ever even seen the VDP packet format, I don't need to care about it - SGDK does that for me, I tell it to draw this here and it is done.

The OD2 tech doc was released, it's right here: https://docs.google.com/document/d/1ST9 ... V8saY8/pub

I only know a bit about the SNES, mostly from reading No$'s documents, never tried to do anything with it myself. And I gotta say - both systems are vastly different and both are dirty in their own way.

The Mega Drive is dirty in the sense that components run asynchronously (synchronisation is not 100% perfect with many edge cases) and the audio hardware has no hardware acceleration for sample playback at all which makes it very tricky to achieve clean sample playback.

And the SNES is dirty in the sense that you need to fiddle with banks all the time (not needed on the MD due to its 16 MB linear address space) and Nintendo was stingy with register and memory bits, forcing programmers to fiddle with bits too (they e.g. crammed sprite coordinate bits together whereas on the MD the 9 bit sprite X coordinate just lives in a 16 bit memory slot with the upper 7 bits left unused).

Oh, I know it all too well every time I emulate a new system and have to add in PAL support.



Most definitely. The Genesis is easier to develop for due to having a CPU that was capable of having a reasonable C compiler for it. But from an emudev perspective, the SNES is leagues nicer to emulate than the Genesis.



That's all very configurable.

If anything, the SNES PPU is too flexible. Very hard to understand the entire process, from start to finish. I really should make a flow chart sometime of how all the various bits and settings come into play on rendering each pixel.



In practice, this is a transparent detail. Just know that for the ROM fetch portions of CPU instructions, it'll be 25% faster on FastROM. So if you can use FastROM, use it.



Remind them of that when they ask you for the nicer retirement home ... ;)

[this is obviously a joke]



... wow.

You don't consider the format of bits to write to the VDP to be a weird quirk??



Yeah, see ... I'm talking about from a hardware design perspective. Not from a programmer perspective. The Genesis wins handily as I said above on account of having a good C compiler for it.



The SNES is not the NES. Just use 'HiROM', and your ROM is at $c00000-ffffff instead of the Genesis' $00000-3fffff. Very simple.

Yeah, the 'LoROM' style was funky, I'll agree with you on that.



OAM was a disaster too, certainly. Having a few unused memory bits in return for a more linear format of attribute fields would've greatly helped with sprite-intensive games.

And I wouldn't ask you to. I know how bad it can be to hack operational code to try to "fix" it without understanding what's going on.

Maybe somebody will do a logic analysis that fills in the gaps, or decap and scan out the PPU, or something. Until then, I guess we'll have to deal with "close enough", meaning perfect for most things but prone to little niggles in cases of creative hardware abuse.

Normally I wouldn't see the need to comment on this, but Oerg866 seemed to think emulator accuracy wasn't an issue with SNES, and an effort to compete with Overdrive 2 might not be well served by that assumption...

I've never encountered a european TV with SCART input that doesn't do both 50 and 60Hz video if fed an RGB signal. NTSC video over composite or S-Video is another matter though, more often than not the set will sync correctly but can't decode the color information.

So although we got shafted with crap PAL conversions of 99.9% of the console games released, the connoisseurs here won out with readily available RGB options and easy 50/60Hz modding options from the 16-bit generation and onwards.

I'm a bit puzzled that a console demo in 2017 is made for PAL, though! It so greatly reduces the number of people who will be able to enjoy it properly. The majority will only ever see it on YouTube on a 60Hz display with the frame pacing destroyed, and even most people with a Mega Drive or Genesis and a good enough flash cart aren't able to run PAL software on it.

PAL gamers got the short end of the straw for years, with slow/glitchy conversions and the like, so I don't find it particularly surprising they're not too hesitant in giving the 60Hz world the middle finger for a change. But yeah, I'm kinda disappointed I can't run some of these demos on my own consoles.

Someone did, we just have to hope they'll share their findings with us :)

Until you start dealing with addressing modes that support only the current data bank and have no long counterpart. There is (dd,S),Y but no [dd,S],Y. There are alalal,X and aaaa,Y but no alalal,Y. There is (dd,X) but no [dd,X]. (But that's arguably less important because the only thing I can think of that uses arrays of pointers on direct page is a music engine, and that runs on the SPC700.) MVN works on hardcoded banks. A full address doesn't fit in a register.


I've never encountered a TV with SCART input. SCART isn't really a thing in the USA.

So the MD has a better architecture than the SNES... read the first 2 sections of that doc... remember these are the people that made the Saturn.. yeah uhuh...
Small note on said doc in I think you mean the C64 VSP bug
I remember one night when the programmers were having a SNES vs MD fight, their was a quip about the MD being a machine you debug with an oscilloscope.. now I see what they meant...

Banking on the SNES shouldn't really be an issue, if you split each bank into a "namespace" then 32K should easily get you by on most things. You could even pack multiple "namespaces" into one bank. You will see this in the games, were typically you can see which banks were given to which programmers, as their style changes. So the System code, IRQ/NMI, standard library type functions bank 0, overworld code is in bank 1, the menu system bank 2, the battle bank 3 etc. Being able to switch the Data Bank Register allows you to store your data in sets in the other banks, and easily switch which "set" you code reads by changing the DB register. This allows you to make very small code that can reference N sets of things with minimal code changes and without having to have large and slow offsets, indirect pointers et al.
MD coders be "so I have the nicest CPU that uses 70% of it die to give me a really nice orthogonal instruction set that eats clocks but I like to program in C because who has time for ASM. I couldn't program ASM for the 65816, its instruction set isn't orthogonal, I have to worry about an edge case like Indirect 24 Long offset with a y."

Why PAL?
a.) see http://static.diffen.com/uploadz/thumb/ ... SC.svg.png then note that most SECAM countries also support PAL, yes you are that tiny red bit, yay you
b.) When you make a demo, you want the best machine you can get, PAL machines will slaughter a NTSC machine.
c.) Why make beautiful artwork to show off your skills and have it ruined by Never The Same Colour, how do you make a hot babe in No True Skin Colour, how do you keep colour consistent in patterns with Never Twice the Same Colour. Use Perfect All Lines
d.) Because Americans got into using Carts and Consoles being consumers and didn't get into programming so they have no demo teams/scene/parties, while the PAL territories stuck with computers and have a large number of them. So them then running NTSC with voltage converters and expensive TV/projection gear at the parties so they can have a machine they have to import and can run less code and is has worse colours and sucks - Makes No Sense.

Yeah, my post was written from a european perspective. The SCART connector was even called EURO/EURO-AV more often than not on the early equipment I used that had it (Philips TVs and VCRs in the mid-to-late 80s). And that's in manuals, the actual connector is usually just labeled "AV".

Wahou, it's gold, thanks to share it ..


SCART was the 80's HDMI

I'm not talking voltage or PAL vs NTSC (which only was a problem if you were into LaserDisc in Europe, never for consoles really), rather PAL50 vs PAL60 (actually PAL doesn't really come into the equation here if you're using RGB connectors, as you should). Any console nut in europe worth his salt has a 50/60Hz switch installed so games can be enjoyed at their proper refresh rate, which in no way affects color reproduction.

Anyway, my argument isn't about that but rather about how people are likely to watch anything nowadays – on a fixed 60Hz computer screen (or television set). PAL50 content will always have the frame pacing destroyed for those. For the same reason I've been arguing with my pals who still make Amiga demos that PAL60 would be the better choice (especially since they do most development in an emulator on a fixed 60Hz display anyway).

For 8-bit computer/console demos I realize that 50Hz is really the only option here in europe, but Amiga and 16-bit consoles always have had the 60Hz option and would now be better off if it was used.

It's not a choice for video colors or something like "revenge of the blue apples and red cucumbers VS the world" .
PAL machines are the best choice for their extended vblank if you need huge VRAM transferts .

I think the first OD demo was pal at start for commodities (to don't worry about VRAM transferts optimisation for the party), but was thinked for 60 fps in mind,and the second was really for pal machines, to benefit from their DMA .

I made the same argument to the VICE team. Make a 60hz PAL C64 for emulator smoothness. Deaths ear. The issue is mainly the Scene is held up by the Hardware purists, who if it doesn't work on hardware then it is not real. The Social Elite as it were. So if I make the Game work on 60hz PAL, what do the social elite get, is it to slow? Do we speed up the SID to run at 50hz or 60hz timings? If we make the SID 60, on a real PAL the music will sound bad, if you don't convert it to 60 then all your frame counters are out for the update of Music. So basically you then forsake the hardware all together and just make this new thing which won't be right on a PAL or an NTSC machine, so why not add a 256 colour mode and 4mhz CPU while you are at it? However these days we now have GSync and FreeSync which should allow us to get 50 on a monitor Just to get the Emulator teams to actually use it/port it to linux so they don't get on high chair about it Also I think it would be interesting to see what happens on a 120Hz monitor, it still won't be dead perfect 50, but it will be closer, maybe close enough.

Uh... Isn't that just common sense? Something that only works on emulators is obviously botched, as it follows a non-existing standard while carrying the name of an existing one (e.g. an NES game that only works on Nesticle is NOT an NES game!). You can't even guarantee that such a program will work across different emulators, since different emulators have varying degrees of accuracy and different made-up features. A newer version of an emulator could even break compatibility with with a broken program unless the emulator author deliberately chooses to keep supporting the specific inaccuracies that make the program work.

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

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


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.

> IIRC If the Z80 tries to access ROM while the VDP is doing a DMA from 68k RAM this can lead to corruption of RAM contents due to glitchy signals on the address bus (similar to the C64’s VDP bug).

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.

> Why make beautiful artwork to show off your skills and have it ruined by Never The Same Colour

Oh goodie, now we're doing TV format wars again. I'd rather NTSC than Picture Always Lousy :P </sarcasm>

> When you make a demo, you want the best machine you can get, PAL machines will slaughter a NTSC machine.

Only if you're obsessed with visible scanlines.

So NTSC gets you 224 active display lines, 38 Vblank lines. PAL gets you 240 active display lines, 72 Vblank lines. If you run PAL at 224 and letterbox your display, you get 88 Vblank lines.

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.

> http://static.diffen.com/uploadz/thumb/ ... SC.svg.png

Who cares about Russia? Other than Tetris, what have they contributed to the gaming world?

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.

LAN Master, Lawn Mower, Zooming Secretary, and anything else using neslib.


Out of the top 10 countries by population, China, India, Indonesia, Pakistan, Nigeria, Bangladesh, and Russia are all 50 Hz (PAL or SECAM). USA, Brazil, and Japan are 60 Hz (NTSC or PAL-M).

I'm sure Nigeria and Bangladesh are both thankful that they can watch "Overdrive 2" on original hardware, but I'm pretty certain this is veering extremely off-topic, and was never really a point in the developers' thoughts behind using 50hz. If they even did put any thought into it, the extra CPU time is clearly the most obvious factor.

Personally I'd argue for 60hz too, though, if only because this is a video game console, and 60hz is the standard for every single video game created for that console. And as Optiroc already stated, "any console nut in europe worth his salt has a 50/60Hz switch installed". It's literally a 30 minute mod at worst, and fixes everything wrong with European MegaDrives.

Sarcasm noted. To avoid this sort of pedantry elsewhere, such as on Slashdot, I've used terms like "industrialized anglophone market" to narrow the relevant market for a particular claim.



If you really want to push vertical resolution, nowadays I'd accept letterboxing all the way down to 336 lines on 480i (NTSC or PAL-M) or 400 lines on 576i (PAL 50 Hz) because that fills a 16:9 display. Let's see interlace get some love outside Sonic 2 and RPM Racing.

IMO, the frame rate difference isn't important, compatibility is. NTSC programs can usually be converted to PAL without issues (they might even work as is!), but the opposite isn't always true. Even if you use forced blanking to increase VRAM bandwidth, that eats away from the time used to generate the new VRAM contents, so you might end up losing performance either way.

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. One could argue that home computers were always like that, where programs would work or not depending on the hardware configuration and available peripherals, but consoles weren't seen like that. Back in the day, if you bought a Mega Drive cartridge, you expected it to work on your Mega Drive, no matter if you lived in Europe (PAL), Japan (NTSC) or Brazil (PAL-M)*. If a game happened to require specialized hardware, that was usually indicated prominently on the packaging, or even marketed as a different kind of game (e.g. Famicom Disk System game, Sega CD game, 32X game).

Just imagine me showing this YouTube video to a co-worker and he's really impressed that a Mega Drive is doing that, and then he asks me if we could run the demo using a Flash cart on my real Mega Drive, to which I reply: "No". It's pretty nonsensical, is it or isn't it a Mega Drive program after all?

So yeah, I find it kind of a cheat when your game/demo is made more impressive by excluding half of the consoles by the same name, because your product will be unfairly compared to multi-region programs that have less resources available to them because of that, specially if you don't make your compatibility issues extremely obvious to the public that doesn't know about the technical details.

*Yes, sometimes there were artificial limitations preventing games from working across regions, but more often than not the software was programmed to be compatible.

And about PCE ???

Don't worry folks, I'm sure the TiTAN call for some Super Nintendo competition extends to the 60Hz/NTSC MegaDrive scene as well! :^)

In 50hz land we've been given the short end of the stick since the beginning of home consoles, so it's sort of funny to see the 60hz master race act like this about something as unimportant as a tech demo

I agree.

I see it this way, if big companies cant be bothered to properly convert or even release their software in PAL land (and therefore lock themselves out of potential revenue), then who in their right mind would expect a small team of enthusiasts to spend extra time and effort, for free, to make their software work in NTSC land?

Lets not forget that some effects probably just aren't possible to achieve on a NTSC machine. Just look at all the NTSC 'fixed' games on the C64. Some of the more famous games still flicker badly.

It just reeks of NTSC entitlement.

The argument about limiting audience size by being PAL exclusive doesn't really hold much water. It's a bit of an assumption on my part, but I don't think that the average console owner is the intended primary audience for these productions. It's the fellow sceners, the ones who turn up to the demopartys, the ones who get listed in the greets section of most demos. The people who have the correct hardware (or are willing to put in the effort to gather the correct hardware) probably come a very close second.

PCE is a warm footbath and a toasty fireplace. No big surprises, no headaches (and no mode 7 or column scrolling.... )

So, are there any Mega Drive emulators that are up to the task of emulating this one?

(I'm not well versed in MD emulators. I usually use Fusion or Bizhawk, but neither seems to handle this.)

Apparently Mask of Destiny, the author of BlastEm is working on getting it running. This is what was said to me earlier today.

Anyway, really impressed with this new demo. I loved the original Overdrive. Demos like this always feel like a trip.

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



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.

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

As part of the 30%, it doesn't fail to run, just a few parts using the blending bits of the debug register are a little janky on mine.

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.

Tesla coils, mammoth tanks, and super sexy voices that say "establishing battle field control, please stand by" ?


USA 318.9
Canada 35.16 = 354.06

UK 64.1
France 66
Germany 80.6
Netherlands 16.8
Belgium 11.2
Austria 8.4
Italy 59.83
Spain 46.7
Portugal 10.4
Poland 38.53
Czech Republic 10.52
Sweden 9.5
Norway 5
Finland 5.4
Ireland 4.5
Estonia 1.3 = 438.78

Australia 23.1
New Zeeland 4.4 = 466.28


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.

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 .


Yes VCE "modelines" are not trivial,but permit some cool screen settings easily .


I like the SGX because it address the lacks of the PCE, a 2nd bgnd layer, and a 2nd sprite layer, the mid-res and hi-res are more useable.

PCE-CD, even with SCD-ROM²,there is nothing special, just the add of an adpcm voice, it starts to be very interesting with the arcade card.

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 really fancy), 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...

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.

I don't find it especially clean,maybe not as bad as snes's one, but definitely not optimal in a programmer point of view .

http://md.squee.co/VDP#Sprite_Attribute_Table


Yes you can keep it hiden,but it does not make it better so far

Westwood was American, not Russian? I really liked Red Alert too though.

May I also remind you that people had no issues emulating "Old vs. new SID" on the Commodore 64.

Not emulating OD2 for this one reason seems like a very fabricated excuse - There's so much more wrong with emulators even breaking effects that *don't* rely on this debug register

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.

You 're right, but only two case to take in account vs how many for genesis ??
For now it's not like you have a precise idea, on which hardware it works and don't works, right ?? .

Yes we do. It's the original VDP chips (315-5313) that have 95% of the issues.

If only someone would document that beyond the fact that it exists ... I'd love to emulate it =(



I mean, apparently there is as we're having it, but ... we can agree to disagree, I suppose.



Don't tell that to the -nearly every game in the library- that used HDMA and per-scanline IRQs to do exactly that ... :/



Everything that is 100% repeatable on all real hardware models should be emulated, yes.

And how easy it is to hard-lock the memory controller.


Mode 2 on Super NES is essentially equivalent to native mode on the Genesis.


Which I would find most useful for tile data decompression from ROM to VRAM.

I think you can find some good (and somehow complete) technical information about it on Spritesmind, but you will have to dig a bit to find it i guess (can't find it easily right now).




Haha, good point you made here Well honestly i think it's still quite difficult to argue the opposite but indeed we can agree or disagree.



I should have been more specific: outside the HDMA channels.
They are here for that but still, if you don't properly time your code and your VRAM writes goes a bit outside the VBlank period, bang ! On the MD, nothing wrong happen... you just lost a bit of time.



To be honest that happen on many old systems and probably on the SNES as well. Still if you access invalid memory area mean you probably have something really wrong in your code !



Except it works in 256px instead of 320px but Indeed it can (almost) mimic the classical Megadrive mode 5.
The point is that Mode 1, Mode 2 and Mode 7 represents about 95% of use case, other modes are almost useless and make everything much more complicated for nothing.



Not only... you can also do fast 5/6 consecutive word writes per scanline without stalling the CPU which is very useful to not waste cpu time on raster effect for instance. You can also do code interlacing to improve VRAM upload capability but that is edge usable i guess

Perhaps the problem is the lack of a counterpart to https://wiki.superfamicom.org or NESdev Wiki. These can be browsed online without having to download a compressed archive to a desktop computer, decompress it using proprietary software,[1] and view it there. They can also be updated with new findings.


That and HDMA isn't intended for writing to VRAM. It works fine for scrolling and COLDATA but not VRAM data.


The on-die memory controller of S-CPU version 1 has undefined behavior when DMA and HDMA finish at the same time, I'll admit. But otherwise, its equivalent of /DTACK, which compensates for slow WRAM, slow ROM, and extra-slow gamepad I/O, is guaranteed to release in 500 ns or so. The lack of a /DTACK timeout on the Genesis makes it even easier for a stray memory read to bring the system to an unrecoverable state.


If /BERR were connected to an inverted debounced /DTACK rather than constant, a program could at least recover from an invalid memory area access to display a core dump to the developer.


Mode 3 is for title screens, and mode 5 is for high-resolution text, particularly dialogue in a story-driven game in the Japanese language.


[1] sega2f available from docs is packed in a RAR file. Unlike Zip and 7z, RAR is licensed in a way that prohibits the public from using public documentation and source code to understand the format. I'd provide more details, but the page describing what's wrong with RAR is on the Fedora project's wiki, and Red Hat is currently suffering a massive data center network outage.

EDIT: I found Licensing:Unrar

No :

https://wiki.megadrive.org/index.php?title=Main_Page

Like snes you have also an online documentation .

At the risk of sounding negative and discouraging what I think is a really great project and an useful step forward for the MD dev community, that wiki is...not yet good enough.

I've created an account to help, though

From User group rights:

Users: [...] Edit pages (edit)

From Request account:

Complete and submit the following form to request a user account.

Make sure that you first read the Terms of Service before requesting an account.

Once the account is approved, you will be emailed a notification message and the account will be usable at login.

From Terms of Service:

There is currently no text in this page. You can search for this page title in other pages, or search the related logs, but you do not have permission to create this page.

I wanted to sign up there, but it asks for a biography. I don't know what details to include or exclude because "Terms of Service" is not found.

This appears to be in line with a trend where administrators of Genesis development communities require manual approval of all new accounts, such as wiki.megadrive.org, SpritesMind, and especially SonicRetro. Is there something that attracts more spammers to the Genesis?

Given how stale that wiki is, I wonder if the admin even bothers approving new accounts anymore...

You've used so many wikis and forums before. This is seriously a stopping point for you? Just don't enter anything in the biography. Nobody is ever going to demand it from you. Nothing bad will happen to you if you do not enter a biography under this light assumption. Participating in spite of the missing ToS page is not going to jail you.

Quick update, the zooming checkerboard demo is half way done.

I find it funny you're trying to replicate the rotozoomer of all things in that demo when you could easily do it with Mode 7.

I'm replicating the checkerboard effect, not the mode 7 effect, even though the mode 7 effect is much more impressive.

I wonder when that write up is coming.

Besides…you read their page. It's empty. You already have no point of disagreement to the stipulation set ø.

You mean, the one posted three pages ago?

I think it's good to see a guy so passionate like him for proving that snes can do wonder with his CPU even at 2.6 mhz.

But IMO, it's better to do a demo which use the snes hardware and some tricks,for doing effects that cannot be done on MD rather than monkey it .
Some effects use the MD's chunky mode, don't expect to have the same fps with planar,mostly with a 2.6 mhz 65816 CPU.

I have a theoretical multi-layered Mode 7 effect that I came up with... the catch is that in order for this trick to work, some tiles must be scaled up by 2 or 4 (or if you want to go to the extreme and have four psuedo-layers worth of Mode 7, by 8). It might work its magic with a Mandelbrot set...???

Isn't there supposed to be another write up that explains how the effects were done?

If you miss VBLANK, the read/write just won't have any effect; it won't crash the system. Same goes for accessing 'invalid' memory areas.

It will come, but it's easier said than done. It's not just about how hardware features were used, some effects (esp. the rotozoomer) have a mathematical background I don't want to leave unexplained, but this will take time, I want to make sure that most people will actually understand it. I will probably draw lots of pictues and diagrams too.

But once it's done I'll post it wherever people might be interested including this place.

Thanks a lot,the first one was very interesting to read

VRAM is locked outside VBlank, yes (as far as I know - fullsnes suggests that there could be holes in the timing). But OAM and CGRAM aren't, and you can in principle corrupt them by writing outside the appropriate blanking times (VBlank/forced blank for OAM and additionally HBlank for CGRAM) because the writes go to the current PPU read address instead of the CPU write address. The DMA direct colour trick (analogous to FantomBitmap on the Mega Drive) exploits this behaviour by writing to CGRAM during active display. To my knowledge, the only successful non-blanked OAM exploit to date is whatever Uniracers does with HiOAM during HBlank.

Pretty much. The 65816 issues has been beaten to death here, obviously, but it is indeed a shame that WDC didn't go for something a bit more expensive, and spent those transistors on for example a couple of 24-bit address registers. Having register/memory size encoded in the instructions instead of relying on status bits would've been nice, too. But hey, the machines are what they are and we love them with all their faults and imperfections... (:

Anyway, congratulations to an absolutely mindblowing demo! One of few "proper psycho code" level demos ever done for consoles, really...


Looking forward to that! That rotozoomer is a damn head scratcher. The greetings scroller is also really something else... The interference, blending and plasma effects are obvious how you do after reading the technical write-up, but nontheless impressive and you just gotta love this kind of "world's first" hardware exploitation effects.

I got 8 layers of strips moving onscreen. Now I need to turn these strips into checkered squares.

Something I forgot the 68000 had was a MOVEM instruction that could move several registers to memory in 1 instruction. I wouldn't be surprised if the rotozoomer used it. You can store a 8x8 tile inside the 68000 registers and send it straight to VRAM (if there is enough bandwidth) with MOVEM.

Wait, it just occurred to me. What if the fractal rotozoomer really is just 2 layers with AND-masking, like the plasma transparency effect was?, but there's 6 colors so I don't know how that would map out.

1 instruction, but a metric fuckton of cycles. Worst case 18+4n.



No, you can't. The movem instruction sends it to a continous set of addresses. So if you were to do

movem.l d0-d3, ($C00000)

it would write these to $C00000, $C00004, $C00008, $C0000A - a sure-fire way to completely and utterly crash everything.

The movem instruction is intended for stack operations.



As I said earlier: You know nothing.

Please calm down everyone. We were half joking when we said that, it was rather meant as: "your turn, SNES scene". But seeing how everyone in here is getting busy we succeeded

Given that it almost took us 4 years to make this and we don't have much SNES experience don't expect to see anything on the SNES from us anytime soon. Also, Overdrive 2 isn't over yet. We have documents to write (the tech doc was only so quickly done because I wrote it in parallel with making the demo so just had to proof-read and fill in some extra notes and stuff), incompatibilities to track down and fix if possible, make carts, etc.

And please don't just try to copy effects. Sure, many effects are easy to do on the SNES due to its superior graphics capabilities (3rd layer for rain, mode 7 for rotating cube / rotozoom, etc.), but please try to make a whole and unique demo instead of just saying "the SNES can do this and that too! or better!"

Anyway, I'm looking forward to seeing your SNES demos.

(And movem is actually useful for quickly copying data in RAM or loading/storing registers in some cases, but it depends on the use case, 25% speed gain compared to other 68k instructions in best case. But as oerg866 said you can't use it to write to video memory, all you can do is writing to RAM and then doing a DMA later on, but it's usually faster to just do a DMA from the source data in the first place and not waste CPU cycles on movem.)

You can take you're time writing you're document.

It started to calm down until:


@Oerg866: You seem convinced that people are trying to attack you ever since your first post on this thread, which isn't true.

This has been a super fun thread to lurk on, and in saying that I haven't seen any good reasons to become hostile toward others on here. Almost makes me wanna poke some fun accusations at the Sega 16-bit community for having problems with just that, but I wouldn't know.

I understand the impulsive reaction to try and recreate the exact same effects, to prove that "the SNES can do it too", but ultimately, being creative and thinking of new ways to combine the things the SNES does best might give more interesting results, and will probably be less frustrating than trying to figure out how each effect was implemented.

Okay I've done some more research into this, there is no free lunch. PAL-60 is a lie.
Basically there is the 6526 PAL-N and the 6527 PAL-M but
PAL-N is 65/312 at 50hz so it still gives you 50fps
PAL-M is 65/262 at 60hz so it still gives you 60fps.
Now the PAL-M has the same number of clocks per frame as normal NTSC, so while it has the PAL colour encoding, it can't match a PAL machine, it is still lacking 2626 clocks. Its just a slightly better NTSC.
PAL-N while being the fastest machine, in that it will give you an extra 624 clocks per frame, not to be sniffed at, but it is still 50fps so you will still get the jerk on PC monitors.

This is something that's been on my mind for a while. Here are my thoughts:

A lot of demoscene stuff is basically smoke and mirrors. I get that the whole point is to optimize around a lack of interaction but I'd think the majority of people don't realize this. The effect is that you have people who think you can create an interactive game using all of these effects (see: YouTube comments section, but then, I should probably get back to blocking the comments, as they are rarely insightful). A lot of stuff is at least partially faked or pre-computed (Second Reality 3D scene), which strikes me as rather dishonest.

There's also an obscene amount of elitism in the scene. The constant platform wars are incredible exhausting and I don't understand how anyone can even cope in such an environment. When even Speccy coders do it, you know your community has problems (I realize this is possibly a joke but it has all the rhetoric of platform elitism).

Having said all that, I might be interested in contributing to a SNES demo, assuming that the project isn't run by assholes. I would probably be the Awkward Outsider though as I'm not from a PAL region (though I am interested in the possibilities afforded by the additional DMA headroom provided by the 50hz format). Even if I don't work on a demo though, I still want to work on software for the SNES. The PPU has some interesting bells and whistles. I can render VSTs from Renoise and import them straight to the SNES as game audio. That's really cool! The CPU is weird but I find it a fun challenge to work with (it also helps that despite any awkwardness, I can still do 16-bit arithmetic which really does wonders). I also hope that maybe I can help other people realize the joy of developing for this weird machine. And if anyone wants to shame me for liking the SNES, they're terrible people.

It hit the low point when the Amstrad team(s is there more than one?) got personal https://www.youtube.com/watch?v=YJosZfm560Q actually calling out effects by groups, C64 groups.
At least it is a quality demo

Apart from the part about the demos themselves being "dishonest", those are a lot of good points. Demos are a bit of a strange thing, cause in order to appreciate them you need to actually know what's going on - but at the same time you also need to be able to entertain the audience who knows nothing about the hardware. I remember the winners of demoscene compos often being plain cutscenes with catchy music or funny animations rather than the ones that pushed the technical boundary of the system.
In the case of the SNES, Oerg866 has a good point that trying to figure out how to code stuff that could easily be done with Mode7 would be pretty superficial for a tech demo. Platform elitism is one of the dumbest things ever that gets only more dumb when people drag it up on the subject of 90s consoles in 2017. I would love to see what you can actually do with a SNES demo, as I think you could really have some impressive things that no other pre-3D console could pull off if you start getting really creative about it, just like the MegaDrive is doing its own thing.
I think the whole elitism thing on the demoscene extends to more than just platform elitism though, as there's always been this sense of friendly rivalry between groups. But like any other kind of friendly rivalry, things can get heated and some people will come across as aggressive.

Demos just have to be entertaining. It doesn't matter if an effect is "faked" as long as it is still technically impressive - which would rule out stuff like a pre-rendered video except for the video player itself when the system itself can barely support FMV. In other words, the code can be impressive even if the result itself is not particularly unique. Of course the best is a combination of both.

It's also a bit like stage magician shows - everybody knows you most often can't code a game around a scene because that scene itself is already 100% optimized to the technical limits.

Not everyone unfortunately... you wouldn't believe the number of people who see the PS1 T-Rex demo and ask "why don't any games look this good?" When you think about how the console is presumably using so much power to render the PS2.5 dinosaur that it can't even render a simple Mode 7-esque floor, the impressiveness drops to zero. I think tech demos for native 3D hardware are pretty lame in general, although a couple stand out (most anything for the Atari Jaguar will, given that the games commercially released for it were so terribly optimized that you don't have a good understanding of what the system can actually do).


That was the least tasteful thing I've ever seen.


Exactly why the few SNES demos generally suck. On one of the Smash it Elix demos, there's just a Mode 7 plane spinning in the background while 8 64x64 sprites act as the vertices for a cube. Um, okay? I still think Mode 7 can be useful though, but, like any other hardware assisted graphics in a demo, only if it's being used in a clever way alongside the CPU. For example, you could make a 4bpp raycaster with sprites with Mode 7 for a textured floor and ceiling. (However, you might need the Mode 7 multiplication/division registers, but I'm just trying to make a quick example.)

That's exactly what I was thinking. I'm sure you can use Mode7 really creatively if you're good and able to think out of the box. Something unique would be an effect that didn't actually LOOK like Mode7, since we're all used to the "standard Mode7 look" from all the games that used it, but I'm sure it can be utilized for much more unique ideas.

Mode 7 is most often used as a rotoscaler but it's actually working off a generic transformation matrix. I'd say one of the less used effects is the ability to vertically shear images at the pixel level. The effect could possibly be combined with horizontal interrupts for more complex visuals but the timing on it might be tricky.

Edit: By horizontal interrupts I meant mid-scanline interrupts, but perhaps something could be created using both?

Something I've been kind of wanting is just a simple visual reference of using HDMA on all the PPU registers. Many of them are obvious (e.g. mode, brightness) and some don't make any sense (address?) but it'd still be nice to have a visual representation of same.

@lidnariq: What?

@HihiDanni: The timing would most definitely be tricky. I'm sure 93143 could explain it again for us.

This is making me want to make a PPU documentation ROM with examples of the different graphical features. After all, the Genesis/MD has one for its VDP, and it could potentially be useful given some of the PPU's quirkier functions.

Then add some colour windows over the top for "shadow vectors" just because

More cliché SNES hardware effects? Windowing is pretty cool if, again, it isn't entirely obvious. I really like what they were trying to do with stage 5's boss in R-Type III (https://www.youtube.com/watch?v=ExfYd_1D5Ww#t=22m56s) but the shapes that they were trying to do were too complex. The windowing could still be better though, as it's apparent that the window borders are being figured out computationally in some way instead of being entirely pre-made.

Like Mode 7 though, I think it can be used in more creative ways. I wonder if you could use the two windows to save CPU time for rendering untextured polygons, where the two largest are window layers. You still have to find the edges though, and depending on if you're drawing from back to front or front to back, it could be a real pain in the ass.

No needs to be impressive technically,if you look at overdrive 1, there is nothing impressive on the effects side, it is composed at 90% of hardware effects(intelligently used), but was very well paced, with very good transitions and a non less good music,you add some solid artworks, and all the ingredients are here to make a good demo and this is why it was so popular IMO .

Is the write up almost done yet? I'm still interested.

It has been out for a while now :

https://docs.google.com/document/d/1ST9 ... V8saY8/pub

I meant for the fractal rotozoomer write up.

https://www.youtube.com/watch?v=WJ3AsZp-yTA

So Oerg866 was lying the whole entire time, and it is using the undocumented transparency effect.

I still don't know exactly you can have 6 colors with AND masking though.

This is not an explanation of individual effects, it's a list of hardware notes snarkily aimed at emulator devs (presumably to maintain the smoke and mirrors).

If this is the Sega community's idea of getting SNESers involved in the demoscene, you can count me out.

I dunno; to me it just reads like a summary of research notes by someone who thinks it's fun to mess around with the Mega Drive. My understanding was that a specific explanation of all of the stunts they pulled in Overdrive 2 was not the intent of that document, and that something more along those lines would be forthcoming.

...I feel like if Titan is allowed to use debug transparency even though it fails on some units, we should at least be allowed to use DMA and HDMA at the same time without careful timing, and maybe subtractive delta luminance in a DMA direct colour video mode...

The post kind of implied that this was that explanation doc. They could still be working on that writeup but I'm not really sure why it's taking so long.

Realtalk: Kinda already mentioned before but I don't really want to make a demo, in part because I want to be honest and upfront with the stuff that I do, and also because I don't want to engage in platform wars. I want to have meaningful conversations about retro hardware, not angry Internet Arguments(tm). Fuck that. The only way I could make a demo is if I could make it into a labor of love rather than something done out of spite but given the current vitriol I'd consider this to be nearly impossible. Others are welcome to try though.

I'm just gonna focus on homebrew instead. Most of the driving force behind my work there has been both designing things for other developers to use, and getting to talk about silly weird hardware quirks, even if that makes my preferred system look bad. This kind of thing should be fun, damnit!

I do much better work when I am not just trying to compete (though I do kind've want to finish that little checkerboard parallax thing I started even if it's not my original idea). Something I've been thinking about trying is drawing software sprites on a Mode-7 layer, similar to how Galaxy Force arcade game draws graphics.

Feel free to make a SNES demo as a labor of love. I see no reason for animosity between programmers based on different platform choices. There's a ton of awesome stuff you can do with the SNES - doesn't matter if the Mega Drive can do the same, just make something cool.

No need to argue about which 16-bit console has the best hardware in 2017... They're all shit by today's standards!

I love that way of putting it. DigitalFoundry would have hated the SNES.

i agree, and you should rather don't take the titan's words for a console war, take it as a mutual motivation between the both platforms, and nothing else .
Really, i don't see any animosity from the titan's guys .

That was my assumption too, but then I saw the guy posting here... No reason to stoop to that level though

One thing i'd like to see on the SNES today is a step away from the tech-demoiness of many of its games. I hope i don't tread on too many nostalgic toes by saying so. But one thing i reacted to as a kid was that NES games could often be more pretty, beautiful or distinct (subjective, i know) than snes counterparts because they were obsessed with maximising the use of colours in smudgy gradients. I don't think the console had a long enough cycle to see a rollback of that aesthetic. It's also a child of the early 90s, so there's that.

I agree. A lot of SNES artists were just using more colors because they could, without stopping to think whether they should.

I cringe every time I compare Return of the Joker on the NES against Revenge of the Joker on the SNES. It's incredible how the 8-bit version of the game is better than both 16-bit versions (I'm including the Genesis version here) in every possible way!

I especially feel that the classic side scrolling action game took a hit on the SNES, due to the ability to display much bigger sprites with no penalty. Once again, developers did because they could, before stopping to consider whether they should. The only games on the SNES I can think of that come close to that same feeling of the NES classics are Hagane, Contra 3, and Majyuuou.

True. The downside of bigger sprites is bigger backgrounds, and bigger backgrounds mean less distance between the player and the edge of the visible portion of the map when measured in character heights. This in turn means either slower movement or less player reaction time. I had to explain this to the artist of Haunted: Halloween '85 early in development.

Ironically, having more colours to choose from for a sprite can help give a smaller sprite/metasprite the definition it'd risk lacking on a NES or SMS. That's rarely how they thought at the time.

I think a parallel can be drawn between GB and SNES in the regard of platformers. But on the SNES it was by choice, whereas the only option to fit a larger portion of a level on the GB screen was pixel ants a la Super Mario Land.

Am I the only one who feels like graphics on the NES were actually a bit too small? There just seems like a lot of empty underutilized space between objects. Reaction time is a concern with larger sprites, but it mostly comes down to what you're actually doing with your sprites. You can have small sprites that move really fast, and you end up with weird looking stuff like characters powerwalking at 80 miles an hour.

Having roughly 32x32-sized sprites seems like the sweet spot, IMO.

I was just reminded of some early doodle i did and forgot about for a long while based on the idea of a gauntlet-styled game where enemies actually were free-moving sprites like in the arcade original.
I think bio force ape might've been a conscious choice to go for precisely that. It just fits the narrative that all that mutant ape does is on exaggerated overdrive, doesn't it? But sometimes the format of two sugar cubes on top of each other gets really old.

Had we had more horizontal coverage on the NES (like the AVS is able to pull off) without cancelling, i think 18-24w standing (depending on stance), 32w running would've looked really nice with a height of 32-48h (depending on posture and height). Wide pixels counted for. That's all within reach on the SNES of course; just that it's somewhat uncommon.

This stupid fractal pattern is still giving me headaches. I know it can't be software drawn because the glitch video shows a stripe pattern. So then it must be the "debug transparency" effect, but all the docs say it's just an AND operation. If there were only 4 colors, I would have figured it out, but there's 6 colors. Is there an XOR masking too?

Could you explain what this is? Web searches haven't brought up anything for me.

Probably the debug register here. My guess was that this was intended for developers to check if sprites and background tiles were being placed on-screen as expected even if obscured or hidden.

Edit: The register is explained in Titan's notes

That register is only for in factory testing when chip is being made. It isn't mentioned in any documentation, other than "reserved, do not touch".

As far as writeup to the effects goes, I don't think that will ever happen, there was only supposed to be documentation on the hardware things that made half the things possible at all (particularly bus crossing details and layer blending functions).

Layer blends depend on analog effects within the silicon and are very much guaranteed to fail on original VDP (315-5313), different manufacturer made chips behave slightly differently. Newer chips (315-5313A and 315-5313A-01, MD2 ASIC integrated version) work without glitches (with the exception of 315-5487 which doesn't have working 50Hz mode, but GFX will still operate ok).
Clone chips such as SE-93 does not exhibit issues either, meaning it is based off the two later versions. Some single chip hardware clones have issues with access timings and some debug register functions do not work and break few effects and emulatorclones do not work at all. Genesis3 VA2 doesn't work with things that require 128KB VRAM mode to work, the VRAM layout differs on that model in 128KB mode (but could probably be worked around). 128KB mode is used to allow 8bit DMAs.
In some places where you see vertical lines in groups of 3 about 16 pixels apart with 32 pixel gap you're seeing CRAM contention, whatever value is DMA'd into CRAM is shown on screen.

With BlastEm emulator, is it possible to use a Save State from BlastEm and use it in another program?

What's this then?

With the limited debugging features BlastEm has, I can tell that it has 16x32 sprites arranged in a slanted grid. It doesn't fill the entire screen, but I think the Genesis can tweak them mid screen to fill up the screen. I'm guessing this is supposed to mimic vertical tile scrolling, so I think it's supposed to add extra colors to the BG layer that is used for vertical tile scrolling. Every sprite uses palette 3 apparently. I think the vertical tile scrolling BG layer must use a different palette. It doesn't explain how the horizontal line scrolling BG would use more than 4 colors though.

I finally figured out how this trick was accomplished.

Vertical stripes are drawn on both BG layers. BG1 gets 3 colors in one palette, BG2 gets 3 colors in another palette. It uses line scrolling to shift the vertical stripes diagonally.

Horizontal stripes are drawn using a slanted grid of 16x32 sprites. It uses mid-screen multiplexing to fill up the whole screen.
Only the 16 pixels across the screen have to be calculated, and the slant of the "sprite grid" takes care of the rest.

Now here comes the fun part. On a normal emulator, the sprites are hiding behind both backgrounds, but on real hardware the debug AND masking feature is applied with the sprites on top. How do the colors merge? Like this:

BG 1 uses these colors:
101110
101101
101011

BG 2 uses these colors:
111110
111101
111011

Sprites use these colors:
110110
110101
110011
111110
111101
111011

Bit 4 depends if it's a BG1 color or a BG2 color. Bit 3 depends if it's a lower sprite color or a higher sprite color. Bits 0-2 determine which 2 of the 3 colors are overlapping. If there are 2 bits that are 0, then those two colors are overlapping. If just one bit is 0, then the color is overlapping with itself.

This is exactly what fascinates me the most about 2D retro systems. The way in which stringent technical limitations inform the creative decisions of artists and designers, and them figuring out the "best" ways to work within those parameters. Every individual decision and component of the visuals, audio, or even game design being the way it is for a very deliberate reason. Return of the Joker has that very distinguished "NES Noir" look that Japanese developers gravitated towards near the end of the system's lifespan, since that was a proven way to convey moody and more "complex" visuals with the limited palette. When you get so much more headroom to work with inside a similar (insofar as 8- and 16-bit development zeitgeists being somewhat close to eachother) framework, that whole aspect driving the creative vision risks getting lost. That's pretty much why I tend to find NES and Genesis games to be more visually fascinating in their color usage to reach certain aesthetics, in spite of the SNES being objectively better on an exponential level in that regard.

The same philosophy extends to audio as well. I'm actually not that big into the NES expansion chips (nor the PC-Engine, for that matter) where you're tacking on a bunch of extra voices. Since they're still just basic, static waveforms, it remains very "chiptuney", but the larger headroom afforded by the channels also tends to erase the distinct way in which stock 2A03 music in composed, and that's at least half of the fun for me. Stock 4-5 channel 2A03 music has a very tight, focused sound I enjoy that leans more heavily into counterpoint to convey harmony. Compositions made using the extra chips just tends to sound very... diluted to me and yields the same reaction as when you compare those 16-bit ports of Retun of the Joker.
Pretty much the same reason I'd also prefer listening to a SNES orchestra compared to the same thing done on a rompler of the same era with 32mb of memory compared to 64kb. Both have a very obvious early "sampler-esque" sound to them, but there's a lot more interesting optimization tricks and choices on the SNES that makes it more fascinating.

I actually this kind of problem with the music in the Titan (both 1 and 2) demos as well. Strobe's entire style is based on heavily leveraging the single channel PCM playback with lots of sounds/instruments baked into the samples as the foundation of the entire track (probably explains why the ROM is so big in the first place), with the actual FM being used more as a complement on top of it. I mean, sure, it sounds cool and all, but I don't find it an all that interesting use of the sound chip.

if i recall correctly, OD2 music consume 3.2Mbytes of rom space(the entire demo is 8Mbytes) .
It's 2 minutes of 8bit 26.5khz samples .

Which goes against Oerg's statement that they never use prerendered anything. There's also no reason why some of that fractal rotozoom can't use prerendering, because it only needs one row and one column of tiles per frame, and everything else is line scrolling, sprite shearing and AND masking.

I didn't make a comment back when Oerg said it, but no, us SNES developers don't use a dozen SFX chips to do stuff. You're confusing us with the ROM hacking community.

That's pretty bullshit.


Making it your mission not to have anything prerendered is kind of arbitrary; the only real reason you don't prerender is because of rom size, but as TOUKO pointed out, Overdrive 2 is massive for what it is. Where do you even draw the line at what prerendered means? I'd think this could be stretched to include using any sort of lookup table, and the demo likely does. There's absolutely no point in calculating sine/cosine at runtime for anything outside of some sort of professional physics simulation.

In the demoscene, "prerendered" actually does have specific meaning. More-or-less it means "no video decoders".

The contents of the ROM is not an uncompressed raw streamed soundtrack—there's something doing some mixing. The drum loops are all long samples, though.

(Play file offset 0x5d400 through 0x2e6800)

The damoscene for non-framebuffer based systems? FMV on the SNES or the Genesis are going to look very obvious.

Not if you do 2bpp on PAL, and be careful with the colours. Elix did exactly that with their first demo, though I think the main point was the music (they were working on a tracker, but it seems to have been moved to the back burner).

EDIT: I'm going by what other people said. I have not personally verified that nu was prerendered.

...And it still sucked.

My statement on sampled audio size, was not to criticize the demo or if it's real time or not .
Its just for pointing the fact that if you want quality samples, you must spend a big bunch of ROM, nothing else .

It's obvius that OD2 use some big prerender tables in ROM, you cannot do complex math like sin,cos,tan in realtime,but the display construction is,and i don't think that all the GFX+code take 4.8 Mbytes,but for me the essential is that OD2 rocks and is very enjoyable with the good spirit of demoscene in it ..


The coder (ferris) did not deny that fact,so i think all was really a simple FMV.