turboxray

So you want to be taken seriously, want to speak with authority on SNES graphical capabilities, all in the context of pushing the SNES to the limits (in any area), but we're supposed to be okay with you being lazy on details? How does that even work?!?! That's not being lazy. That's being disingenuous to your audience. Either take the time to fix it, or don't do it at all. Because YOU had to be called out on this. You didn't volunteer this information until people called you out on it - until there was pressure to invalidate your credibility. If you knew better and didn't say anything, then that's disingenuous. Plenty of room to spare?!?! But your own incorrect and "messy" math, you literally only have room for 96 (8x8 sprite cells) max with no room for 2bpp tiles. A single frame of your Alucard sprite takes like 30-40 of those 96 cells (again, 96 meaning no room for 2bpp tiles for the layer). How is that, in anyone's imagination or interpretation of a 4th gen console, plenty of room to spare? It's this kind of bullshit. People that see your videos or whatever, and don't know, see this a line like this "plenty of room to spare" and actually believe you. I'm sorry, but that makes you a fraud. You are purposely misrepresenting the systems capabilities. Ohh, just like the "multiple accidents" where you showed off 24bit color images im place of the actual reduced 8bit images in your videos - got defensive about it when you got called out: "it looks the same anyway", finally acknowledged it, and then did it again! "I've been told..". THAT's the crux of the issue. Yeah, you've been told. You've been told by me multiple times (even on this "authentic snes sub-forum"). You've been told by other people, multiple times. The problem is, you shouldn't need to be told anything. Even if you don't code, you should be able to derive ALL of this without being "told" anything. I mean, YOU are the one parading yourself around as the SNES graphics expert. And, ironically, dismissing ANYONE else's criticism if they "haven't coded for the SNES". And this leads to my issue with you. Yes, you specifically. There is SOO much more to this number than this. You don't get to simply say.. I'm only using this much tiles, so I only need this much tilemap space. It's doesn't work like that. Why am I nitpicking something like this? Because you are literally taking the system to its limits for VRAM space. There's no room for error here. You don't get to "push the system" right up to the edge and also get to be sloppy with the details - or not even understand how the details come into play. This is more than just "messy". Remember, YOU are presenting yourself as an authority on this subject (you have a whole YT channel dedicated to this). You don't get to be hand-wavy, because you don't have the experience of doing anything like this on the real hardware. You didn't cut your teeth on this kind of stuff. Hell, 8 months around you had a melt-down because you couldn't figure out some simple beginner stuffs about the SNES PPU. Let me put this into perspective, since you actually 100% dismissed me in one of your tantrums when I told you about clipping your screen usage for using 8bpp mode so you could get a little more usage out of vram - and you were like "I won't compromise! I want full screen 8bpp glory!", but NOW has changed your tune haha; If you're using a 256px wide display resolution (no clipping), and you want to scroll.. horizontally.. you need more than a 32x32 wide map. You need a 64x32 map. You don't get to choose a 33x32 or 34x32 wide map, or whatever. Yes, can manually (either by not scrolling vertically, or using an HDMA for a "sew" line) use only 28 of the 32 rows (29 if you plan to scroll verticall.. you need one more row than your display height). These details are important. Because you either clipping the display via the window mask registers to get something like a 248px or 240px wide display area, or you use a 64x32 map config. If you choose a 64x32 map space, but only use 33x32 area at a time.. you don't get to use the off screen area for tiles or sprites, etc. That trick only works if you manually cut off the map for the vertical size, not horizontal. Why am I mentioning this and 64x32 map? Because that's TWICE the vram size as a 32x32 map. It's still twice the size of you clip/not use some rows too. And you've never once mentioned the 16x16 tilemap mode. You never mentioned horizontal display width clipping. What does that mean? You're math is wrong. Or you need to make some modifications for this math to work out. Neither of which you understand. Simply because you've "been told" rather than understand this for yourself (again, you don't even need to have coded on the SNES to understand this. This is very basic stuff). And because you are scraping EVERY byte you can possible get because you are right up against the limitation (i.e. "pushing hardware"), both your understanding and your math need to be accurate.. not messy. If you can't even figure the simple stuff out, how is anyone supposed to take you seriously on the more complex details??? There are other parts can I easily pick up apart, but this round and around hamster-wheel thing with you gets tiresome. The above is a demonstrative pattern that you keep falling into. Again, if you're going to "speak with authority", which you ARE doing through blog and video mockups, and present things that push the system.. you better both get it right and understand what you're talking about. I'll give credit where credit is due; you have learned more and grew in your understanding since 8-9 months ago, but you still carry that same shitty attitude, and worse yet your level of arrogance has gone up. What? "Ignore what I said in the past. Ignore that I was wrong, etc." What is that?? You literally can't be an adult and say, "Yeah, I was wrong in the past and I've grown and learned more now in my journey - blah-blah-blah.. <soap box>". And by help, you mean "being told". If only there was a way for you to actually learn this stuff.. as well as gain some humility in the process. "A broken clock is right twice a day". One, the demos DID have to be altered. And one those demos had to pull some mid screen sub/main tricks to get it near to what you wanted. YOU never accounted for that. The person that hacked SMW to show it off, deserves the kudos.. not you. Also, I don't think anyone really doubted those two demos in working order.. rather the criticism is that they "looked like ass" compared to what you were throwing away (in mode 1). Your demonstration didn't prove that it was absolute worth the trade-off in how you went around portraying it. So no, you get to take cred for that and say, "See? These two unrelated demos, that I didn't even code up and had to be cut back, gives me complete validation and credibility going forward in everything I saw and mockup". It doesn't. Those were simple demos. The ambitious stuff you're trying to post here, is leagues ahead of that stuff.

The only thing I would probably add to those combos, is either an upgraded SuperCD Bios/config to at least 512k ram instead of the on-cart 192k of added ram, just because the original memory foot-print becomes a limitation.. and not in a fun way, or target the Arcade Card (now that TeD emulates it, but someone else recently made an AC compatible hucard too). Many have talked about an SGX+AC+CDROM combo, and it definitely would be amazing (showing off what it's capable of)... but so far no one has done it. I personally like working with the arcade card because most of the time the memory is just graphics or maps, etc. I.e. not code. And the Arcade Card gives you a really nice set of what basically amounts to 4 beefy address registers to directly access that memory without "mapping" any of it. It's a qualify of life thing, very convenient, and makes code design a little cleaner/easier too. I would love to see an all out SGX+AC+CD project. But you can also do a bi-compatible projects that detects SGX. Not as exciting, but would reach a wider audience, and also hasn't been done in the homebrew scene. On top of that, Mesen 2 has come along and added PCE/SGX/CD support.. with an amazing debugger. PCE tools and development is in a much better state these days. If you have some ideas and would like to put together a proof-of-concept demo (single level or such), send me a PM. I'm pretty busy with work at the moment (been working OT over the past year), and I have a HuTrack music engine that I'm finishing up for a few people using it on their projects by the end of this year - but I'm planning out next year. And I'm looking to get stuff out the door and into PCE retro fans hands (playable stuffs).. and looking to put together a larger project.

Weird, but okay. I mean, hey - if his attitude and attacks on other people don't bother you, then have at it.

You can't have two layers of transparency like that. Transparency/translucency via color math only works between the sub and main screens. When you designate a layer to a screen.. the whole layer comes along for the ride. So if sprites go to the sub screen... ALL sprites go to the sub screen. And the only control about which sprites participate in color math, is by looking at sprite color palettes 0-3 and 4-7. Four of the 8 will participate in color math and the other four will not. And because all sprites on are on layer, it's impossible for a translucent sprite to appear on top of another, as translucent. He watches youtube videos. Looks at graphic effects.. knows from a high level that things like windows, hdma, layers.. exist but doesn't know anything about the details or how they really work. So he makes assumptions and guesses because that's what he's seen in videos (and the bits n' pieces people tell him). This concept of creating shapes with masks was explained to him about 8-10 months ago. Even a site link in the discussion showing it off to him. I mean, even early titles SMW did mask shapes (and scaled them). So, he's got a high-level understanding of how masks work (start and end point), but lacks the understanding of how it actually works and the limitations involved, and has gotten this mask/window stuff wrong on multiple mockup videos. But you know the saying, "even a broken clock can be right twice a day". Though somehow with Kirk, it's only once a day hahah. He just sees stuff in games (actually videos, because he doesn't really play these games), tacks on a simple change/twist, and parrots it as his own creativity. That a side though, apart for when he does get the graphic effects right, he still has no concept of performance and implementation costs. Here's a quip from his last video " at least the way it's done here using the two built-in windows plus HDMA and the backdrop colour, which is pretty low cost in this case compared to using other potential methods to achieve roughly the same result on other systems. :)". He has no clue or understanding to legit qualify this statement. Not only does he have no understanding of the impact on the performance for the SNES for this effect, he has zero context/clue/experience/etc of what it takes on other systems. Like I've said, he thinks HDMA is this magical thing that solves all issues at little-to-no performance cost. He has no idea that those some 100+ lines for the chess pieces, have two start and stop end points, and that you have to transform those coords all those coords for each line, clip as needed, and then rebuild the HDMA table values. And that just assumes he only horizontally scrolls with them. This implication of "built-in" for the context he's showing.. is not what they are; they're simple clipping/mask windows.. not meant for this. So this idea of "built-in" and "pretty low cost" is just pure bullshit on his end. It's an exploit of a simple hardware mask feature, into a more advance graphic effect, that requires some non-trivial level of design and performance-cost to implement.

Here's some back history: He goes around attacking MD fans that cheer on new homebrew.. out of some jealousy fit. Or attack fans talking about top tier MD games in general (you'll see him in the YT comments, and twitter replies - tho on twitter he's quickly blocked by authors of posts). He goes after homedrew devs of other systems and tells them the SNES is better (Kanya style). He doesn't understand technical stuff and gets upset at people with plenty of experience dev'ing on the system or just experienced coding on multiple retro consoles.. because they won't "answer his questions with simple answers". He fails to grasp that not everything has a simple answer (because the motive for simple answers to technical questions are to put the SNES in a superior light to all other systems, and to challege fans of other systems). I've seen him have a melt down multiple times because he couldn't get his simple answers from the experts. As he gains more exposure, and alienates/pisses-off more people, it feeds into this delusion that it's a conspiracy to keep him and snes dev down. You'll often see him use his new phrase "authentic snes dev discussion" as a way to dismiss anyone he doesn't agree with. He's also made the claim that unless you code for the snes, you can't challenge him. Very convenient, when he's alienated all the experts and they don't want any discussion or anything to do with him. He'll move from platform to platform, because he doesn't like critics or anyone to correct him, and the end up not like him.. mocking him, etc. His latest strategy here, is to just put people on ignore (but proudly put them on a list in his sig for all to see). He has no coding experience, or technical experience, and self-confessed that he can't even do simple arithmetic to calculate how many tiles fit in vram, yet goes around parading as a SNES expert when it comes to graphic effects. He throws around things like HDMA (even tho he doesn't know what is really is), and high resolution mode (even though he fails to understand it applies to backgrounds only, not sprites), 2048 color mode (my favorite of his claims, but he 100% has no idea how it works and how it's not even a real 2048 color mode but just a fixed 3:3:2 RGB 256 color palette), how the snes has "128 sprites on screen" but complete fails to grasp the moving parts of that, that pretty much makes that number superficial, etc. He uses inaccurate mockups in gamemaker, with all sorts of mistakes, but parades them around like it's equivalent of the real deal (I'm all for mockups.. from people that KNOW what they are talking about. Not this guy). Some of the "mistakes" he makes are on purpose (24bit color images instead of 8bit palettized, or more colors than palettes allow), to make the snes look better than it is (he's been caught multiple times on this, even after being corrected/pointed out). Anyone that calls him out on this stuff, gets touted as a troll and they want to suppress the publics knowledge of "snes real abilities".. again, conspiratorial. He believes that while he lakes technical skill, his abilities to come up with creative technical graphic tricks far exceeds those that have been doing this on real consoles (with actual code). Yet he has no experience and is still just learning the snes technical capabilities (it's taken him two years, but has carried that attitude the whole time). Both the level of arrogance and ignorance of this guy is astounding. On top of that, he attacks devs when they won't help him out, because he's alienated them (even threating suicide, and comparing himself to Near). He's personally gone after me and my YT channel.. when I was completely ignoring him and not engaging with him.. not provoking him. I've seen him go after (non snes) devs on twitter. His ultimate goal? Is to gain enough information on the SNES so he can fight/defeat MD fans. He's obsessed with this 16bit console war thing. Many of times he has taken things out of context that was explained to him, just to attack MD fans. He's also asked about technical specs, in relation to "how might it be better than the MD". In a previous melt down, he's admitted that is his goal - he wants to prove to all MD fans that the SNES is better in everyway, every spec, etc to the MD. If the MD has a better area/spec, he contorts his argument to dismiss it whatever advantages another system has. The guy is mentally unhealthy (he's blown up on people) and is completely obsessed. The list goes on and on. He's gained quite the reputation over the past two years. So much so, people don't want him associated with their work or whatever because of the negativity of his actions and reputation he brings. They don't want or need it. He'll move from place to place (discord, forums, etc) because he eventually alienates and/or pisses off everyone or just outright banned (usually begging or pressuring people to implement his gamemaker mockups into real roms.. and then throws fits when no one will do it for him. He really doesn't like to be told to go learn to code for the SNES). He's tried to re-invent himself here (he doesn't beg snes devs to replicate his mock-ups on the real console), and now actually claiming he's a SNES dev and graphics expert, and just puts anyone on ignore that questions him (and makes a list for all to see. Check out his sig). The fantasy lives on.

hahaha. Apparently gamemaker is SNES++

Been trying to find uses and think of ways PC-Engine' High Res mode could be used for things.. I mean other than it being high res. For things like the original composite video, high res mode is nice in that you can make some serious high color and high res images. And I made an image converter and demo roms to show it off. But.. stills or such.. meh. You can only get soo excited over still images or such. What about action? So playing some Zelda 2 remake in wide screen got be thinking how PCE could handle this. I'm not the first person to think about tailoring graphics from that era console to work on wide screen TVs. The problem is that the pixels get stretched (anamorphic wide screen). SNES and low res PCE/MD/etc 256px get really stretched out. Even when you do correct for this aspect ratio.. them are fat pixels. Personally, not a fan (even on c64 or 7800). MD has a 320px mode, and they're still kinda wide. Wider than normally 256px res pixels on a 4:3, if that gives an idea (1.22 PAR in WS... ehhh. Doable, but ehhh). PCE's mid res is.. okay... in wide screen about the same low res 256px mode in 4:3 (1.14 PAR in WS). But high res mode!!! The pixels get stretched out, but they're still pretty slim when viewed in wide screen ratio. Like, CPS-1 arcade slim on a 4:3 monitor.... slim (0.767:1 PAR)! If the pixel height was 1 unit, then the width would be 0.761 of a unit on PCE high res viewed as wide screen. And it would fill about 90% of the wide screen area too. Or make it wider if you wanted to (pce can do overscan). Anyway, so high res and full wide screen support! The real calling for PCE's high res mode hahah. A unique position where it can do something the other consoles can't really come close to. Hopefully you can see the Zelda 2 mockup pic from the twitter post. I converted it to PCE colors, and scaled/adjusted the image for PCE high res wide screen aspect ratio viewing. I mean hey, the last PCE game came out in 1999 (Dead of the Brain).. they had wide screen TVs by then. I think a Zelda 2 remake or clone/homage homebrew would work nicely. PS: Just for Kirk.. the snes can't do this. The "512px" wide mode he loves to tout about, is only for the background layer. It doesn't apply to sprites - they are always in low res mode. For some reason, he always leaves this detail out hahah. I wonder why...

Maybe I'll give it another try their. I had tried a few times and they didn't answer.

Yeah, and no section for PCE. They cover a lot of crap, some of it barely functional (early demos). It's definitely not in-depth or whatever. It feels like those old school meta retro-news site. I wasn't looking for something indepth.. I was just curious as to why they don't have a PCE/TG section and why they don't conver it... when they clearly cover everything else under the sun. Anyway, they have a twitter page. I've asked them, and they've completely ignored me. I figured with the lack of a PCE or TG category, and ignoring my questions multiple times, only one homebrew thing covered ever for PCE/TG (there has been work in the homebrew scene since then).. that they have something against the PCE. Really seems like they go out of their way to ignore it.

Indie Retro News Does anyone know the author of this site? And why they refuse to have a section for anything PCE/TG related? And refuse to cover any PCE/TG news. What's the story behind this?

That's from "TOTAL".. whatever that is. Why is the parallax rubbish??? It's there. What more does it need to be? I don't get these British mags BITD.

Yeah! Some hucard early-ish games use 3bpp for tiles/cells instead of 4bpp.. but then layer them with sprites to get past the 7 color limit when needed. And that layered sprites allowed for more animation for less storage, so might as well do them as 3bpp anyway. Some SNES games do this as well (using 3bpp instead of the full 4bpp) - Zelda ALttp. But they could have made it so that as they took damage, the armer came off hahah. Who knows.. maybe there's a cheat that allows it.

You plan to keep playing through the series? I'm curious how good the 3rd game is.

Not quite quirky... Anyway, this "authentic TG16 sub-forum" needs some lovin'.

Infidelity stuff is pretty great - and really high quality extensive hacks of NES games into basically as all new games. His Legend of Zelda hack is just amazing on NES. His approach of bring NES games over to SNES is just like that Finnish group that did it for PCE back in the early-mid 90s - all that stuff is converted over to native console. Pretty much just the original game logic code is left intact (as much as it can be), but all new replacement tile/sprite/audio/etc routines written to replace the originals. The SNES has a lot of video features that are as extension of the NES (the way tilemaps work as sections, 8x8 sprite size, etc), but it still has to be all converted over. The SNES also doesn't have any memory mapping unit that can mimic the NES, so that's work to repurpose it into SNES banks. That means potentially running into issues his approach (the early games are small enough that he can duplicate code). So it's a lot of work.. and a per game basis. But Infidelity is definitely up for the task. In my opinion, the novelty wears off pretty quickly as just original ports. So, there isn't much appeal to me playing these on other consoles. That is until you add upgrades! I think that's the real value. Once these roms are made, anyone can hack them like a native SNES game (via debugger/etc). There're already MSU-1 audio upgrades for the Duck Tales games. The NES2PCE stuff I did for the PCE started back in 2007. It really did start out as a joke to see how far I could get Dragon Warrior could run on the PCE. I just wanted to see how far I could get the game to run on the PCE. I looked at the Finnish examples roms and decided I did NOT want to replace all graphic/sound routines by hand for each game. This is how Infidelity is doing it (same as the Finnish group). NES2PCE runs ALL video/hardware/mapping/IO/etc through an emulation/simulation package in real time. The original 6502 code just runs as is on the PCE, but I patch all load and store instructions that touch the hardware, to JSR to my emulation backend. The PCE video is NOTHING like the NES, so it has to jump through a lot of hoops to get things contorted and converted.. in real-time.. to PCE hardware. But since the PCE processor runs roughly 3-4x the NES, the emulation overhead doesn't impact speed. Matter of fact, slowdown is still eliminated (noticeable in Megaman games which have slowdown on the NES. But Jackal is more difficult without the slowdown hahah.. it's also two players on the NES2PCE port). Unfortunately, PCE doesn't have the tiny 8x8 sprites of the NES, so it uses 16x16 sprites for those 8x8 sprites.. and can still run into flicker. If the game uses 8x16 mode, then less flicker. I actually added "NES+" video emulation registers to my emulation backend, so that anyone could hack the "NES" roms running on PCE to use 4bpp color, extended palettes, larger sprites sizes, etc - simply by using additional "hardware registers". I even added a "DMA" to transfer graphics, etc. But back then, debuggers were crappy for PCE, and no-one really did any hacking or coding for it. That was my real intent on the NES2PCE stuff - upgrade the games sound and graphics (Megaman 1 upgrade WIP actually had graphic updates and new sprite sizes, 6 button support, fast weapon changing, etc). But no one took interest. And then that Tobias guy sold my early Megaman beta build as a real "prototype" PCE game (re-pressing CDs). That's when I dropped all the NES2PCE projects I had in the works. I didn't want other people selling them. I think I had about 10 NES games running. I was working on improving the audio emulation at that point (even adding stereo separation for "NES" channels). Metroid and Zelda were in the works. But to honest, looking back now - those games are pretty simple. There's nothing stopping someone from writing a proper game engine, even open source, for whatever system (SNES, PCE, MD, etc) for these kinds of games. There's also NES "HD packs" support now - if you want upgraded NES games. It's just that Infidelity has a track record of delivering on these products - so might as well let him have at it hahah. Anyways, I'm waiting for him to port his Zelda hack to SNES.

Kirk still doesn't get it; sprites are a single "layer". There are only two points to do color math with: sub and main windows. You set a "layer" to one of these as the destination windows for color math. You don't get to pick and choose this sprite goes to sub and this sprite goes to main, etc. It's all or nothing. The only thing special about sprites, that of the 8 palettes.. half of them are excluded from participating in color math while the other have do participate. But you cannot have a sprite appear as color math over another sprite, simply because you can't have two different sprites set to sub and main. So his "shadow" sprites will not work when placed over the sprites used for the giant goomba (and his window mask trick). The shadow sprites, being on top, will literally cut a hole into the goomba sprite overlaps, and just show transparent against the BG layer underneath. This will happen to ANY sprites that overlap like this, and color math is involved.

Your post got me interested in what the upgraded differences were (and just the game in general, I never played this on the home system BITD.. only arcades). FMV is cool and all, but game needs the main character colors/graphics to be updated (an overhaul). Maybe even some of the backgrounds. And seeing how the sprites are 15 colors, but somehow look worse (less), I decided to see what it would look like on PCE: Not bad. PCE conversions I did averaged around ~50 colors a character (more characters than what is shown here). Still 4 palettes left over for projectiles/etc. It'd definitely be a time consuming task - but you could reserve two palettes per character on the SNES and at least make them look decent (they're supposed to be high color renderings). With 8 palettes for sprites, two chars would use up 4 and the shadow flipped sprites would use up 1, leaving you with 3 palettes for projectiles and such. Additional palette per character would be a big improvement (even if it only netted you like 4-5 more colors). Ohh.. you know what.. it's using sprites for color math.. and that means palettes 4-7 are for color math and 0-3 are for normal sprites. Color math for the floor shadow/reflections of the characters. So you don't have that many palettes to play with unless you change this. Ehh... I rather have more detailed/high color characters and weaker shadow effects. Anyway, FMV for the backgrounds would have been a nice MSU-1 hack, but I don't think there's enough DMA bandwidth for that (or vram space to double buffer). Maybe partial screen FMV parts...

I did want to make a mention of sound/music engines. I think that's an area where people just hate or are intimitated by it, and whether it's Assembly, C, etc - having the tools for both playback and music/sfx creation is really important. That's a trend I've seen over the past decades. And I do think having libraries you can import for whatever functionality is pretty decent as well. That goes right up there with small bits of startup code that correct initializes everything for you (that has bitten people in the ass over the years when they want to run on the real hardware - but a standalone rom, or a rom-menu loader). Anyway, just wanted to clarify that; I don't think it's a requirement that you HAVE to do everything yourself. I include stuff like sound/music engines in that. Unclear if my original post comes off as "you need to learn and do everything yourself else you're a coward and a piece of trash". I would never expect someone to become a master at everything, or let alone say that's a requirement. Anyway, from a homebrew development perspective, there are some things pretty important (to have up-front) and I think sound/music is definitely one of them. Something you can important and easily use. And a tool/app that you can give an artist so they can just worry about going to town on those sweet, sweet chip generated tunes (piss-off you MSU-1 cheaters hahah. /jk Whatever gets it across the line). I can see the same thing for some basic mode 7 support. And maybe some libraries for quick and dirty hdma table effects. But I'm thinking about this in C/Asm context, not SNESmaker context.

The nice thing, is that you don't need to do the OR'ing part, right? Just write to that plane and the hardware takes care of it - free hardware assist. So yeah, if you use the lower 3 planes for lower 7 colors, and you setup the palette in such a way that when any bit is set in plane #4, then it would use the upper 7 colors. Should be able to DMA just a byte at a time to vram on the SNES (that was something I never tested years ago). You could also apply dither to the 4th plane to get more than just a single on/off transparency difference. That's one way. Another would be to divide it into two 2bit planes. This works in the 16 color subpalette too. I'll give away a lil' bit of my secrets. Here's an example on the PCE (that's directly portable to the SNES, even tho it's trying to replicate the snes original hahah). This is SMW ghost house room for one of the bosses. I converted it to 2bpp tiles on PCE (it's a quick and dirty conversion; light rays could use some manual touch up but it's decent enough for proof of concept). And here's the 8 palettes of 4 colors. And here's the ghost 2bpp layer that I'll composite over: Normally, you only have 3 colors for drawing on the "upper" 2bpp "layer" because you need the base color #0 so that normal stuff shows underneath it - basically the upper 2bpp layer is like a sprite and needs an invisiable/see-thru color slot. But in that ghost pic I have 4 colors (the extra 4th color is the mouth). Since I have an extra set of 8 palettes I didn't use, I can have alt set for the mouth color. But it also requires setting subpalettes dynamically (changing them for that overlapping area on the tilemap). Originally, I was doing this with sprites. As in, manually creating a sprite layer that just has the image data underneath it, and then it gets paired with this. It's a small section, so doesn't require much CPU resource per frame to do it. I had done a similar approach with replicating the first boss of Mystical Ninja on the PCE. It required two sprite layers with a manual cut-out and one set of translucent color pixels for each layer (and then overlaid to the original 3bpp + 1bpp layer). If I had taken the sprite approach for the mouth in the above example, then I would have 8 more palettes for 4bpp.. so mixing modes as long as the translucent ghost doesn't over lay on them (I would clip for that anyway) - basically I could have done that with the bricks layer on the side walls, making them not part of the transparency tile sets - and save a couple 2bpp palette entries. And lastly, since the translucency effect relies on the colors in the subpalettes - I can control the type of transluceny (color, tint, etc).. as well as fading between no translucency (solid colors), to any levels in between (fading in and out). On top of that, if you have vram to spare, you can setup the normal 8x8 tiles associated with a palette.. to 8x4, 8x2, or even 8x1 if you clip the screen a little bit. Though that also means more cpu overhead if you're also changing the palette associations on the fly. Leaving them static just requires an HDMA (or interrupt) to do X|Y line adjustment every X num of lines. But it would give you a little bit more color freedom. If you're trying to do an 8x1 approach in mode 0 though, for all 4 layers (and for full screen).. that's going to each up a chunk of vram. But you could have sections of the map "high-res" palette block association and other areas lower res or base res (8x8), to save on vram. Just a side note: The way I have the tiles laid out in vram and how I write to them - I only need the ghost tilesets to be pre-shifted 8 pixels to the right (so 8 copies of 2bpp images).. an old ST trick. I don't have to waste time trying to shift the planar pixels via manual cpu resource. And I get Y starting point/position for free. I had some ideas of how to do this on the MD, but it wouldn't be the planar approach and would involve quite a bit more cpu resource too - but I'm sure I could pull off the ghost house effect at 60fps. Rilden's tool is great, but I found for stuff like this it was better to do it by hand. Maybe Rilden's tool to get a rough estimate or first-pass. I don't use it for 2bpp stuffs, even when I do want a first-stage lossy conversion. I use my own palette sorting and conversion tool. Rilden's tool is amazing, but for conversions that need attention to detail and when you need the ability to make corrections to the tile and palettes - then I use my own tool. I use my own tool for either loss-less conversions or taking in Rilden's output as a first-pass for further tweaking purposes. And hardware window reg/area transparency! Basically like the snes.

I think it's a pretty good litmus test that if page numbers are the barrier to entry on snes development for you, you have much bigger problems haha. A "hold your hand documentation" snes dev doesn't exist because 1) the official dev manuals exist. 2) tutorials, wikis, demos exist. 3) Emulators with open-source code exists. 4) There is an active snes dev community that can answer your questions. 5) Retro dev was never meant to be easy; it has a steep ramp-up, it has extreme restrictions on performance, storage, bandwidth, etc compared to more modern systems - but once you get past that it's more level sailing (assuming you some sort of background in application development and understand good coding design and practices, version control, etc). There is an expectation that you need learn these concepts and understand them well. In the grand scheme of things, given all that exists for you to start development, 8+ month to ramp up time to a decent/comfortable level isn't an issue. If that sort of time investment just to ramp up scares you, look to more modern systems for development. That kind of documentation only helps out beginners - once you ramp up, it's not that useful IMO. That sound harsh, but it sort of weeds out serious people and people that just want to "mess around". I'm a professional embedded software engineer by trade. You would think in a professional environment, that sort of documentation exists. Most of the time, it does NOT. If you need to understand things in detail, you need to dig through the source code yourself, scrape up documentation here and there, etc. This is my job on the daily. Maybe I'm more thick-skinned about this, but this is the real world. If you really have a dream of making snes dev projects, there are real world requirements that you need to step up to. But also, there ARE a community of people willing to help (compared to the professional world, not so much haha). People you can talk to/chat with. Making friends and not alienating people really goes a long way (hint-hint). Also, people in the snes hacking scene have been doing this for decades. People with zero programming experience, zero assembly knowledge/experience, etc. They ramped up. And, if you feel overwhelmed.. and have zero experience in retro dev and all that it entails, you can always get your feet wet on a lesser system (like the NES, or SMS) - it'll teach you the basics. This whole; I have this childhood dream and want to pump out my retro dev game in a year.. is just mostly unrealistic without some sort of previously experience in the related field. Anyway. I just wanted to point out that on the surface - not having this holistic tutorial driven documentation as the reason why snes dev is not flourishing appears to be the problem. I know that's the perception, but that's not actually correct. Specifically, because people by example have demonstrated over the years that they will give up anyway - even with that help in ramp-up time. Because they lack the fundamentals of all the things that go into development because just coding for the console (build scripts, environment tools, tool chains, etc) - concepts like data structures, code organization, etc. Or they just realize that it's a bigger/more complex issue that they had anticipated. It's more than just; can I write 65816 assembly and can I write an HDMA table. It's much more than that. Is that kind of "single package documentation" beginner intro tutorial a "nice to have"? Sure. It's convenient, if you're a complete beginner (which I would say that SNES system probably isn't a good choice for that anyway). Is it required? Definitely not.

New drinking game; every time Kirk mentions authentic and snes sub-forum in a post...

It is haha. It involves some careful planning, definitely in the bandwidth area but also vram layout. I was talking with a homebrew snes dev last week about it, and they're going to see if they can implement it in their snes project. Once you wrap your head around it, you can start to think of clever ways to use it. There are no videos on it that I know of, but you can think of it as hardware accelerated transparency because of the nature of planar format. While not exactly planar, the Titan demo (I forget which one) on the Megadrive uses the same idea - it turns on a debug mode feature on the MD that OR's the two BG planes together (early models of the MD don't support this tho, but all PAL models do). For planar, think of 4bpp graphics as the OR'ing of 1bit planes (albeit with the 1bit values in specific slots), and then set the corresponding sub-palette to dictate what that looks like. Funny enough, Ninja Spirit on the PCE does this for the 2nd level (Forest area).. with the leaves of the trees and the far pseudo BG layer. It's pretty minimal, but was surprised to see it done in a commercial PCE game. It's definitely going to dictate art direction IMO. Maybe even to the point where it doesn't look like a SNES game anymore, but something indie retro with 8bit flare.. but obviously more capable. I think I mentioned it before, but something like Shovel Knight. There's no way that would be an 8bit game (I remember the authors trying to justifying it as near NES capable because of.. "mappers" haha). But something along those lines, place nice with art design that doesn't need color fidelity packed into a tight area. IMO, transparency is sort of off putting for that design too, but doing vertical "copper" gradients would fit right in (ala HDMA). I think you can safely do 8 color changes per line (though that might be back-to-back, and random slots being less).. but that would give you the ability to apply it to different BG planes (or sections within them). Something like that would be aesthetically pleasing. I had a few pics that represented that look. Yeah, the issue becomes a balance between making the 4 individual planes blatantly apparent, but at the same time not clobbering your art/level design and/or make the screen too "busy". If you're trying to make 2bpp tiles look 16bit, then you're definitely in for a challenge haha. But, I'm totally not against it - would love for it to be proven otherwise. I spent a lot of time studying Amiga games that tried to do a lot with just 7 colors per playfield. Or even Agony - which uses 1bit playfields (AFAIK).. but a copper gradient. I was trying to do a version of Agony for PCE because of the planar trick and unlimited writing to vram during active display. But I don't think Agony looks good compared to anything SNES can do even in mode 1, but it's a demonstration of 1bit and 2bit playfields. If you do some mockups, please post! Here, twitter, snes dev discord (or my dev discord), etc. Would love to see it! Funny enough, GBC was my first console that I dev'd on back in late 1999. I really liked that lil' console. Was both happy and sad when the GBA came out - it meant the end of the GBC. But yeah.. unfortunately 8bpp and PCE high res 4bpp (both take up the same amount of space) eat up a TON of memory (rom) for unique large graphics. TG has the CD unit (and arcade card), but SNES dev potentially would need the MSU-1 or a custom mapper. I had played through Zelda's Adventure on the CD-I, ripping the BG screens, and experimented with making a demo on the TG16. TG16 having 16 palettes made it nice in that each screen would have a dedicated 8 subpalettes, meaning you could scroll between two screens and each having their own color "space", but the amount of storage needed for those BGs in high-res mode really added up. So much so, that I decided to experiment with 352px and 256px instead to save on storage space. They looked really good even in the lower res, but still took up a lot~. Everyone always forgets about the PC-Engine Super Grafx.. but I have plans for it. Now that SHD3, Mister, emulators, etc support it - I think it's a viable platform since "niche" seems to be gaining popularity in retro dev these days. People want something special/different/alternate-universe-fantasy, etc. That means that "Bonk's Adventure" demo I made for the PCE... would be 4 layers of 4bpp graphics on the SGX! I think an "SGX" add-on for core PCE consoles is more or less trivial, and also an option. But that's neither here nor there; we need an actual SGX homebrew game first. Anyways, yeah - I think MD getting a LOT of attention for its more advanced homebrew and demos.. is already having an effect on SNES dev. People are already asking.. so what's available on SNES for dev'ing tools. And the resurgence of GB with GB Studio too. All this homebrew/dev attention will indirectly drive that tool and environment development on SNES. While I'm not interestied in a SNESmaker for SNES, I think a mature "C" solution with modular library support is what's needed for more serious development. C won't be as performant as assembly, but that's where in-line assembly comes along for the ride. I've already seen how HUGE performance gains can be made with just a little bit of sprinkled ASM in TG16 "C" (HuC) projects, and how well that worked out, so I know the same would apply to SNES. I've jokingly threatened to port HuC over to SNES if a "C" solution isn't figured out by the next year hahah. Luckily, a LLVM is being worked-on/adapted for SNES.

Part of it is that C/C++ on the 68k is better performance for the arch than anything 65x design wise (clock speeds aside). But mostly, it's the tool chain and library support (Stef went above and beyond for the sprite sheet parser... it's that good). And code looks and feels more modern.

Sure, but that's no different than the z80 on the Genesis. At least the S-SMP is still 65x based. The z80 is painful compared to coding on the 68k. But they solved the problem with just having someone else supply a "driver/engine/interface", and you just interface with it via whatever functions. I did the exact same thing on PCE; I wrote a complete music and sound FX engine - people can use it without ever knowing the details under the hood or having to ever write code for it. And being ISR driven approach means there are timing issue (you no longer have direct access to audio registers because the ISR will trample them and vice versa), but the "interface" provides everything you need. It's no different than most embedded systems. But yeah, the NES is just simpler. You can design a simpler game, and gamers will still accept it within the ecosystem of NES commercial tier games. Tho I personally was annoyed when that whole "single screen game" fad would just NOT die out on the NES homebrew scene haha. I mean, the NES CAN scroll. It can. It's not that difficult. It was cute at first, but then got old fast.

Also, why are all these snes dev threads in this section, anyway??? There's are Programming and Homebrew sections on AA.