nesdev.com

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