Nova the Squirrel 2 (WIP)

[NovaSquirrel | 30]

Just now, erockbrox said:

Very cool. I am looking forward to this. The chips challenge aspect looks awesome and if there is a custom level builder so I can make my own puzzles then I'm totally down for this.

I'm intending on having an in-game level editor for Mode 7 levels, but also those levels are just stored as Tiled maps PC-side, so they're easy to edit.

[NovaSquirrel | 30]

Wow, looks like I forgot to post any updates here. Years later, I'm still working on the game. There's been a lot of stuff here and there with other projects that ended up taking a lot of time (like Petal Crash Online was a huge one), but now I'm back to making it my main focus again probably? I keep trying to get back to it and focus on it but it's hard to make that stick. It's hard to summarize a few years of on-and-off game dev but I figured it'd be nice to show off a few things I have done.

I spent the past while working on a new hub world map. I want a heavy story focus but I don't want it to feel clunky or forced, and something similar to what Drawn to Life for DS does felt appropriate, where you go to a map between levels with NPCs on it that you can talk to. My map is inspired by the Satellaview map and Pokémon maps primarily.

I did an improved camera! It tries to minimize vertical movement by doing stuff that's similar to what Super Mario World does, but with linear interpolation in there, and I've made changes to improve it since I recorded that.

I've done a lot of work with just generally adding polish, fixing bugs, adding in new enemy types and new features. There's a sword ability now! And I have an actual plan laid out for how I want the first world to flow, and my current intention is to get the first world really polished and then put out a first world demo that people can play and give feedback on.

There's a bunch more changes in the NesDev thread if you want to look at those.

[Gloves | 11,777]

I still can't get over those knuckle sandwiches lol. Amazing.

[Scrobins | 1,725]

This update looks amazing, thank you for sharing! Would you be interested in a VGS release of the first game through us and Mega Cat?

[NovaSquirrel | 30]

Just now, Scrobins said:

This update looks amazing, thank you for sharing! Would you be interested in a VGS release of the first game through us and Mega Cat?

I don't think I'm really interested in doing cart releases but I appreciate there's interest

[Scrobins | 1,725]

No worries! I’m excited to follow your progress on this game.

[NovaSquirrel | 30]

I'm revisiting the mode 7 minigame again because I was never really happy with slow-paced puzzles with lots of 90 degree camera turns. I based this attempt off of Rainwarrior's Dizworld demo because it also had an example of how to position sprites within the world (so I could have enemies and other things moving around on top of the plane), but I ended up really liking the way that big floaty jumps look using Dizworld's code for calculating perspective data at runtime, so I'm playing with basing the gameplay around that instead.

I still want to have puzzle elements, and there's definitely some Chip's Challenge aspects still there, but I'm exploring gameplay that's more focused on air movement. I think this is actually a much better fit for the rest of the game than something really slow and restricted to a grid.

[NovaSquirrel | 30]

There's been a whole lot of graphical improvement on the mode 7 levels! I gave the player character a lot more animation than she had before, and I added a lot of decorations, which make it feel a lot more like an actual world. Decorations always end up doing that and it's a great way to improve things without much work. From here I would like to add some sort of notice about how many items you need to collect before you can go through the goal, and I'll probably give them a more creative design than just hearts

I added the ability to take blocks and slide them somewhere, which I think is how attacking enemies will work, though the focus is a lot more on platforming and exploration than on combat.

On Twitter I posted a video of a good amount of gameplay with the new animations and decorations.

[Gloves | 11,777]

That's just straight up amazing. Well done!

[Tanooki | 4,933]

Geez!  That's insane with those animated GIFs.  If that's truly representative of the working game, this puts what you have so far in the top 10-20% of home made programs for the SNES for sure.  Even higher on that list for those that tap into more advanced level of system function.  Are you using a DSP chip?  This seems to be using some of the same scaling/mode 7 tricks that Hind Strike does which is a mimic of how the camera and all works in Pilotwings (which both use the DSP.)  it's rare I buy aftermarket stuff since usually there's enough jank I can't justify it, but this is looking to get more fluid and more well thought out, at least in images, but if it plays as nice as one would hope it would, this is going into the small buy worthy list of thigns to do.

[NovaSquirrel | 30]

13 hours ago, Tanooki said:

Geez!  That's insane with those animated GIFs.  If that's truly representative of the working game, this puts what you have so far in the top 10-20% of home made programs for the SNES for sure.  Even higher on that list for those that tap into more advanced level of system function.  Are you using a DSP chip?  This seems to be using some of the same scaling/mode 7 tricks that Hind Strike does which is a mimic of how the camera and all works in Pilotwings (which both use the DSP.)  it's rare I buy aftermarket stuff since usually there's enough jank I can't justify it, but this is looking to get more fluid and more well thought out, at least in images, but if it plays as nice as one would hope it would, this is going into the small buy worthy list of thigns to do.

Yeah the gifs are recorded from an emulator, so they're representative of the gameplay I currently have, though this is a side thing in what's mostly a 2D platformer. I'm not using a DSP chip; I considered it, but I really want people to play my game on flash carts, and there's a big price difference between ones that don't support coprocessors and ones that do. I also just want to explore what the SNES can do on its own.

That means I'm more CPU-limited than I would've been with a DSP-1, and the camera is a little more janky (due to having to use lower precision math), but it feels worth it to me. I did improve it a lot by using precalculated data for the effect when you're on the ground.

I'm just planning on having the game be free, like all my other games, and I hope lots of people try it out. 

I also can't take credit for the perspective effect itself because that borrows a lot of code from dizworld.

Edited April 23, 2023 by NovaSquirrel
Crediting dizworld

[Tanooki | 4,933]

@NovaSquirrel I totally get that.  I've been talking to Piko of Piko Interactive I guess now more or less for a decade and something now, and in that time he got a contract to sell that Hind Strike for awhile.  While other games were your usual $50 CIB more or less, that one due to the DSP1 chip having to be harvested added like $30 to the price of the package, so I believe it that it's an expense.

I take it to deal with some of the draw for your effects you're using a FastROM board?  I'll never like the fact some of the launch and after games on the system cheaped out using the LoROM boards, it caused so much unnecessary lag/frame issues in some games where it never should have like Gradius III.  Lame LoROM cutting the speed of the SNES down by a 1/3 sucks.

[Sumez | 2,950]

LoROM/HiROM is a (community-coined) simplified terminology for a memory mapping configuration on the cartridge that has no influence on the game's speed. The only real reason I can think of preferring one over the other is coding habits.
HiROM is probably favorable if you have some really large blocks of data in your ROM image, while LoROM is more convenient when your program code is spread out across multiple data banks. I seem to recall Nova having some other reasons for preferring HiROM though.

FastROM is a thing though, and has no relation to those other two - it's essentially an overclocking setting. I think it's probably a good thing they designed the SNES with that in mind? Otherwise every game would have been "SlowROM" today, because Nintendo wouldn't risk games not running correctly with a faster clock speed. If you're mass producing hardware like that, it would have been a very big risk to run.

I could be wrong, but I think it's been proven at this point, that FastROM is always safe to enable in the SNES even with less capable ROM chips? Either way, nowadays there's no way you'd make a SNES game without using FastROM - any EEPROM chips you might be able to source, and obviously any flash memory used for mass production or in everdrive/fxpak/etc are easily specced more than fast enough for FastROM.

As for using a DSP-1 coprocessor or similar, I think it's something cool to experiment as a homebrew developer, but I also think if you got to use it, you really gotta be able to get some mileage out of it, and showcase some really cool effects, instead of just using it as a crutch to avoid the game running slow.
The SA-1 especially is a culprit that I think has been a little too good at enforcing that myth about the SNES CPU being horribly slow, what with hacks like that Gradius 3 one. You can get away with tons of things on the SNES CPU, you just gotta know how to program it, and I doubt Nova would ever struggle with slowdown in her games.

That said, getting a convincing 3D plane effect out of Mode7 graphics is definitely a lot harder than you might think, and you can easily spend most of your available CPU budget just building a HDMA table for it. Even if it's reusing rainwarrior's code, I think that bonus stage is super cool, really great job!

[NovaSquirrel | 30]

5 hours ago, Tanooki said:

@NovaSquirrel While other games were your usual $50 CIB more or less, that one due to the DSP1 chip having to be harvested added like $30 to the price of the package, so I believe it that it's an expense.

That's surprising, since I would expect that you'd be able to make a DSP-1 clone for a few dollars with a cheap microcontroller, since all it does is take math commands from a hardcoded list of options and give results.

42 minutes ago, Sumez said:

HiROM is probably favorable if you have some really large blocks of data in your ROM image, while LoROM is more convenient when your program code is spread out across multiple data banks. I seem to recall Nova having some other reasons for preferring HiROM though.

I wrote a script that automatically manages the ld65 config for me, so there's no convenience downside whatsoever to using HiROM so I might as well. The main benefit I like is that, for data that can't cross bank boundaries (like anything I send through DMA) there are fewer boundaries to avoid, so things can be packed down tighter.

42 minutes ago, Sumez said:

As for using a DSP-1 coprocessor or similar, I think it's something cool to experiment as a homebrew developer, but I also think if you got to use it, you really gotta be able to get some mileage out of it, and showcase some really cool effects, instead of just using it as a crutch to avoid the game running slow.
The SA-1 especially is a culprit that I think has been a little too good at enforcing that myth about the SNES CPU being horribly slow, what with hacks like that Gradius 3 one. You can get away with tons of things on the SNES CPU, you just gotta know how to program it, and I doubt Nova would ever struggle with slowdown in her games.

That said, getting a convincing 3D plane effect out of Mode7 graphics is definitely a lot harder than you might think, and you can easily spend most of your available CPU budget just building a HDMA table for it. Even if it's reusing rainwarrior's code, I think that bonus stage is super cool, really great job!

The main problem I ran into is that building the HDMA table and calculating sprite screen positions from tilemap positions are both very expensive without DSP-1 and it's hard to have both. With the Dizworld code, you lose 60 fps the moment you combine generating the table with calculating the position for more than two sprites. So I have to make game design compromises due to that, but that's fine with me - creatively solving problems imposed by limitations is part of what makes retro console dev fun, for me.

I kinda view most uses of SA-1 as a band-aid for making code run faster when you're not willing to rewrite the code or change the game design to allow for faster code. I'm sure Super Mario World's code is also a mess from what I've heard about it, especially with all the clunky stuff people have done to it to add features without rewriting chunks of the game. My game's in a different situation since I am actually writing everything with speed and my desired features in mind from the start, and I have profilers and such to help me find where I can improve things. I'm hoping that I can show that you can do cool stuff without a coprocessor, and that the SNES is plenty fast on its own.

Glad you like how it looks! In earlier versions of the mode 7 levels I wasn't sure if people would like it much because it was slower paced and grid based, but I think this newer game design is a much better fit alongside the fast paced 2D platformer gameplay.

Edited April 24, 2023 by NovaSquirrel

[Sumez | 2,950]

26 minutes ago, NovaSquirrel said:

I wrote a script that automatically manages the ld65 config for me, so there's no convenience downside whatsoever to using HiROM so I might as well.

I think being able to always assume I can access LoRAM variables as long as my DB value is the same as the PB one, is just a crutch I've gotten used to.
I guess it might be possible to define a program segmentthat always goes into the upper half of a bank, and then just stick to using the $80-$BF mirrors when executing from it?

26 minutes ago, NovaSquirrel said:

I kinda view most uses of SA-1 as a band-aid for making code run faster when you're not willing to rewrite the code or change the game design to allow for faster code.

Exactly, but that's not what most people who don't know the hardware will see. Instead they see "the SNES is too slow to run Gradius 3, so it needs a SA-1 hack to run properly. every SNES game now needs a SA-1 hack to avoid slowdown".

IMO the single biggest bottleneck for SNES performance is probably the "high table" for sprites, necessiating bit manipulating for every single sprite added in most games with a freeform approach to sprite positioning and size

 

Edited April 24, 2023 by Sumez

[NovaSquirrel | 30]

7 hours ago, Sumez said:

I think being able to always assume I can access LoRAM variables as long as my DB value is the same as the PB one, is just a crutch I've gotten used to.
I guess it might be possible to define a program segmentthat always goes into the upper half of a bank, and then just stick to using the $80-$BF mirrors when executing from it?

Yup, what I do is keep code in the upper half of each bank and execute it out of the $80-$BF mirrors.

My script looks at all of the segments that are used in the game but not defined to be in a specific bank, and then finds banks where they will fit (by using od65 to figure out how big each segment is), and it creates memory areas that split banks into data sections and code sections like this:

  ROM1: start = $c10000, type = ro, size = $fca7, fill = yes;
  ROM1_code: start = $81fca7, type = ro, size = $359, fill = yes;
  ROM2: start = $c20000, type = ro, size = $9574, fill = yes;
  ROM2_code: start = $829574, type = ro, size = $6a8c, fill = yes;
  ROM3: start = $c30000, type = ro, size = $8837, fill = yes;
  ROM3_code: start = $838837, type = ro, size = $77c9, fill = yes;

So if I mark segments as "put me in a LoROM area mirror" it really is like I'm programming LoROM.

7 hours ago, Sumez said:

IMO the single biggest bottleneck for SNES performance is probably the "high table" for sprites, necessiating bit manipulating for every single sprite added in most games with a freeform approach to sprite positioning and size

I'm using a technique to reduce how much CPU time that take up a little bit (have a second 512-byte buffer that can be written to with the same indexes, then combine bits afterward, skipping unused sprites), but yeah, the SNES sprite system is the biggest thing I would redo if I had the opportunity to. I'm imagining a world where they gave each sprite a whole extra byte instead of two bits, and then in addition to avoiding shifting it could contain more size bits, more tile number bits, a "affected by color math or not" bit...

[Tanooki | 4,933]

I never agreed with that idea the SNES was too slow and SA was the way, seemed like an overclocked fix using proprietary parts, seemed strange.  I get in some cases it had valid uses and it did make for nice copy protection too.  I kind of had a feeling poor optimization was a leading reason with some games, especially earlier ones rushed to that 91 early 92 period.  But it was some time later I learned of what emulators throw around as LoROM and HiROM where speeds ended up being restricted even lower which could compound the problem.  it was just recently I saw someone took the same attitude against SA1 band-aids and applied a basically so called cheap and easy hack to the Gradius III code to HiROM set it and wham, game ran excellent, on par with the SA1 overkill project showing it was senseless.  I've been hoping to see a rash of HiROM hacks to stuff, such as Konami shooters since Parodius has the problem too on the first one in particular.

[erac | 78]

Even if a DSP-1 MCU version only cost some dollars, you also have to amortize the engineer's cost to create it. Over 100 copies? Gonna be more than 30$.

[NovaSquirrel | 30]

22 hours ago, erac said:

Even if a DSP-1 MCU version only cost some dollars, you also have to amortize the engineer's cost to create it. Over 100 copies? Gonna be more than 30$.

That's fair; I usually look at everything from the perspective of just doing it all myself and learning how to do whatever I need, since that's how I do projects. And my work is all noncommercial, so my time doesn't have a price on it.

 

I added a minimal HUD showing how many items you need to collect for the goal (and later: what items you have) and I added a fan animation so the fans actually look recognizable. I think the minimal look is kind of nice.

[Sumez | 2,950]

3 hours ago, NovaSquirrel said:

And my work is all noncommercial, so my time doesn't have a price on it.

Oh to be young enough to be able to say this with a straight face