I'm not sure what use it is besides a tech demo though.
Why doesn't someone with your knowledge (I think there are some people here) create a homebrew SNES game that can keep up with some of the classic games and make it use your sound "engine" for example?
AFAIK there are only 2 (!) SNES homebrew games available which I can't really understand. Is the SNES so much more difficult to handle than the NES for example?
AndiNo wrote:
Is the SNES so much more difficult to handle than the NES for example?
I can think of several reasons why people who have considered Super NES homebrew may have switched to the NES or the Game Boy Advance:
- NES is conceptually simpler, with only 30 registers total and only one assembly language that's well supported by sophisticated free tools. Getting an SPC700 mode into ca65 would help.
- Standards for art are lower on NES than on Super NES due to fewer colors and fewer layers. Super NES might hit the asset complexity wall sooner.
- For games that can benefit from Super NES style graphics, the GBA is an easier beast to tame. It has one 32-bit CPU fast enough for C and a more orthogonal register map. Moreover, copiers for homebrew have been available since half a year after release.
Quote:
Getting an SPC700 mode into ca65 would help.
WLA-DX has supported the SPC700 for a long time.
I largely agree on the other points though. The GBA PPU in fact is basically an improved SNES PPU, but the GBA is so much easier to program for. There was somewhat of a SNES coding scene back in the early '90s, with groups making cracktros and demos for the SNES (mainly using their Amigas I guess). But since then there has been very little interest in SNES programming compared to other retro systems.
Great sound demo! Next time I burn a CD for my SNES clone (Gamestation) I'll have to see what it does on there.
AndiNo wrote:
Why doesn't someone with your knowledge (I think there are some people here) create a homebrew SNES game that can keep up with some of the classic games and make it use your sound "engine" for example?
AFAIK there are only 2 (!) SNES homebrew games available which I can't really understand. Is the SNES so much more difficult to handle than the NES for example?
If a game is going to use the SNES PPU to it's full capacity, it can get complex. It's relatively easy to max out what you can display on the NES screen, before resorting to extra hardware (mappers).
Most SNES games are 1024kB. It takes a good amount of creativity and dedication to create that much code and data from nothing. Compared to NES, where you can create 24kB or 40kB of code/data and potentially have it be just as great as the old classics.
mic_ wrote:
Quote:
Getting an SPC700 mode into ca65 would help.
WLA-DX has supported the SPC700 for a long time.
I used TASM (Table Assembler) when I made the NSF player, there was a table file for it included with some SPC docs. TASM worked fine, it just had a few odd things like having to do JMP !addr or something like that for addresses.
In fact I was originally considering SNES developement, but for reasons tepples mentionned switched to NES. Also one reason he doesn't mention is the availiblitity of a lot of demoes and tutorials for the NES. (okay I was following CRAPPY tutorials and admired CRAPY demoes that only ran on nesticle back then, but yet it did the thing to make me want to do the same thing and want to code my NES games).
WLA supports SPC700, but to say the true there is a couple of bugs in the SPC700 version, and it's annoying when you see your program has bugs not because you did an error, but because of the assembler.
You have to be especially careful with the adressing modes. Like in the 6502 version where you have to add .w all the time to specify you're using a 16-bit opcode, in the SPC 700 you have to use a ! to specify 16-bit mode I think.
Wla is a terrible assembler. It's full of bugs and unintuitive features. But, it's fully adequate for SPC-700 programming, since you just need to write your music engine, and you've got a flat 64K memory space. But the fact that you have to program a second processor just to get sound is a lot more complex than using the NES APU. It's kind of like the old BASIC home computers versus having to deal with a whole OS just to output PCM.
Well I currently use WLA, but I have to admit I'm not fully satisfacted - I'm still mostly satisfacted. I switched many times in the order X816 -> NESASM -> XorCyst (by the way is Snow Bro still alive ?) -> Wla-DX.
Do I need to do yet another switch to CC65 ? You say there is unintuitive features, but just like CC65 you need a few config files before you can compile anything. The good thing is the # of taget CPUs supported, and I only experienced bugs with the SPC700 verison, not 6502. The problem is that back then the author was responding to messages and taking request in accound, but now it seems to have kinda quited his work and there is no updates any longer, and this is a bad really bad thing.
Another problem is that it assumes it's always linking to fixed-length ROM files, not variable-lenght files that are put on a C64 disk (altough this problem isn't a problem for NES dev, it might be a problem for FDS dev).
Relocatable code is something that really lacks, I only have one small routine that I copy in RAM and modify in my NES game so I can get away with it, but if you ever wanted large chunks of code with multiple labels to be copied to RAM and modified from there, it would be a real headache to deal with WLA.
On the other hand WLA has special features that are unique like the ability to use overwrite sections, I use this to overwrite parts of CHR-ROM I don't use with other data (that I read by $2007) to save PRG space. I don't know if CC65 would support something like that. It also supports structures which is a nice plus.
In all cases it really suck when you are limited by your assembler instead of the system' capabilities.
tepples wrote:
AndiNo wrote:
Is the SNES so much more difficult to handle than the NES for example?
I can think of several reasons why people who have considered Super NES homebrew may have switched to the NES or the Game Boy Advance:
- NES is conceptually simpler, with only 30 registers total and only one assembly language that's well supported by sophisticated free tools. Getting an SPC700 mode into ca65 would help.
- Standards for art are lower on NES than on Super NES due to fewer colors and fewer layers. Super NES might hit the asset complexity wall sooner.
- For games that can benefit from Super NES style graphics, like TOD, GBA is an easier beast to tame. It has one 32-bit CPU fast enough for C and a more orthogonal register map. Moreover, copiers for homebrew have been available since half a year after release.
You could look at it the other way too. SNES could be easier to develop for in some respects compared to the NES. Less restrictions for your artists as you have more colors, more tiles, more sprites per line, much more storage, DMA transfers, huge amounts of RAM, etc.
MottZilla wrote:
tepples probably sounded like he was plugging gbadev.org when he wrote:
For games that can benefit from Super NES style graphics, like
TOD, GBA is an easier beast to tame. It has one 32-bit CPU fast enough for C and a more
orthogonal register map. Moreover, copiers for homebrew have been available since half a year after release.
You could look at it the other way too. SNES could be easier to develop for in some respects compared to the NES. Less restrictions for your artists as you have more colors, more tiles, more sprites per line, much more storage, DMA transfers, huge amounts of RAM, etc.
Everything good you said about SNES goes double for GBA.
That is one major problem with SNES development, absolutely nobody can settle on a cross assembler.
Many people use WLA-DX, which has more red tape than MASM on the x86; as well as lots of bugs.
Others use ca65, which can't target the S-SMP. I'm not sure how blargg makes his S-SMP tests.
And of course there's my cross assemblers, xkas and spcas; which nobody here is even aware of, but they're very popular in the ROM hacking circles, as well as for all of my emulator test ROMs.
tepples wrote:
Everything good you said about SNES goes double for GBA.
SNES uses a much bigger screen to display its graphics so it looks at least twice as good as the GBA
Just compare Metroid Zero Mission to Super Metroid! At least that's the reason for me to favor the SNES over the GBA. Think of the sound quality, too.
byuu wrote:
And of course there's my cross assemblers, xkas and spcas; which nobody here is even aware of, but they're very popular in the ROM hacking circles, as well as for all of my emulator test ROMs.
I know nothing about them, what makes them better than WLA which everybody seems to dislike somehow? But unfortunately it seem I can only use a modified version of WLA with the SNES SDK which I'm using. I could give it a try though...
AndiNo wrote:
SNES uses a much bigger screen to display its graphics so it looks at least twice as good as the GBA
My GameCube uses a big screen too, and I have used it to play Game Boy Advance games. GBA also has the advantage that one can put a build of a game on a flash card and take it on the bus for play testing without having to worry about emulator inaccuracy.
Quote:
Think of the sound quality, too.
That's a toss-up. Sure, GBA is limited by its 8-bit DAC, but SNES never had the space nor the CPU power for compressed music like
this.
tepples wrote:
My GameCube uses a big screen too, and I have used it to play Game Boy Advance games.
I should have put it this way: It's not the screen size but the quality and detail of the graphics. On the SNES (like Super Metroid) they could use larger sprites and still have a larger gameplay-area on the screen.
Quote:
That's a toss-up. Sure, GBA is limited by its 8-bit DAC, but SNES never had the space nor the CPU power for compressed music like
this.
I wasn't thinking of what CAN be done but of what HAS been done, comparing similar games on different systems. Listening to Super Metroids soundtrack is just a lot more pleasing than listening to the music of Metroid on GBA. Maybe I should just say that I like the SNES more then the GBA
byuu wrote:
That is one major problem with SNES development, absolutely nobody can settle on a cross assembler.
Many people use WLA-DX, which has more red tape than MASM on the x86; as well as lots of bugs.
Others use ca65, which can't target the S-SMP. I'm not sure how blargg makes his S-SMP tests.
And of course there's my cross assemblers, xkas and spcas; which nobody here is even aware of, but they're very popular in the ROM hacking circles, as well as for all of my emulator test ROMs.
I definitely agree. Infact I've used xkas when doing my BS-Zelda hacks as it was the easiest assembler to get working. The only bad thing for me is that XMSNES which I would like to use in SNES homebrew was made fort he wla-dx assembler. I haven't looked into seeing if I could build it in xkas or anything else yet.
Tepples, while I agree that GBA is even more so than the SNES in the respects that I mentioned, I will say for me personally the SNES is a much more appealing system for homebrew because it's a console and not a portable. Also the SNES is a system from when I was growing up so I hold it in higher regard than the GBA.
One other potential point is that I really wouldn't know how to manufacture my own GBA cartridges but I could do so for SNES. But it always boils down to preference. I've considered doing development on all sorts of systems, NES, SNES, GB/GBC, Genesis, PS1, even GBA at one point seemed interesting.
Looks like a nice start to a game. Be sure to let the community here know when you make more progress.
The same person that made XMSNES, eKid/mukunda, also made another audio driver that does IT files. That would be SNESMod.
More info (go to SNESMod)
http://www.youtube.com/watch?v=5P8dH64m2Cc
Here is a little update. The diagonal shooting looks weird, because I didn't make a diagonal shooting sprite animation yet.
KungFuFurby wrote:
The same person that made XMSNES, eKid/mukunda, also made another audio driver that does IT files. That would be SNESMod.
More info (go to SNESMod)
I was unaware of this. I'll have to check it out when I have some time. I was always disappointed that XMSNES didn't get properly finished.
psyco, keep up the good work. You might also want to consider saving some alpha/beta roms as your project progresses and date them. Then when the project is done you and if you share them with others can look back on the progress of your game's development which is always cool.
psycopathicteen wrote:
http://www.youtube.com/watch?v=5P8dH64m2Cc
Here is a little update. The diagonal shooting looks weird, because I didn't make a diagonal shooting sprite animation yet.
Looks very impressive, keep on going!
It looks really cool. Are you planning something for the sound in the game?
I wrote a some kind of a game (MGS-style: more cutscenes and secrets than actual gameplay ;) for the SNES some years ago. I think I can dig up the source code etc. for it and publish it here if anyone care, however, I don't have anywhere on the web to store it, most unfortunately.
dr_sloppy wrote:
I wrote a some kind of a game (MGS-style: more cutscenes and secrets than actual gameplay
for the SNES some years ago. I think I can dig up the source code etc. for it and publish it here if anyone care, however, I don't have anywhere on the web to store it, most unfortunately.
I could give you an account on the membler-industries.com server, if you want.
Imagine a game that alternates four-second snatches of gameplay with four-second unskippable cut scenes. WarioWare series has a 1:1 gameplay to cut scene ratio, but in context, it doesn't bother me.
tepples wrote:
Imagine a game that alternates four-second snatches of gameplay with four-second unskippable cut scenes. WarioWare series has a 1:1 gameplay to cut scene ratio, but in context, it doesn't bother me.
If the cutscenes are not fullscreen, both the casual gamers and the technical gamers would be pissed off. If the cutscenes are full screen the casual gamers would be pissed off but the technical gamers would be
impressed by the fact that it's running full screen video through a 2.68Mhz dma bus that is not active during active display. Once the source code is released, and everybody finds out he used a trick, the technical people no longer find it impressive.
psycopathicteen wrote:
tepples wrote:
Imagine a game that alternates four-second snatches of gameplay with four-second unskippable cut scenes. WarioWare series has a 1:1 gameplay to cut scene ratio, but in context, it doesn't bother me.
If the cutscenes are not fullscreen, both the casual gamers and the technical gamers would be pissed off. If the cutscenes are full screen the casual gamers would be pissed off but the technical gamers would be
impressed by the fact that it's running full screen video through a 2.68Mhz dma bus that is not active during active display. Once the source code is released, and everybody finds out he used a trick, the technical people no longer find it impressive.
What are you talking about???
I'm thinking about a "floor & ceiling tilting level" after the first miniboss. The visual effect would be pretty easy to do, but I'm a little afraid the collision detection would be complicated to program since I already wrote the tile collision detection routine to work with upright tile grids. But atleast it will be cool looking, and it will add some interesting gameplay mechanics that you don't usually find in released titles.
Who ever said that cool looking special effects can't make a game more fun!
Well one part of Castlevania 4 manages to rotate the room. However I think collision detection with the map may be at a minimum or totally non existent since you only can stand on a small strip of land which could just be a platform object and not part of a background map collision.
I think I figured out how to do it. Have two seperate sets of coordinates, one set will be the playfield coordinates, the other the collision coordinates. When the player sprite is in walking/standing mode his movement will be calculated with the collision coordinate and converting the updated collision coordinates to playfield coordinates. When in jumping/falling mode, his movement will be calculated via playfield coordinates, and will be converted to collision coordinates for collision detection.
Memblers wrote:
dr_sloppy wrote:
I wrote a some kind of a game (MGS-style: more cutscenes and secrets than actual gameplay
for the SNES some years ago. I think I can dig up the source code etc. for it and publish it here if anyone care, however, I don't have anywhere on the web to store it, most unfortunately.
I could give you an account on the membler-industries.com server, if you want.
Thanks!
http://membler-industries.com/dr_sloppy
Hey dr_sloppy, I'm impressed by the sound for Cute Angel(a). Some of those tunes I can actually recognize from Astrohawk 2003 Edition (Paul Lay actually assisted you with the sound according to the credits! That's nice.), but some of the other stuff are tunes that I didn't hear. Nice large soundtrack. ^_^
In first quarter 2014, this discussion continued in
Why no SNES homebrew scene?