turboxray

This part, "The Sprite Line Buffer is where sprites are pre-rendered to during hblank before being compositied (typo) together with the backgrounds. It is 256 pixels wide, and a total of 2304 bits." That might be true that the line buffer itself is only 256px worth of composited pixels, but the sprite "rendering" is often attributed to the accumulated fetch line limit.. which is 272 pixels (or 34 8px wide cells). Most people only care about the "sprite pixel line limit", and not further under the hood, because it's something you have direct control over or rather your sprite cells per line do. I've already seen people stating this is 256px in other tech discussions (not sure if this is the source of that or not). Probably best to make the distinction here to avoid confusion.

I need to play through this.

What hahah. That's the crappiest example of per-offset-tile scrolling ever. You literally can do better without it - smh.

The site's stated sprite pixel line limit in incorrect. He gives the impression that the sprite pixel line limit is 256 when it's not.

Yeah, given all the capabilities of the color formats and BG layers, the amount of vram is weirdly small. Maybe doesn't have to be 128k, but something like 96k with the last 32k mirrored would have been fine. It's just soo cramped. And making the two sprite banks 16k and not 8k. The sharp X68000 is pushing the vram bandwidth, but it's has segmented/separate/dedicated sprite cell vram to help get it there. Nintendo could have gone with a similar route. I would love to know the detailed development history, and what was priority and when stuff was added/changed during the development cycle. It feels like the focus was primarily on BGs (from early shots), and what they ended up with sprites was probably what they started out with.. maybe originally only having 8x8 and 16x16 as the only two sizes (128 16x16 sprites is 16k.. maybe just a coincidence?). I'm a curious as to when they decided to add color math support during development. I feel like that could have been late in development. On a related note, a lot of arcade systems right around the late 80s up until '90, typically only have support for 16x16 cell size for sprites. CPS-1 arcade system CANNOT fill the entire screen with sprites, yet the SNES/PCE/MD can easily do this (and more). Where the CPS-1 shines with sprites, is the sprite pixel line limit. But that's about it. Sharp X68000 is like the CPS-1 in this respect but has even more limited total screen coverage for sprites with a bit of healthy sprite line limit (not close to the CPS-1, tho). This is a nice site delving into it: https://fabiensanglard.net/cps1_gfx/index.html

I think the focus on "8bit data bus" or "16bit data bus".. at whatever speeds - is completely irrelevant. Why? Because you're not engineering NEW hardware. You don't have a choice in anything - what you get is what is there and implemented. So talking about it like it you have some sort of control over it, is useless. We're talking about software development, not hardware development. We're talking about making games - so that's the ONLY thing that matters.. performant code; how performant is the code, right? That's literally it. I have no idea why people get wrapped up in the "here's the bandwidth transfer rate in 1 second for the bus". It's not like you can change this. The same goes for stuff like the ALU. Unless you're a hardware designer that develops processors - the actual size of the ALU is completely irrelevant. What you care about is the register size, instruction speed, and what can you do with it. The z80 reportedly has a 4bit ALU.. yet we don't go around proclaiming the z80 is a 4bit processor (because that would be ridiculous). Like wise, the original 68k to a software developer is no different than a 32bit processor.. because you have a support of 32bit operations. It IS a 32bit processor.. don't care what the ALU is or the bus size (it could be super fast 1bit serial for all I care). The only thing I care about is; do I need a 32bit operation, and if I don't does the 16bit equivalent perform faster? That's it. That said, the 65816 is basically the 8bit 65x design. Sure, a few extra nice stack interface instructions, but it's just an extension of the same design. And in that respect, the 65x design and the 68k design CANNOT be compared directly, nor can you compare it based solely on speed (mhz). 68k instructions on average take more clock cycles than 65x or '816 design, but you get more bang for your buck on the 68k. Where it matters, is when you don't get those "extended bucks" on the 68k for whatever operations. What do I mean by this? If you do 8bit operations on the 68k it has no performance improvement (i.e. less clock cycles) than the 16bit equivalent. By extension, some stuff HAS to be 32bit on the 68k (address vector stuff), so instructions supporting 32bit operations are used - even if you only need say 16bit or 24bit. The 65x and '816 can gain performance in these in-between areas. There's a lot of core logic that goes into a game in which fast small instructions get the job done; stuff like mask checking, JSR/RTS, etc - stuff like direct memory access and/or R-M-W related instructions. People like to focus on "16bit math", but a game isn't some giant ass page of "calculator like instructions" - there's a lot of other logic. 65x design is built on small simple but fast instructions. And in a game machine were a lot of the heavy lifting is done with auxiliary hardware (video, sound, dma, etc) - the scope of what the processor code looks like, comings down to more basic tasks and not "crunching" so much. So the realized gains on the 65x design needs a look at the holistic picture, because if you try to narrow the focus too much, you miss out on this important detail. The 68k is an amazing processor, MEANT for an OS with applications running on a small computer. The fact that it does not hog the bus, is by design for this very reason and is important in that context - as well as relocatable code, etc. That's not an issue on these consoles. The analogy I like to use is; the 68k is like a slower small truck - you can haul a lot of stuff in a single trip. The 65x design is like a two-seater sports car. It's fast, but you can't load much up in a single trip. So, optimize for what you can. It's not the best analogy, but it hopefully shows you can't simply boil things down to apples-to-apples comparisons. All that techno jarble out of the way, what is the performance difference between these two processors in the context of similar gaming hardware setups? I'd say the '816 in the SNES (with optimal code) is roughly ~70% of the performance of the 68k - taking into consideration actual clock speeds, ram delays, and the SNES running with fastrom. Keep in mind, the '816 realized performance is NOT 3.57mhz in fastrom - it's about 3.08mhz because of slower work ram access. The point here, is that the SNES processor is not 50% the performance of the 68k in the MD. Depending on the game logic requirements, SNES could be a little less than 70%. But the important thing to note here is the catch; optimal code. What REALLY separates these two designs, is that you can get performant code out of the 68k pretty easily. The entry to barrier for performant code is pretty low on the 68k - it's almost automatic haha. That is NOT a true statement for 65x design, which extends to the '816. When time is a huge factor for development to release cycle, THAT matters. In my opinion, this is one of the main reasons why you see the 68k in sooo many arcade systems. It comes in high clock speeds, and you don't have to write convoluted code and come up with convoluted data structures for optimization like you do with the 65x design. Sega, being an arcade developer first and foremost - had to have known this and is most likely why they chose the 68k for the MD. There's "true performance" and then there's "realized/practical performance". And all these discussions love to talk about the potential to "true performance". But how realistic is that? The other side of that coin is.. how much performance is a game using per frame? Because it's probably rare that it's always using near 100%. And because of "frame locking", it's possible that a single instruction can cause "slow-down". The only thing gamers see is that either the game slowed down or it didn't. They have no idea about by what percentage did the game "missed its mark", but yet we love to talk about specs and capability. I dunno.. I think that's an important piece of the understanding, before you can claim this or that in broad context. If a game on the SNES blows the frame budget by 2-3% when it slows down... that is a big difference compared to something like 20-30% (even if the user experience is the same). That's a part of the performance conversation, but we never talk about it. And so I don't think you can really talk about performance if you don't have an accurate understanding of what impacts that performance and by how much. On the flip side, if you have processor X running at Y mhz/speed, but no game taxes the process for the full frame performance budget.. that number becomes less meaningful. As in, "this system runs at 12mhz".. but the system under load never requires that upper limit, say gets close to 75% of that limit, then that number doesn't have the context that it needs. Take the thought experiment of dropping a 12mhz 68k into the NES... what does that net you? After a certain point.. most of it is wasted/unneeded. Because the processor does not drive the audio and video in a "raw" sort of way. You'd have a lot of ideal time spinning on the frame lock.

He did.. and then Kirk tried to take all the credit for the inspiration. Color cycling isn't an unknown thing and many of us have already messed around with it. All Kirk did was remind someone that they already had this idea but to actually show people via a video haha. But yeah, Kirk, the great inspirer. I do love the fact that Kirk thinks he came up with something new and exciting with mode 0... but completely failed to see all the artifacts in the mode 0 layer conversions for juggernaut are a horrible side effect... and that you could simply augment a 2bpp layer with sprites. And in that respect, you wouldn't need mode 0.. you could use mode 1 and one of the 2bpp layers would be juggernaut + sprites. Because think about it.. mode 0 would not work with the WHOLE game.. unless the whole game was only that level (and those two characters). Anyone with any sort of experience with 2bpp can tell you this; sometimes you get lucky and get some semi-decent results, most of the time you get severely cutback detail with attribute clashing which requires segmenting the art ala NES/GBC style. This whole "24 colors" statement is bullshit. It's 3 colors per 8x8 tile. Sure, you have 8 palettes for those 3 colors, but you burn through them really quickly because you need "transitional" tiles that share colors between two color groups. Ask me how I know this hahah. But yeah "24 colors" to work with.. huh, "someone with an agenda trying to push a false narrative"

This is the best part of his comment, "This isn't even truly debatable unless you literally don't understand how the SNES works imo, or you are someone with an agenda trying to push a false narrative, or, and this is really the worst as far as I'm concerned, actually do have a clue how SNES works at a programming level yet are so limited in your thinking that you've never even tried to see if it can or cannot do whatever you think and indeed proclaim it can or cannot do." The irony... soooo much of it hahaha. I love it! It's gold.

Yup! I KNEW kirk was gonna post something related to this video hahah. I also love the part where he tries make it seem otherwise, " It's just an idea for getting the biggest fighters I can possibly imagine in a SNES fighting game, which was inspired by what Maxwel achieved on SNES and then thinking about how to maybe take that even further in some aspects." Yeah, nothing to do with the new video. "Now imagine... if you dare.." What in the Shatner is this? Well, one thing I didn't have to imagine was seeing it running on the Genesis. There was no daring or imagining. The obsession with mode 0 has reached next level kirkhead. Never mind the nonsense of why he has random characters laying on the ground (just because, I guess), so the KO bar is made of sprites? Well, you can't just slap a few pieces in the sprite banks and call it done. It's needs more intermediate pieces than that so it can show depletion! I guess the life bars ALWAYS have full life. Is that what you dare us to imagine? Also.. Ryu and Chung-li are a single composited sprite? What? Nevermind that they are 33 colors in that example.. are they just going to never animate then? What is their purpose? To sit there and never animate or move around? Slapping and pixels into what you want to visual as the snes sprite banks doesn't prove anything other than your lack of understanding and sloppiness. This is just all drivel nonsense.

Has auto-translated CC subtitles.

Generically, it's referred to as "raster effects". SNES HDMA transfers are also "raster effects". On systems that use the interrupt method, a more specific name would be "h-int" or "hsync interrupts" or "horizontal interrupts". There's no need to use the term because HDMA doesn't exist on MD (or almost any other system out there). Is the SNES the only system you'd dev'd on?

"kirkhead".. I love it! As far as a bug or unintended, or intended. I'd call bullshit on its intention. That's some Japanese developer backtrack talk to save pride haha. Given a complex system, and combos did exist, I'd imagine it was more of a risk to correct it and easier to just leave it in (given that it wasn't supposedly widely known). The only issue I remember were "jab-throws" combos.. which I think were in the console ports. I specifically remember people calling out in arcade matches at local shops.. rules like "no jab-throws". Kirk's argument about the 6 button controller is stupid. Okay, maybe if you're 6 years old, got the game for x-mas on the SNES.. then you might have a point. Because you didn't have money to buy a 6 button pad or something. Everyone I knew that had a copy of SF2-whatever-version had a 6 button pad (or a pair).. for Genesis. It does seem silly to even argue which version is better - because we can all now play the original arcade versions. As much as Kirk loves being a kirkhead, you'll see sega fanbois in the comments (on X, which this drama started) with stuff like "I always knew SF2SCE on MD was superior to SNES version.. and now I have proof". Not just Kirk still living these console wars haha. This is important to a lot of Sega fans for also who the console war never ended. My one and only issue with Genesis SF2SCE back in the day, was the horrible "laryngitis" voices. Other than Guiles stage looking a bit fugly, the colors were fine. It was the voices I couldn't get over. A friend had gotten it before I had a chance to pick it up... I skipped on that version. I picked up a used copy of the SNES Turbo a year or two later... didn't play it much. I had gotten my fill with CE in the arcade and was burnt out on SF2. I never understood how people could play SF2 like it was Tetris (never ending replay value) - I moved on to other games. I had a Genesis and SNES, and Turbo-Duo BITD. I import games, mostly for Genesis and Duo. But I skipped over the PCE version; I didn't buy/play it until like 2003. Off topic, but sorta related: I never understood the obsession/belief that arcade games with FM always had the superior sound. I mean, just because it's FM (YM2151). I often found arcade sound-tracks were fine, but nothing special or emotionally attached to (the sound of the instruments). IMO most of the time they lacked character, and some/most even had that thin-steely sounding instruments (which I didn't sounded superior) that to my ears just sounded "generic". I liked console's take on renditions of arcade games music. Even when it came to Genesis ports of arcade games where they changed up the instruments a bit (Vapor Trail, Ghouls n' Ghosts, etc). That said, being close as possible to the SF2 arcade sound-tracks, as it needing to sound almost exactly the same with FM instruments, always seemed silly to me. I still find the SNES and PCE renditions of the SF2 sound-track to be more interesting than the arcade version.

So.. does anyone know what improper sprite rotation is supposed to be?

I've known you since you bragged about coming up with a "brand-new" compression scheme all by yourself (i.e. RLE), as DragonBoy. I know you've been so obsessed with this for the past 13 years, but if you take a step back for a minute (and maybe realized who you're actually quoting here).. you'd probably understand that was a "slant" against some of the SNES developers back in the day, not the hardware. Come on, now. It was literally the experience we got back in the day on the SNES. So my mark isn't that far off hahah. But if you want to get technical with your comparisons here, you're clearly not a profession developer. I've seen snippets of your code. Unless you've miraculously changed, your stuff lacked design, modularization, etc - your stuff is full of literals and hardcoded things instead of standard/professional design (even lacking labels, using direct addresses). You write code like a rom hacker with no background in software engineering, and you've also been working on these same demos for like 10 years. That is NOT representative of a professional development environment or development cycle back in the day. I never once called you out on it, though, because your goal wasn't to be a professional software developer.. it's this obsession of pushing the SNES. And that's fine. Completely fine! But understand there's a difference between pushing the system without care or any sane coding standards, and actually developing code/engine/etc. There's a pretty big difference between hardcoding some literals or fixed code because you have years to spend tweaking it... and actually writing code/design (functions/data structures) that are strongly decoupled and allow pivoting of design during development. That stuff adds overhead, is slower in execution, etc - but with the trade-off that it's more flexible in design and refactoring/reuse (which was way more important to a development company and team back in the day... and still is today!). That's a side that rarely, even in the homebrew scene, that ever gets talked about. When talking about performance, etc - that context is important but is rarely in the discussion. And not once have I've ever seen you acknowledge this. Your focus has always been, performance in the context of "how can I push the system to extremes", and never what performance means in the context and perspective of professional software development BITD.

FastROM access will be 3.58mhz, but 65x is heavily reliant on ram because of the absence of general registers. And that SNES system ram is still 2.68mhz. Weird that Big N knew this about the 65x design and still chose to have system ram at 2.68mhz or 8 master clock cycles. So speeding up rom access doesn't give you full instruction speed (3.58mhz). A more accurate instruction speed for "fastrom" is ~3.07mhz (on top of slow system ram, you still have ram refresh stalls throughout the frame). Not the assumed and often inaccurate emulation speed of 3.58mhz that gets reported/touted. So ~14% faster, not often quoted ~33% faster.

Wow.. that guy has done nothing but hack SMW for 11 years straight. That's some dedication. Weird, but dedicated.

You mean 4 objects on screen with slow down? Because that's what you would have gotten back in the day. No need to SNESify a PCE game. SuperGrafx-ify it, since that would offer more than the SNES could. And by "interesting", you mean your attempt at "troll is as troll as does" hahaha.

Except he created an alt account there (SNES AYE):

It's interesting (to me at least) that while it looks impressive, but if you read between the lines.. he mentioned that he had to put a large chunk of it on a BG layer because of how SNES has limitations for sprites in vram (which the other 4th gen systems do not). His end-game (from what I've read) is trying to do some sort of dynamic allocation system for sprite cells in vram to overcome the small amount of vram defined for sprites (it's a hardware thing). Having sections of the "object" on the BG layer means it uses BG tiles and it wouldn't eat into the small amount of sprite segmented vram and would have room for other sprite stuffs. This isn't an issue on the MD and PCE - sprite data can exist anywhere in vram and isn't limited to 16k like the SNES. Just some of the challenges and weirdness of the SNES when it comes to sprites compared to its other extended capabilities.

Exactly my thought. It's only interesting in the perspective that they were found and are unreleased. Else, mostly garbage IMO.

The mask nose-piece makes it look like he has a stubby pig snout.

I have the TeD Pro and EDFX... I run it with multiple PCE consoles, including TG16, and I haven't had any issues.

The Japanese box art goes hand in hand with the title "Super Maro World". I mean it's got a lil planet haha. It makes more sense.

Weird.. it's like the PCE has some kind of super power over the snes or something: (PCE left, SNES right)

Wow! For some reason I don't remember this. Tho I didn't really care about ratings and more about what import games they were covering at the time. Funny thing is, this is how I got my Boxed SGX and all SGX games for a total of $50 from my friend back in early 1993. He wanted a jag, and sold me the SGX setup hahah.