Where does one beat the other? The Video, sound, pure power, etc? Just wanted to get some unbiased and technical thought on it...I'll start off by saying:
Genesis:
68K at 9Mhz. Pretty good, only problem is it takes a ton of cycles to do anything.
SNES:
65816 at 3.56Mhz. Pretty slow, but offered much more quick general processing but still didn't really out do the Genesis since you can't create clocks at magic.
What's everyone else takes on the system? In all major areas would be nice if you wanna get in to it.
CPU,PPU/VDP,APU,Etc.
Technically they are different. Only when you look at specific things with a numerical rating can you find which scores better.
The 68K was certainly far better suited for writing games in a high-level language. 8 general-purpose 8/16/32-bit integer registers and 8 general-purpose 16/32-bit address registers (and also to a limited extent integer), versus a single 16-bit general-purpose register, and two 16-bit indexing registers. No contest.
I didn't like the Genesis much. Not very robust case, especially volume slider. Bad controller shape and trigger button layout. Too few buttons. AFAIK no stereo audio out on back, so you had to plug headphone-to-RCA into front, which was very vulnerable to getting hit. Video has annoying vertical artifacts. FM sound resulted in games sounding too similar. Hardware-enforced extra bootup text before game starts on later units. Distorted sound on later units. A few games were great, including music, and I still keep one around to play Michael Jackson's Moonwalker, Quackshot, Target Earth, and Wonder Boy in Monster World.
The SNES is technically supperior in all areas, and the so called faster CPU of the Megadrive is a hoax made by Sega fans, because even if it is clocked faster it needs more cycles to do anything making it roughly the same computing power as the SNES' CPU.
This is not surprising as the SNES is more recent
3gengames wrote:
68K at 9Mhz.
The clock speed of the Sega Genesis's 68000 CPU is 7.67 MHz. More precisely, it's 15/7 of the NTSC color burst frequency, or 15/7 times the clock speed of the Super NES's 65816 CPU when operating in fast ROM mode. However, the true speed factor is only 15/14 for these reasons:
- The 68K's data bus is twice as wide.
- The 68K can access its data bus only every four cycles.
As for "Blast Processing" in the chipset, the only remotely technical claim I've ever seen about "Blast Processing" is that it refers to high-speed copies from main memory to video memory using the DMA unit. The Super NES can do the same thing.
blargg wrote:
The 68K was certainly far better suited for writing games in a high-level language.
Developer productivity win.
Quote:
Bad controller shape and trigger button layout. Too few buttons.
No really usable shoulder buttons, but the later controller does have C, B, A, Z, Y, X.
Quote:
AFAIK no stereo audio out on back
Redesigns had stereo audio out the A/V connector.
Quote:
Video has annoying vertical artifacts
Compared to annoying diagonal artifacts on the Super NES.
Quote:
Hardware-enforced extra bootup text before game starts on later units.
Game Boy, Game Boy Advance, GameCube, Nintendo DS, and everything later have bootup text as well. (This has been
parodied.) Worse yet, Wii has no autostart; the player must interact with Disc Channel by pointing at the Sensor Bar with a Wii Remote even if the game can be played without the Sensor Bar.
You can remove the auto start stuff from the DS and the Wii. In fact, my Wii overheats and crashes 95% of the time whenever it tries to run the Wii menu. The only thing that makes the Wii usable is Bootmii auto-booting the Homebrew Channel, and the ability to run Gecko OS to boot disc games.
blargg wrote:
Not very robust case
Really? I still own the Genesis I had as a kid and I dropped it from a fairly high place (the top of a VCR which was on top of a cabinet) quite a few times (my brother and I often pulled the controller cord too hard!), but it has hardly any scratches, and works perfectly.
Quote:
especially volume slider.
Mine is in great shape, and I abused that as a kid too. The one in the japanese Mega Drive I bought more recently for US$10 is perfect too.
Quote:
Bad controller shape and trigger button layout. Too few buttons.
I like it. Maybe it has to do with what we used as kids. If you had a SNES you'll probably find the Genesis controller weird and vice-versa. I love the SNES, but I prefer the Genesis controller (the SNES controller is too small, the directional button is not as responsive, etc.). Like tepples said, more buttons came later.
Quote:
AFAIK no stereo audio out on back, so you had to plug headphone-to-RCA into front, which was very vulnerable to getting hit.
Yes, this is true for the first model. Not that it bothered me when I was a kid, since I only had RF and my TV wasn't even stereo.
Quote:
Video has annoying vertical artifacts.
I can hardly see that on my (PAL-M transcoded) Genesis, but it's very noticeable on the japanese MD (not sure if it's still NTSC or has been modded).
Quote:
FM sound resulted in games sounding too similar.
Little sound memory on SNES results in muffled sound, like if you had your head inside a bucket.
Quote:
Hardware-enforced extra bootup text before game starts on later units.
Doesn't bother me at all.
Quote:
Distorted sound on later units.
Can't really comment on that, as I've never seen (or heard the sound of) such units. From what I read, this was the case with cheap Genesis-on-a-chip consoles not manufactured by SEGA (even if they were licensed by SEGA).
IMO, SNES wins mostly on graphics (more colors, more layers, more effects, slightly lower resolution though), the rest is debatable. Everyone seems to think that SNES sound is God, but it has some serious shortcomings too (it's often muffled as hell because of highly compressed samples), so I really can't give it a win. Genesis music sound really crisp, even if the instruments are repetitive, so both have pros and cons.
tokumaru wrote:
I can hardly see that on my (PAL-M transcoded) Genesis, but it's very noticeable on the japanese MD (not sure if it's still NTSC or has been modded).
PAL/M is likely to hide a lot of encoding stage sins. For one thing, the Pr component of the color subcarrier inverts phase every line.
tokumaru wrote:
Little sound memory on SNES results in muffled sound, like if you had your head inside a bucket.
I'm pretty sure that's because samples weren't properly equalized for the Super NES DSP's Gaussian interpolation method. It's possible to make sounds not muffled by applying a pre-emphasis EQ before encoding them with BRR. If I were to get into Super NES development, I'd probably write a short script in numpy to find the proper pre-emphasis curve to make it sound like the more common cubic spline interpolation.
This thread makes me laugh...
EDIT :
I am not as infinitely familiar with SNES as I am with MD and SMS but here goes :
Sprite setup is a lot more flexible on MD. You get grouping and chaining from hardware, all the tile layout is linear, you can use any of the 16 possible sizes at any time on any sprite. Sprites can use all of VRAM and coordinates are all flat. You can multiplex sprites too if you can fit at least one VRAM write next to sprite table changes, or the internally cached table is not updated. I could fill 32 x 240 area with just one sprite.
VRAM can be updated any time on MD, you will never get missed writes or reads. There is a 4 stage FIFO on the data port too so you can freely blast in small bursts of data during active scan time. Though when FIFO is overflowed the CPU is stalled. There are 18 access slots per line in active scan, one slot every 16 pixels, and one VRAM refresh cycle every 16 pixels, so only 3 slots per 64 pixels. In passive scan you can never overwhelm the FIFO, the VDP can take one access every 2 pixels, totalling 198 slots per line (with refresh slots every 64 pixels as before). DMA can use up ALL the access slots because it is VDP itself that is doung it.
There's 313 lines in 50Hz and 262 lines in 60Hz, which of 224 or 240 (only possible in 50Hz) are active. That gives such kind of figures on VDP access :
Code:
+------------+---------+--------+
| Line width | Passive | Active |
+------------+---------+--------+
| 256 pixels | 161 | 16 |
| 320 pixels | 198 | 18 |
+------------+---------+--------+
+----+------------+---------+---------+---------+
| Hz | Resolution | Passive | Active | Total |
+----+------------+---------+---------+---------+
| 60 | 256 * 224 | 6118 | 3584 | 9702 |
| | 320 * 224 | 7524 | 4032 | 11556 |
+----+------------+---------+---------+---------+
| 50 | 256 * 224 | 14329 | 3584 | 17913 |
| | 320 * 224 | 17622 | 4032 | 21654 |
| | 256 * 240 | 11753 | 3840 | 15593 |
| | 320 * 240 | 14454 | 4320 | 18774 |
+----+------------+---------+---------+---------+
Number of tiles that can be transferred :
+----+------------+---------+---------+---------+
| Hz | Resolution | Passive | Active | Total |
+----+------------+---------+---------+---------+
| 60 | 256 * 224 | 191 | 112 | 303 |
| | 320 * 224 | 235 | 126 | 361 |
+----+------------+---------+---------+---------+
| 50 | 256 * 224 | 447 | 112 | 559 |
| | 320 * 224 | 550 | 126 | 676 |
| | 256 * 240 | 367 | 120 | 487 |
| | 320 * 240 | 451 | 135 | 586 |
+----+------------+---------+---------+---------+
The numbers in 50Hz are pretty big compared to 60Hz. I would love to see exact numbers of SNES PPU access.
One other cool thing that you can do with the VDP is displaying a 512 color flat bitmap at cost of reduced CPU time (proportional to bitmap size). You set up the DMA to Color RAM and put auto-incremeth value to Zero. Now you overwhelm the FIFO to gain synchronity to the VDP, disable VDP rendering and start a DMA transfer. This gives you a 198 or 161 pixel wide flat bitmap with pixel format like this :
Code:
xxxxRRRxGGGxBBBx
It is nicely 16 bits too and what 68K can deal with very well. Only problem is that these CRAM pixels are 2 screen pixels wide, with a 4 pixel wide CRAM pixels where VRAM refresh slots are. There are 4 refresh cycles visible, and some in normally invisible screen area.
This method also allows to show full screen image, 288 lines in 50Hz and 240 lines in 60Hz. But as said earlier the CPU is halted during this time so it is pretty much limited to slide shows when the image is large. You also cannot start the bitmap during passive scan as you cannot overwhelm the FIFO, you can only do it in active scan.
This is a lot more useful in MegaCD applications though where the other CPU can render a new bitmap while MD side is displaying one.
Cycle counting is impossible, MD is an async design. One Z80 or VDP access or interrupt is enough to ruin all the precision.
Are there any artifacts on SNES when you update a Color RAM entry midline ? On MD you get one pixel in the access slot point with the color of the color being written to the CRAM. This is because the CRAM is single port and you either have missed write or missed read. Write happens and when the color is read the value being written to is read instead.
...and now I remembered one more thing... bitplanes. They allow for some neat things but compress badly and are pain to render into when you want to.
Without these there would be no 2bpp BG layers modes though... When I work on SMS I wish there were none of that, so I could do some nice optimizations and VRAM use and rendering and tile management. I may be too accustomed to packed pixels though.
Z80 in MD is primarly meant for sound management. Unlike the SPC unit, Z80 has full access to ROM and limited access to RAM at all times with no restrictions besides the stupid serial banking register. I can access all the ROM space with no involvement from 68K side.
Communication between 68K and Z80 are a bit more complicated because 68K RAM access is restricted, you can only clear a value in it due to bus timing issues. 68K cannot see Z80 RAM at all, until Z80 bus is requested which stops Z80. Then 68K can see ALL the Z80 RAM (and use YM2612, it is on same bus as Z80).
The RAM at Z80 side is pretty much only for holding the sound driver, you do not need to put any music or SFX data there, you can read it off ROM directly.
As for as sound generation goes, synthesis has its pluses and minuses. Certain sounds are impossible to make without using whole chip for that sound (orchestra hits), but most stuff is. My most I mean it. FM is extremely versatile and powerful, but with about 50 parameters per sound it gets overwhelming when you don't know what you are doing. ADSR of the FM chips is more natural in a way that sound is not forced back to zero on a new note, like it seems to be on the SPC. When you tap a key or string on an instrument the sound gets louder and louder and wont go silent for a moment. You have to use software envelopes to overcome that on the SPC.
BRR compression is weird stuff. 4 bit samples that can be filtered to sound less bad, but still bad... Sample RAM is very limited and looping is restricted to block sizes, and many games have badly looped sounds because of it. Lot of games use looping on percussion instruments and it sounds rather... horrible, I don't have a better word to describe it. Other problem with samples is that you really do not get a good range on a sample, only few octaves before the sound gets very different from what it should sound like, there's also no way to shape the timbre of the sound either. On FM you can have really dynamic sounds and you have nearly full octave range on any sound you create. 53KHz sample rate really helps too with the crispness and range.
I do like smooth panning that the SPC can do, and the negative volumes. Some neat stuff can be done this way. I wish I could invert output of a channel on the YM chip...
I'll stop for now, when you have questions about MD inner workings I can most probably answer.
EDIT 2 :
Answer to the post below : This stuff is gone through so many millions of time by now... what makes me laugh is some of the ignorance and stubbornness that make such threads appear again from time to time.
Why, because it was doomed to irrelevance from the start? (SNES versus Genesis)
TmEE wrote:
looping is restricted to block sizes, and many games have badly looped sounds because of it.
This is the most annoying thing in the SNES sound. It is really difficult to make a nicely looped samples other than simple (hand drawn even) waveforms, you have to resample sound to a frequency where a period gets into multiply of 16 samples, do all kind of crossfades to smooth out the transition, and it still sounds bad. Also those clicks, because release stage takes fixed amount of time, and any major volume change or starting a new sample before release goes to zero makes a click. Damn thing.
BRRTools can be configured to automatically resample samples so they are at a multiple of 16 bytes. Several different resampling algorithms are available, so hopefully at least one of them will have decent results.
And I agree the click on new notes are annoying, but this can be easily solved by delaying all keys on by one "frame" (by "frame" I mean instance of the sound engine). This way, if a key off and key on happens at the same time, there is room to first key off the sample (the hardware takes care to make it goes to silent smoothly without clicks) then on the next frame you start the new note properly.
This is not restricted to the SNES and is the only way to make a consistent transition between two notes on a channel.
About the fixed release time, you are free to implement your own release by using the enveloppe mechanism. Same goes with volume changes.
Quote:
Why, because it was doomed to irrelevance from the start? (SNES versus Genesis)
As a side note, Sega's rival console with SNES was named Megadrive I don't know why people insist on calling it Genesis which is a music band's name... it sounds weird to me.
I can tell you from my practice of writing a music driver and making SNES music for my projects that it isn't all that easy. Could be solved, but still, quite a headache.
To be fair, Genesis has keyon clicking issues too, but at least no looping problems, and generally it felt much easier and comfortable to make Genesis music.
In the US, it was SEGA Genesis and Super NES. In Japan, it was the Super Famicom, not SNES, so it's a matter of choosing one of the two names for each system.
To be honest I've never even heard of a group called SNES.
Genesis rock. I love Phil Collins.
Bregalad wrote:
The SNES is technically supperior in all areas, and the so called faster CPU of the Megadrive is a hoax made by Sega fans, because even if it is clocked faster it needs more cycles to do anything making it roughly the same computing power as the SNES' CPU.
This is not surprising as the SNES is more recent
I don't think so. Since both CPUs are radically different it's hard to compare. But the 68000 in the Sega Genesis (the name is appropriate as it was very popular in North America where it went by that name) probably is faster or rather it offers more computation time for games. The SNES CPU was under powered. Perhaps due to the time between when it was designed and when it was released. But I really doubt that "it needs more cycles to do anything" is a fair assessment. You're going to write programs differently between the two processors so it makes things harder to compare. The difference in speed/performance probably isn't as dramatic has fanboys will make it out to be. One thing to consider is the PC-Engine which has a 65xx type CPU that is clocked at over 7mhz. So it is the same family as the SNES with a CPU going atleast twice as fast.
My main complaint about the Genesis hardware was and still is that I think they should have allowed for more palette memory to boost the overall amount of color palettes available to backgrounds and sprites. The 4 palette sets for a technical 64 colors at once is too few. The PC-Engine had 32 palette sets! Perhaps too much. SNES had 16 palette sets (256 colors) which was a good spot. I think it would have had a great benefit to Genesis graphics if sprites and backgrounds had separate palette memory banks, basically 4 * 16 colors for BG, and another 4 * 16 colors for Sprites for 128 colors. I think it would have been sufficient to dull the gap between SNES and Genesis. And I don't think the cost in hardware would be been too great to add logic and the memory to support that.
The key thing to remember in all of this debate is that both consoles had games that utilized what was available to them very well and resulted in great games. Both systems in the right hands could produce amazing results.
MottZilla wrote:
Sega Genesis (the name is appropriate as it was very popular in North America where it went by that name)
If you're picking a name based on popularity, maybe you should consider that everywhere else in the world it was called "Mega Drive", it was only called "Genesis" in North America. The SNES on the other hand, was only "Super Famicom" in Japan (maybe other parts of Asia as well?). So there are probably more people in the world who had a Mega Drive and/or a SNES than people who had a Genesis and/or a Super Famicom.
Only thing I can think of why MD does not have palettes separated on different layers is that they ran out of silicon real-estate. That remains to be seen until someone decaps the VDP and takes a look.
Some arcade boards do use the MD VDP, but with external RAMDAC and utilizing the digital color bus of the VDP to do 8 palettes (4x BG, 4x sprites).
As for CPU, 68K jumps far ahead when you do 16 and 32bit operations on it. 32bit ops take very few extra cycles but process lot of data. The CPUs are wildly different though, but the way I see it many tasks that take couple of instructions on 68K need 2...3x more code on the 65x type CPUs, in the end things even out. One is faster on some stuff, other does other things better.
I found this forum post with code that says different, the 68K is much less efficient at some math math than the 65c816. And the 8-bit registers on the 65c816 don't help it's cause as 8-bit on 68K is non-existent.
http://www.assemblergames.com/forums/ar ... 21947.htmlhttp://pastebin.com/f76e312e0
3gengames wrote:
http://pastebin.com/f76e312e0
68000: 146 cycles
65816: 63 cycles
After compensating for the faster clock speed of the 68000 (15:7 ratio), the 65816 version is only 8% faster.
3gengames wrote:
I found this forum post with code that says different, the 68K is much less efficient at some math math than the 65c816. And the 8-bit registers on the 65c816 don't help it's cause as 8-bit on 68K is non-existent.
http://www.assemblergames.com/forums/ar ... 21947.htmlhttp://pastebin.com/f76e312e0You're going to just keep posting that over and over again aren't you? As I said over at NintendoAge, that example is only for pure CPU to CPU without the rest of the system and assumes they are both at the same clock rate. It doesn't take into consideration the large difference in clock rates between the systems nor does it take into consideration system bottlenecks. Best case scenario that bit of code will execute faster on the SNES. That's assuming it's well optimized and completely ignores the case of RAM access which has to be done at a slower clock rate of 2.68MHz. In the worst case scenario with the CPU running at 2.68MHz due to slower ROM (Which was common on the SNES), that bit of code executes slower on the SNES.
The same person who wrote that bit of code in that Assembler thread had this to say recently over at Sega-16:
tomaitheous wrote:
The SNES is slower than the 68k in the Genesis; that's well known. But it's not slower by 50%. The real speed of the SNES cpu floats around ~3mhz (in fast mode. slow mode is strictly 2.68mhz) because of how the 65x architecture puts all the addressing vectors and data registers in zero page (or direct page as term is used on the '816). Instructions are made up of cycles and each cycle that touches main ram (work ram) is wait-stated down to 2.68mhz (rom fetch cycles are 3.58mhz if the rom is fast-rom). And even with the crippling 8bit data bus for the '816, the core of the processor is based on the 65x series which was very fast for instruction cycle times and the expansion to 16bit regs and math really give it a boost (not to mention some nice new instructions). From my tests, I'd put the performance around 70% of the MD CPU (disregarding a few advantages each processor has over the other in some cases).
He later went on to say that the 70% figure is only if your code is insanely well optimized on the SNES side.
Warning: This guy is a disgruntled Sega biased fan. I'd not listen to him, as he's a person who spits numbers but yet seems to have never written any program in his life, so I doubt he can provide anything to this thread.
But yeah, 8% faster. The main key that I was going for is it's a piece of 16-bit math code for something we'd even use in a real game...and it performs on par. But whatever, I tried to make this so it'd have unbiased information but that's now gone through the window.
And he's also in this threa. But still, for the 65816 to have 70% of the performance with so few registers and needing to do many more memory accesses in some cases, it makes sense. But still, you're acting as if the 65816 gets about 50% or worse with how you word everything. Please, for the sake of keeping it interesting and not full of shit, can you not post again, Trekkie Kid?
3gengames wrote:
Warning: This guy is a disgruntled Sega biased fan. I'd not listen to him, as he's a person who spits numbers but yet seems to have never written any program in his life, so I doubt he can provide anything to this thread.
But yeah, 8% faster. The main key that I was going for is it's a piece of 16-bit math code for something we'd even use in a real game...and it performs on par. But whatever, I tried to make this so it'd have unbiased information but that's now gone through the window.
And he's also in this threa. But still, for the 65816 to have 70% of the performance with so few registers and needing to do many more memory accesses in some cases, it makes sense. But still, you're acting as if the 65816 gets about 50% or worse with how you word everything. Please, for the sake of keeping it interesting and not full of shit, can you not post again, Trekkie Kid?
I never said it was 50% worse, I said it was slower. And it's not just the CPU that causes problems, it's other bottlenecks in the System.
I'm not really biased towards Sega or it's systems. I like Nintendo's systems as well. However it seems there's a certain group of people who love to bash Sega's systems unfairly. When the argument pops up, I tend to defend the Genesis as it seems to get unfairly bashed. My criticizing your argument isn't keeping this thread from being interesting at all.
As for not programming, I actually do quite a bit of programming. It's just not in Assembly. I'd love to learn Assembly at some point, it's just finding the time to do it.
If you don't know assembly, then why are you so vocal on something you don't have any clue how it works? Yeah, I think that says enough...as for being unfairly bashed, maybe learn a thing or two and come back and then scream how wrong we, programmers who work in assembly, are. I've worked with both architectures, 68 and 65 series, so I can assure you...you're not qualified to have an opinion as it's more than simple stuff that you're thinking of that's different, sorry...but it's the truth.
3gengames wrote:
If you don't know assembly, then why are you so vocal on something you don't have any clue how it works? Yeah, I think that says enough...as for being unfairly bashed, maybe learn a thing or two and come back. I've worked with both architectures, 68 and the 65 series, so I can assure you...you're not qualified to even peep on this stuff.
For Assembly I'm not qualified to go into much detail. However it doesn't mean I can't read or pay attention to what's stated in these discussions when they come up and point out areas where things don't add up. I didn't say unfair bashing was going on here, you were however doing that in the Nintendo Age thread. And if you truly didn't want me to see this thread, why on earth did you link me to it?
You don't have to be a master of assembly however to figure out how long it takes for a clock cycle to happen on a CPU when you know the clock rate. Nor does not knowing assembly prevent you from figuring out from that information how fast a block of code will execute when you know how many clock cycles it will take.
This thread is called SNES vs Genesis. But all you seem to be doing here is 68000 vs 65816 while ignoring every other aspect of the systems.
There's lots of tricks you only learn by using assembly instead of just looking at the tech sheet.
And I linked it to show you the responses from people who actually know something, it wasn't so you could post in it. Thanks for ruining the whole purposed now, though. Although I'd still like to discuss this with the normals members. Not people with their Genesis shirts inside out trying to talk about another system. I mean, you are from Sega-16 and only joined NA AND here to get in your toots about how much the SNES was crushed by the genesis. But whatever, say whatever you want, this thread is dead to me now since you're here raining on the parade of being realistic with everything.
The closest thing to mode 7 on the Genesis is offset per column-pair and offset per scanline. It's enough to make the floor rock, but it can't rotate by more than about 1/8 radian (7 degrees) without noticeable artifacts. Without mode 7, how do racing games work on the Genesis? Is it the same principle as Pole Position and Rad Racer? Or would one need the Sega CD accessory to make
Cameltry/On the Ball?
Dunno, but this software implementation of a psuedo mode 7 is pretty well done, and probably written in C. Although I bet some inline assembly loops were included, too.
http://www.youtube.com/watch?v=wG4V_kLL0NIETA: Most games seem to use a just rad racer/screen update thingy, as the backgrounds framerates are pretty bad. But honestly I've always liked Genny for racing games as Mode 7 is just too bland after a while.
tepples wrote:
The closest thing to mode 7 on the Genesis is offset per column-pair and offset per scanline. It's enough to make the floor rock, but it can't rotate by more than about 1/8 radian (7 degrees) without noticeable artifacts. Without mode 7, how do racing games work on the Genesis? Is it the same principle as Pole Position and Rad Racer?
Or would one need the Sega CD accessory to make Cameltry/On the Ball?
Would the Special Stages in Sonic count?
Also there's some racing games on the Genesis that pull off decent polygon rendering such as Kawasaki Super Bike.
Special Stages in Sonic 1 have restricted geometry because of the overdraw limit. Make a straight wall of blocks like those and see what doesn't flicker. But
the ones in Sonic 2 did impress me, in fact prefiguring Frequency and the
multiplayer mode of Amplitude.
Anything involving software rendering is going to be faster on MD. Bitplanes are not helping with it at all, DMA speed is higher in MD and you will not have problems when any access happens during active scan.
I have been playing Flashback on SNES past few days and the cutscenes really chug compared to MD version... frames often take half a second to render. That game does some really neat vectors/shapes/etc rendering in the cutscenes.
tepples wrote:
Without mode 7, how do racing games work on the Genesis?
I always liked the graphics in
Street Racer, with its nicely textured roads. The SNES version uses Mode 7.
Quote:
Or would one need the Sega CD accessory to make
Cameltry/On the Ball?
I believe that a proper Mode 7 effect would indeed require a Sega CD. There's one game that took an interesting approach to 3D-like graphics on the Genesis,
Panarama Cotton.
TrekkiesUnite118 wrote:
Would the Special Stages in Sonic count?
Those were done completely with sprites, AFAIK.
Quote:
Kawasaki Super Bike
That looks cool, almost Star Fox-like.
tokumaru wrote:
I always liked the graphics in
Street Racer, with its nicely textured roads.
I've seen similar graphics in a Game Boy color racing game. How does that work exactly? Is it essentially a software version of Cosmic Epsilon, where each texture row at each scale is stored in the cartridge?
Quote:
There's one game that took an interesting approach to 3D-like graphics on the Genesis,
Panarama Cotton.
This looks to be mostly the same tech seen in 3D Battles of Worldrunner and Tetra Star: a Rad Racer floor with a separate sprite cel for each Z range.
Quote:
Quote:
Kawasaki Super Bike
That looks cool, almost Star Fox-like.
Yeah, it did remind me of Stunt Race FX, except without the FX or SVP chip.
I forgot there's also F1 World Championship which uses the same Engine as Kawasaki Super Bike.
http://www.youtube.com/watch?v=qofonsN3Nwc
tepples wrote:
I've seen similar graphics in a Game Boy color racing game. How does that work exactly? Is it essentially a software version of Cosmic Epsilon, where each texture row at each scale is stored in the cartridge?
Each line is stored at different widths VRAM (generated at runtime I suppose) and they are then scrolled in by midframe scroll adjusts.
EDIT: all pre-rendered/drawn, no runtime stuff happens.. the small stuff looks too good.
tepples wrote:
I've seen similar graphics in a Game Boy color racing game.
Halloween Racer?
Quote:
How does that work exactly? Is it essentially a software version of Cosmic Epsilon, where each texture row at each scale is stored in the cartridge?
I'm not sure, since I don't know of any Genesis/MD emulators that will display the unmodified background planes. I'd guess you're correct.
Quote:
This looks to be mostly the same tech seen in 3D Battles of Worldrunner and Tetra Star: a Rad Racer floor with a separate sprite cel for each Z range.
Yes, but the neat thing about it is how the effects are combined in different ways for different parts of the levels. It even has vertical parallax scrolling at some point.
Quote:
Yeah, it did remind me of Stunt Race FX, except without the FX or SVP chip.
Indeed, the amazing part is that it's not using any kind of special chip, and that it looks better than Hard Drivin' (it appears to be soother too).
tokumaru wrote:
tepples wrote:
I've seen similar graphics in a Game Boy color racing game.
Halloween Racer?
It was
Wacky Races. I'm just trying to figure out how this effect was done in order to figure out how feasible it'd be on an NES.
This should be piece of cake on NES if you have a mapper with scanline counting ability. Banked CHR ROM makes that really easy to do...
tepples wrote:
I'm just trying to figure out how this effect was done in order to figure out how feasible it'd be on an NES.
Sonic 3D Blast's Special Stages appear to use a variation of the same effect, which even includes walls. I was once trying to figure out a way to do something similar on the NES, but for some reason I gave up.
Sonic 3D Blast special stages uses just (non-linear) vertical raster stretch, it is much easier than roads in racing games, as no horizontal stretch involved.
It looks like the bridge uses mirroring, so the CPU only has to render half of it.
There is no software rendering involved, only per frame vertical scroll changes for the stretching. Horizontal scrolls are most probably handled by the line scroll table, it makes little sense to handle these realtime.
TmEE wrote:
There is no software rendering involved, only per frame vertical scroll changes for the stretching. Horizontal scrolls are most probably handled by the line scroll table, it makes little sense to handle these realtime.
I'm talking about Sonic 3D special stage.
There is no software rendering in the special stage, just stretching. I have made
very similar effect on the Genesis some time ago, it is actually so simple that takes just a few lines of code.
I'm talking about the foreground, not the background. The bridge that Sonic is walking on has both vertical and horizontal scaling, where as the lava pit behind him, only has vertical scaling.
Honestly, I didn't notice that at first, but I still think it doesn't really scale anything. As there is only the same looking stair, I guess they have one prescaled stair (just a few scales) on a background plane, and set a needed line of the plane for a raster line. If someone could get to a special stage and make a savestate, he could check if this is true using GSaveState (a program similar to the vSNES).
It is not scaling anything, when you look into VRAM it is all there already, generated before the stage starts. All of the stretch and scale is a mixture of horizontal and vertical scroll changes.
Relevant video:
http://youtu.be/Bm-ICwWxaAYEDIT: It's a Genesis/MD demo recreating Starfox's visuals without any special chips (it's slower than the actual Starfox, but maybe it can be optimized further?).
(That demo is exactly why this thread came to existence
)
It uses original SNES data as is. I have spoken to the maker about it and there is a lot of room for improvement, especially when all the data is converted to something more usable on the 68K.
Haha, it would be excellent if someone was to create a Star Fox port for the MD.
It'd have to use different level design, different player character design (not an Arwing), and different enemy design though.
tepples wrote:
It'd have to use different level design, different player character design (not an Arwing), and different enemy design though.
That depends on whether the person who's making it cares about copyrights, doesn't it? If it's not for money, I don't see anything wrong in making a 1:1 port.
To each their own, but I personally think Star Fox has terrible graphics (for SNES standard) and aged very badly.
Back then everyone was like "OMFG it's 3D on the Super NES !!" but now it looks like total crap, as everything is drawn with something like 10 single colour polygon, which looks terrible. On the other hand games with advanced 2D graphics aged very well and are still as enjoyable as they were on their release date.
Also the Super NES could probably do this without the FX chip as well, the frame rate would just be lower.
tepples wrote:
It'd have to use different level design, different player character design (not an Arwing), and different enemy design though.
I was specifically referring to a port / remake of Star Fox, not "openMegaTuxRailShooter3D" featuring generic replacements for almost everything that made the original game what it was.
I just think back to previous remake projects that got stomped by Square Enix's legal department.
tepples wrote:
I just think back to previous remake projects that got stomped by Square Enix's legal department.
Well, there's also the almost endless supply of Mario, Zelda, and Metroid Rom Hacks and Fan Games that Nintendo doesn't really seem to give a damn about. And then there's also all the tons of Sonic Fan Games and Rom Hacks that Sega doesn't care about.
I honestly don't think Nintendo would really care if someone ported Starfox to a 25 year old obsolete system. They didn't seem to care about the Super Mario Bros port.
Bregalad wrote:
The SNES is technically supperior in all areas, and the so called faster CPU of the Megadrive is a hoax made by Sega fans, because even if it is clocked faster it needs more cycles to do anything making it roughly the same computing power as the SNES' CPU.
This is not surprising as the SNES is more recent
I just looked through a Sega-16 thread about StarFox, and Zebbe quoted you, spewing out his "I've spoken with 2 programmers and they both said..." bullshit again.
Does Zebbe honestly thinks he's fooling anyone? Even if he actually does know them, it still doesn't matter what they say, because none of the programmers he named have ever programmed a single game for the SNES in the first place.
You misspelled his name
We're very fortunate to have two game consoles to spend inordinate amounts of time with trying to determine which is superior. How else would we find excuses to get so angry at each other?
Anyway, regarding Star Fox and polygons, you don't need to have the CPU render pixels by itself. The SNES can do a solid color line fill by doing a fixed address DMA from ROM to RAM.
That would require to have a linear buffer and the whole buffer format conversion, plus the overhead of preparing DMAs for large amounts of short lines (distant objects), so this may be not that effective. Would be interesting to see a demo with implementation of this tech, though.
Quote:
I just looked through a Sega-16 thread about StarFox, and Zebbe quoted you, spewing out his "I've spoken with 2 programmers and they both said..." bullshit again.
Does Zebbe honestly thinks he's fooling anyone? Even if he actually does know them, it still doesn't matter what they say, because none of the programmers he named have ever programmed a single game for the SNES in the first place.
Not only I've never written any SNES games, but not even a tech demo !
The best I did was modify an existing demo and write some SPC700 code (that I lost stupidly by the way).
Also I'm totally biased against Sega and I fully assume my position. They, their consoles and their fanboys sucks so hard !! And why did they have to release so many different console, it's like they released one every year. They released 2 consoles between the NES and the SNES, and another 2 or 3 between the SNES and the Playstation/N64. Seriously. Why hadn't they focused more on quality than quantity ?
Bregalad wrote:
Why hadn't they focused more on quality than quantity ?
I believe SEGA was always trying to get into the next generation before everyone else. It worked for the Mega Drive, their first worldwide success. Nintendo was pretty comfortable with the NES and everyone making games for it, until SEGA released the Mega Drive. That worked for SEGA that time, but unfortunately for them this trick never worked again.
The Mega Drive/Genesis add-ons were just plain stupid though. People had to basically buy 2 SEGA consoles in order to play SEGA CD or 32X games, and few people did that. I remember I did kinda want a SEGA CD when I was a kid, but SEGA never showed me anything that made me REALLY want to own one, so I never did.
Quote:
People had to basically buy 2 SEGA consoles in order to play SEGA CD or 32X games, and few people did that.
Yeah, but this formula worked in Japan for the Famicom Disk System. It only worked for a short period of time (1986-1988), much shorter than the console's lifespan (1983-1994) but nevertheless it worked.
So there is other reason behind the failure of the Megadrive's add-ons, every likely the fact they were released too closely with the Saturn, and the PlayStation. Also the SNES was very expensive just when it came out and many people would take the decision to buy one only several years after, and they'd rather buy a SNES than a Megadrive add on to complete their collection. The idea to release 2 add-ons at almost the same time is terrible - if at least they released only the Sega CD, and deleayed the Staturn, it would probably have worked.
This is just hypothesis, what I say might be plain wrong (especially considering I don't know much about Sega consoles, because - of course - I am completely biased against them
).
PCE Engine had a really successful addon, and that is most probably the main reason for the MegaCD idea. Only difference is that NEC was pushing the CD instead of cards, while Sega did both CD and cart.
There is a very recent review at Sega-16 with one main figure at Sega during the 32X times and there is a lot of good info about why it made sense etc. In the end it still turned into a blunder... but it sold hundreds of thousands, unlike some other flops from others.
I do personally think there was no need for either, or the MegaCD should have had its own video out so the DMA to MD VDP VRAM for display bottleneck gets eliminated, and in the process you can introduce fair bit of extra stuff as far as graphics go.
You can do 512 color flat bitmaps with MegaCD though, using the CRAM DMA method I described earlier in this thread. MegaCD side is not halted for the duration of the DMA, so while MD side shows the bitmap, the MegaCD side can render next frame. Chilly Willy is cooking up something around it last time I spoke to him.
Hey, people actually have links to my old pastebin posts?
This could have accounted for the TCD being a lot more expensive at launch, but it shows more care in the engineering that the base unit + add-on only needed one power supply between the two, while the Megadrive + Mega CD had their own power cables.
MegaCD could be powered from the MD side, but only on models that do not have carbon covered contacts on the expansion connector... all japanese units have carbon coated connections. Those few ohms of resistance the carbon causes is enough to cause instability when the MCD is powered from MD during seeking operations when power draw is greatest.
Scraping off the carbon would fix the problem and that is what I do on my machines to make them behave good on my "single AC brick modded" MegaCD.
This thread has been thoroughly entertaining
thanks!
I don't know about you guys, but my sega genesis runs at 10MHZ!
CareerOfEvil wrote:
I don't know about you guys, but my sega genesis runs at 10MHZ!
What is all that mess??? 10MHz overclock involves an oscillator, a switch, and at most four wires... please tell me all that does something else as well!
I got one that ran reliably at 17MHz with select games, Flashback being one of them. That one had so super smooth cutscenes then. That game is an atrocity on SNES...
mikejmoffitt wrote:
CareerOfEvil wrote:
I don't know about you guys, but my sega genesis runs at 10MHZ!
What is all that mess??? 10MHz overclock involves an oscillator, a switch, and at most four wires... please tell me all that does something else as well!
Hahaha! Yes it is a mess. Before I had a digital camera, so I'll see if I can get some new pictures. On top of having an oscillator, there's also a circuit to output s-video.
I was able to get the SNES to software rotate a sprite, while running an unfinished version of Gunstar Heroes on stock hardware. The rotating sprite is placed at the end of the "level" using the dynamic-loading-corridor trick shown as described here.
http://tvtropes.org/pmwiki/pmwiki.php/M ... micLoading
Congratulations, it looks neat ! And without any slowdown
You need to make the parts of the explosions have random trajectories and speeds. It is lot easier than it seems.
psycopathicteen wrote:
I was able to get the SNES to software rotate a sprite, while running an unfinished version of Gunstar Heroes on stock hardware. The rotating sprite is placed at the end of the "level" using the dynamic-loading-corridor trick shown as described here.
http://tvtropes.org/pmwiki/pmwiki.php/M ... micLoading Locks up randomly in zsnes. Controls don't work in higan. I think your demo is gimp'd.
I'm just seeing a white background with some grass at the bottom and a guy running in place, controls do nothing... what's supposed to happen?
Controls works fine for me. Pehaps you're using an old/outdated/inaccurate emulator ? Or pehaps psycopathicteen could rewrite his joypad reading routine so that it is more tolerant ?
Controls don't work in the latest version of higan, which AFAIK is the super duper most ultra accurate emulator of all time. Anyway, I just tried ZNES too, and, as reported, it crashes randomly, but I can see what it's supposed to do now.
Since BSNES changed to higan I never bothered to update ever again. Honnestly Higan is completely unusable and is a piece of... okay I'll say nothing since byuu is arround, but you see the point.
Looks like I'm not missing much using the last version of BSNES and SNES9x.
Bregalad wrote:
Since BSNES changed to higan I never bothered to update ever again. Honnestly Higan is completely unusable and is a piece of... okay I'll say nothing since byuu is arround, but you see the point.
I was pretty disappointed with the direction it was heading too, but the "import" feature in higan makes it quite usable. I really miss the NTSC filter though.
Quote:
Looks like I'm not missing much using the last version of BSNES and SNES9x.
From a gamer's point of view, probably not... but you know people say that about outdated NES emulators too, right?
I could run it in some version of BSNES tha I had around. Input did not work in Higan on which I tried first.
The people at nintendoage.com told me that it works on real hardware, but that was before I added the rotating ball at the end.
I can try it on my SD2SNES the next time I unbox my SNES (I have no idea when that's gonna be!), if no one else has done it by then.
Still, in my experience with the NES, even if a program appears to work well on hardware, the fact that it fails on emulators could mean that there's something wrong with it, maybe it's relying on some edge case that could still result in bugs on hardware under certain conditions. IMO, you should try to find why it's not working on some emulators, to make sure the error is theirs and not yours. I mean, input is the most basic thing a game does, unless you're doing it in a very unconventional way there's no reason for it not to work, you must have goofed somewhere.
http://wiki.superfamicom.org/snes/show/TimingQuote:
When enabled, the SNES will read 16 bits from each of the 4 controller port data lines into registers $4218-f. This begins between dots 32.5 and 95.5 of the first V-Blank scanline, and ends 4224 master cycles later. Register $4212 bit 0 is set during this time. Specifically, it begins at dot 74.5 on the first frame, and thereafter some multiple of 256 cycles after the start of the previous read that falls within the observed range.
This is the problem. Joypad reading has to be enabled before dot 32.5 on the first scanline.
Quote:
Looks like I'm not missing much using the last version of BSNES and SNES9x.
No worries, I'd rather not have nonconstructive critics on my forum anyway.
Quote:
I was pretty disappointed with the direction it was heading too, but the "import" feature in higan makes it quite usable. I really miss the NTSC filter though.
Me too. I tried, but was unable to port blargg's filter to support the color depth of my monitor, same deal for the SaI algorithms.
Next version is going to support multi-pass shaders, and I'm pretty sure there are GLSL implementations of it (but I don't know how good they are), so it should return soon in some form.
I also finally accomplished my goal of making an efficient dynamic animation engine, and I even know how to take it one step forward.
The trick is to compress all metasprites into a block that is 2 tiles tall and power-of-2 tiles wide, using a combination of 16x16 sprites and 8x8 sprites, and have the system strategically place the metasprites to fit within the rectangular grid of VRAM, to avoid fragmenting. I still use the double-buffered 30fps load scheme, but now I could fit more metasprites into 8kB of vram (the other 8kB is being used for non-dynamic sprites), and I have more vblank time left over.
Taking this one step forward, instead of using the 30fps double-buffered scheme, I can make newly spawned objects search for an open vram slot, update the vram slot when there is a new frame of animation for the object, and automatically de-fragmentize vram when an object is killed. Obviously, there should only be a DMA update requested if there is either a new frame of animation or a vram slot relocation (due to auto de-fragmenting), but only if there is enough "DMA bandwidth" left.