New SNES game in development: Furry RPG (working title)

Hi,

I just thought I'd let you guys know what I've been working on during the last couple of months.















Being a personal project, the game will feature an epic storyline (worthy of a 21st century SNES RPG), a cutting-edge battle system (I hope), spectacular graphics, and (of course) 100% Furry characters.

Download the current pre-alpha/tech demo build:
http://manuloewe.de/snestuff/projects/furryrpg_build_00197.7z

Have fun with the demo!
Ramsis

P.S. If you happen to be a pixel artist with some experience doing Furry characters and feel like contributing to the project, please don't hesitate to contact me.

This is magnificient! I especially love the dialogs, very well done I'm looking forward for more!

I've been following this project on the SNESFreaks forums. My main motivation to follow the game is to follow the trail of custom music that gets produced (I like listening to new SNES music, and this is the first SNESGSS game that I've seen... not counting games made by Shiru).

Your method of banking the music reminds me of other SNES games that had copies of its sound drivers with some modifications hanging around on the SNES. I cite Cool World and Street Hockey '95, as both had multiple sound drivers in there on a technicality (Cool World had a copy reserved for playing the Title Screen music, while Street Hockey '95 had one for the staff roll).

I have an idea to cut down on memory consumption caused by having duplicate copies of the sound driver. Simply have one copy of the sound driver in the ROM, then have copies of a series of three pointers (six bytes total) corresponding to your music that will be loaded at $208 in SPC700 RAM. When you switch banks, you'll only have six bytes plus the filesize of whatever music you're using to load. The code to load data is defined in a way that makes this real easy.

You can up the memory savings further if you kept track of what samples were used in what pieces of music (the ADSR table can be grouped with your song data) and then put the samples in their own section of the ROM to be plucked individually.

Ooh, excellent work! You had me at the title, lol. I'll be looking forward to this and following your progress closely!

I tried it on my 1/1/1 Super NES with a PowerPak, and you appear to be off to a good start. So let's polish what I see here. About the hi-res text box:

• I'm not entirely fond of the use of colored hires text because it can be hard to read on composite. I noticed the same problem in "Demo world map". I haven't tried it in NO$SNS yet to see how VRAM is laid out, but I wonder if VWF techniques combined with hi-res can help improve readability.
• DOMINIC isn't supposed to represent the hot glue sculptor we know as Drakon, is he?
• Does the FENNEC PUPPET become a FENNEC REAL, um, KIT later on?
• What kind of cultural process produces names like Gregory Perpetuus Ebenezer Hrabanus Eindhoven Dubois Quaoar van der Muhlhausen Nido sulle Colline Jr.? A name that long might result from a patronymic chain, as seen formerly in Wales and among the gnomes of Dragonlance, but how else?

Some blinking dots in the H-IRQ test. It only happens on some resets though.

I have a couple suggestions for the mode 7 map:

• Try drawing that map with interlace turned on. On "odd" frames, draw at distances halfway between the distance you're using for each scanline. This should reduce some of the shimmer in far areas.
• For things that are suposed to stick out of the ground, such as that tower, try using software-shrunk sprites. I've posted a demo of this technique in the NES section.

The music:

• 02 crashed.
• 03, 04: With a slow-attacking strings sample like that, it might be better to alternate melody notes between two hardware channels so that one is releasing a note while the other is attacking. This avoids the cheap-sounding instant releases that plagued strings in a lot of Super NES RPG music.

When I saw the still of the sprite animation test, I imagined a 6- or 8-frame jog, but when I tried it, I got a typical RPG Maker 1232 walk. Would smoother walking be hard? I wonder if you could use Star Fox Adventures as a rough model for the angles and such.


EDIT: I have screenshots of the red text.

Not sure why song 02 crashed on Tepples, it plays fine on my SNES (with an SD2SNES) (and I don't know what 1/1/1 means). Agree with what was said about the red text and the walking animation. Dunno what's up with the bits of junk on the H-IRQ screen test, it happened to me the first time and now I can't reproduce it.

Other than that, I am extremely impressed and I'm eagerly waiting to see more!

CPU revision ($4120), PPU1 revision, PPU2 revision ($213e, $213f).
1/1/1 and 2/1/3 are both quite widespread; the former has a few bugs. (Including, but not limited to, something DMA, but I can't find a good list of other changes.)

Oh, cool, thanks for that. Mine is apparently 2/1/3!

Out of curiosity, do you know what emulators use? Also, how is it that you can have a PPU2 reversion 3 when, to my knowledge, there was never even a 2?

I'm looking at this program using SNES9X 1.53 trying to determine what went wrong on song 2. Loading is not the problem here.

I'm not sure what's going on, but for whatever reason the game has a chance of freezing when sending command ID 04 (which I believe sets up the volume) or command ID 06 (which plays the music), presumably because the SPC700 fails to output a zero or the SNES barely misses the signal and the SPC700 goes to a non-zero value and never goes back (or it has to do with values accidentally being ORed between the SPC700 and the SNES). Not sure why it only happens with song 2 (loading is at least successful, given that it's the largest song you have).

I like the hires graphics.

Really? I find that they clash with the rest of the game.

Admitingly, I originally thought that the portrait was added onto the picture, until I saw it on the TV screen.

Wow, thanks for all the input and feedback, guys.


Very cool, this definitely sounds like it's worth a try, as does your idea with leaving samples in audio RAM, even if only to speed up song loading.

BTW KungFuFurby, do you happen to know how to add panning information in SNESGSS? As it seems, the software ignores panning data in MIDI files for whatever reason. And I couldn't figure out how to do it when editing the song.

About the song crashing issue, I've been aware that all emulators (including higan-accuracy) tend to freeze after repeatedly loading any of the three songs, but I never encountered any issues on real hardware so far. Will have to look into the matter some more. As SNESGSS is very poorly documented, I had a hard time figuring out how to proceed when loading a (new) song at all.

Here's how I'm currently doing it – not sure if this is 100% correct (with an initialization of the SPC700 done earlier, of course):




You're right, the red-colored font doesn't look great on real hardware, even when using RGB. The issue is especially apparent on non-1CHIP consoles. I'll experiment with the tone, maybe that'll be enough to improve readability.


Huh? Even though I'm not quite sure I understand the question, the answer is probably no.



I can't find any spoiler tags, so I can't tell you here and now. (Look here for my notes on playable characters, which – spoiler alert! – will answer your questions. )


The fancy H-IRQ stuff is indeed a bit unstable. I've thought about scrapping it altogether, or patch up the area where flickering typically occurs with some sort of sprite-based window decoration. In any case, the final design of the main menu is yet another thing to work on.


Thanks! Will give that a shot once I find the time (and am done figuring out how to do smooth Mode 7 rotation, and a flexible way to zoom in and out).


Thanks, but pretty much all the graphics in the current build is placeholder artwork (in case of the Mode 7 map, it's ripped from Illusion of Gaia's intro). I envision the Mode 7 landscape to be drawn from a seemingly much higher distance, where no tall objects penetrate the atmosphere (think Secret of Mana).


What you see in the current build is my very first attempt of a sprite animation algorithm. Indeed I plan to do a 6- or 8-frame animation at some point. VRAM space for sprites is very limited though, so I'll have to find a way to reload character data at will (maybe DMA the required section of the spritesheet into VRAM during Vblank whenever the player changes the walking direction or something …).

Another reason for the current 3-frame walking animation is that I couldn't find any usable Furry character spritesheet except for Gengen's, from Suikoden II.

(Star Fox Adventures? Isn't that a 3D game? )


Yes, there was a version 2 PPU2.

Here are the currently known SNES chipset revisions (likely complete):

v1/1/1
v2/1/1
v2/1/2
v2/1/3

I have at least one console of each chipset revision in my possession, so …

Thanks again, y'all!

Ramsis

According to http://superfamicom.org/console-serial-database, there's also a 0/0/0.
Sorry to get off topic.

Oh, by the way, I fixed up your profile pic to get rid of the white lining because it was freaking me out! (I have OCD.) Sometimes, Photoshop just doesn't "cut" it. (see what I did there? )

Thanks, Espozo. Not meaning to be Mr. Know-it-all, but I'm not using Photoshop but The GIMP for graphics editing. And believe me, 0/0/0 chipset SNES consoles don't exist – apart from perhaps as an awkward consequence of a poorly done MySQL implementation.

I looked up the code for the sound driver. Panning is not supported in an actual music file as a command. That’s why it got ignored during conversion. Panning, according to the sound driver, is only ever used in sound effects, and it is mono everywhere else. Yeah...

Drakon (real name Dominic █████) is known for AV mods and cart reproductions with poor soldering and lots of slathering wires in hot glue to make up for it. There was recent talk in #nesdev on EFnet about making a game parodying his penchant for using hot glue. Google drakon hot glue and become warned about this joke of a modder.



Assuming you don't mean these (photo by Ferenghi)


I'll go look for background there.


Or better yet, actual "window" decoration.


You can still use 3D models for 2D sprites. It's how Donkey Kong Country and Mario vs. Donkey Kong were made.


EDIT (2018-04-18): Wikimedia Commons moved Ferenghi's photo to a different filename, and hotlinks do not redirect.

Goodbye then, SNESGSS. It's too bad, but a mono soundtrack is in no way acceptable in my opinion. Looks like I'll have to go MSU1 for the music after all, as I had planned at an earlier stage anyway.

That seems a trifle abrupt.

I believe the current implementation of MSU-1 on the sd2snes doesn't allow saving, though... I could be wrong, but I'm pretty sure I read that not too long ago.

Be careful with the MSU1! It's really expensive when it comes to memory (you're essentially using raw WAV data for audio, meaning those files can end up in the hundreds of megabytes when combined).

It disables auto-saving. Saving still works but you must do whatever it is to manually make it save.

You could just write your own music engine. It can't be that hard because the SPC700 is largely a 65C02 clone with a rearranged instruction decode table. Is the SNESGSS source code available? Had you planned on setting pan for each instrument (more realistic for orchestral-type soundtracks) or for each note?

Mono sound really isn't that bad anyway. Most Neo Geo boards only outputted mono audio, if I'm right. (Only a handful of the single slot ones didn't.)

The SNESGSS source code can be found here: https://code.google.com/p/snesgss/

You could in theory add extra features (panning's the big one, but perhaps modifying the ADSR in real-time if needed so that the note doesn't just cut?). However, I would do so at the cost of the maximum range for the short delay command, not the note range.

Be careful, though: panning can conflict with the SFX.

I was interested in modifying SNESGSS myself to add a loop counter to the reference feature. I felt that this would add some RLE-style compression for when references are used more than once in a row. However, I am developing my own sound driver instead (it's going to take a while for me to make it... could be a few years, so no guarantees).

I haven't looked, but I don't see how it would have much of a "cost" if each instrument has a constant pan amount.


Illustration by Darkdoc of the layout of an orchestra

This means you can set a pan position for each instrument when it is played.

• Piano hard left
• First violins, french horns, cornets, timpani, and triangle medium left
• Second violins, piccolo, flutes, clarinets, and xylophone barely left
• Violas, oboes, bassoons, trombones, cor anglais, and bass drum barely right
• Cellos, trombones, contrabassoon, snare drum, and cymbals medium right
• Double bass, contrebasses, and organ hard right

I don't see how, as the pan would be written only at the start of a note.

Wow, that's a weird orchestra layout. English horn and contra bassoon usually goes together with the other woodwinds. Also, contrabass is the same thing as double bass. WTF?

The panning I was thinking of was going to be as one of the effect commands (in the same league as volume, detune, slide up/down, etc.) so that it didn't have to stick for the entire song.

[*snort*] ...yeah, if that's a real pipe organ, it's going to be all over the sound field, with each pipe in each stop having a different position, not necessarily in chromatic order. And that's before reverb is taken into account. The position of the console is totally unrelated to the position of the sound source, which is generally more or less L/R symmetric...

I suppose a portable continuo unit or a Hammond or something like that could potentially have a definable position that small... but if it's an electric organ with a rotary speaker, it's going to be flinging its sound all over the hall anyway (see "reverb")...

...I'm used to much more extensive resources than the Super NES audio module provides...

At least SNESGSS let's you add arbitrary volume changes and pretty transparently adjust samples, and portamento. I've been thinking about making my own SNES tools but I'm not much of a programmer (they'd be made in Processing, which is built on top of Java at this point, and then I'd probably port them to other platforms).

I've been trying to use Schism Tracker as well and then converting with snesmodlite, but the results are a little unpredictable (ie how samples get converted), not horrible, but unpredictable. I feel like Schism Tracker is a bit better suited for production (does SNESGSS actually have the ability to edit multiple patterns?)

I'm hoping elix put out their tracker maybe at some point: https://www.youtube.com/watch?v=l-VfFzOQRDk

or bazz does more work on his


That being said I quite like the demos, my only advice is that the walking furry character seems a bit asymetrical (ie like he is limping). What do you make your graphics with?

I haven't had many unexpected results using SNESMod. I have had issues with bass guitar samples under certain circumstances. In one song, the sample would be perfect and in another song it would be weird sounding at the beginning, maybe sort of crunchy and/or clicky. This was a long time ago, so I don't remember what steps I went through to fix it.

Other than that everything has always come out as expected.

the issue I had was with a snare sample that kind of trailed off, it got a little bit shorter and more "clamped down" in the final .spc file.

I also tried to pitch shift a sample up too far (I think 4 or 5 octaves I forget what the limits on the SNES are as I type this), and it just wasn't playing back.

Conversely, SNESGSS is pretty great/accurate as far as sound reproduction.

Hi!

About the panning, I think it would be sufficient to be able to set pan on a per-instrument/per-channel basis, although a melody "meandering" from one speaker to the other (think The Prelude from the three Final Fantasy installments on the SNES) would be nice to have, too.

Altering SNESGSS myself is out of the question though, as is writing my own SPC700 sound engine (at the current time, at least). So my best bet is to concentrate on what I can do best, and use the available means to deliver it to the audience.

BTW, game size isn't really an issue nowadays, is it? So I'm not afraid of huge amounts of PCM data at all. The only thing that matters to me is that it sounds the way I want.


Thanks! As I said, all the graphics is placeholder artwork as I'm completely hopeless when it comes to drawing. The animated character in the current build is Gengen from Suikoden II, pretty much the only Furry character with a spritesheet suitable for this project out there on the web. I didn't reduce the number of frames, nor did I mess with the graphics itself. So if he's limping, it's not my fault.

My main concern with game sizes comes with distributing the game. It can be harder to distribute a game that ends up at a few hundred megabytes than it is to distribute a game that's 8 megabytes (mainly on file hosting concerns and bandwidth if the game gets frequently downloaded).

Well, SNESGSS still makes a good sound effect system.

It is if you want to distribute copies to the public in cartridge form, or if you want the game to run on an emulator that doesn't support MSU-1 (such as emulators for old PCs or mobile devices).

Ehh... I'd rather people have their "dream game" then have to have it watered down just to fit on a pre existing SNES cart. (Like every arcade port ever.) There are always things that you can do to take up less space like compressing the graphics, but to be honest, if I ever make something, I probably won't even bother. It is always possible to make a custom cart for your game, but this is only really theoretical.

I am in error in my research... I was using my local copy to look up the code, not the online copy.
Turns out SNESGSS added panning on December 26th, 2014, and I should download the new version.

I'm still interested myself, even if I'm going to manually make the music files myself.

This is excellent news indeed. I hadn’t checked the SNESGSS code site since mid-December, so I missed the update. Thank you so much, KungFuFurby!

Oh thank God Ramsis! You finally fixed your profile picture! (I'm really crazy...)

Theoretical??? That sure is an opinion..

Well I don't think you'd have a problem.

daww thanks m8

Ramsis I love your demo dude! Nice work!

Thanks, bazz!


Hey, KungFuFurby, does panning work correctly for you? I was going to put up another build tonight featuring stereo music. Within the SNESGSS application, it works great, as it does with a directly exported SPC file. But once I export the SPC/music data and use it in my project, it's still mono.

Also, I couldn't get the SNESGSS sound driver to remain in SPC700 RAM while simply loading new music data, as all my tries resulted in garbage audio. Can you please elaborate on how this should be done?

Thanks,
Ramsis

You need to issue a command to the SNESGSS sound driver to make it play sound in stereo (the sound is mono by default). The command ID according to the source code is 03, and you need to send it a parameter of 01 to make it stereo.

Feel free to use the old method for now for this build (as in, having copies of sound drivers per piece of music) if you're having trouble.

To initialize the sound driver (I'm using the pointer 0xC80000 for this, as this is your blank copy of a sound driver but no music/SFX in build 197), you would do the same thing as you did previously: get the filesize (which is the first two bytes of your file) and then get the pointer to the sound driver code, and then call the load routine.

For loading a new music pack (samples and all)...

First, you would take your compiled SNESGSS sample and code file (which defaults to spc700.bin according to official documentation), and (omitting the filesize, which is 2 bytes and may or may not be embedded in spc700.bin) skip the first 8 bytes of this file (as in, do not include), and only include six bytes. Put in a filesize of 6 bytes for this fragment, and when you call the load routine, send it to SPC700 memory location $0208 (These are the three pointers to the ADSR table, SFX and music).

Include the same spc700.bin file again, but this time skip the entire filesize of the sound driver (which, in decimal form, amounts to 2340 bytes). This is your sample pack with pointers and ADSR table (this is the basic version: we'll sort samples later). When you call the load routine, send this to SPC700 memory location $0B24.

Last, but not least, include your music file, and assign this a memory location of ($200 + filesize of sound driver + filesize of sample pack).

Thank you for your valuable input, KungFuFurby, I got it all to work – stereo sound, only one copy of the sound driver in ROM, and no more random freezes when loading a song.



Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00198.7z

BTW KungFuFurby, is there any "recommended" way for loading and playing a song? Because I noticed that unless I issue another SCMD_INITIALIZE to the sound driver after feeding new data to it, it won't play the song correctly (if at all).

Here's how I'm doing it in this build (in pseudo code):



BTW, to track down what caused the freezing in the previous builds, I traced the song loading using Geiger's debugger and noticed that an NMI occurred during a - lda $2140 | beq - loop. Turns out that NMI and IRQ were not disabled in the spc_command_asm subroutine (but only in spc_load_data). So thankfully, this was an easy fix.

That initialize command is required each time you change the pointer to either the ADSR table or the SFX (you currently don't use SFX). Otherwise, the main thing that seems to be going wrong in your playback is related to wrong ADSR envelopes. Since changing sample packs changes the ADSR and SFX pointers, that's a required command.

The initialize command messes with the stereo option by zeroing it out, thus also making the Stereo command required. If there's an option to make the sound mono, you can take advantage of this situation by simply checking for stereo being activated in the game and simply not use this command if the sound is set to mono.

If you use matching sample packs (and ADSR/SFX tables, too), then both commands are not required when switching songs (Stereo only needs to be called once in this case, since that's when the entire code is loaded in the first place).

Either that, or instead of sending those three pointers to $0208 and then calling those two commands above, you can instead send two of them to direct page using the load command. This takes three loading commands instead of one (since now they're two bytes each and not bunched up together), and you have to send the pointers to $0004 (ADSR table pointer), $0014 (SFX pointer), and $020C. The last one is $020C because the play music command automatically reads from that memory location instead of direct page (and sending it to its direct page location will mean it gets overwritten anyways).

Be careful, though: you'll still have to load the same set to $0208 if you ever have to call the initialize command again.

The flute in song 05 is hitting a lot of wrong notes. Given the name "buskers", is it supposed to represent an in-game inexperienced musician?

Hey, KungFuFurby, thanks! Now that I got it working though (and my song loading routine seems complete), I think I'll stick with sending the pointers to $208.

@tepples, the full title of the song is, "Three Buskers and One Buffoon." It's said buffoon is playing the flute. Note however that he's actually a virtuoso musician, and positively annoyed by the buskers' rather unsophisticated tune ... which, all in all, will result in a funny little cutscene.

BTW, I've updated the song, the buffoon is now a lot more gleeful towards the end. (Yes, the flute being totally off-center, and staying there, is intentional.) Also, there is another new track, also intended for a cutscene/flashback/whatever. Be sure to listen to it in full length (~5:15 min.).



Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00199.7z

I've a little question.

How did you setup/compile your file ???

You're one of the indie demo/games that seem to be correctly setup compiled and that work for me on my SNES + SUPER UFO 8 Linker.
Lots of demo/compiled programs don't want to load (bad dump of rom too but the same rome with correct dump/header load without problem)

I'm new in SNES assembler, i try some test with WLA-DX, the SNES-SDK and PVSNESLIB.
All code generate work on emulator but won't load on SUPER UFO 8.

Your demo load perfectly and work without any problem.
I'll apreciate a lof if you can tell me how you setup your rom.

PS: Your work on the current engine demo is really impressive

Hey!


Thanks!

No idea what's wrong with your setup, though. Maybe test your ROMs on bsnes/higan before loading them onto your copier?

Anyway, here's a new build:







Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00213.7z

Have fun, and feel free to report bugs/glitches!

Ramsis

Now it's finally possible to do turns on the Mode 7 map. I achieved this by pre-calculating no less than 1024 HDMA tables -- four for each one of the 256 rotation angles.



Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00220.7z

Unfortunately, you can't "fly" forward on any rotation angle yet as the BG is apparently scrolled relative to the northern edge of the Mode 7 GFX, not the first scanline or X/Y center coordinates. But I'll definitely make that possible somehow, too.

Second try now:
How long does each table take to calculate? I seem to remember Super Mario Kart calculating a bunch of HDMA tables into $7F0000-$7FFFFF at power-on using the DSP. Or are they precalculated into ROM using an algorithm that would use excess real time if implemented on the S-CPU?

Indeed, the SNES CPU is too slow (or rather, Vblank is too short) to calculate matrix values for all 224 scanlines in real-time, so I had the SNES subsequently pre-calculate all necessary sets of matrix parameters into WRAM, then dumped each set to a file and included the dumps in the ROM.

Due to how the rotation math is implemented, there are 256 possible angles and 224 16-bit values per Mode 7 rotation/scaling parameter (4), so the matrix data currently amounts to a whopping 1024 HDMA tables or 256 * 448 * 4 = 458.752 bytes (though technically, registers M7A and M7D share the same values, so it's "only" 344.064 bytes, all in all). The current angle value ($00-$FF) is merely used as an index into the set of matrix parameters. During Vblank, the appropriate 4 tables of 448 bytes each are copied to the WRAM locations accessed by an indirect HDMA transfer.

I'll have to calculate even more tables though, as I would like to be able to change the "height" during flight.

BTW, the rotation math in my implementation is fundamentally based on bazz' Mode 7 tutorial, although enhanced by my own discoveries, ridden of quite a few bugs, and simplified in several ways (e.g. you don't need to change your calculations for a clockwise rotation -- just decrease the angle value instead of incrementing it).

In any case, I wouldn't know of any other recent homebrew demo/game for the SNES featuring a working Mode 7 rotation with perspective, so I tend to be a tiny bit proud of my achievement.

Lastly, here's a build that eliminates any and all scrolling glitches present in #00220 and earlier, and shows the current angle using a sprite-based VWF:



Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00221.7z

Very clever idea to pre-compute the values for mode 7 rotation! :D

No sense making the game suffer, just to pretend like it's the mid-'90s when ROM was expensive. It seems so obvious, but I've seen fan translations that prided themselves on packing everything into unexpanded ROMs, like some sort of demoscene challenge.

In the case of SNES games, banking could have made it painful to expand those ROMs, depending on how the game handled that.

Also I seriously can't believe there isn't a feasible way to do this when many other games probably did it without a ton of precalculated tables (possibly precalculated operations, but not the full thing). Heck, how did F-Zero do it? (and F-Zero isn't using any coprocessors). Because I can't imagine the fully precalculated table method scaling well in the long term.

The tables (having looked inside the ROM) really look like there should be some simple math to convert each table from six 224×128 arrays of int16s to six (224+128)×1 arrays of int16s and six multiplies for each scanline... maybe can't be done in vblank, but caching the current angle and the adjacent ones should be doable. In fact, adding the extra dimension of altitude might require it...

On the other hand, you can get new 5V DIP EEPROMs up to 512 KiB, and new 5V TSOP/BGA EEPROMs up to 2 MiB, all for roughly the same price, so ... I really doubt it's worth caring yet.

Why does the calculation have to fit in VBlank?

Thanks! And I agree about the sometimes pointless efforts to save ROM space.


Belief is one thing. Research, coding, and finally having stuff work is another.


Pun intended? Anyway, sorry, but I don't see your point.


You need to do 16×8 bit signed math, so you are restricted to PPU ports $211B/$211C and $2134-$2136 for your calculations.

From nocash's Fullsnes on these:


I can confirm that this is true: In an earlier build, I had a V-IRQ fire after each scanline to calculate Mode 7 parameters for the next one, and quickly set the ports accordingly. Turned out there wasn't enough time in Hblank to calculate and set all four parameters, but even when I reduced it to compute and set only the two scaling ports, the display was no more than a complete pixel mess.

Last time I checked, really big parallel 8-bit 5.0 V ROM was still expensive. This is why you get 27C322 multiplexer mods, TSOP adapters, level shifters, and the like. If you're translating a game that was already 32 Mbit, ExHiROM donors were hard to find, and people might not have taken the availability of 64 Mbit ExHiROM boards from infiniteneslives.com into account. Or you might be making an original game that fits in the 262144 byte limit listed in the rules of a competition that seeks to produce a collaborative multicart.

Well, I imagine F-Zero did it somehow.


What happens if including the translation (i.e. moving around the map) ends up being not so trivial with the tables? You'll have to include combinations for them too. You'll run into the many-MB or even possibly GB range. Having several tables for each part of the calculation is feasible (and most likely what most games do), precomputing everything into a single table probably won't, however.

EDIT: also I find it ironic complaining about people restricting themselves to the limitations of a given ROM size but not about restricting themselves to the limitations of two and half decades old hardware.

It's possible (if a little fiddly) to do that with the ALU.

Partial precalculation is probably a good idea. But if you try to add altitude without adding at least some real-time math, you're going to have to multiply the amount of space your method currently takes by the number of altitude increments you want...


Final Fantasy VI did both rotation and altitude during the airship sequences.

Here's a build that implements on-the-fly calculation of all Mode 7 matrix parameter tables using CPU multiplication registers during active display -- just to illustrate to you guys how awful that turns out.

From my notes:


As I suspected well before I actually decided to give it a try, 224 scanlines of active display still aren't enough to calculate all four tables (at least not without heavy slowdown), so I introduced a frame counter and split the calculations between odd and even frames, reducing performance from 60 fps to 30 fps.

Please be warned – doing turns on the Mode 7 map will very likely make you sea-sick.

Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00222.7z

N.B. Please don't bother speculating again and again about how this or that game might have managed to implement Mode 7. Instead, feel free to impress me (if you can), and possibly contribute to this project, by showing ( ) us all your own working Mode 7 perspective implementation (BTW, have fun doing it).

Thanks!
Ramsis

Mario Kart Super Circuit for Game Boy Advance also calculates turns at 30 fps.

I forgot to mention: Horizontal scrolling (L/R shoulder buttons) causes heavy glitches in build #00222, the reasons of which are unknown (and likely won't be investigated) at this time.

More work on Mode 7. Just like in the previous build, everything is calculated in real-time. Horizontal scrolling is disabled for now as it breaks everything. Yes, the horizon line will be blurred later on.



Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00223.7z

That is amazing.

Makes me feel a little disappointed that I haven't done much SNES work this month (and I mean that in a good way).

Thanks, UnDisbeliever. BTW, I haven't had the time to try out your platformer yet but will do so shortly.

Anyway, here's the preliminary result of my recent text box upgrade -- thanks again for all the help, guys.



As you can see, Furry RPG's text engine now features a hi-res VWF. The only major issue remaining is that it only works correctly in PAL mode, the likely reason being that most of the routines are still on Vblank, which is too short in 60 Hz for all of them to complete. So today's build is PAL for a change.

Oh, and please notice how the text box and portrait were offset from the left and right to avoid clipping on older TV sets.

Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00227.7z

"Quaoar"? Does this take place before or after contact with the native peoples of the west coast of North America?

There we are, once again in full 60 Hz glory:




The script has been expanded as well:



Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00228.7z

The first song is so beautiful. I like those dramatic minor subdominants and dominants in mutation.

Thanks, much appreciated. I'm currently working on the main theme, hoping that it's going to turn out even better yet ...

BTW, in case anyone is interested in Furry RPG's storyline, here it finally is (in a very small font as there are major spoilers ahead -- please be warned).

On learning that a »ghost« haunts their village as of late, frightening the kids and stealing food from unlocked pantries, best friends Alec Marlowe, a young hunter (lion), and skeptic scholar Lilac Pondicherry (tigress) join foreign soldier Primus Greyfur (wolf) for a trip into the vast forest just beyond their doorstep. Bent on hunting down and uncovering the villain, whom they suspect to be very fleshly in appearance (although furred, of course), the three venture deep into the woods, where they eventually make a discovery that will forever change their destinies as well as the history of their country, the Republic of Librefur. For in an abandoned military outpost, unbeknownst to anyfur, Reinhold von Pappenheim (fox/coyote?) has been living a secret life, with an unsightly Fennec puppet named Dorothy as his sole companion.

Initially posing as a trickster and ventriloquist, Reinhold is soon revealed to be the exiled heir to the throne of Fleckenstein Kingdom, beyond the Republic’s eastern border. He tells Alec and his friends of an uprising in his home country. The rebel forces are supposedly led by »the Badger,« whose sole purpose in life appears to be to overthrow the reign of the Pappenheim line of kings, and plunge the realm into chaos and destruction.

Convinced that his new friend could be lent a paw returning to his people, claiming back the throne and restoring peace to Fleckenstein, Alec and his comrades join Reinhold on a journey back to the kingdom—only to find it in full preparation for war against its three neighboring states: the Furderal Empire, to the south, the Free County of Coathill in the north, and the Republic of Librefur, due west.

Shocked about this finding, Alec and Lilac agree to return home in order to warn both the Palace and the population of Librefur of the impending invasion. But before they can even leave the capital of Fleckenstein, the four friends are all arrested and put in separate jails, knowing they will be publically executed on the very next morning for alleged high treason. However, Alec, Lilac and Primus are found and liberated at night by nofur else than »the Badger« himself, a.k.a. Kilian Lacrimo della Valle (cheetah), who tells them that Reinhold was nowhere to be found and has most likely already been killed.

During their journey back to the Republic of Librefur, the remaining three tell Kilian about Reinhold’s identity. Kilian, in turn, explains that nothing of what Reinhold told them was true. According to »the Badger,« the Pappenheim reign is actually a ruthless and cruel dictatorship that needs to keep up its outward saber-rattling so as to remain credible to its large amount of faithful citizens, and that the rebels indeed intend to rid the country of its unfurable leader. He reminds Alec that he and his friends are far too deeply involved within the conflict to go back to their normal lives anymore—as Fleckenstein assassins have already been sent out to track them down—and instead convinces them to retreat to the abandoned outpost in the forest, fortify it in case they are discovered by Fleckenstein spies, and aid the resistance from there.

In time, they are joined by others hoping to stop Fleckenstein: young Damian Fleck (jaguar/leopard?), a martial artist who is loyal to his home kingdom, yet afraid the Pappenheim’s war-mongering might wreak havoc on it; Tara of Idenmarch (lynx), a Fleckenstein refugee who saw her family being murdered by Pappenheim’s henchmen; Gregory P. E. H. Eindhoven Dubois Quaoar van der Muhlhausen Nido sulle Colline (bear), a would-be Coathill aristocratic who gets quickly debunked by Kilian and, being a carpenter, decides to help rebuilding the outpost; Kit, a foxling whose flute-playing ensnares friends and foes alike; and several others (i.e., secret characters).

When the motley crew around Alec finally re-enter Fleckenstein Kingdom to confront Reinhold in the hopes of ending the war before it really begins, they appear to succeed—only to realize that hardly anyfur amongst them is actually what he or she pretends. Not only that, but the real threat is found to stem from deeper than the deluded minds of those few who seek to conquer the lands around them.

In the end, Alec has to make a decision the world he knows depends upon—as do both his own life and the lives of all his friends …

Questions/comments are welcome, as always.

Thanks!
Ramsis

What did you do about mode 7? Did it just end up working faster than expected?

After optimizing things quite a bit, yes it did. Also, I'm saving the calculations for 56 scanlines thanks to the "sky", plus M7D gets fed the same values as M7A, which cuts down CPU usage a bit, too. This currently allows Mode 7 calculations @60fps.

Cool.

Does M7C get fed the negative of M7B? No need to waste a multiply on that if you can just flip a bit...

Wow! This is really awesome. Looks and sounds great! I really hope that you will find time to finish this project.

I had no idea that a game like this was in the making.

Aww, right! How could I miss that in the first place? Anyway, thanks for pointing it out, allowing me to optimize things even more.


Thanks! As a matter of fact, I won't ever be able to finish this project without a graphics designer on the team, so wish me luck finding one (or more).

Pretty neat demo. But I hope Mode-7 map will be scrollable at greater speed.

BTW, how do you guys compile? Tried wladx several times after reading tutors, never happend to work.

I use WLA-DX. Why it might not be working is a question that could be nearly impossible to answer though without more information.

I'd suggest you start a new thread about it and we'll help you to get started - people are reasonably fastidious about staying on-topic in this forum and I just don't wanna derail Ramsis's thread here.

Sure thing. Please try this latest build, where you can fly in any direction (press the A button and left/right on the D-pad):
http://manuloewe.de/snestuff/projects/furryrpg_build_00237.7z

Yeah, fast nothing flies fast now, but only in straight foward direction. Fast nothing turns around not so fast.

As I said here, the code isn't optimized for speed yet.

Changed perspective a bit, and added a much-needed (yet preliminary) horizon blur effect.



Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00238.7z

Much stronger effect now. But I suggest you use sprites for buildings and settlements on the map because they have wrong perspective.

First of all, demo GFX (ripped from Illusion of Gaia). Secondly, we've been through this before.

One thing I would suggest though is to try to tone down the brightness for the horizon by a little, and have you considered making it kind of blue tinted? I mean, whenever you look at mountains far away, they almost seem to turn blue if you know what I mean.

Thanks to Python, I can now adjust the "viewing angle" onto the Mode 7 landscape almost indefinitely (at assembly time only though). Also, it's finally possible to change the altitude during flight.







Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00240.7z

By "viewing angle" do you mean whether it's pitched up and down, the field of vision, or something else? Because you can fake pitch by scrolling the whole view up and down and making slight adjustments to "altitude".

Not sure how to describe it, but I basically meant the "tilt" of the Mode 7 plane against the camera.

A top-down view like this would equal 90 degrees exactly:


Watch Tales of Phantasia's intro to see the "angle" become "steeper" as the camera appears to pan up and down.

You appear to be describing a change in pitch.

I've never played ToP. But in F-Zero, the camera starts straight down, zooms in, and then rapidly pitches up to gameplay position. Is that the effect you're referring to? If so, it can be simulated by changing the horizon position and making small adjustments to other variables like height. You can solve this using similar triangles, or if that's too hard, you can ask one of us to do that.

Right.

While it may not look like much has changed at first glance, I'm rather fond of the progress made.

• Tilemap updates and other DMA stuff during Vblank is now done as requested by the main program only (probably still not as cool as d4s' DMA FIFO, but we're getting there )
• Hero sprite was reduced to 16×32px, allowing for more efficient sprite math (don't blame me for placeholder Gengen looking like s*** now as there's still no pixel artist around for this project ... )
• Hero spritesheet doesn't need to be all in VRAM any more, plus there are more frames available for smoother animations (not used ATM)
• Hero can finally move in 8 directions

Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00243.7z

This new build supports scrolling backgrounds (no collisions/dynamic tile map updates yet, though).



Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00248.7z

I like it! I was just playing now before the last update. I just love that music Sun, Wind and Rain.
One bug which is in Snes9x is that I hear popping sometimes.

Thanks!!

Build #00252 is out. The biggest news is multi-language support for the dialog text engine. While I was at it, I started to work on the German localization as well. You can switch between available languages (English and German as of now) with D-pad up/down whenever the text box is open.



Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00252.7z

Also, I'd like to mention once again that the full source code to the project is now on Github.

(Edit: Yes, I went back from Win 10 to Win 8.1 a while ago, in case anyone wonders. )

Where you having problems with Win 10?

I'm having problems with Win 8.1. After the latest round of updates, I can no longer run Photoshop, nor Internet Explorer. They just completely crash my computer. I'm currently using GIMP and Chrome as replacements. I was considering moving up to Win 10, while it's still free.

The problem with Win 10 is that with every major update (like the 1511 build), all of which you're forced to install in any case, a new WIM is installed onto your system. But if you have a 3-boot UEFI system like myself, updates like these are likely to mess up your UEFI boot partition (they did in my case, anyway). As I'm not fond of having to boot-repair my system every six months, and especially since software I use all the time (like Intel WiDi v4.3.4.0) didn't work AT ALL on my system running Win 10, I decided it was time to downgrade for good.

This game looks really awesome. I think uploading the source will also help other trying to make their own snes game too. I support this project.

A proper main menu is in the works, featuring a selection ring (with placeholder sprites, of course).



Press X in the demo area to access the menu.

Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00256.7z

Am I misremembering there being a patent on the SoM ring menu? I suppose it would be expired, by now...

There was a patent on the friggin ring menu? I need to look into this. I wanted to implement something similar and I'm nervous to try it out now!

Super NES era software patents have almost certainly expired by now.

Aw, no instant source-supplying from Tepples? Yes, I was more trying to remember if there had been one. Brian Fehdrau kind of hints that there was in an interview about SoE, but I was unable to find something more concrete.

...though, trying to find software patents generally depresses me, given how often I can look at one and come up with an instance of prior art.

35 USC provides that patents expire 20 years after they are filed. Two common conditions qualify a patent for a term extension: when a product requires regulatory approval for marketing, such as a drug, or when the patent office commits an undue delay in examining the patent. There was a transition period sometime around the tail end of the Super NES era when patents lasted the longer of 20 years after filing or 17 years after grant, but in practice, those situations are very similar to extensions for undue delay.

Interesting, I wasn't aware that there was a patent on any (!) implementation of a ring menu. Thanks for sharing, @Myask!

Back to topic: The latest build features 1 new music track and the first MSU1-based ambient sound -- amongst other stuff.



Download:
ROM & PCM & MSU

Simply download all three files (last one is intentionally 0 bytes in size) and rename them based on your situation ...

For higan v098 (make sure "Ignore Manifests" is checked in the settings):

For sd2snes:

Then go to area/dialog test.

Have fun!

Ramsis

Build #00261 features two new BGM tracks, and a dynamically (dis-)appearing HUD:



Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00261.7z

There's a scrollable Mode 1 world map (WIP) in build #00264 (the static Mode 3 map was scrapped), and some cool sprites contributed by Tantalus:



Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00264.7z

Just a quick update on the inventory sub-menu ...

Item names are rendered statically (i.e., as graphics) for now -- thanks again @byuu for the idea and @tepples for a handy Python script that helped a lot in achieving this goal.

What do you guys think? Is this acceptable, or should I pursue the dynamic rendering approach I had in mind earlier instead? (If you vote for the latter, please don't forget to elaborate on your point of view so as to help me make up my own mind on the matter. Thanks!)



Download:
http://manuloewe.de/snestuff/projects/furryrpg_build_00266.7z