nesdev.com

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.