New homebrewn SNES game released - N-Warp Daisakusen

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
New homebrewn SNES game released - N-Warp Daisakusen
by on (#37383)
I've released a tiny multiplayer beat em up for SNES earlier this week.
Took around 4 weeks to program.
You can check it out here: http://gra.dforce3000.de/ , (slightly outdated) videos can be found here http://www.youtube.com/watch?v=Yx2wFwIrces and here: http://www.youtube.com/watch?v=jp9jVMa6XR0

by on (#37385)
My god, this is for the SNES ?!? It looks like at least a playstation/NDS game.

by on (#37393)
If the SNES can do this, it can do Smash Bros.

by on (#37394)
My god man, that is awesome! That whole intro was really really cool. By the way, I read the stuff you said in the video description on YouTube; I don't think the voices are cheesy. They seem to fit in absolutely perfect : )

Great job, that really is awesome!

by on (#37398)
tepples wrote:
If the SNES can do this, it can do Smash Bros.


I've always wanted an SNES Smash Bros.! But it'd have to be where every character has the same model as they did in their game.

But anyways, yes, this is very impressive for the SNES!

by on (#37406)
Thanks for your kind comments, always appreciated. =)

I'm not exactly pushing the system to its limits with this game, but I tried to depart a bit from the usual SNES look.
In general, my engine is geared towards maximum data throughput to vram and audio ram.
I don't care one bit about ROM-size, because it's virtually unlimited nowadays.

I guess most people dislike hearing recordings of their own voice, I'm no different in that regard. ;)

As for Smash Bros on SNES:
I think the >Entertainment guys are working on a similar project.

I'd also love to work on a group project, but it would have to be something original with original characters.

by on (#37438)
Quote:
In general, my engine is geared towards maximum data throughput to vram and audio ram.
I don't care one bit about ROM-size, because it's virtually unlimited nowadays.


If you run into any issues with that, please don't hesitate to get in touch.
I'd be happy to work with you to add some special features like expanded S-DD1 / SPC7110 mapping capabilities to support >48mbit games.

In particular, I'd really like to see an animated video running on the SNES. We definitely have the bandwidth to pull it off. The trick would be to use Mode3 + a tilemap to center the image, so all the tiledata is linear. Create a palette that is RGB332 (direct color mode sucks, low bits always clear, so whites look light gray.) Then use force blank and NBA swapping to toggle where the image data goes between the top half and bottom of half of RAM. That lets you span the transfer over two frames instead of one, which obviously halves the refresh rate. NTSC video runs at 30fps usually anyway.

There's even left-over RAM for subtitles, and the active display region can be used to spool voiced audio to the S-SMP.

I imagine it'll look roughly as good as the pre-MPEG Saturn movies. But on a much older, much slower system; where it's said to be "impossible."

Example:
@ 192x144
192*144=27648 bytes/frame
262-144=118 scanlines/vblank+forceblank period
118*(1364-40)=156232 cycles/frame
156232/8=19529 bytes/frame throughput
60->30fps conversion -> 19529*2 = 39058 bytes/frame

@ 208x156
208*156=32448
262-156=106
106*1324=140344
140344/8=17543
17543*2=35086

So let's say in the former case, we need 27648*30=829kbytes/second of ROM storage. If we throw in S-DD1 or SPC7110 real-time decompression, we can drop that by ~30% or so to ~600kb or less/second. Yeah, I know it's really painful. But with a custom bank swapping mapper, I don't see a reason we can't make a 64MB proof-of-concept video.

I've wanted to do this for a while, but I don't have the audio expertise. I was hoping someone would find the SNES CD player add-on for that one "Let's Learn English"-like game. Then I could emulate redbook through it. But I've never so much as seen a picture of one, not entirely sure it even exists, though it's technically pretty trivial. Connect to expansion bus, and stream the audio through the S-DSP mixer pins ...

by on (#37446)
800 kB per second? That's near DVD-Video's maximum bitrate.

I'd wager that 112x96 at 12 fps, scaled up by 2 using mode 7, might be more reasonable. Wolfenstein got away with such a low res, and so did FaceBall (except FaceBall wasn't scaled up). Now we're down to 128 KB per second.

Is the CPU too slow for even basic motion compensation (straight copy of 8x8px blocks, no sum/diff, only whole pixel displacements)? The Sega Genesis's MC68000 CPU had the advantage here; it could run a slimmed-down version of Cinepak. But if you're serious about video, it might be a better choice to decode the video using some sort of ASIC on the cart.

by on (#37450)
I'm sure it's doable.
The small videoplayer that's used in a part of the intro of nwarp daisakusen was merely an afterthought slapped together in a couple of minutes without any optimization.
It's capable of 60fps playback (no buffering of frames) and each frame is around 7kb in size(tiles+tilemap).
That's around 400kb per second already.
I just play the video back at 30fps because i feel that's fluid enough (and manually cleaning and optimizing each frames picture to fit into the 7kb limit was painful enough. )
Sound is streamed via HDMA at 8000hz and uses around 10 scanlines of cpu time every other frame, absolutely neglectable.

If someone would code a proper and optimized video player, 30fps with 256 color frames would surely be possible as long as you leave enough forced blank at the bottom and top for vram transfers, as byuu said.

To be honest, just coding a player as a proof of concept is not something I'd like to do, but including it in a nice game would be nice. I hope I can try that some day.

Thanks for the offer regarding bankswitching emulation. I think I'd probably try to whip up my own tiny mapper in hardware first, but that would make debugging hard. At the moment, I wouldn't even know how to fill more than 64Mbits. I tried to went all out with N-warp Daisakusen, but didn't even exceed 16 megs.

I have never heard of that CD-player add-on. Do you have any details? Sounds interesting.

Also, I'd be happy to run tests on my satellaview to help improve emulation. I've posted it before, but it seems to have gone unnoticed so far.

by on (#37451)
Quote:
But if you're serious about video, it might be a better choice to decode the video using some sort of ASIC on the cart.


A real cart would pretty much have to exist first. It'd be so lame to add something to an emulator that doesn't exist in real life. I'm not sure why it stops bothering me with only a few protos, but yeah.

Quote:
It's capable of 60fps playback (no buffering of frames) and each frame is around 7kb in size(tiles+tilemap).
That's around 400kb per second already.


Yeah, problem is it's not "true" video, you have to do it all with sprites and such. Much more difficult, and less flexible. But it's really the only sane way to do it on the SNES ...

Quote:
I have never heard of that CD-player add-on. Do you have any details? Sounds interesting.


Unfortunately not. Nach is the one who told me about it, but he doesn't have any real info, either. For all I know, it doesn't even exist :/

It would be fairly easy to make, though. Just need to interface with the expansion bus somehow.

Quote:
Also, I'd be happy to run tests on my satellaview to help improve emulation. I've posted it before, but it seems to have gone unnoticed so far.


Ah, I appreciate the offer, but remote testing is just way too difficult. I usually run hundreds of tests in rapid succession to figure things out.

FitzRoy recently bought a BS-X unit that he offered to let me borrow, and another person offered me one via PM, but I haven't heard back from him just yet. Probably would help if I responded to PMs and e-mails faster, myself.

But yeah, hopefully I should be covered. I definitely wouldn't mind some RE help, though :D
Have your notes cached for when I start on it. Didn't mean to ignore them, sorry.

by on (#37454)
This is very impressive. Given enough ROM space, I bet d4s could port Final Fantasy 7 to the SNES :)

by on (#37486)
d4s wrote:
I have never heard of that CD-player add-on. Do you have any details? Sounds interesting.


Probably referring to the infamous official SNES CD-ROM. Which I'm sure you've heard about at least one time on AG?

by on (#37489)
Quote:
The Sega Genesis's MC68000 CPU had the advantage here; it could run a slimmed-down version of Cinepak.


I'm pretty sure the 12.5mhz second 68000 in the SegaCD was taking care of the cinepak decoding. The SegaCD doesn't require the second CPU to poll the MCU of the CD unit, so it's free to do other tasks. Not to mention the SegaCD's ASIC chip could convert bitmap images to tiles extremely fast.


Can't you increase the DMA total bandwidth in vblank by turning off the display early? If so, clipping to 192 vertical res would almost double the transfer rate.


I still want to interface my Super CDROM2 CD addon unit for PCE, to the SNES at some point. I don't know much about the BUS for the external port on the bottom but if it's really only 256bytes, then that's more than enough to map the CD registers. Converting the PCE's system card routines should be doable. Is there an interrupt line available on the external BUS (B-BUS?)?

by on (#37521)
The bottom port on the snes, maps into the same address bus B region, 0x2100-0x21FF, however, you can not use 0x2100-0x213F, as that is used by the PPU, and you can not use 0x2140-0x217F, as this is used by the APU. (IIRC)

I might be incorrect on which range the PPU is using, but you do have to respect these ranges, and not attempt to use them yourself for any other purpose. If 128 bytes is not enough, then you will have to make an interface chip, and come up with some register addressing scheme through that chip.

by on (#37522)
Even 16 bytes of address space would be enough for, say, an ATA interface to a CF card or a CD-ROM drive.

by on (#37524)
But then you really need somewhere to load that data into. I don't think the built in 128K of RAM + 64k of VRAM would be enough. You'll need your BIOS and some RAM in a cartridge sitting on the A-Bus to make anything interesting. Though the neat thing about this idea would have been that the CD-ROM add-on could have been pretty much just the drive itself, and then the System Cartridge could be upgraded seperately at a later date. So they could have done what PCE did and started out with a basic CD-ROM system but then later upgraded it by having a system cart with more RAM and then later even put in a coprocessor like Super FX or SA-1.

It would have been sweet though CD-ROM technology (for video gaming) just cost too much back then I think. It would still be neat if someone would design and produce their own SNES CD-ROM. The idea to adapt the PCE CD-ROM is very cool.

by on (#37531)
dXtr wrote:
d4s wrote:
I have never heard of that CD-player add-on. Do you have any details? Sounds interesting.


Probably referring to the infamous official SNES CD-ROM. Which I'm sure you've heard about at least one time on AG?


No, I wasn't referring to the Phillips or Sony CD-ROM add-ons. This was for a language tutor thing, from what I recall. Again, it might not even exist.

by on (#37533)
byuu wrote:
No, I wasn't referring to the Phillips or Sony CD-ROM add-ons. This was for a language tutor thing, from what I recall. Again, it might not even exist.


Ok. sounds interesting.

by on (#37534)
Quote:
It would still be neat if someone would design and produce their own SNES CD-ROM. The idea to adapt the PCE CD-ROM is very cool.


Yeah, the basic idea is that I don't want to emulate a fantasy device. But if someone can make real, tangible units, I'd be happy to try and emulate the devices. Would make for some great new homebrew, and redbook upgrades to existing games and such. Much easier to modify a few S-SMP BGM playback commands than it is to re-write a game for the PC.

by on (#37535)
caitsith2 wrote:
If 128 bytes is not enough, then you will have to make an interface chip, and come up with some register addressing scheme through that chip.


I think are about 8-12 memory mapped read/write ports total on the CD base system, so that wouldn't be problem.

Quote:
But then you really need somewhere to load that data into. I don't think the built in 128K of RAM + 64k of VRAM would be enough. You'll need your BIOS and some RAM in a cartridge sitting on the A-Bus to make anything interesting. Though the neat thing about this idea would have been that the CD-ROM add-on could have been pretty much just the drive itself, and then the System Cartridge could be upgraded seperately at a later date. So they could have done what PCE did and started out with a basic CD-ROM system but then later upgraded it by having a system cart with more RAM and then later even put in a coprocessor like Super FX or SA-1.


Yeah. The CD base has 64k system ram built in but it would be futile to try and interface it with the SNES. Modifying only key bios subroutines for 65816 and the different mapped port locations and place it on a cart/rom. The cart would need system ram as well (4-8megabits would be decent).

It wouldn't give the SNES a lot in terms of upgrades(CDDA playback, ADPCM play unit + 64k internal ADPCM sample ram/buffer, huge storage), but the cool factor would be there ;) I love those old (video game anime) style cinemas with CD audio/voice acting.

Also, did the on cart coprocessors have direct access the B-BUS without effecting/interfering the sCPU?

by on (#37538)
If you don't mind a lack of random in RAM, you could always use address registers, ala $2180. Set the address in $2181-3 and read/write to the auto-incrementing $2180 register.

Quote:
Also, did the on cart coprocessors have direct access the B-BUS without effecting/interfering the sCPU?


The cartridge port has the B-bus on it, yes. But you need a PCB with the extra four pins on each side.

http://www.romhacking.net/docs/[195]ports.txt
/PA0-7 + /PARD + /PAWR.

Note that D0-7 appear to be shared. So I doubt you could bypass the S-CPU and have the expansion port device and cart talk to each other directly, unless you like bus conflicts.

And yes, as you can see, both the cart and expansion ports have IRQ lines.

by on (#37539)
Quote:
Note that D0-7 appear to be shared. So I doubt you could bypass the S-CPU and have the expansion port device and cart talk to each other directly, unless you like bus conflicts.


Oh man, there's no /RDY line on the cart port :( That would have been nice to have been able to pause the sCPU and drive the address and data bus. Assuming the sCPU is buffered against another device driving the bus like the stock 65816 was supposed to be - iirc.

At least there's an irq line on the external port (needed for ADPCM streaming and/or subchannel reads).

by on (#37619)
Okay, I dug through some two-year-old threads to find this info again ...

http://www.famicom.biz/all/htmls/4988615006203.html
http://www.proc.org.tohoku.ac.jp/~hoshi/voicer/

It's not a CD-ROM add-on. It's an IR controller that sends commands to, I'm guessing, certain CD-player models, to select the desired tracks. It may be as tacky as just sending "next track" commands and expecting you to line the thing up yourself.

Pretty lame :(

EDIT: actually ... that gives me a good idea. The expansion port is a bitch to use, because of the custom connector. But the controller ports are quite easy. Splice an existing controller and use the wires.

Eg blargg's serial controller device. It would seem to be a lot easier to develop a physical CD-playing mechanism that you talk to through controller port 2 than through the expansion port.

Then just couple the audio+stereo out from both the SNES and CD-player with a cheap Radio Shack adapter.

In fact, I see no reason I couldn't rig up a PC program to simulate such a device now.

by on (#37719)
Oh, wait! I'm involved in Smash Bros for the SNES... and if I remember correctly, we recently ditched using the Nintendo characters out of copywrite concerns. :( The game is actually called SNES All-Stars at >Entertainment.

I'm also involved in an RPG for the SNES, and for both I'm making the music.

by on (#37720)
Jagasian wrote:
This is very impressive. Given enough ROM space, I bet d4s could port Final Fantasy 7 to the SNES :)


Oh boy... I would be really suprised.

by on (#37755)
Quote:
This is very impressive. Given enough ROM space, I bet d4s could port Final Fantasy 7 to the SNES Smile

This sure would be cool ! But Fianl Fantasy 7's music uses up to 16 music tracks and the SNES only have 8, so it would have to be scaled down to only 8 tracks.
Also, I doubt you'd want to store it streamed because there is like 80 tracks, and it takes 4 whole audio CDs (okay most tracks loops 2 times so it would take the equivalent of 2 CDs at best). This is 1400 MB.

I don't know how he managed to get 3D graphics on the SNES, so I'll be quiet about this point. The 3D found in FF7 isn't very compley either, it's mostly 3D characters with very few polygons (Clad is about 20 geomertical forms) pasted on a pre-rendered bitmap. The world map and minigames are in real-3D tough.

by on (#37756)
Bregalad wrote:
But Fianl Fantasy 7's music uses up to 16 music tracks and the SNES only have 8, so it would have to be scaled down to only 8 tracks.

But would that be much of a problem?

Quote:
Also, I doubt you'd want to store it streamed because there is like 80 tracks, and it takes 4 whole audio CDs (okay most tracks loops 2 times so it would take the equivalent of 2 CDs at best).

But would the "bells, frogs, bing cherries, jingle bells, ham and cheese, SEPHIROTH!" fit in the SPC's RAM? How did Clay Fighter and the like do it?

Quote:
The 3D found in FF7 isn't very compley either, it's mostly 3D characters with very few polygons (Clad is about 20 geomertical forms) pasted on a pre-rendered bitmap. The world map and minigames are in real-3D tough.

Some of those could be downgraded to FF4/FF6 standards without too much impact, I'm guessing.

by on (#37759)
tepples wrote:
But would the "bells, frogs, bing cherries, jingle bells, ham and cheese, SEPHIROTH!" fit in the SPC's RAM? How did Clay Fighter and the like do it?

Well the real lyrics are in Latin. The longest sample in FF7 is the "veni-veni-venias vene-noe frachias" one and takes arround 200kb recored with 16-bit PCM.
It takes 9/16 of that size to place it into the SPC's RAM, that is 112kb. So no it doesn't fit, but it would if resampled. I've made a NROM NES cart that play those samples (that fits in 32kb by using your compression algorithm).

All 6 voices samples used for one-winged angel takes 850kb in 16-bit PCM alltogether, that makes arround 480kb BRR encoded. Their sample rate would have to be divided by 8 (3 octaves lower) to store all of them in SPC's ram, resuling in very poor quality.

Quote:
Some of those could be downgraded to FF4/FF6 standards without too much impact, I'm guessing.

Sure, but that's not what he was talking about I guess.

by on (#37762)
That's where sample streaming comes in. :D ClayFighter did just that. I think the vocals for the One Winged Angel track should be streamed as well if that were to happen...

by on (#37776)
I don't think I'd ever want to port FF7 to the SNES.
Would be a nice feat, but not worth the tremendous effort imho.
I guess just about everything can be downgraded if you're willing to make compromises.


N-Warp Daisakusen doesn't render graphics in realtime 3d, btw.
That's just a pre-rendered video in the intro.
Hence the earlier discussion about video playback on the SNES.

by on (#37777)
Bregalad wrote:
Well the real lyrics are in Latin.

Yes, Bells frogs is in Latin, and Morphine makes the holy known is in Finnish, and Dew isn't a German commercial for soda.

Quote:
The longest sample in FF7 is the "veni-veni-venias vene-noe frachias" one and takes arround 200kb recored with 16-bit PCM.

At what sample rate? I seem to remember that sample is about four seconds long, which would put it at 22 kHz, right? Big Bird's Hide and Speak got away with 8 kHz.

Stigma against double posting makes this topic hard to split.

by on (#37838)
It's still very impressive to see a pre-rendered 3D video on the SNES. This explain why this were possible. Just like the intro in the GBA's Kindom Hearts : Chain of Memories. I remember I was stunned when a friend showed me that video, I was sure the GBA weren't capable of 3D graphics before seeing that.

Yes the voices samples in FF7 were originally meant to be played at 22050 Hz (half of the PlayStaion's DSP sampling rate).

by on (#37840)
Bregalad wrote:
It's still very impressive to see a pre-rendered 3D video on the SNES. This explain why this were possible. Just like the intro in the GBA's Kindom Hearts : Chain of Memories. I remember I was stunned when a friend showed me that video, I was sure the GBA weren't capable of 3D graphics before seeing that.

KH uses the same codec as the Game Boy Advance Video carts. It's compressed: 45 minutes in 32 MB, or about 12 kilobytes per second including audio and 12 fps video.

by on (#37847)
Quote:
KH uses the same codec as the Game Boy Advance Video carts. It's compressed: 45 minutes in 32 MB, or about 12 kilobytes per second including audio and 12 fps video.


Damn, 45 minutes ... I'm so jealous of the GBA's processing power. Damn Nintendo for being so cheap with the S-CPU! We probably couldn't handle LZSS decompression at 12 frames per second.

12fps is pretty lousy, though. It must look like a slideshow at that rate.

by on (#37848)
byuu wrote:
12fps is pretty lousy, though. It must look like a slideshow at that rate.

Plenty of animated series shown on Nickelodeon and Cartoon Network are drawn at 12fps. Do they look like slideshows?

by on (#37853)
tepples wrote:
Plenty of animated series shown on Nickelodeon and Cartoon Network are drawn at 12fps. Do they look like slideshows?


They may be drawn at 12 fps but they are frame duplicated to 24 fps and telecined to 30 fps before broadcast.

by on (#37859)
shadowkn55 wrote:
They may be drawn at 12 fps but they are frame duplicated to 24 fps and telecined to 30 fps before broadcast.

Likewise, each frame of a Game Boy Video is shown five times on the GBA's 60 Hz display.

by on (#37860)
Quote:
Plenty of animated series shown on Nickelodeon and Cartoon Network are drawn at 12fps. Do they look like slideshows?


Honestly? Yes ... yes they do :/
Especially Adult Swim shows. But a lot of the new animation does. Not just the US stuff, either -- .hack//SLIDE, for instance.

Neat to know it really is only 12fps, though. But yeah I see your point, you do have quite a bit more tolerance in animation than in say, live action fighting, for instance.

by on (#38215)
If the stock Genesis can handle FMV - then the SNES can with some cheap tricks!

What about using the S-FX1 (MarioChip) to perform the grunt work for us and move the decompressed data to the tile ram?

Also; Its probably not THAT hard to build a PIO IDE Connector (Running in 16-bit no less) controller (something that sites between the cartridge and motherboard -- like a Game Genie; but with hardware registers that can control the CDROM)

Of Course you could just stick a powerful little ARM chip in there and just bit-bang all the video hardware while the CPU sleeps... ;)

by on (#38243)
PDP-13 wrote:
Of Course you could just stick a powerful little ARM chip in there and just bit-bang all the video hardware while the CPU sleeps... ;)

That would be Super Game Boy Advance. That would be cheating.

by on (#38271)
Quote:
Of Course you could just stick a powerful little ARM chip in there and just bit-bang all the video hardware while the CPU sleeps...


I'm curious how you're going to drive the same address/data bus that the sCPU is attached to without physically burning it out? Is sCPU address/data driver buffered?

by on (#38307)
tomaitheous wrote:
Quote:
Of Course you could just stick a powerful little ARM chip in there and just bit-bang all the video hardware while the CPU sleeps...

I'm curious how you're going to drive the same address/data bus that the sCPU is attached to without physically burning it out?

The ARM core would decode to an internal work RAM, and then the memory controller could field requests from the DMA unit. Look at any of the other coprocessors, such as the Super FX, SA-1, and SPC7110.

by on (#38447)
Out of curiosity, how much is the VDP, em, PPU data bandwidth in SNES anyway ? Doing FMV should not be any too serious task... unless compression is involved. I could do display around 10x 320x240 4bit BMP files per second on MD ( http://www.hot.ee/tmeeco/DWNLOADS/CAR.RAR ) without using DMA in 50Hz, in 60Hz the rate drops a little... Using DMA and tilemaps instead of bitmaps would yeld in a higher rate aswell. I've heard SNES has quite fast DMA... ?

by on (#38929)
TmEE wrote:
Out of curiosity, how much is the VDP, em, PPU data bandwidth in SNES anyway ? Doing FMV should not be any too serious task... unless compression is involved. I could do display around 10x 320x240 4bit BMP files per second on MD ( http://www.hot.ee/tmeeco/DWNLOADS/CAR.RAR ) without using DMA in 50Hz, in 60Hz the rate drops a little... Using DMA and tilemaps instead of bitmaps would yeld in a higher rate aswell. I've heard SNES has quite fast DMA... ?


I can not give exact figures, but it should certainly be doable with 30fps, letterbox format or both.

On an unrelated sidenote, I've finally made it to Kotaku and many of the major gaming newspages with N-Warp Daisakusen, which in turn sparked the interest of various german print magazines. A couple of articles are in the works, people are constantly asking for interviews, I'm loving it!

It's obvious that the game has a very hard time on newspages like Kotaku, getting more or less directly compared to the recent big commercial games of today, but as the saying goes, "any publicity is good publicity". ;)

Like I said on http://gra.dforce3000.de, my primary concern is making people aware of the fact that SNES homebrew isn't dead yet.
I'm looking forward to what the future holds.