What do you think SNES needs to see more new indie/homebrew games?

[Kirk_Johnston]

55 minutes ago, bent_pin said:

Not really, it's more of a self-serve pot luck. 

Yeah, that would apply too. And it's not the best situation currently for SNES development, that I can say for sure [from a personal perspective anyway].

 

55 minutes ago, bent_pin said:

 

it was a limited market in its day. The only reason it was a commercial success is because Nintendo released it.

I would suggest that's not quite based on sound factual evidence more than opinion there, and one that doesn't feel very authentic to the SNES sub-forum. But that's your prerogtive to believe, feel, and express whatever you choose here.

 

55 minutes ago, bent_pin said:

 

Meh, the market for SNES homebrews is so very limited. There's no gain in investing in a nearly non-existent market. The 4th gen winner was Genesis. Were someone to invest the time, Genesis would be wiser target for at least a chance at a return on the time invested.

I would say the modern SNES market is no more limited than it is for any of those other retro consoles, and I would be inclined to say it's actually potentially bigger market than all of them given the relative sales numbers of all these systems, both in their time and indeed in modern times as best we can measure such things as popularity and such. I mean, the NES was more popular than all of them back in the day, with the SNES being the second most popular, both by quite some ways, but it's pretty clear to me that the SNES holds a bigger audience of interest today than even the NES, hence the likes of the SNES Classic Mimi selling over double the units of the NES Classic Mini, which itself sold millions more units than any of the other similar systems, as well as things like the most popular games from these retro systems on the Switch online service and other system's online services being SNES titles, etc. At least I've not seen a better set of metrics that shows otherwise. So I'd certainly be willing to at least give the SNES a genuinely fair chance at a healthy indie/homebrew scene with the kinds of tools that I personallly think would benefit it, or some other meaningful approach, before dismissing it.

 

55 minutes ago, bent_pin said:

 

A miracle.

Then I would recommend all the authentic SNES fans in this sub-forum who'd actually like to see new games for it start praying . . . or simply continue to positively discuss the system, show their genuine love for it, post intersting SNES threads, come up with helpful suggestions for ways to increase interest in it, suggest various contructive approaches for how we can encourage growth of the indie/homebrew development scene around it, and just celebrate and ecounrage those people who actually are trying to do anything SNES related (who are presumably sharing that already either in here or some other dedicated SNES forums/threads/whereever), etc.

Edited September 26, 2023 by Kirk_Johnston

[+bent_pin]

3 hours ago, Kirk_Johnston said:

I would suggest that's not quite based on sound factual evidence more than opinion there, and one that doesn't feel very authentic to the SNES sub-forum. But that's your prerogtive to believe, feel, and express whatever you choose here.

How many homebrew titles are there for SNES as compared to Genesis?

 

3 hours ago, Kirk_Johnston said:

Then I would recommend all the authentic SNES fans in this sub-forum who'd actually like to see new games for it start praying . . . or simply continue to positively discuss the system, show their genuine love for it, post intersting SNES threads, come up with helpful suggestions for ways to increase interest in it, suggest various contructive approaches for how we can encourage growth of the indie/homebrew development scene around it

You could pray or you could learn to program it yourself, the same way many others have, and release your own game. If you make a decent one, put me down to buy a copy.

 

Overall though, I would be very surprised if you could find an experienced programmer to do a job like this without a significant payment to get it started. However, if you want to get the ball rolling on an open source project then you can do just that by learning SNES asm and starting to write useful functions. Learn how to use Github and post those working functions. Do that and I can all but guarantee that you will draw help from other programmers who will contribute for free, to your open-source project. In contrast asking others to do what you won't will yield little to no results. 

[Tanooki]

I know I'm being ignored, and that's fine and all, but don't say I didn't try.   Also @bent_pin you crossed the line there I think, you may end up blocked too.

[Domeshtan]

Well, I'd settle for a well written book on programming the SNES in assembly language. (Not super-tech talk stuff. Just down to earth examples with explanations how it works.) I have the Learn Multi-Platform assembly programming with Chibu Akumas Vol 2 but it just scratches the surface. You can make a "hello world" program, put a smiley face on the screen and move it around with the pad. It's just enough to get your feet wet but some of the code just looks wrong. It will run on an emulator but not real hardware. (I have the tools for it). Took me about 2 months to figure out what was missing. I mostly stumbled thru things until they worked with a lot of trial and error. Mostly error! But once you got it you could move on to the next problem. I can say that SPC700/SMP audio system was a total fricking pain to figure out and is definitely not user friendly. Took a long time just to get a tiny "beep" from my laptop. Eventually I figured out how to play BRR sound samples and made a VERY basic music player. Took a looping break after that as it took about 3 months just to figure out the audio system. A nice book like the Hugg books for programming Atari 2600 and NES would be very welcome at this point. The Colecovision one someone else wrote was ok but didn't cover Z80 stuff as much.

[+bent_pin]

7 hours ago, Tanooki said:

I know I'm being ignored, and that's fine and all, but don't say I didn't try.   Also @bent_pin you crossed the line there I think, you may end up blocked too.

 

30 minutes ago, Domeshtan said:

Well, I'd settle for a well written book on programming the SNES in assembly language.

That's a much more viable option. 

[jeffythedragonslayer]

For now, you all can settle for Eyes & Lichty.  We need more people reading that book.

[JurassicDope]

Tbh I bet the majority of people that would develop for retro consoles don't even know its a thing 😅

[Kirk_Johnston]

8 hours ago, Domeshtan said:

Well, I'd settle for a well written book on programming the SNES in assembly language. (Not super-tech talk stuff. Just down to earth examples with explanations how it works.) I have the Learn Multi-Platform assembly programming with Chibu Akumas Vol 2 but it just scratches the surface. You can make a "hello world" program, put a smiley face on the screen and move it around with the pad. It's just enough to get your feet wet but some of the code just looks wrong. It will run on an emulator but not real hardware. (I have the tools for it). Took me about 2 months to figure out what was missing. I mostly stumbled thru things until they worked with a lot of trial and error. Mostly error! But once you got it you could move on to the next problem. I can say that SPC700/SMP audio system was a total fricking pain to figure out and is definitely not user friendly. Took a long time just to get a tiny "beep" from my laptop. Eventually I figured out how to play BRR sound samples and made a VERY basic music player. Took a looping break after that as it took about 3 months just to figure out the audio system. A nice book like the Hugg books for programming Atari 2600 and NES would be very welcome at this point. The Colecovision one someone else wrote was ok but didn't cover Z80 stuff as much.

A well-considered answer and much appreciated authentic response to positively addressing the topic at hand. I too think that would be extremely helpful to the SNES development community overall. Hopefully someone with the level of understanding, talent and time to create such a thing might see your suggestion and at least start thinking about it. 

Edited September 27, 2023 by Kirk_Johnston

[Kirk_Johnston]

5 hours ago, JurassicDope said:

Tbh I bet the majority of people that would develop for retro consoles don't even know its a thing 😅

Yeah, probably true. That's why, for anyone who's genuinely interested in seeing more new indie/homebrew SNES games, I think creating more awareness of the SNES in any way we can is also a worthwhile contribution. Just talking about it more, celebrating it, sharing any cool games and demos for it that we see in here, on our social media, YouTube, wherever, and reminding those lapsed SNES gamers of how cool a system it was/is. And I know there's obviously a small amount of that going on in this forum and such, so more of that is all good. Actual suggestions of things like the SNES programming books are, imo, great ways to start considering how to increase the amount of material out there to help anyone who even just pondered the idea of making a SNES game at some point, and maybe inspire them to give it a go. 

[Kirk_Johnston]

7 hours ago, jeffythedragonslayer said:

For now, you all can settle for Eyes & Lichty.  We need more people reading that book.

A great suggestion.

[Domeshtan]

5 hours ago, Kirk_Johnston said:

A well-considered answer and much appreciated authentic response to positively addressing the topic at hand. I too think that would be extremely helpful to the SNES development community overall. Hopefully someone with the level of understanding, talent and time to create such a thing might see your suggestion and at least start thinking about it. 

The thing is there are examples and documentation "out there" but it's so scattered or uses its own assembler or special tools. Use 64tass... No use ca65... No use WLA... SNESGSS would have been great to use as a solution for adding music and sound effects but no mater what I tried I couldn't add things into my code to get things to work. It's like I could read the source and was like "Yeah, OK I see what you are trying to do more or less" but could not get things to assemble properly and some things looked wrong in the code for using byte, word and long word values. (One of the things about the 65816 CPU is how you can change registers from 8 bit to 16 values back and forth.) What got irritating was trying to read code that looks like it's bouncing back and forth like a rubber ball between 8 bit and 16 bit values. I guess if you don't do certain things your code might not assemble right. The YouTube videos from Retro Game Mechanics Explained was invaluable for figuring out how things worked on the SNES 65816 (Ricoh 5A22 CPU) and especially the SPC700/SMP audio system. Another annoying thing is that I needed to use two different assemblers to put the code together... One for the 65816 main CPU side and a different one for the SPC700 (which there are not many out there) for writing your own audio program. Audacity for creating sound effects and instruments, brrtools to convert them, a hex editor to chop off the first 200 bytes of your audio program to prepare it to be transferred to the SPC700 side with its weird "handshake" ritual sending it byte by byte... Many tools just to get something to work. YYchr can be used for adding graphics but I didn't know how to properly use it to add things at the time. There is information out there but to have everything together in one book that is easy to understand (Well, as easy as you can make it anyway) with working examples covering all the topics well commented as to what is going on line by line and works on "real hardware"... a book like that would be most welcome! I can't tell you how many hours have been wasted trying to piece things together from files and info scattered all over the place. It's why I took such an extended break from programming SNES. Two months just to get "Hello World" on my T.V. with a real Super Nintendo and another 3 months to mostly figure out the audio system... So much wasted time! If someone could have just gave me straight answers instead of countless trial and error.

Edited September 27, 2023 by Domeshtan

[Razzie.P]

59 minutes ago, Domeshtan said:

Two months just to get "Hello World" on my T.V. with a real Super Nintendo and another 3 months to mostly figure out the audio system... So much wasted time! If someone could have just gave me straight answers instead of countless trial and error.

Just roll with it.  Call your game "Hello World" and just like that, you already have the title screen finished.  😁

[Kirk_Johnston]

1 hour ago, Domeshtan said:

The thing is there are examples and documentation "out there" but it's so scattered or uses its own assembler or special tools. Use 64tass... No use ca65... No use WLA... SNESGSS would have been great to use as a solution for adding music and sound effects but no mater what I tried I couldn't add things into my code to get things to work. It's like I could read the source and was like "Yeah, OK I see what you are trying to do more or less" but could not get things to assemble properly and some things looked wrong in the code for using byte, word and long word values. (One of the things about the 65816 CPU is how you can change registers from 8 bit to 16 values back and forth.) What got irritating was trying to read code that looks like it's bouncing back and forth like a rubber ball between 8 bit and 16 bit values. I guess if you don't do certain things your code might not assemble right. The YouTube videos from Retro Game Mechanics Explained was invaluable for figuring out how things worked on the SNES 65816 (Ricoh 5A22 CPU) and especially the SPC700/SMP audio system. There is information out there but to have everything together in one book that is easy to understand (Well, as easy as you can make it anyway) with working examples covering all the topics well commented as to what is going on line by line and works on "real hardware"... a book like that would be most welcome! I can't tell you how many hours have been wasted trying to piece things together from files and info scattered all over the place. It's why I took such an extended break from programming SNES. Two months just to get "Hello World" on my T.V. with a real Super Nintendo and another 3 months to mostly figure out the audio system... So much wasted time! If someone could have just gave me straight answers instead of countless trial and error.

I empathise. And hopefully verbalising this out loud will bring attention to it, and then the people with the skills and experience to do so can think about how best to help everyone in the community there.

 

A single set of really concise and easy to understand SNES development documents that anyone who wants to get into SNES development can follow, even just having something as simple as--it's crazy this is even a thing that ever needed to be brought up (blimmin' Nintendo)--page numbers actual human beings can follow, would be great.

 

Next, a set of shared tools covering the major aspects of SNES developlment that everyone can work with that ideally use some kind of common setup, interface, and development environment, would be another huge step forward for the wider SNES development community imo, which is what I imagine a core component of a truly great SDK to be. And then, in some ideal scenario for me personally, having both all the hardcore SNES developmet stuff that already exists for those who prefer that, plus the kind of more broadly-usable single/all-in-one SNES development tool that I've been talking about, would be dream time.

 

Now, I'm not proposing I'm the solution to all these things happening, or even that I'm anything more than just one small voice in a web of noise. But I'm just trying to help get the conversations going among all the authentic SNES fans and SNES developers in here and out there, because that seems like a good place to start and is something I can at least do with my own bare hands.  

Edited September 27, 2023 by Kirk_Johnston

[Wayler]

But in the real world, this is what you accomplish with those hands. 

[turboxray]

2 hours ago, Kirk_Johnston said:

it's crazy this is even a thing that ever needed to be brought up (blimmin' Nintendo)--page numbers actual human beings can follow, would be great.

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. 

[KulorXL]

So, SNES dev here, and I figured I'd chime in on this one because it's a topic that comes up a lot in SNES dev servers. First, my credentials...

 

So if the SNES is so popular, why isn't there more homebrew for it? I think there's a number of reasons...

On 9/26/2023 at 5:21 AM, bent_pin said:

Meh, the market for SNES homebrews is so very limited. There's no gain in investing in a nearly non-existent market. The 4th gen winner was Genesis. Were someone to invest the time, Genesis would be wiser target for at least a chance at a return on the time invested.

This is sorta a very typical mindset I see a lot: people who would otherwise be interested in SNES dev are more attracted by the established audience for Genesis or NES homebrew, versus the somewhat unproven market for SNES homebrew. Another common mindset is just not being impressed with the hardware compared to the Genesis. On the Genesis, you get a relatively fast CPU, with a ton of registers, and a nice pipeline for writing C code, which are all pretty important for people writing code. I've also seen it echoed more than a few times that all the various graphic features/limitations and edge cases are actually a pretty big turnoff (8 graphics modes, with their own rules about layering and priority, then you've got color math and windowing etc. and let's not even get into mode 7) versus the Genesis which has a much more straightforward and simple graphics chip. And then of course sound basically turns into low-level networking coding, which is a herculean task compared to getting audio out of just about any other system. With all of that on top of the more established tools pipeline on the Genesis, it seems like most coders who aren't particular about which 16-bit system to develop for end up gravitating towards the Genesis.

Semi-related, it's worth pointing out that a lot of people try getting into SNES dev by starting out with Super Mario World romhacks, and apparently Super Mario World is a really easy game to hack new levels or graphics into, but once you start trying to go crazy and do assembly-level hacking on it, it's actually a bit of a nightmare. The engine is very slow and hard to work with, and you're locked into a very specific subset of hardware features that aren't all that impressive. A lot of SMW hackers seem to end up giving up on the idea of doing any kind of homebrew because they either mistakenly believe making a homebrew would be even more difficult (it's actually easier), or mistakenly think that the hardware is far more constrained than it actually is.

As for documentation though, I actually think the SNES is in a pretty good place. Fullsnes is pretty much a definitive manual for anything you'd probably want to do: https://problemkaputt.de/fullsnes.htm

And then the SFC development wiki does a pretty good job breaking this info down in a slightly easier to navigate format: https://wiki.superfamicom.org/registers

The nesdev wiki has a nice section for the SNES, I particularly like this visual breakdown of the various ROM layouts: https://snes.nesdev.org/wiki/Memory_map

And of course the various dev servers have a pretty wide knowledge base to tap into, we're all pretty eager to help anyone interested in getting into this system.

 

21 hours ago, turboxray said:

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.

My first time seriously coding in assembly was doing a music engine on the Atari 2600, which is a much simpler piece of hardware for that kind of task (it only becomes hellish once you start trying to draw graphics). It took me probably about a year to get comfortable with it. The SNES is like an extended version of the same CPU architecture, so I was able to go into it with a head start, but even so, it took another year or so just to wrap my head around the crazy memory map. Then it's been about 3 years so far just to develop the base-level game engine...granted one of those years was spent figuring out how to do mode 7 perspective planes from scratch because nobody had ever documented how to do it on the actual SNES before. So yeah, it's definitely a time commitment! If I hadn't specifically wanted to play around with all those crazy SNES hardware features and just settled on making a Genesis game instead, I'd probably be on my second game by now.

 

Oh, as for the OP topic, would a SNES Maker tool be what it takes? Maybe, but I'm also not sure it would be beneficial. I know at least some people completely shy away from Gameboy homebrew because GB Studio productions come across as "cookie-cutter", which is a bit of a shame, but all-in-one tools like that tend to produce results along those lines. An SNES Maker tool would likely increase the quantity, but I don't know if it would be the quality people are looking for. SGDK is a much more basic framework than NES Maker or GB Studio, as far as I'm aware.

[Tanooki]

@KulorXL Thank you very much for your posts so far, especially this one.  This puts a real kick into the pants of the types around here who claims there's no tools, poor tools, poor references, excuse after excuse.  It's amusing as your work with that impressive looking shooter seems to be the re-run of choice often of what COULD be done.  Clearly it can, and you're capable.  But I agree SNES brewing is in a pretty decent space.  I've pointed out it has been for a time, Hind Strike, NekoTako, and others that have blazed a trail since the last decade are proof enough.  Sure it's not as prolific, but sometimes as N64 loved to push, quality can trump quantity.

 

I do hope you stick around.  I'm hopelessly lost on coding, I have a history (PTSD-lite) going back to my only bad grade/time in college where I just can't code, let alone setup tools to compile embarrassingly enough.  Yet, I love the technical, reading it, trying to grasp it, seeing in action, you're doing it there and it's appreciated, so if you're happy to stick around a bit with this somewhat older and somewhat more mature group of people here it would be great.  For me a milestone would just equally being able to compile roms people make but don't build, to just understanding and getting how the stuff works short of the doing myself.  I've been at it since the mid 90s helping with some key projects and I adored those years learning, testing, working on such things as it was a hell of a wild west time of this all.

[Tanooki]

Why did my post end up hidden and need approval is this something new?

[CapitanClassic]

You said the bad orange man’s name.

[Kirk_Johnston]

3 hours ago, KulorXL said:

So, SNES dev here, and I figured I'd chime in on this one because it's a topic that comes up a lot in SNES dev servers. First, my credentials...

 

So if the SNES is so popular, why isn't there more homebrew for it? I think there's a number of reasons...

This is sorta a very typical mindset I see a lot: people who would otherwise be interested in SNES dev are more attracted by the established audience for Genesis or NES homebrew, versus the somewhat unproven market for SNES homebrew. Another common mindset is just not being impressed with the hardware compared to the Genesis. On the Genesis, you get a relatively fast CPU, with a ton of registers, and a nice pipeline for writing C code, which are all pretty important for people writing code. I've also seen it echoed more than a few times that all the various graphic features/limitations and edge cases are actually a pretty big turnoff (8 graphics modes, with their own rules about layering and priority, then you've got color math and windowing etc. and let's not even get into mode 7) versus the Genesis which has a much more straightforward and simple graphics chip. And then of course sound basically turns into low-level networking coding, which is a herculean task compared to getting audio out of just about any other system. With all of that on top of the more established tools pipeline on the Genesis, it seems like most coders who aren't particular about which 16-bit system to develop for end up gravitating towards the Genesis.

Semi-related, it's worth pointing out that a lot of people try getting into SNES dev by starting out with Super Mario World romhacks, and apparently Super Mario World is a really easy game to hack new levels or graphics into, but once you start trying to go crazy and do assembly-level hacking on it, it's actually a bit of a nightmare. The engine is very slow and hard to work with, and you're locked into a very specific subset of hardware features that aren't all that impressive. A lot of SMW hackers seem to end up giving up on the idea of doing any kind of homebrew because they either mistakenly believe making a homebrew would be even more difficult (it's actually easier), or mistakenly think that the hardware is far more constrained than it actually is.

As for documentation though, I actually think the SNES is in a pretty good place. Fullsnes is pretty much a definitive manual for anything you'd probably want to do: https://problemkaputt.de/fullsnes.htm

And then the SFC development wiki does a pretty good job breaking this info down in a slightly easier to navigate format: https://wiki.superfamicom.org/registers

The nesdev wiki has a nice section for the SNES, I particularly like this visual breakdown of the various ROM layouts: https://snes.nesdev.org/wiki/Memory_map

And of course the various dev servers have a pretty wide knowledge base to tap into, we're all pretty eager to help anyone interested in getting into this system.

 

My first time seriously coding in assembly was doing a music engine on the Atari 2600, which is a much simpler piece of hardware for that kind of task (it only becomes hellish once you start trying to draw graphics). It took me probably about a year to get comfortable with it. The SNES is like an extended version of the same CPU architecture, so I was able to go into it with a head start, but even so, it took another year or so just to wrap my head around the crazy memory map. Then it's been about 3 years so far just to develop the base-level game engine...granted one of those years was spent figuring out how to do mode 7 perspective planes from scratch because nobody had ever documented how to do it on the actual SNES before. So yeah, it's definitely a time commitment! If I hadn't specifically wanted to play around with all those crazy SNES hardware features and just settled on making a Genesis game instead, I'd probably be on my second game by now.

 

Oh, as for the OP topic, would a SNES Maker tool be what it takes? Maybe, but I'm also not sure it would be beneficial. I know at least some people completely shy away from Gameboy homebrew because GB Studio productions come across as "cookie-cutter", which is a bit of a shame, but all-in-one tools like that tend to produce results along those lines. An SNES Maker tool would likely increase the quantity, but I don't know if it would be the quality people are looking for. SGDK is a much more basic framework than NES Maker or GB Studio, as far as I'm aware.

All great points.

 

I actually agree that a simple all-in-one "SNESmaker" tool along the lines of what I'm suggesting would likely bring a bunch of lower quality stuff with it--this is not unique to only the simpler and more intuitive game creation tools--but with the very real potential for some great stuff as well. The reason I don't personally have a problem with the idea of it existing is because I do not believe it should exist instead of all the current and future hardcore SNES tools and such, but actually as well as them. Each individual SNES creator could then freely choose to go hardcore, casual, or somewhere in between based on their own capabilities and ways of working and creating, rather than being basically locked into only one very particular way of doing things, which clearly only suits a very tiny niche of potential SNES game creators and is not a great or ideal situation imo. So, from my perspective at least, it would be a win win for the full breadth and depth of potential SNES developers out there if both/all options existed.

 

Also, in terms of this SNESmaker tool, I'll just say that I think it would also ideally want to allow all the standard SNES features to be used by default, which means all eight background modes, colour math, HMDA, window/shape masks, row/line/column scrolling, Mode 7 background scaling and rotation, etc. So, even though it might not be possible to do the impossible like your very impressive Mode 7 level with variable height for example, it would still allow pretty much every single effect I've shown in my concepts, which tend to just use standard SNES features used in pretty standard ways, and I think would still give talented SNES game creators the ability to make some amazing stuff. And, if it were an actual available option right now, I fully believe most people in the SNES community would be okay with that and certainly see it as a bonus over the very tiny trickle of new SNES games we're seeing just now.

 

I choose to believe that all the true SNES fans out there would be very happy to see many more brand new SNES games coming out in modern times, just as fans of any of the other retro consoles getting new games are. And I similarly believe they'd be fine if that means not all of them would be AAA masterpieces, but along with that the chance that quite a few of them actually would be great. And I really don't think that will happen until SNES development is approachable and realistically possible by far more people.

 

Those are just my personal thoughts on it as someone who absolutely wants to make actual working SNES games and demos, but currently finds all the available tools and such just too convoluted and too difficult to get to grips with, so any and every possible way of making that easier for all involved is all good in my book. So I will always advocate for that.

 

Your work on Rex Nobilis is very cool, and it shows just what can be done on SNES in the right hands when you can code hardcore Assembly and also combine that with thinking just a little beyond the default. 

 

Thanks for coming in here and authentically adding to the SNES discussion. Your genuine contribution to positively and meaningfully advancing the SNES community, especially in terms of your actual work on any real SNES content is greatly appreciated by yours truly.

 

I look forward to seeing more of Rex Nobilis and indeed any of your SNES work in the future.

Edited September 28, 2023 by Kirk_Johnston

[Mittens0407]

On 9/26/2023 at 5:40 AM, Kirk_Johnston said:

I would suggest that's not quite based on sound factual evidence more than opinion there, and one that doesn't feel very authentic to the SNES sub-forum.

On 9/26/2023 at 5:40 AM, Kirk_Johnston said:

Then I would recommend all the authentic SNES fans in this sub-forum who'd actually like to see new games for it start praying

On 9/27/2023 at 12:53 AM, Kirk_Johnston said:

A well-considered answer and much appreciated authentic response to positively addressing the topic at hand.

On 9/27/2023 at 8:03 AM, Kirk_Johnston said:

But I'm just trying to help get the conversations going among all the authentic SNES fans and SNES developers

42 minutes ago, Kirk_Johnston said:

Thanks for coming in here and authentically adding to the SNES discussion.

-ATTENTION CITIZEN-

Your SNES related comments have been deemed "inauthentic" by the Ministry of Culture.

You are to be stripped of your social dignity, and your name will henceforth be added to the state "ignore list".

 

LONG LIVE KIRKISTAN

[Tanooki]

@Mittens0407 That post didn't seem very authentic to me, you decide which one.

 

Having just read his thread, that's kind of annoying to say the least.  Inauthentic, a light touch of gas lighting(of course) because you know only true snes fans want a lot of brand new games made in a game maker that doesn't exist and likely won't due to the hardware.  What Kulor said didn't sink in very much which is a shame.  Irony saying he's both authentic and adding to the conversation, because well HE actually is the one who actually proven in code both authentic and adding to the pool.  I have to wonder if that was typed out with clenched fists, angry brow, and some random muttering because a slap down in that direction would just put the end stop to the entire mess.

[turboxray]

 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.  

Edited September 29, 2023 by turboxray

[Domeshtan]

Well for sound engines SNESGSS was looking really interesting to me except I could never figure out how to get it to work in my code. I could go thru it and kinda see where things were going, but some stuff looked like it was in C and some other stuff looked wrong and wouldn't assemble right. I never figured out how to use the timers on the SPC700 side properly so I used the blanking period on the other side to get things working.. Most of the time.

[Kirk_Johnston]

8 hours ago, Domeshtan said:

Well for sound engines SNESGSS was looking really interesting to me except I could never figure out how to get it to work in my code. I could go thru it and kinda see where things were going, but some stuff looked like it was in C and some other stuff looked wrong and wouldn't assemble right. I never figured out how to use the timers on the SPC700 side properly so I used the blanking period on the other side to get things working.. Most of the time.

From what I'm hearing and what I've experienced firsthand, it seems like there's certainly lots of different resources and tools and things you can use to try to start working on SNES development, but maybe most of them aren't quite mature and/or intuitive enough yet to truly be viable to all but the most dedicated hardcore types who are willing to battle through the fires of Hell to get something out of them. Bit of a shame that it's all this difficult and convoluted right now. Because, there's quite a few people telling the tale that maybe there simply isn't the interest in SNES and that's why we aren't seeing as many new games for it as some of the other systems, but i call total and utter bull on that, and I say it's because there's not the means for all those people who would absolutely love to work on SNES and/or indeed buy new games for SNES. Some people are simply not quite the hardcore types I mentioned, which are really the only ones who can currently partake in this current indie/homebrew SNES scene for the most part. That's sad. I have literally zero doubt the SNES audience is there, both SNES developers and SNES gamers/consumers, but we can't all be programming/maths geniuses, and I don't think we should necessarily have to either. So I hope things improve in the future, both in terms of it becoming easier for any wannabe SNES developers to genuinely get into the scene and using any available tools, without having to be rocket scientists or Sherlock Holmes just to do so, and then in turn for any starved SNES fans to see and start buying all the awesome new SNES games that could and should come of it. I still have hope.