turboxray

What is this rambling nonsense???? You literally don't know ANYTHING about coding on the snes and yet you're gonna make these claims??? You have no clue. And no, you will not be "quickly" swapping out all 64k. LMAO. At least Kirk sort of tries... you just say whatever nonsense comes to your mind hahah. "Sounded good in my head... must be true."

Also your hero: "Many think that high-resolution modes have a large color limit, but in fact they don't. There are 8 palettes of 16 colors, standard for the SNES. The limitation is in the number of layers. Mode 5 still allows two of them, but Mode 6 only allows ONE. It's not worth it just for that effect. lol"

I can totally understand why others would put it in their S-tier list.

I think you're right. Like the underarm lower pieces. Also, as I was posting those pics I realized the sprite viewer doesn't actually show the full damage haha. As-in the actual cells getting dropped don't show as being dropped in the viewer. The situation is really bad/ugly when the arms are at "level" with the perspective of the screen view, but that doesn't happen too often so it's not too bad.

Someone needs to tell Kirk about Classic Gaming forums over at Digital Press. I'm sure they have not heard about the good word: color blasting. Classic Gaming (digitpress.com)

It's not. I played it through to the boss. There are plenty of sprites left over. (those remain cells are all off screen.. aren't used). The game does use the priority setting, but it uses it selectively. Like when the arms are in such a position that overlap is at its worst. You'rte not seeing 16x16 sprites being dropped from the table; each arm if positioned just right is like 304 pixels over sprite overlap.. a single arm in the right position is more than the entire sprite line fetch limit haha. The sprite rotation isn't random, because you can easily see the same patter repeat. On top of dropping out of sprites, it's also got that weird snes thing where is drop highest priority cells. This kind of boss would have been a good candidate for sprite compositing ala one of the addon chips. Yeah, same. I liked it originally because it was new and flashy and had nice graphic effects. I can see why people put it up there on their list, but it's not S tier in my opinion. If not for this thread and playing through the game today, I think the last time I played through it this was like 10 years. Just not one I normally think to come back to.

Some of the flicker looks like line drop by "too many objects per line"... but some of it looks like the unique sprite flicker to the SNES where top layer sprites cells are dropped instead of sprite cells underneath (on the NES/SMS/PCE/MD, it's always lower priority "underneath" sprites that get dropped). Looks like a mixture of both, which makes it even more noticeable IMO.

Funny thing about Axelay, when you change the weapon in-game... the sound effect is the exact same sound the Home Depot intercom would make before an announcement over the loud speaker system. Or.. at least around the time when this game was out.

Like Dottie? Very much so. And I like that lower color count, but the palette of colors that are just soo beyond 9bit or even 12bit color. I like that style.. it's ALL about color count. It's something the SNES can very much pull off. Sometimes when a game tries to pack too much color it ends up looking gawdy or busy, or both.

That was just an example, but let me clear this up; 1) I won't be doing this manually, and 2) I'm not really dividing colors into two halves per se. I have a script that does all the permutations of re-ordering a fixed set of 16 colors (well 15 as BG #0 needs to stay in place), and then builds all tiles needed, and then converts them to st1/st2 opcodes, and then removes all redundant "st1" opcodes of the previous value is the same, and finally does a measurement test to find the fastest layout - so by brute force I'm going to find that fast transfer method setup/layout.. however that turns out to be. Remember, I said previously that the VDC can only take 16bit writes to vram. Even if the stored data ends up being 1bit ,2bit, 3bit, or 4bit... 4bits will ALWAYS be written. And the intersection of two "sets" could in fact overlap like in your example. There's no automatic segmentation rule that says colors have to be divided into two halves. A tile stored in one 3bit arrangement may in fact use "common" color from values 0,2,4,6 which would be from 4 colors from the perspective of another 3bit arrangement (where the highest bit is clear). If the arrangement of the fixed set of colors makes that example, then fits the arranged schema. And even though I clearly have tiles (like a large set of them) that required number of colors are a single set 6 (and never deviate from this), some tiles will be the same boat where they will be 7 colors or under (meaning you could in theory represent them as 3bits) but need colors from that set and colors from another set. Anyway, these are just examples and are really irrelevant because my tool-chain script for the build process is going to produce what I need for the fastest upload rate. I'll never need to look at it, only call it, and only measure the overall performance in game. Edit: But like I said, if you want to talk about details... take it over to the nesdev forum "other retro dev" section.

That's an exaggeration. Plenty of complex systems are RE'd without any official manuals. I mean, just look at all the MAME systems we have. None of those official manuals were ever leaked. I would 95% of the time the official manuals don't help other than official terms for things, because stuff was already figured out.

My first thought would be.. I'm in Japan! So, I'd want to spend every second exploring Japan. SMW park wouldn't be at the top of my list, in that situation, especially because since it's state side. But then I was watching Asianometry's video on Disney in Japan, recently on YT, and it might be worth it since it'd probably be a completely different experience.

@Biff Burgertime Thanks! I wasn't sure if people were like, "I sick of this crap already" or whatever. Though I think I'm getting sucked too much into this and should really be working on personal coding projects haha (which cpuwiz has already dropped the hint a few times now haha). I do agree with Trekkies though.. SonicRetro is responsible for some pure bullshit that people who don't really understand, assume it's a good source of truth and just parrot the info on that site - I've seen a lot of it. Kirk is basically the one-man-SNES show of that. But honestly, I do love the tech talk. I do like the ingenuity homebrew (and commercial) devs come up with to solve problems for retro dev projects. Definitely want to try my hand at some videos explaining some of the tricks and limitations.

The details get pretty complicated, but I've cut my teeth in "dynamic" tiles for the PCE. Basically, I'll need a 64x256 buffer in vram. The far layer is a single 16 color palette (because it's the one that's animates, not the top layer). But they way the graphics are laid out in the original assets (which grey columns have a 8pixel black bap between the red-ish textured arches and stairs), I separate the colors into groups of upper and lower. I.e. lower colors go to bit planes 0-2 and upper colors go to bit planes 1-3. This means for certain sections of the tiles I only need to update 3 bit planes instead of 4. The PCE video chip only takes 16bit writes to vram, but the lower 8bit "LSB" retains the last value written to it, so if you write t he MSB the last value in the LSB comes along for free. This, save one byte out of 4. I'm also storing more of the columns of the dynamic tiles are "ST1" and "ST2" opcodes.. which are special PCE opcodes that write directly to the video port (write immediate value to video port). This will bloat the graphic data by double, but saving one byte via the fore mentioned scheme, I saw two bytes here. Also, because of the nature of the graphics that make up the far BG layer in the original, I only need to store a small number of columns.. because they nicely fit together. This stuff gets really deep in the weeds and gets very PCE specific. Things such as PCE can write to vram during active display. It's not 100% as fast as vblank, but it's pretty close (quite a number of PCE games do this too). So I'll be chasing the beam, so to speak since I don't want to have to deal with a double buffer scenario. Because this stage only scrolls horizontally, it makes the logistics soo much easier. I can more easily plan out where/when the writes/updates are going to happen. On the PCE, I have ~119222 cpu cycles per frame. If I have to double buffer, I don't think 16k total is going to break the bank. I only have one tilemap layer that takes up room in vram. If I really need to, I can clip the display to 248px wide and use a single 32x32 map size. Stuff like that. Edit: This might be too deep in the weeds discussion for here. We can take this over to the nesdev "other retro dev" section if you want. And since this really isn't SNES related.

Having played both, and was a big fan of the first one, I thought the 2 game's pixel art wasn't exactly on par with the first game. Weird, considering it's a sequel.

I didn't even realize Shockman was on the SFC. I should have guessed haha.

You doubt my skills, sir?

The more you tell him otherwise, the more he's gonna double down on this. That's his defense mechanism when reality closes in. He's probably planning a YT campaign right now. Probably Twitter/X too.

Ohh, that's just me.. knowing that he's predictable as ever. I knew Kirk was gonna get pissed off and all worked up (even though he says he ignores people). He's done this in the past on other forums where he's made like 50 edits in 5 minutes when he's all worked up. He was kinda known for this. So when I saw him reply, and then an edit popped up.. I just manually copy pasted his reply every time an edit came in hahahah. Good ol' fashion manual copy/pasta. I mean, it wasn't that difficult.. the majority of his edits happen in the first 5-10 mins when he's all worked up. Kirk is pretty predictable in so many ways. The more you tell him otherwise, the more he doubles down. That's what all this "color blasting" nonsense is about. It's him going off having a fit.

What haha. It's totally a bad name. I mean I'm not against whatever quirky names or whatever people want to come up with, but shouldn't it be sort of descriptive to what it's actively doing, no? Nothing is getting blasted here. Not even a trickle.. it's just a stagnant piles of 3:3:2 non-indirect pixeled tiles sitting in vram. And those pixels are even getting blasted. No blasting is happening. I mean you already have a catch phrase "Direct Color" which that's exactly what it is. Why not use what it's already called? It's like trying to rename mode 7 to something else. But yeah, "blasting" is not happening. I think Kirk misunderstand what "blast" means in the "blast processing" marketing lingo for the Genesis; it's just a dma to "blast" colors on a given scanline. This is more like.. color "preserving".

Dunno. Probably some interns at Konami haha. The weird stuff that you find, right? Maybe they thought they were gonna save on some vram? Or maybe they pulled in some library code from a different project and just stuck with the limitations. But yeah, this game needs a hack for sure.

Interesting. This is exactly what I and others have been telling you about mode 0... and Direct Color mode. Following your logic, seems like you've finally come around. Took a bit, but congrats. This is predictable. The Kayne interrupt. The classic "wall of snes capabilities" spewed out in some emotional fit of rage (I was telling Jeffy about how this was your signature reply all across the net when you were specifically harassing devs and fans of other retro systems). But let me break this down further.. you know, since you don't code on the SNES and don't realize the things you say and retort with are just silly. Time to line-item reply.. That literally makes no sense. Why would you use the "wee little engine that could" to approach development on the SNES. That's seriously ridiculous. Do you often look over to the SMS dev forums to figure out how you're going to make a SNES game? This logic is moronic. If you coded for either system, or rather both, you'd realize the PCE can do stuff the other systems cannot. The PCE is not just a SNES with 1 BG layer and 9bit color. There are things the PCE can do that neither the SNES or MD can do. I'd could make a list for you, but I don't think you're emotionally prepared for that. So making a blanket statement like this, and not even knowing any of the techniques I'll be using.. really just shows a grand level of ignorance on your behalf with these systems (gamemaker and watching videos won't get you this level of experience and knowledge). Yes. That's called the SNES. Since I'll be using all of the PCE 16 BG palettes and all 4bpp tiles not 2bpp modes.. what are you going to do if you can't replicate what I'm doing on the SNES? If the SNES has to fall back to using a 2bpp for part of it, does that mean the SNES is inferior??? Hmmmm. Also, when and where necessary? What haha. What if it's unnecessary.. can it still do it? I swear some of the stuff you throw in your replies to sound technical.. just comes off as word-salad manifest nonsense. I know the snes overall strength is in color and such, undeniably so, but you do know that the PCE has double the BG palettes and double the sprite palettes of the SNES, right? I mean, the PCE has 16 palettes just for sprites.. that's ALL the subpalettes for sprites and BGs on the SNES. The SNES does not pwn every system in every area. You need to stop pretending as such. It's also one of the areas where PCE's high res 512px out shines the SNES high res 512px mode.. PCE has more colors because it has more palettes (double the SNES), and it's 8x8 on the PCE instead of the worse 16x8 on the SNES. I know this upsets you, because you attacked/harassed my PCE high res videos demanding that I give you the demo roms hahah. You know the PCE can actually do wide screen, unlike the SNES? I mean, you could on the snes but the sprite pixels is would ugly wide - where as they would be perfectly normal looking on the PCE.. even high res while still being wide screen. Yeah but not in Direct Color mode. It's actually inferior to the PCE with a DC fixed palette (and the way that it's "fixed" too). Again, showing your ignorance. Unless your game is a bullet hell shmup where almost everything is an 8x8 sprite.. then no. No, it actually doesn't work like that. I would need a whole section to explain why the SNES sprite system is not anywhere near as capable as you think it is. But you're in luck! I'll be doing some tech talk videos now that we're in 2024. I'm sure you'll love these, because I'll be talking about FACTs of all three systems. Facts.. not delusions or deceptions or disingenuous gamemaker mock up videos that egregiously show the snes in a false positive light. Let me post a few examples for you. Here's Batman on SNES: Batman, in all his awesome pose, takes up 31 hardware sprites! The clowns take up like 29 sprites. You can do the math.. 31+29+29+29 = 118 sprites. SNES is only capable of 128 sprites So Batman is basically blowing its sprite budget and can only have 3 enemies on screen without dropout. This isn't even a sprite pixel line issue. Here it is on PCE: Clowns went from 29 cells to 5 cells. Batman went from 31 cells to 10. So 10 + 4 + 4 + 4 + 4 + 5 + 5 = 36 sprites out of 64. Isn't that weird? Only 36 sprites and can show more enemies than the original SNES game? The clown on PCE is 4 sprites because the main body is a 32x64 sprite. And no, you won't be using the useless 64x64 sprite size on the SNES. But the PCE will be flexing that 32x64 size as it's used in a lot of games. So lets do the same for SNES and drop the horrible 8x8 size setup. The SNES can only have 2 sprite sizes at a time, where as the PCE can have all 6 selectable sizes with no limitations. The SNES, using 16x16 and 32x32 size setup would require 50 sprites to do the same. 39% more than the PCE. But I hear you say, the snes can display more sprites! The reality is, yeah the SNES has a 128 table.. but at 16x16 and 32x32 size setup.. you're going to blow your sprite pixel line budget before you max that out. If you go 8x8 and 16x16, you're going to blow your table size budget instead (and increase the load on the processor). This isn't just some edge case scenarios to make the snes look bad in the sprite department.. it IS relatively bad.. compared to the PCE (and of course the MD which dominates here). Now throw on top the sprite cell vram limitation of the SNES compared to the PCE. Hell, the PCE can also update more pixel data in a frame than the SNES can; PCE might not have as fast DMA.. but it has the entire screen available to write to vram, and while that may take more time on the PCE - the processor is soo much faster that it's easy and doable to waste some cycles on this. But don't worry, I'll have a video explaining soo much more in depth. You're gonna love it. I can and have done "semi-transparency" boxes on the PCE. Again, this gets into the technical side.. you know, coding, that you have no experience in. Lolol you will not be replicating the Alucard trails on the SNES. You do know the Arcade Card exists, right? We're talking about SotN release date is pretty late even if it was on a 4th gen console. Definitely would be an AC title. 2megabytes of ram, and a CD drive? Literally could have that rotating sky as just animation streaming from the AC memory haha. I love how you edited you reply and put "stock" everywhere for consoles.. but the PCE CD is the PCE, and the PCE is the PCE CD. See, unlike the SegaCD or 32x.. which are sub-systems and addons to the main console, the PC-Engine is wholey unique in video game history because CD addon took over and replaced the "core" system. It is the only system where the optional media became the main media. The PC-Engine CD is the PCE, and the 'core' unit became the sub-system. You literally have 3 all-in-one Duo units. So yeah, Arcade card buddy. Rotating vortexes. Whoa whoa whoa! Look, I appreciate it that you recognized the talent and ingenuity of the MD and PCE retro dev communities. I do. But you are literally insulting ALL of the SNES dev community. You're insinuating the snes dev community cannot figure stuff out on their own, lack the required talent, skill, and imagination, and that they need to resort to stealing/copying original and talented work from other retro dev communities???? Are you serious? I know there are a lot of smart and more than definitely capable people in the snes dev community and in the SWC hacking community. I don't think they would appreciate the insult. Pretty sure they don't need to wait for PCE and MD communities to come out with stuff so they can "learn from" them. Maybe you need this, but I wouldn't use "we" to mean anyone in the snes dev community. I know your contorted logic. The ultimatum; challenge him to make the demo but at the risk of the "snes" taking it and improving it (somehow adding to my shame, I guess haha) - unclear who's actually going to do this, but it won't be you since you can't code. Gonna make another gamemaker video?? LMAO. Or don't make the demo because I don't want the snes showing improvement on it.. but then I'm seen as a fraud/fake. Dude... you are SO predictable. Ohh no! What am I going to doooo! Hahaha. Here's the thing though.. the "little 8bit PCE that could" that's three years older than the SNES.. doesn't need to equal the SNES to "win". If the PCE can simply get pretty close to the SNES, the SNES loses. PCE doesn't need to beat it or equal it, to humiliate it. I mean, I'm not sure why any system would be "humiliated" and the idea is completely idiotic.. but I'm using your logic/perspective here. So that's all I really need to do. Keep an eye out, because I have some demos I'll be releasing for 2024 that take snes games and replicate the effects on PCE. I'm sure you'll love it.

I guess you're done editing? Holy crap edit after edit every minute hahaha. https://pastebin.com/raw/kKDFA3av That's how you know Kirk is livid! Lolol! He was baiting me to do it, because he was expecting to use it against whatever Pyron had done on the newest SotN Genesis demo.. so he can slight than demo and the Genesis in general. But I don't think he expected me to compare it to that travesty of his mode 0 demo hahah. You can tell he was pissed... because you can count the edits to his post as rack up. Too bad we can't see the count here, but I was able to capture some of them.

Wish granted. ^ A quick convert for PCE. Probably count use some touchup here and there. Parallax would be dynamic tiles (I already calculated the size and processor time for the area needed). Parts of the statues would be sprites. I could pull off 4 layers of parallax for this level. So PCE.. VS mode 0 example

or.. why not a middle ground? Both extremes suck.