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

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

Post by HihiDanni »

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.
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.1 "Flying Kobold"

Post by psycopathicteen »

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

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

Post by HihiDanni »

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.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
User avatar
TOUKO
Posts: 306
Joined: Mon Mar 30, 2015 10:14 am
Location: FRANCE

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

Post by TOUKO »

Waho, i missed this :shock:

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

Re: Superfeather Game Engine v0.5.2a "Flying Kobold"

Post by HihiDanni »

Download link was broken for a bit, should be fixed now.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Re: Superfeather Game Engine v0.5.2b "Flying Kobold"

Post by HihiDanni »

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!
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
Erockbrox
Posts: 397
Joined: Sun Nov 23, 2014 12:16 pm

Re: Superfeather Game Engine v0.5.2b "Flying Kobold"

Post by Erockbrox »

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

Re: Superfeather Game Engine v0.5.2b "Flying Kobold"

Post by HihiDanni »

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.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
User avatar
HihiDanni
Posts: 186
Joined: Tue Apr 05, 2016 5:25 pm

Re: Superfeather Game Engine v0.5.2b "Flying Kobold"

Post by HihiDanni »

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:
Currently, sprite handling is one of the most performance-intensive operations, and I don't see this changing anytime soon. While I have done my best to try and optimize the sprite code while still keeping it flexible, you will need to make sure you're not calling the sprite functions when you don't need to. For objects using metasprites, this is even more important, as 128 objects each displaying 4-sprite metasprites may run the sprite code up to 512 times, which is guaranteed to slow your game down.

So what exactly is happening? Well, the OAM format only has nine bits for the X coordinate, and eight bits for Y, so we need to ensure that each sprite we want to display is actually on-screen. Before this, of course, we avoid doing any work if we know that we have already filled up the OAM with 128 sprites.

The result is that if objects are attempting to draw way more than 128 sprites, many of these sprites won't show up. But as objects leave the screen, CPU usage actually increases! How can that be? Well, normally we don't have to do the range test on much more than 128 sprites, because we hit the 128 sprite limit early. But now that some are off-screen, we end up testing the range of many more sprites before we hit the sprite limit! Therefore, make sure you either destroy or prevent drawing of objects that are outside the screen.
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.
Attachments
superfeather-ex-metaspritebounds.sfc
(256 KiB) Downloaded 187 times
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
HelloDarkSNES
Posts: 1
Joined: Sun Jan 28, 2018 3:47 pm

Re: Superfeather Game Engine v0.5.2b "Flying Kobold"

Post by HelloDarkSNES »

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

Re: Superfeather Game Engine v0.5.2b "Flying Kobold"

Post by HihiDanni »

HelloDarkSNES wrote: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.
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.
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 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.
SNES NTSC 2/1/3 1CHIP | serial number UN318588627
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Superfeather Game Engine v0.5.2b "Flying Kobold"

Post by calima »

HihiDanni wrote: Only problem is that the cc65 compiler doesn't seem to support 65816. Hopefully that can change soon.
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.
User avatar
Drew Sebastino
Formerly Espozo
Posts: 3496
Joined: Mon Sep 15, 2014 4:35 pm
Location: Richmond, Virginia

Re: Superfeather Game Engine v0.5.2b "Flying Kobold"

Post by Drew Sebastino »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Superfeather Game Engine v0.5.2b "Flying Kobold"

Post by tepples »

Espozo wrote:What's even the point of trying to make a compiler for the 65816?
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?
creaothceann
Posts: 611
Joined: Mon Jan 23, 2006 7:47 am
Location: Germany
Contact:

Re: Superfeather Game Engine v0.5.2b "Flying Kobold"

Post by creaothceann »

You might also be able to do the game logic with macros.
My current setup:
Super Famicom ("2/1/3" SNS-CPU-GPM-02) → SCART → OSSC → StarTech USB3HDCAP → AmaRecTV 3.10
Post Reply