You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Following up on a discussion on Discord with @ISSOtm - there was the idea of a new section in the tutorial for people who have experience with GBStudio and are interested in doing some asm. This would ideally be written with someone with experience in both fields. I'm just going off the GBStudio docs for some ideas on this one https://www.gbstudio.dev/docs/
What's the same in GBStudio ?
tiles are 8x8
palettes have four colours and sprite palette colour 0 is transparent
same screen size
same maximum number of tiles in vram
sprite limits per line
you can use hUGE to write music and reuse GBStudio songs
What's different?/What's a GBStudio feature vs a gameboy feature?
there's no scripting language or VM in asm
GBStudio allocates a palette and certain tile vram ranges for things like UI/text, in asm it's your choice
smallest sprites seem to always be 16x16 in GBStudio? in asm you can have 8x8 or 8x16 sprites and build larger metasprites from those
GBStudio maps can be > 32x32 tiles and the engine handles scrolling (as long as the map data fits into a 16kb bank), in asm you need to handle scrolling for larger maps yourself
However, last time I checked (like, 1.5 years ago) GBStudio did not really tell you the hardware restrictions. I even found some GBS restrictions misleading, e.g. object limit per scene (which you could actually exceed with no consequences apparently).
We have Choosing tools for Game Boy development which tries to explain the various tools, the difference between them (without going into detail) and a general overview of the different approaches depending on the paradigm chosen. Have you seen that? Maybe we can improve that one (and link to it in some initial paragraph of gb-asm-tutorial)
I like the motivation (GBStudio users are a big on-ramp), but I’m worried a “do GBStudio things in ASM” section is premature given where gb-asm-tutorial is today. Right now we still haven’t fully established all the fundamentals.
Without that base, a GBStudio-oriented section risks giving the wrong impression: that there’s a fairly direct mapping where you can “translate” workflows or copy/paste equivalents. In practice, most of what GBStudio gives you is engine/infrastructure (scene system, asset pipelines, VRAM allocation policies, scrolling/tile streaming, entity/collision, UI/text, save/state, etc.) and in ASM those things can't simply be "plug and played". They need to come from an organic system design. We can provide templates / plumbing / examples, but still after we have some solid bases to refer to.
Loosening the distinction between programming language and platform/environment/implementation, because there's not much choice of the latter for a given language (I was confused why it first seemed like it listed each option's pros/cons twice)
Adding TRSE as another option
Mentioning the most important hardware limitations
160x144-pixel screen
384 tiles (8x8-pixel 2bpp images with no color mapping yet), 768 on the CGB
Two 32x32-tile maps that are used for the background and an optional "window", a background layer is drawn on top of the background and can only be placed in the bottom and/or right corner/edge
Fourty objects/sprites, all being 8x16 or 8x8
Cannot really draw arbitrary images; instead, it takes a 160x144 piece of the background and draws the window and the objects on top, all of the three being tile-based
Max. ten sprites per scanline (generally considered to be the worst limitation)
Four colors per background palette, three per sprite palette
One background palette and two object palettes, eight each on the CGB; to be assigned to every tile being drawn
Four specialized 4-bit audio channels, not designed to play arbitrary audio
1 MiHz CPU (M-cycles; equal to 4 MiHz T-cycles), double on CGB (optional)
CPU access to tiles, tile maps, objects and color palettes is restricted to short timeframes
Limited memory: 8 MiB ROM (but 4 MiB is more common), 8 KiB RAM (32 KiB on CGB), 128 KiB cartridge "save" RAM (but 32 KiB is more common), complicating voice and FMV playback even further (but it is possible)
Activity
nummacway commentedon Feb 13, 2026
However, last time I checked (like, 1.5 years ago) GBStudio did not really tell you the hardware restrictions. I even found some GBS restrictions misleading, e.g. object limit per scene (which you could actually exceed with no consequences apparently).
ISSOtm commentedon Feb 16, 2026
Well, yes, that'd be the point of such a page.
avivace commentedon Feb 20, 2026
We have Choosing tools for Game Boy development which tries to explain the various tools, the difference between them (without going into detail) and a general overview of the different approaches depending on the paradigm chosen. Have you seen that? Maybe we can improve that one (and link to it in some initial paragraph of gb-asm-tutorial)
I like the motivation (GBStudio users are a big on-ramp), but I’m worried a “do GBStudio things in ASM” section is premature given where gb-asm-tutorial is today. Right now we still haven’t fully established all the fundamentals.
Without that base, a GBStudio-oriented section risks giving the wrong impression: that there’s a fairly direct mapping where you can “translate” workflows or copy/paste equivalents. In practice, most of what GBStudio gives you is engine/infrastructure (scene system, asset pipelines, VRAM allocation policies, scrolling/tile streaming, entity/collision, UI/text, save/state, etc.) and in ASM those things can't simply be "plug and played". They need to come from an organic system design. We can provide templates / plumbing / examples, but still after we have some solid bases to refer to.
nummacway commentedon Feb 20, 2026
Nice article. It could be improved by:
nummacway commentedon Feb 21, 2026
I made a proposal here.