Superfeather Game Engine v0.5.2b "Flying Kobold"

So initially I wanted to release my SNES framework once I had completed all of the features I wanted, but given that folks are mostly still at the stage where they're trying to get simple sprites on-screen, I figure that releasing it in its current state is bound to help at least somebody. Therefore, presenting...

Superfeather

Latest version: 0.5.2b "Flying Kobold"
Download: https://cosmicchipsocket.com/files/superfeather-0.5.2b.zip

This archive includes precompiled binaries, so please verify checksums!

MD5: 7b2595adc7edd8b58852a28603130f29
SHA1: 8a556cac312e03dfa8ea978bc0f8a5615b20ebed
SHA256: 7c0ff5cb69f42e5bdac715d704c37362f65620387fab0a3d3e776c240896f308

Public git repo: https://github.com/cosmicchipsocket/superfeather


From the manual:

Superfeather is a framework designed to help you create fast and colorful 16-bit games for bsnes/higan, snes9x, and of course real hardware. It includes functionality common to many games, such as a gameloop, object handling system, and sprite management. The three core principles behind the framework are performance, flexibility, and convenience.

• Performance - The engine should run well. It should be able to scale to demanding genres such as shmups.
• Flexibility - The engine shouldn't try to make too many assumptions about the type of game running on top of it. Game code should be allowed to use as much or as little of the functionality as it needs. Engine tunables should be made available via constants.
• Convenience - The engine should provide working implementations of common and useful features such as metasprites and object management. Getting content into the game should be relatively straightforward, and tools made available for this purpose.

In practice, these principles sometimes overlap - for example, the idea that game object code only use as much functionality as it needs falls under both flexibility and performance. Sometimes, however, these principles may conflict with one another. If a subsystem is designed around performance but is not very convenient to use, that makes it a candidate for being reworked to fit both of these principles.

The following features are currently implemented:

• Gameloop - Functional VBlank and controller input handling, plus the ability to jump between self-contained scenes.
• Game Objects - Create and destroy objects, and give them unique behaviors.
• Sprites - Define OAM data for sprites, and then draw them at object positions.
• Metasprites and Animations - Define extended sprite data for larger, animated graphics.
• DMA Queue - Request VRAM transfers to occur during VBlank.
• Audio Driver - Use SNESGSS to play music and sound effects.
• Crash Handler - Debug BRK crashes and other errors you determine to be fatal.
• Buildsystem - Simple Lua-based buildsystem with easy configuration.

These features may show up in a future release:

• Dynamic Sprites - Automatic sprite streaming for sprite animations that would not normally fit in VRAM.
• World System - Construct large scrolling levels out of metatiles, place and spawn objects.
• Collision Data Structures - Indexing for fast object-to-object collisions, necessary for shmups.
• Data Compression - Get the most out of your ROM size, with limited impact on loading times.
• Audio Improvements - Sample streaming, soundbanks, and precise tempo.

Known issues:

• Currently, if VBlank time is exhausted, the engine forces a fatal error. This is to help developers avoid the DMA/HDMA crash on CPU revision 1 model hardware. There are probably better ways to avoid this, but they need to be investigated.
• A Linux binary of GFX2SNES is not being shipped currently. For now it is wrapped in Wine.
• Heartcore Editor does not have an undo feature (yet). Please take care to save your files often.
• Communication with the SNESGSS driver may introduce significant latency, as much as 5-10% CPU, depending on timing and the state of the audio driver (e.g. whether music is playing). A future version of the framework will likely use non-blocking coroutine-based polling to work around this issue.
• The pseudo-RNG needs to be rewritten to be smaller and faster.
• The buildsystem does not currently generate a checksum for the resulting output.

Right now I have no idea how easy or hard this thing is to use, and I would love to continue developing the engine's features and API in response to user feedback, so feel free to try it out!

It looks pretty good. I'll try playing around with it a little more.

What exactly does the lua build do?

Pretty cool stuff. Looks like many of the goals align with what I was/am trying to do with my Ngin project for NES.

You might get better visibility if you host the source on one of the common repository hosting sites, like GitHub, GitLab, or Bitbucket.

It runs ca65 and ld65 on the files you tell it to. The configuration is inside config-build.lua.


A public git repository will happen at some point.

Ngin looks pretty cool! Do you happen to have compiled versions of the sample programs?

You might want to add "SNES game engine" or something similar in the title, because I had no idea what this was before I clicked it.



...Man, I'm a slacker...

Good point. (I had someone else ask what this was too)

Topic subject updated.

I find it interesting how little code it takes to make an object handler when you're using X compared to DP.

I will totally look into this. Hopefully it is easy and advanced enough for me to use.

So! A few things I'd like to see feedback on:

How useful are the manual and examples? Is there anything I need to explain in more detail?

Is there anything I'm doing wrong? Is there anything I can change or improve to better fit the three core principles (Performance, Flexibility, Convenience)?

Is there a better way to create read-only data structures in CA65? Currently I'm using macros for them but this means that you have to have the whole entry on one line (which is particularly bad for the PpuDefs). You also have to refer to the definition of the macro to know what the parameters are.

I'm going to take a short break, and then I'd like to start working on 0.6 which will add a VRAM engine and a dynamic metasprite editor. These things alone should greatly increase the utility of the engine. Scrolling levels will be 0.7 most likely.

I've been looking though the code, and I'm wondering what an object pool is.

EDIT: Oh sweet, there is even a manual, to explain everything.

I haven't downloaded yet, but I will soon so I'm going to ask. Is there a level editor for this engine?

Also there are tons of custom coded sprites and custom blocks over at super mario world central, how easily could these resources be converted to work with your engine? It's the same assembly language so I'm sure that eventually some resources could be converted to a homebrew engine.

There's no platform collision yet, but once there is, it looks like it should be easy.

A level editor will come in a future release. It may take some time because scrolling level support is a big can of worms but it's something that I definitely want to do! Getting it all working is exciting to think about!

Anything from another engine will need conversion. For graphics, it will be easiest if you have the original images as you'll be able to import those into Superfeather via the editing tools. One of my goals is to make it easy to add things to your game.

I don't know how to use LUA, so how do I get it to run the compiler?

This is awesome, we need more SNES homebrew code in the wild.

I've read through the code and understand how the engine works. I love the simplicity of this engine (unlike mine which is a little all over the place). I hope you keep it up as the engine expands.

I did have a bit of trouble recognising the start of a routine due to the lack of spacing. Would it be possible to add a second blank line in-between the routines to improve readability?

I'll code up a short game with your engine over the next two weeks and report my findings as they develop.



You need to expand the Memory Bank Details section.

The code bank table is a little confusing. I do not believe a beginner to the 65816 would read it and realise that they cannot jsr addr or jmp addr from the hi bank to the lo bank.
Honestly, I'm not sure how to properly explain it myself, but I think adding these two rows to the table would help:

The phrase "Indirect addressing via RAM is not available when running code in Code 0 Lo or Code 1 Lo" is also confusing. I initially though you were talking about direct page indirect address but after scratching my head for a few minutes realised you were talking about function pointers.

I understood the rest of the manual just fine.



I do not like the fact I have to pass the object pool index to DeleteObject. This prevents me from writing a routine for deleting objects when they go outside the active window and reusing it across different pools (unless I store the pool in the object, which complicates the object's init routine).

Thanks!


I'm a big fan of line breaks to visibly separate portions of code so this is on my todo list.


That's a good idea. I'll try to be more explicit about referring to function pointers. It's one of those gotchas I noticed while I was trying out the feasibility of doing HiROM program bank with LoROM data bank.


When I designed the object pool system, my intention was that a given type of object would only ever be used in one specific pool and that DeleteObject would be called by the object itself. But since CreateObject is pretty fast, I could probably afford to do some record keeping there so the user doesn't have to.

I had also envisioned the objects themselves taking care of the out-of-screen logic, since AddSprite does a preliminary range check of its own. If the function exits with the overflow bit set, you can delete the object right there, or do a more precise check (since the range used by AddSprite is a bit... asymmetric). This is the technique used in the Bounceballs example.

I asked this question a few posts ago.

You don't need to know any Lua. You should just be able to run the build.sh or build.bat (depending on your platform) and it will run the Lua script for you.

I tried clicking on build, but the ball bouncing demo looks exactly the same.

You'll have to be a bit more specific than that. It sounds like you opened the .bat file via the shell. Command Prompt windows opened this way will self-close after they're done. You probably want to open the Command Prompt yourself and run the .bat file from there. Don't use an Administrator prompt or you may run into issues with user permissions on any files generated.

All I'm getting is this.

So as it turns out, Wine CMD is not an accurate substitute for Windows CMD. I tested the buildsystem in Wine and it handled the forward slashes just fine but they end up confusing native Windows. This should be fixed in 0.5.1.

New version also has a few small changes to the documentation. See original post for the download.

I will make you a deal.

If you can give me a level editor that looks equivalent to Lunar Magic (the super mario world editor) with drag and drop support for sprites and blocks then I will make a professionally made SNES game. Deal?

Lunar Magic screen shot:



Also, on super mario world central, anyone can upload custom sprites and blocks onto their database and these resources can easily be used in anyone's game.

For your game engine, it would be great if a similar setup were possible, for example a site where anyone can upload their sprites, blocks, code for others to use and share in their own games.

From a level designer's perspective, what sort of functionality are you looking for? It will be easier to meet your needs if you provide a more concrete list of requirements.

My initial plan was to use a metatile system as the basis for levels but I could also add support for in-memory direct 16x16 tiled levels if you'd like.

Just do this, lol. If this game engine is meant for your typical person who just wants to make an SNES game but doesn't know much about programming or cares about compression (I know I don't), then they're just going to want to edit the tile map directly. You might as well also support 8x8 tiles while you're at it.

Reading the code in the game engine, I know the stuff like the metasprite routine isn't meant to be touched by the majority of people, but do you think that maybe you should make all the names not so shorthanded? I'm sure you explain what everything does in the documentation, but it's a bit intimidating in my opinion.

This might be overkill to you, but here's a sample of my code. I made it so I'm biased, but it's very readable to me.


Also, I use a lot of these to break up my routines:


Just putting ";===" makes it apparent that something new is starting, but it's not very obvious unless you look for it.

Can you give me an example of a routine that is using too much shorthand? I need some examples before I'll know what to fix and how. The only big difference I notice between your style and mine is that you use snake_case for function names while I use CamelCase.

I already mentioned that whitespace between routines is something I'd like to fix.

The big issue with raw tilemaps is that they're not very scalable as they take up a lot of memory. This is specifically why metatiles exist, which is how games like Sonic can have such large levels. But storing a raw array of 16x16 tiles lets you edit them more easily, especially during gameplay, which makes that method more suitable toward Mario or Zelda type games. Depending on how the map is stored in ROM, the editor may or may not have direct tilemap access, if the raw array is merely the target of load-time decompression.

I took a quick look at a video of Lunar Magic and it seems that terrain is built out of resizable rectangular elements. It's a novel idea, though you kind of lose the raw tile access (at least, during edit time). And when you decompress to a raw tilemap you still have the same scalability issues. But I like this as well as the metatile format so I want to include both of them, so users can choose which would be best suited for their game.

I will make a video describing what Lunar Magic can do.

https://www.youtube.com/watch?v=gANeGtb3F0E&feature=youtu.be

I forgot to add that you can:

- highlight multiple blocks/sprites and move them around in a group
- highlight blocks/sprites and copy and paste them, even from one level to another
- hit a button on the keyboard and run an emulator of your choice with your game loaded

The raw SNES tilemap editor already features multi select and copy/paste so I'll be sure to add support for that in the level editor too.

I'll look into a button to run the game. Edits will be done to separate files so changes will need reassembly of the ROM. My current process is to keep a console window open, click on it and press Up + Enter, then click on bsnes-plus and press Shift +Tab to reload the ROM. I can probably streamline it for other users though.

I'll watch the video itself when I'm not on mobile.

I just thought of something. Are you going to have some kind of sprite priority sorting?

You can already do static sorting through the use of object pools. But dynamically sorting stuff would be very useful for both beat-em-ups and RPGs (strangely, neither of these are cases I had considered). I'll see what I can come up with.

Or a fake 3D level in a shmup.

I thought that the only efficient way of doing this would be with an OAM linked list, and a table of entry points for each depth level.

Just finished up version 0.5.2, which has a few tweaks and new editor features:

• Added a "create blank raw file" feature to the editor. Press N on the initial screen to use it.
• Added the ability to paint tilemaps with the mouse, plus a visual tile picker screen, to the tilemap editor.
• Decorated the top of each function in the engine and example source to improve readability.

Download link in the original post.

Waho, i missed this

impressive stuff .

Download link was broken for a bit, should be fixed now.

A small update: there's now a public git repo!

https://github.com/cosmicchipsocket/superfeather

The git version already fixes several bugs from the current release (0.5.2). See CHANGELOG for details, and ROADMAP for what to expect from upcoming releases!

Does it have a drag and drop sprite and block GUI level editor yet? If yes, then you got me sold, if no then I will have to wait a little more.

The ROADMAP currently has it listed for version 0.7. Scrolling level support is not the easiest thing to implement so you'll have to wait a bit longer. Sorry about that.

Hi everyone. The holiday season has sucked up my time but I've picked up the pace lately. This month I've been making changes to fix bugs, make the API easier to understand, and add more functionality to sprites and features to the editor.

A few days ago I implemented an optimization which I think is worth posting about here: you can now do a bounding box pre-check to see if the overall metasprite is on the screen at all before drawing it. Folks who have read the manual may have noticed this blurb under the "Performance" section:


I wrote a test example for this as well as the optimization, and the results were interesting: There is some overhead to the operation: drawing 32 metasprites increases CPU usage by about 4% (though afterward you'll hit the 128 hardware sprite limit, so it won't increase further for metasprites using 4 hardware sprites). However, CPU usage for when the metasprites are completely outside the screen is dramatically reduced: In the most extreme case it results in a decrease from 100% CPU to 25% CPU overall. For a bunch of objects trying to draw 512 hardware sprites total, I'd say this is pretty good.

The optimization works best for objects that average at least 3 or 4 hardware sprites per metasprite - using this on metasprites with just one or two hardware sprites will be a pessimization.

Not too long ago I had watched someone play a bit of Parodius. There was a part with vertical scrolling that was slowing down despite almost no objects being in view (they were mostly below the screen). So I have a new theory that a lot of developers just didn't apply this kind of optimization to their games.

Anyway, here is the example if you'd like to play around with it.

Hello HihiDanni,

you're doing a great job, almost exactly what I was (almost desperately) looking for. I am an experienced developer in some languages and technologies, but I just don't have time to learn assembler and tools just for my hobby project :( Ideally, I was hoping for compiler from some high-level language, ideally managed one. Strange thing with SNES - CPU is 27 years old, it has large community (at least as it seems to me), but homebrew development is almost on same stages as in 90's - asm or nothing... Even much more complex i386 now can be fully emulated in JavaScript, but not this one.
Have you thought about crowdfunding your development? In my searches for SNES framework I've found NESMaker - project with same goals for NES with more than 400% funding! Probably it was discussed on this board in NES section, but I'm here just for SNES, so didn't read them.
I'm ready to fund this project with 3-digits amount if you'll start it.

Thanks!

I know that there are one or two C-based frameworks - I originally toyed around with devkitsnes before getting my feet wet in SNES assembly programming. The problem is that it uses WLA-DX as the underlying assembler. I'm sure WLA is good for the 8-bit targets it supports but its 65816 support needs work - it does a poor job with tracking the register size and therefore is prone to generating crashy code. It also does not track the size of symbols which renders some of its more useful features basically useless. The C compiler (tcc) also does not seem to be very complaint - it doesn't even short circuit if statements, which would have improved its lackluster performance. I'd like to see if cc65 as the C compiler and assembler gives better results. From my experience, ca65 has been pretty reliable so far. Only problem is that the cc65 compiler doesn't seem to support 65816. Hopefully that can change soon.


Thanks for the thought, but I'm not currently looking to crowdfund this. It's mostly just a personal hobby project (although one that I hope people find useful).

It's cool to see projects like NESmaker, though. Game making tools such as Klik & Play are what got me into programming in the first place. The design of NESmaker looks reminiscent of the DOS-based RSD Game-Maker - a lot of it is about designing assets and using a property system to create tile and object behaviors.

This is likely not going to happen. None of the active contributors are interested in that, and I'm not aware of any outsiders working on that either.

What's even the point of trying to make a compiler for the 65816? It's not bullshit complicated like modern x86 processors where you have instructions with 13 letter opcodes. The SNES is a pain in the ass to program for, but the problem is not the chip itself, but everything around it, (stupid memory mapping, weird hardware) and I don't see how C can solve this. Well, a good reason would be that far more programmers know C than 65XX assembly, but it's not incredibly difficult to learn.

For one thing, to be able to share game logic between your Super NES game and your Genesis, GBA, or PC port of the same game. Otherwise, if you write the 65816 assembly version and the C version separately, how would you go about proving them equivalent?

You might also be able to do the game logic with macros.

See the many 10-page threads on this very topic.

Congrats on the progress, your engine looks awesome. For now, i'm toying with C, but I hope someday to be able to code in ASM to use your engine in a game project



Please excuse the newbie question, but how can you track CPU usage for SNESdev? Is there an emulator/debugger able to do that?

(I'm used to rely on BGB for GBdev, but I haven't found a SNES emulator with a similar feature)

You can latch the HV counter just before you wait for vertical blanking and display how many scanlines are free. This works even on hardware.

Correct, I latch the H/V counter to get whatever the current scanline is when I'm done processing the frame before VBlank. However, I also use a lookup table to translate that into a human-friendly value. You can find that lookup table here.

VBlank happens when the vertical counter is at V=225. However, the counter actually ranges from 0 to 261 (262 if using interlace). And depending on the length of your VBlank routine, you might finish your VBlank processing before scanline 0, so after V=225 you need to wrap your CPU utilization value back to 0. This lookup table takes care of that for you.

Also keep in mind that if you have slowdown (i.e. VBlank fires before you're finished with the frame), the CPU usage value won't be 100%, but will show you how much CPU you're going over by (assuming you only miss VBlank once, anyway). For this demo however, I check if there's been slowdown and cap the CPU meter at 100%.

P.S. I would appreciate it if this topic wasn't used to start language wars.

Thanks a lot for the tip!
Counting the "idle lines" to estimate CPU load is very clever - I wouldn't have thought of that myself!
Is that how people did it in the 90's too?

@HihiDanni, I'll try to use your LUT to count the CPU usage with my C code.

That and playing with the border color, color math, or other PPU features to get a visual sense of where the beam is when the code finishes. Even the NES has limited color math.

I think an issue is not very many people know how to make a compiler.

Correct. Even those of us who have attended college may not have taken compiler design as an elective. The only required language implementation course at my alma mater was "Programming Language Concepts", which spent 10 weeks on two things: 1. learning functional programming paradigm and 2. writing a Scheme interpreter in Scheme. Any less skilled or less experienced programmer can learn to write an interpreter.

So I guess it's a good idea to include enough basic functionality in this engine that programmers using it won't miss not having a compiler.

EDIT: Toned down the language

True, not everyone is an expert on how to write a compiler, but there is still some groundwork already - the cc65 compiler. Obviously it doesn't support the 65816. It'd need to be adapted to the new instruction set, registers, and programming model, but at the very least it serves as a rough guideline.

I suspect that a lot of the motivation behind the cc65 project is the large platform support offered by targeting the 6502 architecture. The 65816 unfortunately has seen a lot less use in computers, so it's not surprising that there isn't a ton of interest there. Should SNES homebrew kick off however, it might attract someone willing to take on the project of adding the missing 65816 support. Not saying it will happen, but it'd be cool, and I think worth striving for.


Is this the goal of the engine? Well, kind of... This is a game engine, a library, an abstraction layer. It's quite a bit different from a programming language, and not directly comparable. Writing your code in C won't save you from needing to write or use a game engine in some capacity. Nobody wants to fiddle with raw OAM manually every time they want an object to move across the screen (especially with the high OAM table). That's what abstraction layers are for. It's true however that a good library can make an otherwise not so great programming language more enjoyable to use (Qt and C++ for example). So yes and no. This engine is in assembly, but mostly because I want a solid foundation. Maybe someone could write some C bindings on top of it, or something similar. I think that'd be pretty neat. In any case, I like to think of this in more broader terms, i.e. making SNES programming easier, not just for assembly specifically.


Was this necessary?

Does cc65 only run in 8-bit mode?

From the documentation for the cc65 compiler:


If you browse the source code there's a lot of assumptions made about the register set, so it would need some work to adapt it for the 65816. Still though...

@HihiDanni, the NESmaker kickstarter was pretty successful. It had about 2,000 backers and $200,000+ raised. I think it would be great if you made a SNESmaker Kickstarter for your SNES game engine. What if it blew up and become really successful? Obviously people are interested in this kind of thing.

But you'd still need a compelling original Product Identity (that's IP spelled backwards) with which to test the engine, the way Mystic Searches was for NESmaker.

More generally, I intend this to be a project, not a Product. Identity I'm fine with (I had fun coming up with all the goofy codenames for each version), but ultimately I'm making this because it's something I decided to work on in my free time.

A fully-fledged "SNESMaker" would be scope creep for this project. I simply don't have the time and energy for something like that, not to mention running a campaign and the whole nine yards. Once you have expectations for deliverables (especially ones you are financially and/or legally responsible for), it kind of stops being a hobby.