Superfeather Game Engine v0.5.2b "Flying Kobold"

A place where you can keep others updated about your SNES-related projects through screenshots, videos or information in general.

Moderator: Moderators

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

Superfeather Game Engine v0.5.2b "Flying Kobold"

Post by HihiDanni »

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/supe ... 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!
Last edited by HihiDanni on Sat Dec 23, 2017 6:37 pm, edited 9 times in total.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Superfeather Framework v0.5 "Flying Kobold"

Post by psycopathicteen »

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

What exactly does the lua build do?
User avatar
thefox
Posts: 3134
Joined: Mon Jan 03, 2005 10:36 am
Location: 🇫🇮
Contact:

Re: Superfeather Framework v0.5 "Flying Kobold"

Post by thefox »

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.
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi
User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Re: Superfeather Framework v0.5 "Flying Kobold"

Post by HihiDanni »

psycopathicteen wrote:What exactly does the lua build do?
It runs ca65 and ld65 on the files you tell it to. The configuration is inside config-build.lua.
thefox wrote:You might get better visibility if you host the source on one of the common repository hosting sites, like GitHub, GitLab, or Bitbucket.
A public git repository will happen at some point.

Ngin looks pretty cool! Do you happen to have compiled versions of the sample programs?
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Superfeather Framework v0.5 "Flying Kobold"

Post by Drew Sebastino »

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... :lol:
User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Re: Superfeather Game Engine v0.5 "Flying Kobold"

Post by HihiDanni »

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

Topic subject updated.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Superfeather Game Engine v0.5 "Flying Kobold"

Post by psycopathicteen »

I find it interesting how little code it takes to make an object handler when you're using X compared to DP.
Erockbrox
Posts: 397
Joined: Sun Nov 23, 2014 12:16 pm

Re: Superfeather Game Engine v0.5 "Flying Kobold"

Post by Erockbrox »

I will totally look into this. Hopefully it is easy and advanced enough for me to use.
User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Re: Superfeather Game Engine v0.5 "Flying Kobold"

Post by HihiDanni »

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.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Superfeather Game Engine v0.5 "Flying Kobold"

Post by psycopathicteen »

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.
Erockbrox
Posts: 397
Joined: Sun Nov 23, 2014 12:16 pm

Re: Superfeather Game Engine v0.5 "Flying Kobold"

Post by Erockbrox »

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.
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Superfeather Game Engine v0.5 "Flying Kobold"

Post by psycopathicteen »

There's no platform collision yet, but once there is, it looks like it should be easy.
User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Re: Superfeather Game Engine v0.5 "Flying Kobold"

Post by HihiDanni »

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.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
psycopathicteen
Posts: 3140
Joined: Wed May 19, 2010 6:12 pm

Re: Superfeather Game Engine v0.5 "Flying Kobold"

Post by psycopathicteen »

I don't know how to use LUA, so how do I get it to run the compiler?
UnDisbeliever
Posts: 123
Joined: Mon Mar 02, 2015 1:11 am
Location: Australia (PAL)
Contact:

Re: Superfeather Game Engine v0.5 "Flying Kobold"

Post by UnDisbeliever »

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.

HihiDanni wrote:How useful are the manual and examples? Is there anything I need to explain in more detail?
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:

Code: Select all

 jsr addr, jmp addr              | code0lo, code0hi | code0hi | code1lo, code1hi | code1lo
 access function pointers in RAM | NO               | YES     | NO               |  YES 
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.

HihiDanni wrote: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)?
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).
Post Reply