@NovaSquirrel I wrote a GameBoy Sharp Z80alike assembler last summer with integrated assets and banking etc. but its kind of annoying to just write something entirely in assembly so I might need to make the compiler that works above it.

@wolfcoder From what I can tell the bar is set really low with GBDK and it should be very easy to surpass it and make something people would appreciate. Like, never producing wrong instructions when given completely valid C code. :p

I don't mind writing in assembly myself, but if I wanted to spend a shorter amount of time on a project (like a compo entry) I would definitely want a faster option.

@NovaSquirrel funny you mention GBDK lol, I guess I'm not alone in that. It doesn't really give you easy to use options for storing code in ROM banks and page flipping or asset bundling etc. - Its the whole reason I made an assembler last summer.

@wolfcoder Yeah I ignored it and went straight for RGBDS, which I'm happy with aside from missing a lot of features ca65 has like anonymous labels.

When I was actively working on a Game Boy Color game (and maybe I'll return to it) a lot of my goal was fitting a lot more cool stuff into 32KB than GBDK users would've been able to, to try and encourage people to try out assembly.

@NovaSquirrel being able to control better where stuff goes and supporting color functions and all sorts of cart types easily is a goal. If you're interested I can put the result on a GitLab... whenever that is. I do have a ton of work things to do first.

@wolfcoder I get the impression that supporting Color is a library thing more than a compiler thing. You mean being able to control what bank you put stuff in? Banking itself sounded like something difficult to wrap C around unless you toss in 8086-style far pointers and stuff.

Definitely share it if you make it though.

@NovaSquirrel letting you annotate stuff so it goes where you want is handy, yes but also it handling resource assets for you so you dont have to keep encoding them in specific indexed color modes yourself.

@wolfcoder I think most people just slip graphics conversion into their makefile, and that's flexible since you can add arbitrary compression or other processing on top of that easily. With most types of assets (music, definitely levels) everything is so different per-engine that you need a custom thing to convert each.

I directly draw in the right format (with YY-CHR), but I manually run a compression script when maybe I shouldn't if I would actually finally start using makefiles and linkers.

Β· Β· 1 Β· 0 Β· 0

@NovaSquirrel I was taking the all-in-1 approach to make things easier. It would have a DDL for specifying gameplay data like items and equipment. This is mostly because I was going to (at some point in the future) make a complete version of Ruby Wolf as a dual mode GB game:

rpgmaker.net/games/7165/

For the asset stuff, it would allow you to just paint the palette on the sheet and automatically optimize the data size and figure out the required palettes and what cells default to which.

Sign in to participate in the conversation
Computer Fairies

Computer Fairies is a Mastodon instance that aims to be as queer, friendly and furry as possible. We welcome all kinds of computer fairies!