Heartcore Project WIP

Discussion of hardware and software development for Super NES and Super Famicom.

Moderator: Moderators

Forum rules
  • For making cartridges of your Super NES games, see Reproduction.
User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Heartcore Project WIP

Post by HihiDanni » Tue Apr 05, 2016 6:15 pm

Hihi, I thought I would make a thread here to document the work I'm putting into my SNES homebrew game, which I'm going to call the "Heartcore Project" for now. My background is C++ and Lua - this is the first time I've done anything in a standard assembly language.

The game will be a "platform shmup" or a "run 'n' gun" or probably more accurately "run and sling hearts at colorful animals". Gameplay inspiration comes from Alien Soldier and Sparkster SNES. Art and level tile format inspiration comes from Sonic CD which I first played at the age of 6.

Right now I'm still working on the core engine, but these are my accomplishments so far:

- Working toolchain
- Data-driven OAM handling routines with scrolling support
- NMI interrupt routine which I'm _pretty_ sure won't cause crashes or weirdness anymore
- "Cycles remaining" counter (need to look in the memory viewer to see it, but will help tremendously with optimization)
- Object coordinate system with 16.8 precision - 24-bit position and 16-bit velocity (up to 127 whole pixels per frame, far more than enough)

Stuff I need to work on next:

- Uploading the SNESGSS driver to the APU without freezing the game (I fixed the interrupt routine recently so I'll try this again)
- Level scrolling (Need to make level editor first to verify results, and honestly this one kinda scares me haha)

Bits and pieces of my current tech design spec:

- bsnes-plus 0.73+2 as the current reference emulator
- No cartridge assistance besides FastROM
- BG Mode 1, with BG3 used as both a scrolling layer and an "open air" HUD
- All game logic variables within the first 8kB of WRAM, and frequently-used variables in the first 256 bytes where possible. Remaining WRAM used to cache decompressed graphics for later DMAing
- First six audio channels for music, with channel 7 for player sounds and channel 8 for environment/enemy sounds. I hate it when sounds cancel out parts of the music. My ideal use also includes BRR streaming via HDMA for longer sound effects and I will most likely need to modify SNESGSS for this. Bleh.

I am using Aseprite to create the graphics. I use Renoise plus a number of synths (Synth1, Harmless, Drumatic 4) to generate samples and to find suitable looping points, something its built-in wave editor excels at.

I want to make good use of the SNES controller. One thing that really bothered me about Alien Soldier was that they crammed 6+ actions onto a three-button gamepad.

I'll write more about this later. For now, have a .sfc of my current engine progress featuring 128 moving ball sprites.
heartcore_p1.sfc
Heartcore Project engine test 1: scroll (no tile reloading) + 128 sprites + HDMA + 16.8 coordinate system
(256 KiB) Downloaded 154 times
SNES NTSC 2/1/3 1CHIP | serial number UN318588627

User avatar
bazz
Posts: 476
Joined: Fri Sep 02, 2011 8:34 pm
Contact:

Re: Heartcore Project WIP

Post by bazz » Tue Apr 05, 2016 8:00 pm

Disclaimer -- I'm working on the SNES Tracker (ST) and my responses to you triggered a lot of ideas on its development. I hope my posts are still helpful to you, despite them being laden with my development progress.
HihiDanni wrote: Renoise plus a number of synths (Synth1, Harmless, Drumatic 4) to generate samples and to find suitable looping points, something its built-in wave editor excels at.
I love Renoise. I sometimes look at its UI to inspire me for SNES Tracker (see sig). SNES Tracker will be awesome for composing -- but it won't be ready for awhile as I'm still designing it and just generally staring at myself and wondering what I am doing. I think I need some high-level design / CPP / OOP guidance from someone experienced in all of that like Byuu -- if you see this Byuu, I've been meaning to ask you this. And believe me, I know you're busy. But please consider being my mentor from time to time.

HihiDanni, it's probably self-explanatory how you're using the sample editor to do your work with sample points -- but I've had some time away from it. I would love to see how you're using Renoise to work thru sampling to BRR through a "live stream" -- If that's something you would enjoy doing, please do. Otherwise, no problem, I'll RTFM. I can probably get the gist just by using the sample editor again. Hell man, I'll probably have to design something like this into SNES Tracker. I mean, OBVIOUSLY -- I don't want to outsource users to another sample editor unless there is a SUPER GOOD reason -- of which I can only think being that another feature-rich sample editor will provide (more) DSP FX. Whereas I could see SNES Tracker's largely starting out with a main priority of importing samples and also trimming / aligning sample points for looping.

> - First six audio channels for music, with channel 7 for player sounds and channel 8 for environment/enemy sounds. I hate it when sounds cancel out parts of the music.

Do you mind sfx canceling out other sfx?? I am nearing completion of a shmup for another console that only supports 6-channels - but I have the same general architecture as you with one channel for player sounds and one for enemy sounds -- and of course I have sfx canceling each other out -- for instance when player is shooting the weapon and then gets a powerup.. It was worth experimenting with assigning priority to certain SFX. Let me know if I spoiled the adventure for you -- I know sometimes figuring out these things for myself is more thrilling than having someone tell me a solution. And, if you are that way, I'll keep my mouth closed for other things ^__^

> My ideal use also includes BRR streaming via HDMA for longer sound effects and I will most likely need to modify SNESGSS for this. Bleh.

I will make sure to make BRR-streaming a friendly command for the ST sound driver -- if you have any suggestions for the spec of the command I'm open -- but I think I can figure it out. I'll probably "stub it" until later time when addressing it is appropriate.

----------

As far as your demo.. Cool! My only complaint is that the BG was very stuttery scrolling.. But I have the feeling you know why and can fix it.

EDIT: There's also the matter of sprite-tearing but I believe again, you're just showing off 128 sprites and we don't have to seriously consider this issue. but perhaps you will need to address in the future if your gameplay is THAT crazy! In which, I have not that problem solved (and this a case where I would want to solve myself rather than hear of someone's solution -- but only if I was working on a game that required such a solution).

There is also the matter of the BG being pretty hard on the eyes while scrolling -- but it seems to be just for a demo, so maybe I'm being too critical -- but the BG *almost* looks like a faulty tilemap. Yet, I feel it's supposed to look this way. see attached image..

Anyhow, nice job!
Attachments
Screen Shot 2016-04-05 at 11.10.31 PM.png
SNES Tutorials (WLA DX)
SNES Memory Mapping Tutorial (Universal / LoROM) -- By Universal I introduce how memory mapping works, rather than just provide a LoROM map.
SNES Tracker (WIP) - Music/SFX composition tool / SPC Debugger

psycopathicteen
Posts: 2936
Joined: Wed May 19, 2010 6:12 pm

Re: Heartcore Project WIP

Post by psycopathicteen » Wed Apr 06, 2016 2:08 pm

- Object coordinate system with 16.8 precision - 24-bit position and 16-bit velocity (up to 127 whole pixels per frame, far more than enough)
Except when you have a large multi-jointed boss that switches directions, but that can be worked around. I ran into a glitch like that a couple weeks ago.

User avatar
tokumaru
Posts: 11755
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Heartcore Project WIP

Post by tokumaru » Wed Apr 06, 2016 2:25 pm

If the reference point is the center of the object, 127 pixels in 4 directions are enough to make up a pretty big boss! I assume that most parts of a muilti-jointed boss would be separate objects though.

User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Re: Heartcore Project WIP

Post by HihiDanni » Wed Apr 06, 2016 3:42 pm

bazz wrote:Disclaimer -- I'm working on the SNES Tracker (ST) and my responses to you triggered a lot of ideas on its development. I hope my posts are still helpful to you, despite them being laden with my development progress.
That's fine. Long posts are good for thinking about things! I look forward to your tracker!
bazz wrote:HihiDanni, it's probably self-explanatory how you're using the sample editor to do your work with sample points -- but I've had some time away from it. I would love to see how you're using Renoise to work thru sampling to BRR through a "live stream"
Feel free to just call me Danni if it's easier. The Renoise sample editor has a loop point viewer that creates two close-ups of the start and end loop points. As for conversion to BRR, the SNESGSS tracker does that for me. I might stream at some point.
Loop fine editor button (Applies to Renoise 2.8)
Loop fine editor button (Applies to Renoise 2.8)
LoopFineEditor.png (4.05 KiB) Viewed 3506 times
bazz wrote:It was worth experimenting with assigning priority to certain SFX.
I think I might just have a way to mark a sound as "uninterruptible". Details aren't set in stone yet.
bazz wrote:I will make sure to make BRR-streaming a friendly command for the ST sound driver -- if you have any suggestions for the spec of the command I'm open -- but I think I can figure it out. I'll probably "stub it" until later time when addressing it is appropriate.
I think 16000hz would be a good choice.
bazz wrote:As far as your demo.. Cool! My only complaint is that the BG was very stuttery scrolling.. But I have the feeling you know why and can fix it.
Hmm, stuttery? In what way? The demo just scrolls four pixels per axis per frame, as a test. If you're referring to acceleration/inertia, of course I will make in-game movement smoother in that way. If you're referring to "jank" then that is a bit worrisome. The motion seems fine here - are you syncing your emulator's video output to the display?
bazz wrote:EDIT: There's also the matter of sprite-tearing but I believe again, you're just showing off 128 sprites and we don't have to seriously consider this issue. but perhaps you will need to address in the future if your gameplay is THAT crazy! In which, I have not that problem solved (and this a case where I would want to solve myself rather than hear of someone's solution -- but only if I was working on a game that required such a solution).
Honestly I'm not too concerned about this. I mean Treasure clearly didn't seem to care. I'm mostly going to concentrate on avoiding slowdown, though I will also try to design bosses and such to at least minimize scanline sprite flicker. If a little gets through, so what? To me, disappearing sprite scanlines is an interesting glitch aesthetic, almost like the "tape hiss" of 16-bit consoles.
bazz wrote:There is also the matter of the BG being pretty hard on the eyes while scrolling -- but it seems to be just for a demo, so maybe I'm being too critical -- but the BG *almost* looks like a faulty tilemap. Yet, I feel it's supposed to look this way. see attached image..

Anyhow, nice job!
Thank you! The tilemap is literally 16 kilobytes of random data I generated in a hex editor. The tileset char data is also placeholder. They're just there so I could make sure I set the BG char/tilemap address registers correctly.
tokumaru wrote:If the reference point is the center of the object, 127 pixels in 4 directions are enough to make up a pretty big boss! I assume that most parts of a muilti-jointed boss would be separate objects though.
The 127 pixel range is specifically for object velocities. For joint animation I will probably just directly set the upper 16 bits of the position for each axis.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627

psycopathicteen
Posts: 2936
Joined: Wed May 19, 2010 6:12 pm

Re: Heartcore Project WIP

Post by psycopathicteen » Wed Apr 06, 2016 4:59 pm

HihiDanni wrote:
tokumaru wrote:If the reference point is the center of the object, 127 pixels in 4 directions are enough to make up a pretty big boss! I assume that most parts of a muilti-jointed boss would be separate objects though.
The 127 pixel range is specifically for object velocities. For joint animation I will probably just directly set the upper 16 bits of the position for each axis.
I just hope that it wouldn't interfere with the tile map collision detection, if in case the you apply collision to a bosses feet or hands.

Wait, ugh, why didn't I just use separate routines for both vertical and horizontal collision in the first place? It seems like I find something wrong with my game everyday.

d4s
Posts: 92
Joined: Mon Jul 14, 2008 4:02 pm

Re: Heartcore Project WIP

Post by d4s » Thu Apr 07, 2016 1:32 am

HihiDanni wrote: The game will be a "platform shmup" or a "run 'n' gun" or probably more accurately "run and sling hearts at colorful animals". Gameplay inspiration comes from Alien Soldier and Sparkster SNES.
You're certainly not aiming low here.
Hideo Ueda, the guy who programmed Sparkster and Axelay amongst others, IMHO
was one of the best coders to work on the system and one of the few I truly admire.

For someone who just started out on the SNES, your demo is impressive.
I'm pretty sure you can reach your goal if you keep at it.
Best of luck!

User avatar
Khaz
Posts: 311
Joined: Thu Dec 25, 2014 10:26 pm
Location: Canada

Re: Heartcore Project WIP

Post by Khaz » Thu Apr 07, 2016 7:23 pm

Your demo looks rather nice. :P

Have you worked out a collision detection strategy yet? That's the part of my project that was definitely the most time-consuming. I modelled mine after the original Sonic physics engine, since I wanted to be able to move around smooth curves.

Looking forward to seeing more!

psycopathicteen
Posts: 2936
Joined: Wed May 19, 2010 6:12 pm

Re: Heartcore Project WIP

Post by psycopathicteen » Fri Apr 08, 2016 3:41 pm

This just came to my mind at work today. Multijointed bosses can use a linked list of joint objects, instead of having a big table of where each joint object's memory is. Though, it might make it more complicated to set up.

User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Re: Heartcore Project WIP

Post by HihiDanni » Fri Apr 08, 2016 4:37 pm

Okay, I am making progress on SPC stuff but I'm running into a problem that I had before and haven't been able to solve. Basically I upload the SNESGSS driver to the destination starting at $200, and then begin execution at that same address. SPC-side, everything seems normal for a while - it goes through a loop for a bit - and then SPC execution wanders out of the code, across all the 0's (BRK) used for padding the end of the driver, and ends up back inside the uploader firmware at $ffc0. I have no idea why it's doing this, and whether it's due to the driver (though I thought I tested on a bunch of versions of SNESGSS) or the way I'm uploading the driver. It almost seems like there's stack mismanagement going on in the driver?

If anyone here has used SNESGSS, I would greatly appreciate any help because while the tracker has a good reference, actual use of the driver is basically undocumented.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627

KungFuFurby
Posts: 261
Joined: Wed Jul 09, 2008 8:46 pm

Re: Heartcore Project WIP

Post by KungFuFurby » Fri Apr 08, 2016 6:49 pm

I found your sound data right in the ROM, and I got curious myself. Then... I realized you had all sound effects and no music. The music had never been created, and the code never existed to load the sound data.

I provided some assistance with getting the sound to work in Furry RPG, which uses the same sound driver. The only other use I have seen for the sound driver has been much older versions used by Shiru (and some other games by the same developer that are not freely available, if my instinct on sound driver usage is correct)... specifically, Christmas Craze and Classic Kong Complete.

SNESGSS works by swapping in and out music. First, you need to send the load command to the SPC700 (after stopping the previous piece of music, if it hasn't been done yet). The SNES APU will respond with returning to the firmware uploader. Then you load some data to where the music is going to be stored in SPC700 RAM... and then you send a play command.

I actually have never personally used the sound driver myself because of a platform incompatibility with both the utensil and the assembler (down to its source code), but I do have an idea of how it works, and I have been able to provide my assistance with regards to attempting to get the sound driver to work.

User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Re: Heartcore Project WIP

Post by HihiDanni » Sat Apr 09, 2016 10:02 am

KungFuFurby wrote:SNESGSS works by swapping in and out music. First, you need to send the load command to the SPC700 (after stopping the previous piece of music, if it hasn't been done yet). The SNES APU will respond with returning to the firmware uploader. Then you load some data to where the music is going to be stored in SPC700 RAM... and then you send a play command.
Unfortunately all these instructions assume that I have gotten the driver loaded and working in the first place. As I mentioned before, after I transfer the driver to the SPC, execution wanders back into the uploader firmware without me telling it to do anything, so I can't give SNESGSS any commands in the first place. It just goes back to waiting for me to send $cc all over again. This happens even after I load the full driver and a song. It refuses to work at all.

Suspiciously, the very first byte in the generated driver is the "and" instruction, which seems like an odd place for code to begin. Does anyone have a "known good" SPC driver that I can try loading as a test?
SNES NTSC 2/1/3 1CHIP | serial number UN318588627

tepples
Posts: 22017
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Heartcore Project WIP

Post by tepples » Sat Apr 09, 2016 11:01 am

HihiDanni wrote:Suspiciously, the very first byte in the generated driver is the "and" instruction, which seems like an odd place for code to begin. Does anyone have a "known good" SPC driver that I can try loading as a test?
Do you mean a working SPC700 program that begins at $0200 and is verified to make coherent noise on hardware? There's one in my Super NES project template.

User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Re: Heartcore Project WIP

Post by HihiDanni » Sat Apr 09, 2016 1:12 pm

It doesn't have to begin at $200 (since I've generalized my SPC loading code now) but it does need to work.

Anyway, I extracted the driver from the provided .spc and loaded it at $200. For some reason however I had to tell the SPC to start execution at $3cde instead of $200 before it would work. So it seems like I have working SPC upload, it's just figuring out how to get the SNESGSS driver to work (or where I'm supposed to upload it - documentation says $200 for both destination offset and execution but that doesn't seem to work correctly).

Edit: Update! I removed the first two bytes from the SNESGSS driver data and it seems like I'm making progress! It no longer wanders out back to the bootloader!
SNES NTSC 2/1/3 1CHIP | serial number UN318588627

KungFuFurby
Posts: 261
Joined: Wed Jul 09, 2008 8:46 pm

Re: Heartcore Project WIP

Post by KungFuFurby » Sat Apr 09, 2016 1:54 pm

Ah, I didn't think of that. The first two bytes represent the filesize of the entire sound data you're loading, and therefore should not actually be sent to the SPC700.

Post Reply