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

[TrekkiesUnite118]

2 hours ago, Kirk_Johnston said:

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. 

Do you know how open source tools, C Libraries, toolchains, etc. get better? By more people using them and over time expanding and improving them. Do you think SGDK was magical and perfect when it first came out over 10 years ago? It wasn't. It got better over time through more people using it, adding their own code to it to expand upon its features. Since they were actually using it they could give actual useful and valuable feedback to people like Stef to make it even better. Do you know what doesn't help at all? Whiny little bitches like you who instead of giving useful feedback just sit around crying that it's too hard and actively discouraging others from trying out said tools and thus discouraging them from working with the system.

 

Quit sitting here crying that programming is too hard and only "math geniuses" can do it. Anyone can do it if you put in the time to learn and start playing around with it. If a complete idiot like myself can do it, anyone can. But I have a feeling this isn't really about wanting to help the SNES homebrew scene grow, or actually having genuine interest in making a real game for the SNES. It's most likely about you wanting some stupid simple drag and drop tool to allow you to shit out crappy demos on a moments notice to use in your console war arguments on social media.

 

 

[Razzie.P]

9 hours ago, Kirk_Johnston said:

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. 

I'm one of those people, I guess, maybe.  So I guess you're calling "total and utter bull" on my thoughts.  But that's ok... 😐    I mean, I feel that the fact we're seeing so many people jump though the hoops with those same archaic toolsets to develop for other systems is what peeps call "the proof in the pudding," I think.  

 

I don't think anyone doubts that a new batch of "simple, easy to use, push the button and it does the work for you" applications would absolutely create an influx of demos and games for any platform, SNES or otherwise.  But that's not what any development scene "needs."  All it "needs" is for people to want to develop for it badly enough to make things happen and produce results.  Authentic results that say "here it is on the system and here's how I did it.  Feel free to use my code, expand on it, and pay it forward."  Not Game Maker or .bmp that says "here's what we need, now someone go do it."

 

Heck, when it comes to "wanting the SNES homebrew library to grow," you're probably the most hardcore that I've ever seen.   And even you don't seem to care enough about it to actually roll up them sleeves and start making it happen, and instead spend your time and energy playing with Game Maker and bickering on forums, and cataloging your ignore list collection.  And some of those are leading to rifts that's actually alienating the handful of people who perhaps can help make it happen, so in a sense, all that effort is actively pushing your hopes backwards.

 

Any ol' yahoo can bitch and moan about how someone else needs to make things happen.  But if they can't/won't find it within themselves to care enough to dive in and provide authentic results, then it mostly just equates to a lot of piss n' wind.

[Razzie.P]

2 hours ago, TrekkiesUnite118 said:

Quit sitting here crying that programming is too hard and only "math geniuses" can do it. Anyone can do it if you put in the time to learn and start playing around with it. If a complete idiot like myself can do it, anyone can. But I have a feeling this isn't really about wanting to help the SNES homebrew scene grow, or actually having genuine interest in making a real game for the SNES. It's most likely about you wanting some stupid simple drag and drop tool to allow you to shit out crappy demos on a moments notice to use in your console war arguments on social media.

 

 

Absolutely.  I'm definitely no math genius, rocket scientist, or Sherlock, and I can do it too.   Those skillsets would likely be nice to have, but really, the number 1 thing that's needed (in my opinion, which I've learned may be viewed as utter bull) is simply to care enough to devote the time and effort to actually do it.

[+Biff Burgertime]

Yup - surrounded by C++ & assembly programmers, guys who moved across the world to work for Google, I was just some chump dicking around with AHK & Visual Basic. Yet I wound up developing the most worthwhile tools for a popular online game by sinking time into it every day. I had never sent+received packets before, converted all my variables into bytes, 99% of what it took was foreign to me at the start. A year later I had reverse-engineered most of the game protocol and had bots doing a better job as an anti-cheat than the actual game dev. All that and much more, just by devoting time to it every day.

 

Anything you want to learn, be it tech stuff or learning an instrument or whatever, just devote 30-60 minutes to it 5 days a week. Sure change is weird for the first couple weeks, but then it becomes part of your routine. Before you know it, you'll be amazed by how far you've come.

 

oh and I never knew shit about math. Simple arithmetic sure, but nothing beyond that. If needed, you know what I do? Fucking Google it.

Edited September 30, 2023 by Biff Burgertime

[Razzie.P]

21 minutes ago, Biff Burgertime said:

If needed, you know what I do? Fucking Google it.

Yep.  Same here!

 

Always reminded me of this --

 

 

 

[KulorXL]

9 hours ago, Kirk_Johnston said:

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.

[...]

we can't all be programming/maths geniuses

I won't say the tools are in any kind of perfect shape at the moment (they're definitely not), but I think the tools are certainly easy enough to get going with. The library I use is called libSFX: https://github.com/Optiroc/libSFX

It's a very simple thing that basically bootstraps the system for you and gets it to a place where it's running your code, plus a number of macros. Knowing very little about the SNES and having never coded for it before, I was able to install libSFX painlessly and start editing its examples in order to begin mocking up my own effects on the SNES. It was basically a weekend project. Installing libSFX is pretty much trivial: install msys2, clone or download the repo, then make it from within msys2. I was considering putting together a docker image with libSFX already installed and going, but after playing with docker for a moment, I realized that it's actually probably harder to install docker and use an image through that than it is to just get libSFX on your system normally. Then once that's done, the examples have some very simple routines that move some sprites around etc., which are very easy to begin adapting into something you want. It's no exaggeration that my engine began life as a collection of graphical mockups not terribly dissimilar to these Game Maker ones, except running on an actual SNES. I'm definitely no rocket scientist, I never even took college algebra...! I'm just some guy who started messing with effects on the SNES and eventually, through years of effort, turned it into a (still pretty early in development) game. I mean, I've seen the games you've made on Steam or for iPhone or whatever, you can obviously code. If you can do that, you can definitely start messing with SNES effects. Assembly isn't as scary as it looks.

10 hours ago, Kirk_Johnston said:

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

Well, something I was trying to emphasize was where all the different audiences who would potentially consider doing SNES homebrew land up. A lot of the tech-minded people who are into retro coding don't seem to actually care what hardware specifically they end up making games for, and the Genesis right now offers the path of least resistance (SGDK). I've heard it said a number of times that "I'd consider doing an SNES game if it had something like SGDK", so those people could probably become SNES devs if there was a C compiler. There's also a segment of retro coders who are likely to just not be impressed with the CPU or other aspects of the hardware, which can be founded (the 68000 is apparently a lot more "friendly" with how many registers it has, no weird memory segments to have to worry about, and no weird register mode switching or the edge cases that entails), or unfounded (a lot of people seem to think it's far more slow and limited than it actually is). I don't think you can ever get those people to try making SNES games. Along with them, you have the people who are from Europe -- a lot of homebrew comes out of Europe -- who grew up on the Genesis and think it's the better platform, and also the people who are attracted to the Genesis because they feel they can use it to prove that the Genesis is the more capable machine, which goes against the traditional popular perception. Those people are also very unlikely to ever make SNES games. The people who do get into the SNES tend to start with Super Mario World hacking, which basically sucks the life out of them...if they're already pretty disillusioned (which I've seen) or deep in several never ending hack projects, it's not likely they'll want to get into homebrewing. Plus, a lot of people who might make SNES homebrew are Nintendo fans first and foremost -- why would they want to make a completely original game when a Mario hack is way more appealing? One of the biggest SNES homebrew guys is Vitor Vilela, and he started out trying to make a SMW hack which turns the game into like a SMW/Touhou mashup, which lead him down SA-1 hacking, which resulted in all those SA-1 slowdown-free hacks he did, which is pretty much what he's still up to. I think it's pretty telling that one of the biggest ever SNES homebrew productions was a Mario fangame (https://www.youtube.com/watch?v=ZwtE1JRvc-E).

So, with all that, in a sense I do think the audience of potential devs who are interested in making completely original homebrew games might actually just be smaller for the SNES than it is for other platforms. But I really don't think it being "too hardcore" has anything to do with it. I see "hardcore" C64 productions every week, which is 100% assembly out of necessity, and way more limited hardware. Anything anyone makes on the Atari 2600 is pretty damn hardcore -- I tried getting that thing to move some sprites around several years back and gave up on that pretty quickly, yet you can go to the Atari Age store and see how much that stops anyone really wanting to make 2600 games.

All that is to say, if the SNES had an "SNDK", that would probably be the best thing that you could hope for to bolster SNES homebrew, and there are some very clever people who are much smarter than me working on the compiler integration necessary to make that happen. But even once that happens, there's a chance the SNES will just never be as popular of a platform for aftermarket homebrews, for all the reasons I listed above. The best you can do is to either get a team together, or crack open libSFX and start trying to get your own SNES games made, and hope others follow.

[Kirk_Johnston]

1 hour ago, KulorXL said:

I won't say the tools are in any kind of perfect shape at the moment (they're definitely not), but I think the tools are certainly easy enough to get going with. The library I use is called libSFX: https://github.com/Optiroc/libSFX

It's a very simple thing that basically bootstraps the system for you and gets it to a place where it's running your code, plus a number of macros. Knowing very little about the SNES and having never coded for it before, I was able to install libSFX painlessly and start editing its examples in order to begin mocking up my own effects on the SNES. It was basically a weekend project. Installing libSFX is pretty much trivial: install msys2, clone or download the repo, then make it from within msys2. I was considering putting together a docker image with libSFX already installed and going, but after playing with docker for a moment, I realized that it's actually probably harder to install docker and use an image through that than it is to just get libSFX on your system normally. Then once that's done, the examples have some very simple routines that move some sprites around etc., which are very easy to begin adapting into something you want. It's no exaggeration that my engine began life as a collection of graphical mockups not terribly dissimilar to these Game Maker ones, except running on an actual SNES. I'm definitely no rocket scientist, I never even took college algebra...! I'm just some guy who started messing with effects on the SNES and eventually, through years of effort, turned it into a (still pretty early in development) game. I mean, I've seen the games you've made on Steam or for iPhone or whatever, you can obviously code. If you can do that, you can definitely start messing with SNES effects. Assembly isn't as scary as it looks.

I got lost some way through that--lol--although I'd have to go try it firsthand to see how it would be for me personally to use, but hopefully this helps more people figure out a way to get at least up and running that's not too confusing and convoluted for them.

 

I promise, I'll at least look at libSFX a try at some point and see how it goes. Just as I will have another look at PVSnesLib at some point too. 

 

I have some sneaking feeling that these might be the same thing, which kinda sums up how easy it is for this stuff to confuse and lose me. 😛

 

1 hour ago, KulorXL said:

Well, something I was trying to emphasize was where all the different audiences who would potentially consider doing SNES homebrew land up. A lot of the tech-minded people who are into retro coding don't seem to actually care what hardware specifically they end up making games for, and the Genesis right now offers the path of least resistance (SGDK). I've heard it said a number of times that "I'd consider doing an SNES game if it had something like SGDK", so those people could probably become SNES devs if there was a C compiler. There's also a segment of retro coders who are likely to just not be impressed with the CPU or other aspects of the hardware, which can be founded (the 68000 is apparently a lot more "friendly" with how many registers it has, no weird memory segments to have to worry about, and no weird register mode switching or the edge cases that entails), or unfounded (a lot of people seem to think it's far more slow and limited than it actually is). I don't think you can ever get those people to try making SNES games. Along with them, you have the people who are from Europe -- a lot of homebrew comes out of Europe -- who grew up on the Genesis and think it's the better platform, and also the people who are attracted to the Genesis because they feel they can use it to prove that the Genesis is the more capable machine, which goes against the traditional popular perception. Those people are also very unlikely to ever make SNES games. The people who do get into the SNES tend to start with Super Mario World hacking, which basically sucks the life out of them...if they're already pretty disillusioned (which I've seen) or deep in several never ending hack projects, it's not likely they'll want to get into homebrewing. Plus, a lot of people who might make SNES homebrew are Nintendo fans first and foremost -- why would they want to make a completely original game when a Mario hack is way more appealing? One of the biggest SNES homebrew guys is Vitor Vilela, and he started out trying to make a SMW hack which turns the game into like a SMW/Touhou mashup, which lead him down SA-1 hacking, which resulted in all those SA-1 slowdown-free hacks he did, which is pretty much what he's still up to. I think it's pretty telling that one of the biggest ever SNES homebrew productions was a Mario fangame (https://www.youtube.com/watch?v=ZwtE1JRvc-E).

So, with all that, in a sense I do think the audience of potential devs who are interested in making completely original homebrew games might actually just be smaller for the SNES than it is for other platforms. But I really don't think it being "too hardcore" has anything to do with it. I see "hardcore" C64 productions every week, which is 100% assembly out of necessity, and way more limited hardware. Anything anyone makes on the Atari 2600 is pretty damn hardcore -- I tried getting that thing to move some sprites around several years back and gave up on that pretty quickly, yet you can go to the Atari Age store and see how much that stops anyone really wanting to make 2600 games.

I guess all of that could be true in terms of what it means in relation to the current SNES indie/homebrew scene. No one is able to definitively say and certainly not prove conclusively either way right now why the SNES is not getting more indie/homebrew games. Although I think we can see that everyone has an opinion on it. And, until I see otherwise, as in the existence of more approachable and intuitive ways to get into the scene for people who are more like me--that's how I'll put it--I'm happy to stick with my same opinion I've expressed previously, that it's just too difficult right now for a lot of people who might be making SNES games otherwise, which I do not believe needs to or indeed should always be the case. And I personally think that is the single biggest barrier to SNES indie/homebrew growth right now. I guess we can return to this topic of discussion in the future if such a thing I have described previously ever does exist and then we can see if it makes a meaningful and positive difference or not.

 

1 hour ago, KulorXL said:

All that is to say, if the SNES had an "SNDK", that would probably be the best thing that you could hope for to bolster SNES homebrew, and there are some very clever people who are much smarter than me working on the compiler integration necessary to make that happen.

Hey, I would certainly love to see that.

 

1 hour ago, KulorXL said:

But even once that happens, there's a chance the SNES will just never be as popular of a platform for aftermarket homebrews, for all the reasons I listed above.

Yeah, that is entirely possible. We just won't know until the choice is at least there to actually be made. But, I can say that not having the other options isn't conducive to the way I work, so it's not my ideal scenario. And, given all the other stuff I've churned out, I'm comfortable saying that if a more accessible and intuitive tool or even set of tools eventually exists for SNES, and I assuming I personally can use them, I believe I'd be churning out stuff for SNES similarly (within reason).

 

1 hour ago, KulorXL said:

The best you can do is to either get a team together, or crack open libSFX and start trying to get your own SNES games made, and hope others follow.

Possibly, in an ideal world. And who knows what the future holds on that front. I would love one day for that or some variation of it to be part of my future in SNES development.

Edited September 30, 2023 by Kirk_Johnston

[Domeshtan]

The things I found to be a pain to learn so far was how to initialize stuff on a real SNES to get things to run, the SPC700/SMP sound system.... Uhhhg! Had to write my own stuff, the switching between 8 bit and 16 bit registers, had bankswitching issues, DMA transfers... Lots of new stuff to soak in.

[Kirk_Johnston]

6 hours ago, Domeshtan said:

The things I found to be a pain to learn so far was how to initialize stuff on a real SNES to get things to run, the SPC700/SMP sound system.... Uhhhg! Had to write my own stuff, the switching between 8 bit and 16 bit registers, had bankswitching issues, DMA transfers... Lots of new stuff to soak in.

Yeah, I've heard the sound stuff is a bit of a nightmare.

[Domeshtan]

5 hours ago, Kirk_Johnston said:

Yeah, I've heard the sound stuff is a bit of a nightmare.

To put it mildly! The SPC700/SMP audio stuff is its own thing with its own CPU to handle the sound stuff. So now you have to learn another assembly language and write a program to send up into ARAM. (Audio RAM... Have about 64K to play with at any one time) Next you have to write a routine that sends that program to the SPC700 side one byte at a time using a weird "handshake" method of double checking things sent to know it got it before sending the next byte of your program. Uses locations $2140 thru $2143 on the 65816 CPU side you normally use (Ricoh 5A22) to pass data back and forth with the SPC700/SMP side. ($F4 thru $F7). Then there is using programs to make a BRR sample to play back for an instrument or sound effect. Bit Rate Reduced. The SNES can do some kind of fancy math to make a smaller sample sound better. Interpolated I think it is. All sorts of settings for volume, echo, etc... Making a sample directory with bytes telling where in memory to find the sample or loop point locations if you want the sound to keep playing. I've yet to figure out how to use the timers on the SPC700 side properly to get my programs to work so I used the blanking period on the other side to pace my music. (Counts frames drawn to set the pace. Some small audio error I get once in a while but reset always fixed it. Still trying to figure that one out). If you are using a LoROM format (like me) you are using 32K banks so if your program and effects you are sending to ARAM are too big you have to send it in two or more sections.  Writing the "loader" program to send your program over you need to check if the SPC700 is ready to begin the transfer, how many bytes to send and from where, setting destination address. (Everything pretty much gets sent to $200 so you need to skip the first $200 bytes in your program or chop them off with a hex editor like I did and send a slightly modified program). Also heard people had problems with WLADX for the SPC700 assembly stuff so I use SPCAS. Yeah, SNES audio is a nightmare compared to any other system I ever programmed on. It can do amazing things in the right hands but trying to write stuff from scratch is far from easy. SNESGSS is something like a tracker program loaded with instruments and has tons of ways of tweaking things just clicking and sliding things around. It even shows how much memory would be used up in ARAM and by what part of the program. Too bad I couldn't figure out how to properly add it into my code. It would have been sooooo much easier.

Edited October 3, 2023 by Domeshtan

[Kirk_Johnston]

1 hour ago, Domeshtan said:

To put it mildly! The SPC700/SMP audio stuff is its own thing with its own CPU to handle the sound stuff. So now you have to learn another assembly language and write a program to send up into ARAM. (Audio RAM... Have about 64K to play with at any one time) Next you have to write a routine that sends that program to the SPC700 side one byte at a time using a weird "handshake" method of double checking things sent to know it got it before sending the next byte of your program. Uses locations $2140 thru $2143 on the 65816 CPU side you normally use (Ricoh 5A22) to pass data back and forth with the SPC700/SMP side. ($F4 thru $F7). Then there is using programs to make a BRR sample to play back for an instrument or sound effect. Bit Rate Reduced. The SNES can do some kind of fancy math to make a smaller sample sound better. Interpolated I think it is. All sorts of settings for volume, echo, etc... Making a sample directory with bytes telling where in memory to find the sample or loop point locations if you want the sound to keep playing. I've yet to figure out how to use the timers on the SPC700 side properly to get my programs to work so I used the blanking period on the other side to pace my music. (Counts frames drawn to set the pace. Some small audio error I get once in a while but reset always fixed it. Still trying to figure that one out). If you are using a LoROM format (like me) you are using 32K banks so if your program and effects you are sending to ARAM are too big you have to send it in two or more sections.  Writing the "loader" program to send your program over you need to check if the SPC700 is ready to begin the transfer, how many bytes to send and from where, setting destination address. (Everything pretty much gets sent to $200 so you need to skip the first $200 bytes in your program or chop them off with a hex editor like I did and send a slightly modified program). Also heard people had problems with WLADX for the SPC700 assembly stuff so I use SPCAS. Yeah, SNES audio is a nightmare compared to any other system I ever programmed on. It can do amazing things in the right hands but trying to write stuff from scratch is far from easy. SNESGSS is something like a tracker program loaded with instruments and has tons of ways of tweaking things just clicking and sliding things around. It even shows how much memory would be used up in ARAM and by what part of the program. Too bad I couldn't figure out how to properly add it into my code. It would have been sooooo much easier.

Surely there's some way a program/tool could be made that acts like a wrapper that lets musicians make the music like actual musicians and then the program/tool does something behind the scenes to convert it ready for use on SNES. Well, that's what I would hope for in an ideal world. You know, something akin to Mario Paint's music creation tool, but obviously much more sophisticated and versatile, and then you just save it out in "SNES format" and plug it into the rest of the game and go. Now, I am no SNES programmer, so I'm clearly just being naive and idealistic, but man, having to jump through hoops like this in 2023 just get to some music on SNES is bonkers. I feel your pain. I cross my fingers that one day some smart SNES musicians and SNES programmers will get together to create something that will make it a whole lot easier in the future for all the SNES music creators out there to get their work done.

Edited October 3, 2023 by Kirk_Johnston

[M-S]

Or maybe you could include an FM sound chip inside the cartridge like they are doing with Xeno Crisis.

[Domeshtan]

2 hours ago, Kirk_Johnston said:

Surely there's some way a program/tool could be made that acts like a wrapper that lets musicians make the music like actual musicians and then the program/tool does something behind the scenes to convert it ready for use on SNES.

That's what SNESGSS is supposed to do. You can make music and sound effects with it, test out how it sounds, see how much memory in ARAM it uses, etc. When you are done it can kick out pre-assembled code supposedly that would be sent to the SPC700 side. Problem is (at least for me) is that there are other parts that go in the normal code and I can't get it to assemble right. Like there is stuff written in assembly (for another assembler it looks like) and then there is some file that looks like it is written in C that does other stuff not found in the Assembly file. The basic idea is there (if you can get it to work). Like it takes some kind if macro that has a given value and just passes it along to the SPC700 side. (Like Initialize, Play Song, Stop Song, Play sound effect # whatever, etc.) I don't know where it wants to get certain things from, if they have to be in specific spots, etc. Some extensions looked wrong with byte, word and long word. Well somebody got it to work but I can't find much out there where I can get examples to work. I had to make a bunch of guesses with tins if trail and error.

Edited October 3, 2023 by Domeshtan

[Kirk_Johnston]

25 minutes ago, Domeshtan said:

That's what SNESGSS is supposed to do. You can make music and sound effects with it, test out how it sounds, see how much memory in ARAM it uses, etc. When you are done it can kick out pre-assembled code supposedly that would be sent to the SPC700 side. Problem is (at least for me) us that there are other parts that go in the normal code and I can't get it to assemble right. Like there is stuff written in assembly (for another assembler it looks like) and then there is some file that looks like it is written in C that does other stuff not found in the Assembly file. The basic idea is there (if you can get it to work). Like it takes some kind if macro that has a given value and just passes it along to the SPC700 side. (Like Initialize, Play Song, Stop Song, Play sound effect # whatever, etc.) I don't know where it wants to gran certain things from, if they have to be in specific spots, etc. Some extensions looked wrong with byte, word and long word. Well somebody got it to work but I can't find much out there where I can get examples to work. I had to make a bunch of guesses with tins if trail and error.

Well that's cool that this tool exists. Sounds like it might need a bit more work to make it truly intuitive and usable for people who need things to just be more clear, obvious, and natural. Hopefully there's people continuing to work on it who can look into that. As long as actual end users keep providing useful feedback--if there's a development forum or Discord specifically for it, you should continue to post some of your feedback in there for the creators too--I would hope the creators will take that onboard and keep tweaking things to make the tool as approachable and user friendly as possible so more people can fully utilise and benefit it, and then we all benefit from it ultimately. That's what it seems a lot of this SNES development stuff needs most imo. And I think it's okay to ask for that.

Edited October 3, 2023 by Kirk_Johnston

[Domeshtan]

2 hours ago, Kirk_Johnston said:

having to jump through hoops like this in 2023 just get to some music on SNES is bonkers.

Here is what it took for me to get music to play. At about 1:03 you can hear I still haven't got it figured out 100%. Only happened on a real Nintendo once in a while. Part 6 deals more with trying to get a sound effect in general and how things get loaded up.

 

[Mittens0407]

On 9/25/2023 at 11:19 AM, Kirk_Johnston said:

I'm happy to consider what might come from such a tool and hope that at least one in however many games would be genuinely worthy of our time.

On 9/25/2023 at 11:19 AM, Kirk_Johnston said:

but I hope one day I might be able to tick that particular box

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

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. 

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

And hopefully verbalising this out loud will bring attention to it

On 9/30/2023 at 3:01 AM, Kirk_Johnston said:

So I hope things improve in the future, both in terms of it becoming easier for any wannabe SNES developers

On 9/30/2023 at 3:01 AM, Kirk_Johnston said:

I still have hope. 

On 9/30/2023 at 3:13 PM, Kirk_Johnston said:

but hopefully this helps more people

2 hours ago, Kirk_Johnston said:

Well, that's what I would hope for in an ideal world.

11 minutes ago, Kirk_Johnston said:

Hopefully there's people continuing to work on it who can look into that.

11 minutes ago, Kirk_Johnston said:

I would hope the creators will take that onboard

Do not lose hope! Praise Jesnes! 🙏

 

If Kirk ever actually makes anything of substance on the SNES by himself, I'll eat my house.

[Kirk_Johnston]

14 minutes ago, Domeshtan said:

Here is what it took for me to get music to play. At about 1:03 you can hear I still haven't got it figured out 100%. Only happened on a real Nintendo once in a while. Part 6 deals more with trying to get a sound effect in general and how things get loaded up.

 

Cool little tune there.

[Kirk_Johnston]

1 hour ago, M-S said:

Or maybe you could include an FM sound chip inside the cartridge like they are doing with Xeno Crisis.

Yeah, that's certainly an option, but possibly not ideal for every SNES developer. There's so much the SNES' PCM sound can do that allowing all SNES creators to get the most out of it, and in a way that's genuinely manageable by a wide range of people wanting to create music for their SNES games, is worth getting right imo. Hopefully the creators of the sound tools are still actively working on them and are continuing to improve them. I think nailing the already available tools to work with the actual SNES sound chips and stuff is a better move for everyone working on or hoping to work on SNES in the long run.

Edited October 3, 2023 by Kirk_Johnston

[+Biff Burgertime]

4 hours ago, Kirk_Johnston said:

Surely there's some way a program/tool could be made that acts like a wrapper that lets musicians make the music like actual musicians and then the program/tool does something behind the scenes to convert it ready for use on SNES.

Yeah like GEMS on the Genesis? The "easy-to-use" sound driver which gained a reputation for reducing Genesis sounds to various farts?

 

"While GEMS is a very capable driver in the proper hands, it has also grown to absorb much of the ire modern fans have for the “twangy” sounds of certain Western-produced Sega Mega Drive games. As the driver was both widely distributed to developers of all quality, and largely used by developers unfamiliar with the hardware, much of the system’s shovelware library shares a distinct (and poorly received) sound, often described as sounding like flatulence."

[Tanooki]

8 hours ago, Mittens0407 said:

Do not lose hope! Praise Jesnes! 🙏

 

If Kirk ever actually makes anything of substance on the SNES by himself, I'll eat my house.

Just saying...

[KulorXL]

On 10/3/2023 at 11:02 AM, Domeshtan said:

Here is what it took for me to get music to play. At about 1:03 you can hear I still haven't got it figured out 100%. Only happened on a real Nintendo once in a while. Part 6 deals more with trying to get a sound effect in general and how things get loaded up.

 

"If it happens it happens on a real Super Nintendo and only on startup"

I ran into an issue like that a while back. One of the really tricky things about SPC coding is, if the SPC is reading from the port at the exact same time the SNES is writing to the port (which is inevitably going to happen), the data being read is corrupted. You have to be very, very careful to ensure data integrity. If I had to guess, that's probably what's happening here...would have to see the code to be certain, of course.

Nice progress though! If you're on Discord, hit me up if you want an invite to the snesdev server, I'm sure they'd love to see another homebrew project.

[Domeshtan]

1 hour ago, KulorXL said:

I ran into an issue like that a while back. One of the really tricky things about SPC coding is, if the SPC is reading from the port at the exact same time the SNES is writing to the port (which is inevitably going to happen), the data being read is corrupted.

I thought I was double checking things passing stuff back and forth with the SPC700 but I could have missed something. I'm using the blanking period to pace the music because I could not figure out the timers totally. I'll see if I can dig up the code some time. I haven't touched it for about a half a year. After about 4 months to get the audio to that point I decided to take a break. I bought a bunch of Super Famicom carts at the Midwest Gaming Classic and it sparked an interest in trying to learn some Japanese that side-tracked me. Didn't want to waste the summer locked inside either. Figured I would pick up on this stuff again when the weather cooled down. I'm no where near the level of some of the stuff I've seen here but I know I commented my code to death so in the hopes that my game was ever finished the next guy would not have to go thru all the frustration I did trying to figure stuff out. Just tweak a few lines and watch what happens, etc. I was looking at bits and pieces of code from all over the place trying to slap something together to get something to work. I don't say my program is efficient. (Probably have a good laugh looking at it or covering your eyes in horror) but it does run on a real SNES.

[KulorXL]

42 minutes ago, Domeshtan said:

I'm using the blanking period to pace the music because I could not figure out the timers totally.

Actually not a terrible idea, since 1. the timers don't even fire interrupts, so you have to have the SPC checking them in a loop anyway, and 2. you pretty much need to do it that way if you ever want to start messing with streaming. My music engine isn't quite at the point of actually playing music yet, but I'm also syncing the SPC using frame timing via HDMA. Right now I've got it able to do sample streaming (for sound effects) and general-purpose data streaming (for loading new sample banks in song transitions), as well as music pattern data streaming so that the music pattern data doesn't have to eat up my precious SPC RAM...all that's left is to basically do the actual part of the SPC driver that takes the incoming pattern data and plays notes with it.

[Domeshtan]

1 hour ago, KulorXL said:

Actually not a terrible idea, since 1. the timers don't even fire interrupts, so you have to have the SPC checking them in a loop anyway, and 2. you pretty much need to do it that way if you ever want to start messing with streaming.

I thought the point of the SPC700 being it's own CPU and stuff was so that if the 65816 side got bogged down with stuff that the music would not slow down. Yeah, those timers seem screwy to me. They reset after being read? To me that's like having a watch that keeps perfect time but anytime I look at it it would reset to 12:00. I know I'm missing something. I can activate them and see them working while debugging but something is screwy when reading them.

[roots.genoa]

On 10/3/2023 at 9:27 PM, Biff Burgertime said:

Yeah like GEMS on the Genesis? The "easy-to-use" sound driver which gained a reputation for reducing Genesis sounds to various farts?