Skip to content

New Section Idea: "Coming from GBStudio?" #169

Open

Description

@joffb

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

Activity

  1. nummacway commented on Feb 13, 2026

    @nummacway
    Contributor

    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).

  2. ISSOtm commented on Feb 16, 2026

    @ISSOtm
    Member

    Well, yes, that'd be the point of such a page.

  3. avivace commented on Feb 20, 2026

    @avivace
    SponsorMember

    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.

  4. nummacway commented on Feb 20, 2026

    @nummacway
    Contributor

    Nice article. It could be improved by:

    • 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)
  5. nummacway commented on Feb 21, 2026

    @nummacway
    Contributor

    I made a proposal here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions