Homebrew 2D animated characters using Esoteric Software Spine

[Jomeady]

I was trying to port a PC visual novel to the DS (don't ask why, I was bored) and during testing I found out that Spine (software the game uses for character animation) seems to work on the DS. Not sure how well it would work on actual hardware though.

Spine works by creating a mesh that gets animated and textured from a texture atlas. You get 3 files: The texture atlas, atlas file which tells the runtime where each part of the character is in the atlas and a json file which contains information about the meshes, skeleton, animation etc.

All I'm doing is that I'm downscaling the texture atlas to fit in the VRAM banks (in this case 1024x1024 downscaled to 512x512) and running it through a little tool I made that dithers the texture to BGR555 (I'll definitely release that one after some polishing). I then store the atlas and json files in memory and load them into the runtime and do some weird stuff to render it. I don't think I can go too deep into specifics, because the Spine license agreement says that you can only mess around with the runtime if you have a valid editor license. So, see you once I have enough money to waste. Or once I find some sort of alternative.

Either way, it's an interesting way to animate characters, and I'm wondering, has anyone attempted anything similar on the DS?

 

[FAST6191]

That sounds more like someone playing with 3d animations but doing so in a 2d plane. Bunch of commercial games did this (New Super Mario Brothers being among the more prominent) but I am not aware of much in the way of homebrew going down this path. Most 3d things in homebrew world were 3d, and 2d stuff stuck to traditional sprite sheets, albeit with the perks of DS 2d aspects being able to handle some quite custom tile sizes and a fair few of them at once so you could do some fairly exotic stuff if you are more used sprite animations on a NES where swapping a top half and bottom half and maybe some palettes was as exotic as it gets (go grab a phoenix wright game and look at the VRAM, or maybe sprites inside the game -- it can be just the eyes that get swapped out).

 

[Nikokaro]

I was trying to port a PC visual novel to the DS (don't ask why, I was bored)

Out of curiosity, what visual novel did you want to port? Did you want to do it seriously, all the way to final completion, or was it just a momentary hobby? Did you know that you can also, and maybe more simply, use VNDS software?

 

[Jomeady]

Out of curiosity, what visual novel did you want to port? Did you want to do it seriously, all the way to final completion, or was it just a momentary hobby? Did you know that you can also, and maybe more simply, use VNDS software?

I was trying to port Amorous. Not sure how many other VNs are out there that use Spine.

I'm still unsure of how seriously I want to take it, but I'm going to try to port as much as I can, though there are already a bunch of projects I just dropped midway through that I should definitely pick up on again at some point.

I knew there already were some options of making visual novels on the DS, but I wanted to do it from scratch (starting off with libdns) so I could learn more about how the Nintendo DS works.

When I started off, I honestly had no idea that the DS had a bunch of VRAM banks that you have to individually assign to wherever you currently need them and now I know all that and where each can be assigned, mostly thanks to mtheall's VRAM Banks Selector website. I'm still not sure how CPU memory works, and I did already manage to get my very first memory leak, but I'm sure I'll figure out all that as I go on.

That sounds more like someone playing with 3d animations but doing so in a 2d plane. Bunch of commercial games did this (New Super Mario Brothers being among the more prominent) but I am not aware of much in the way of homebrew going down this path. Most 3d things in homebrew world were 3d, and 2d stuff stuck to traditional sprite sheets, albeit with the perks of DS 2d aspects being able to handle some quite custom tile sizes and a fair few of them at once so you could do some fairly exotic stuff if you are more used sprite animations on a NES where swapping a top half and bottom half and maybe some palettes was as exotic as it gets (go grab a phoenix wright game and look at the VRAM, or maybe sprites inside the game -- it can be just the eyes that get swapped out).

The way it works here is the polygons are used basically just to deform the textures, so you never see the polygons directly.
I would definitely be interested in messing around with sprite sheets as well at some point, so I'll have to try something different for that.
The Phoenix Wright games were what got me into DS in the first place, though I never tried looking at the sprite sheets in VRAM before, but swapping out parts of the sprites sounds like a logical thing to do on such a tight memory budget. How would I even go around viewing the VRAM in the first place?

 

[Nikokaro]

I was trying to port Amorous

At first I thought you were referring to the old hentai VN "Amorous Professor Cherry", which is actually now freeware, and I was pleasantly surprised.
Instead, on second thought, I think you're referring to a newer, more modest VN, certainly not freeware.

 

[Jomeady]

At first I thought you were referring to the old hentai VN "Amorous Professor Cherry", which is actually now freeware, and I was pleasantly surprised.
Instead, on second thought, I think you're referring to a newer, more modest VN, certainly not freeware.

It is actually a free VN on Steam and itch.io, but I wouldn't really recommend playing it. I mostly just do it for the memes.

 

[FAST6191]

I was trying to port Amorous. Not sure how many other VNs are out there that use Spine.

I'm still unsure of how seriously I want to take it, but I'm going to try to port as much as I can, though there are already a bunch of projects I just dropped midway through that I should definitely pick up on again at some point.

I knew there already were some options of making visual novels on the DS, but I wanted to do it from scratch (starting off with libdns) so I could learn more about how the Nintendo DS works.

When I started off, I honestly had no idea that the DS had a bunch of VRAM banks that you have to individually assign to wherever you currently need them and now I know all that and where each can be assigned, mostly thanks to mtheall's VRAM Banks Selector website. I'm still not sure how CPU memory works, and I did already manage to get my very first memory leak, but I'm sure I'll figure out all that as I go on.


The way it works here is the polygons are used basically just to deform the textures, so you never see the polygons directly.
I would definitely be interested in messing around with sprite sheets as well at some point, so I'll have to try something different for that.
The Phoenix Wright games were what got me into DS in the first place, though I never tried looking at the sprite sheets in VRAM before, but swapping out parts of the sprites sounds like a logical thing to do on such a tight memory budget. How would I even go around viewing the VRAM in the first place?

Most emulators will have a VRAM viewer, no$gba debug and at least Windows desmume (some Linux options lacked things here) certainly will. That or straight memory if you prefer the hex approach to life.

As far as learning how CPU memory works then do you mean the small bank of it you can assign or general setups? Either way it is a bit of a shame nobody seems to have linked you gbatek before now
http://problemkaputt.de/gbatek.htm
Bedtime reading for basically every ROM hacker and homebrew dev that aspires to go beyond Lua that one.

Also it is for the GBA but... enough carries through
http://www.coranac.com/tonc/text/video.htm
might as well throw in another GBA doc but something to note
http://pineight.com/gba/managing-sprite-vram.txt

 

[Sweater Fish Del]

That sounds more like someone playing with 3d animations but doing so in a 2d plane. Bunch of commercial games did this (New Super Mario Brothers being among the more prominent) but I am not aware of much in the way of homebrew going down this path. Most 3d things in homebrew world were 3d, and 2d stuff stuck to traditional sprite sheets

Actually tons of homebrew and commercial games use the DS's 3D hardware to do sprites. You usually don't notice it because they use a single flat polygon for each sprite with a hand-drawn texture placed on it, the result ends up looking identical to the actual 2D sprite mode. New Super Mario Bros is something different. The characters there are full 3D models, but viewed from the side.

Using a 3D engine for fully 2D work gets around on-screen sprite number limitations and allows complex sprite deformation effects, so it's very common and has been done in 2D games for a long time, going all the way back to the original Playstation. The main drawback on the DS is that the 3D hardware can only be used on one screen at a time, while the true 2D mode can be used on both screens simultaneously.

 

[FAST6191]

Actually tons of homebrew and commercial games use the DS's 3D hardware to do sprites. You usually don't notice it because they use a single flat polygon with hand-drawn texture on it, so it ends up looking identical to the actual 2D sprite mode. New Super Mario Bros is something different. The characters there are full 3D models, but viewed from the side.

Using a 3D engine for fully 2D work gets around on-screen sprite number limitations and allows complex sprite deformation effects, so it's very common and has been done in 2D games for a long time, going all the way back to the original Playstation. The main drawback on the DS is that the 3D hardware can only be used on one screen at a time, while the true 2D mode can be used on both screens simultaneously.

I really don't see much commercial stuff do this for the DS (PS1 different story entirely but its hardware was geared... actually more like done to the exclusion of all others). For the DS all the textures, graphics and more I usually see playing with 2d formats (3d texture formats overlap a bit but not much -- most 2d stuff having very little in the way of alpha) and 2d hardware (playing with BG/OAM registers and all the rest), 3d hardware then mainly being used for things like fun backgrounds (Castlevania probably being the early example) or bonus modes if they are not the forefront of the game.
I haven't undertaken any kind of formal analysis here so it could be like the time I debated how much of the GBA was ARM mode and THUMB mode (turns out in any way you care to slice it save maybe the shiniest aspects of code then way more THUMB than I thought/was used to), and before I do anything like that with a whole library I still want to analyse every game to see how many do or don't contain SDAT audio. That said I made a bit of a hobby of pulling apart DS games as they were being released, and helped a fair few others over the years, so it would be a bit of a shock.

I tend not to play ROM hacker for homebrew games but when grabbing source bundles for mirroring things I also tended not to see either the 3d libraries used (granted I would not necessarily have looked for the devkitpro/devkitarm aspects) or art rolling that way/build scripts using such things to turn artwork into a suitable format/res for the hardware.

 

[Sweater Fish Del]

I don't think you'd see any difference in the graphics assets between 2D games that used the 2D hardware and ones that used the 3D hardware. You're literally just placing sprite art onto a single polygon, so you still need the same sprite art assets, including animation frames and everything. Admittedly, I don't really know how many commercial games did this. I'm just assuming it's a lot since it was such a widespread practice in the industry by then. A lot of people have never programmed using a classic sprite/tilemap mode these days and that was already becoming true in the DS's time. Most 2D games are either brute-forced with 2D bitmap modes or use 3D hardware to implement sprites.

As for homebrew, PAlib and NFlib both included functions for using 3D to handle sprites (as well as supporting regular 2D modes), so no special 3D libraries would have been needed. Again, I can't say for sure which games used those functions, but I know both of my games did (Touchdown the Alien Attack and Megamania Millennium) and so did GeoWars and probably games like Twist and Kongregate.

 

[Jomeady]

I did notice in Ghost Trick: Phantom Detective that the character sprites are drawn using 3D, but those are just simple quads as far as I can tell.

As far as learning how CPU memory works then do you mean the small bank of it you can assign or general setups? Either way it is a bit of a shame nobody seems to have linked you gbatek before now

Thanks a lot for the resources. I did stumble upon gbatek while browsing the libnds documentation (I did notice I called it libdns before, I still get a little confused) but I didn't delve too deep into it yet.

Edit: I just checked it out and oh my god, they have ASCII art of the consoles.

 

[FAST6191]

libnds is the main part of devkitpro's DS handling.

libdns might be a library for DNS (a fairly key part of modern internet/networking) somewhere, could be autocorrect being a pest or might be someone having fingers move faster than their mind (again DNS is a fairly key thing that most would be computer bothering types deal with fairly often).

On ghost trick then it has some fairly fancy things going on so be careful if trying to learn from that (if it is the only thing that keeps your attention then so be it). For instance the nice shadow/light effect saw things having fun with hblanks if memory serves which nobody normally does.