Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - What libraries do people use?

Reply to topic
Author Message
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
What libraries do people use?
Post Posted: Wed Aug 31, 2022 3:22 pm
Having poked around a fair bit recently, quite curious how folks are actually going about writing their homebrew games, in particular how much they are leveraging any existing libraries.

I know that devkitSMS provides a really quite comprehensive set of tools for writing games in C in particular; but what about assembler? Do those who want to write pure assembly games perhaps take the routines from devkitSMS and call them from assembly, or is there an equivalent toolkit for assembly programming?

I also see that there's SMS support for GBDK 2020 – also a C toolkit, but something I know very little about. I guess an alternative to devkitSMS?

And then there's PSGLib, which appears to be one of if not the most popular libraries to handle PSG music playback – makes a lot of sense that no one would want to reinvent that.

I also found an interesting (but I guess fairly marginal?) project on github called smslib which looks like a fairly comprehensive attempt at an assembler library, but highly optimised towards speed over ease of use which I get, although having had a peruse I can imagine some potential frustration in trying to use!

Am I missing any biggies?

Or more often than not have people crafted their own routines and copy them from one project to the next?

Would be interested to hear how much variety there is out there in approaches!
  View user's profile Send private message Visit poster's website
  • Joined: 04 Jul 2010
  • Posts: 539
  • Location: Angers, France
Reply with quote
Post Posted: Wed Aug 31, 2022 4:27 pm
For assembly, WLA-DX (but its not a library)
https://github.com/vhelin/wla-dx

My "own" (me & vingazole) library is a mix between SDCC and WLA-DX (but not public). You can also write ± fully in ASM in SDCC and just use the C part as a wrapper (and the C part is nice for quickly writing & testing functions etc.)

in C, theres also Z88DK
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Wed Aug 31, 2022 4:52 pm
Ah yeah I did check out Z88DK a few months ago, thanks for reminding me of that one! It's similar again to devkitSMS/SDCC if I recall correctly, in that it is a core compiler & linker and also a collection of platform-specific utility libraries.

100% on WLA-DX, I can't imagine using anything else for assembler, but there's actually a fair amount of "boilerplate" setup and for anything more than a trivial program some project structure is fairly essential so I have a starter template project for WLA-DX, not sure whether others have the same thing – not quite a library / framework, but with the addition of a few routines I guess that's what it would be.
  View user's profile Send private message Visit poster's website
  • Joined: 08 Sep 2018
  • Posts: 270
Reply with quote
Post Posted: Wed Aug 31, 2022 5:09 pm
Most of my toying around with the SMS and ASM, Ive used just two external libraries. PSGLib and GSL which are very powerful tools for those who dont want to program their own sound driver or scroll routine.

Other than that, I mainly follow the route of many here and write my own or borrow a library. Ive written a few libraries for personal projects that abstract input control, abstract the VDP interface, and a few iterations of a Maths library.

I know others have gone further and have written their own libraries for SRAM control abstraction, asset decompression, logic/flow control, and so on.

I havent seen very many libraries posted/talked about here since Ive joined but the ones I have seen are very powerful. It seems like a lot of people dont share them since a lot of them, you can just look up how to compose them yourself. Its kinda the nice thing about the simplicity of the z80.
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Wed Aug 31, 2022 5:18 pm
Oh I wasn't aware of GSL before – nice!
  View user's profile Send private message Visit poster's website
  • Joined: 01 Feb 2014
  • Posts: 849
Reply with quote
Post Posted: Wed Aug 31, 2022 5:33 pm
willbritton wrote
Or more often than not have people crafted their own routines and copy them from one project to the next?


This is pretty much what I do.

I craft all my games in pure assembler, as for some reason it’s much easier for me than C, which I only use to write my own small custom tools for when I need data prepared in a certain way. This differs from project to project, though.

I do use PSGlib, as it’s powerful and easy to use, and I’ve ported over an FM sound player from the MSX and added a way to play SFX. Don’t know if that already qualifies as a library.
  View user's profile Send private message
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14688
  • Location: London
Reply with quote
Post Posted: Wed Aug 31, 2022 7:42 pm
I guess decompressors count here? Even if it doesn’t really matter, I like to store my art efficiently.
  View user's profile Send private message Visit poster's website
  • Joined: 17 Jun 2017
  • Posts: 19
Reply with quote
Post Posted: Wed Aug 31, 2022 9:12 pm
I think one of the reasons for the lack of general purpose asm libraries is that a lot people getting started with asm are doing so because they want to learn how everything works at the lowest level and so would prefer to build everything themselves. They therefore build up their own libraries over time and will only outsource certain complex tasks like compression codecs, sound drivers and scroll handlers.

I suppose the other reason for writing asm is the appetite to make things as efficient as possible, and pre-written routines won't necessarily do things in the most efficient way for you as they potentially cover multiple use-cases that you may or may not need. It's difficult getting the level of abstraction right in a lib so it doesn't take away all the decisions from the programmer, but also isn't so low level that they might as well just write it themselves.

I'm the maintainer of the smslib lib you mentioned btw, which is my own lib I've built up. It's still pre-release so I don't think it's used by anyone yet, but is an attempt to at least codify my learnings from this site into working routines with docs and examples. If people are starting out and wanting to build their own routines they could potentially use it as a learning resource, but I'm also building it as a usable library to take away a whole bunch of boilerplate and make SMS asm a bit more game jammable :)

Addendum:
An example of abstraction I'm hitting up against is working on the scroll handler. A lot of the library so far is a thin layer over the hardware aspects (sprites, palette, patterns, etc) which can be done quite matter-of-factly without adding too many opinions to the mix. Scrolling is harder though as it gets very intertwined with things like metatile formats, which can be implemented in many ways depending on how much you want to prioritise speed or compression.

After some scrapped attempts, I eventually created a lower-level scroll handler API here which handles the (complicated enough) knowledge around VRAM write addresses, scroll registers and row/column scroll detection, but has no knowledge of the metatile format. By itself it therefore isn't a 'do everything for me' API and only gets you halfway. However, it does mean separate metatile handlers can be built on top of it in whatever way needed. I created a basic raw tile scroll handler here and I'm working on a general purpose metatile one atm, both of which will be 'do everything' APIs. I suppose this is an example of how we can build up layers of abstraction in libs so decisions and options aren't taken completely away from programmers, but also means they don't necessarily have to code and reinvent everything themselves :)
  View user's profile Send private message
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Wed Aug 31, 2022 10:03 pm
Maxim wrote
I guess decompressors count here? Even if it doesn’t really matter, I like to store my art efficiently.


Yeah I'd say so – it's a pretty big part of writing a game and it's something you come up against right away, although echoing some others' points it's one of those things that I think some people just wouldn't even think about writing from scratch so more of a grab it and go thing perhaps.
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Wed Aug 31, 2022 10:16 pm
eljay wrote
I think one of the reasons for the lack of general purpose asm libraries is that a lot people getting started with asm are doing so because they want to learn how everything works at the lowest level and so would prefer to build everything themselves....


Couldn't agree more! The reason I'm so curious about this is that I'm working on some step by step tutorials to go with my DIY build kit and I'm a huge proponent of learning from fundamentals. But I also didn't want to make the mistake (which would be totally on form for me btw...) of going down the build it from basics route only to have people say hey didn't you see library x, which already illustrates the best way to solve those problems. The picture seems to be though that there isn't such a hypothetical library, at least for assembler level, which is rather as I had suspected.

eljay wrote
I'm the maintainer of the smslib lib you mentioned btw, which is my own lib I've built up. It's still pre-release so I don't think it's used by anyone yet, but is an attempt to at least codify my learnings from this site into working routines with docs and examples. If people are starting out and wanting to build their own routines they could potentially use it as a learning resource, but I'm also building it as a usable library to take away a whole bunch of boilerplate and make SMS asm a bit more game jammable :)


Ah cool, it's an honour! I do like your lib a lot, I spent a good amount of time leafing through it and have definitely taken some inspiration myself, particularly around the way to structure "modules" in WLA-DX, so thank you!

eljay wrote
An example of abstraction I'm hitting up against is working on the scroll handler....

Scrolling is harder though as it gets very intertwined with things like metatile formats, which can be implemented in many ways depending on how much you want to prioritise speed or compression....

I suppose this is an example of how we can build up layers of abstraction in libs so decisions and options aren't taken completely away from programmers, but also means they don't necessarily have to code and reinvent everything themselves :)


Yes very true this. Cross-cutting concerns and coupling of abstractions are ever present in software development, but to me it feels strangely counter-intuitive that it appears so much more rather than less pronounced the lower level you get. One would have thought that the closer to hardware you get the more discrete your building blocks would be but it's almost the other way round - you can barely help but write code that handles two or three concerns at the same time. At least writing console games is a completely closed scope. I have so much respect for those brave souls who write operating systems and the like...
  View user's profile Send private message Visit poster's website
  • Joined: 05 Sep 2013
  • Posts: 3763
  • Location: Stockholm, Sweden
Reply with quote
Post Posted: Thu Sep 01, 2022 7:15 am
I admit more than once I thought I could 'port' devkitSMS's SMSlib to WLA-DX assembly so that programmers could use the same (or very similar) API in their asm programs, but I could never find the time to do so, thus I'm very happy to discover that there's a very similar effort going on! :D

Then I guess the key it's always modularity. One may want some compression, one might prefer another (need more compression at the cost of speed? vice-versa?) one may want to use PSG audio, one may prefer FM, one may want both... so I guess once the backbone of this asm smslib project is done the next step should be to include a collection of available scripts (when licence allows so) or at least links to them to expand the readily available from the start list of tools. I will be happy to provide code and help!

also Kagesan's MoonBlaster FM lib is here, he forgot to point it ;)
  View user's profile Send private message Visit poster's website
  • Joined: 06 Mar 2022
  • Posts: 598
  • Location: London, UK
Reply with quote
Post Posted: Fri Sep 16, 2022 8:15 am
Posting link to @raphnet's input lib :)
  View user's profile Send private message Visit poster's website
  • Joined: 23 Mar 2013
  • Posts: 611
  • Location: Copenhagen, Denmark
Reply with quote
Post Posted: Tue Sep 20, 2022 9:55 am
sverx's PSGlib has been the obligatory external library in my projects since it came out.

My homemade libraries change and adapt from project to project, but I do have a steady core, that has been kicking around for some time now:
; Hierarchy: Most fundamental first.
.include "libraries/psglib.inc"
.include "libraries/vdp_lib.asm"
.include "libraries/map_lib.asm"
.include "libraries/input_lib.asm"
.include "libraries/tiny_games.asm"
.include "libraries/number_display_lib.asm"

The code above is from my latest competition entry (https://github.com/hang-on/knights-of-the-square). The vdp lib handles sprites (inspired by the Sonic 1 disassembly available online), and other vdp stuff. The map lib is specific for the project in question. Input lib handles input, number_display_lib handles hiscore and scoring, and tiny games is a catch all, misc. library, including Kagesan's fading routines and the random number generator here from SMS-Power.
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!