Gameboy Development Forum

Discussion about software development for the old-school Gameboys, ranging from the "Gray brick" to Gameboy Color
(Launched in 2008)

You are not logged in.

Ads

#1 2020-01-22 12:01:01

PinoBatch
Member
Registered: 2018-03-22
Posts: 64

Designing a homebrew directory

Emulators don't include ROMs for legal reasons, and homebrew doesn't get enough visibility. I propose to feed two birds with one scone.

Has anyone here used the "Homebrew Browser" app for the Wii console? It's sort of like a Wii Shop or an App Store for Wii homebrew. I ask because I'm considering writing a spec for a service that emulators could use to download Game Boy homebrew. The browser would read some sort of index file from a server, containing program names and descriptions and URLs and metadata and the like.

Then the question becomes designing an index file and the process to populate a repository in order to solve what I see as three key problems:

Help users find what they want
The index file would need to have some sort of category scheme so that the user doesn't have to scroll through a thousand unrelated things. How might this be organized?

Display enough information about each work
This isn't much of a problem for an emulator that runs on a PC or a modern console. But if someone decides to push it a little farther than emulators to make an Internet-connected cartridge for the console, another problem I foresee is that decoding PNG, the Internet standard format for indexed color images, might pose a problem for a CPU that weak. Screenshots might have to end up scaled down, color reduced, and in some specialized format.

Ensure someone doesn't upload something that could get the server operator in trouble
The browser could be set up such that the user can add a repository's base URL. Then the repository administrator decides whether to accept it or send it back for changes. There'd need to be some sort of means of submission for this.

Offline

 

#2 2020-01-22 14:19:55

nitro2k01
Administrator
Registered: 2008-02-22
Posts: 242

Re: Designing a homebrew directory

PinoBatch wrote:

Help users find what they want
The index file would need to have some sort of category scheme so that the user doesn't have to scroll through a thousand unrelated things. How might this be organized?

I'd say, divide it into categories and tags. Categories are broad and each ROM can only have one category. Tags are more specific, can be applied more liberally, and a ROM can have any number of tags. Please allow for categories to include non-games, for example demos and music compilations.

PinoBatch wrote:

Display enough information about each work
This isn't much of a problem for an emulator that runs on a PC or a modern console. But if someone decides to push it a little farther than emulators to make an Internet-connected cartridge for the console, another problem I foresee is that decoding PNG, the Internet standard format for indexed color images, might pose a problem for a CPU that weak. Screenshots might have to end up scaled down, color reduced, and in some specialized format.

Anything that is a screenshot of something running on the actual hardware could theoretically be reproduced on the same hardware. However, that might require non-trivial hardware tricks, like scanline or even mid-scanline perfect register manipulation. Also, around 6k of data per image (worst case for a GBC game including both tiles and map data) might be on the high end for what can be delivered while maintaining a smooth user experience.

Perhaps it would be a good idea to define a format for miniature images that would be shown in a subset of the screen for this particular purpose. This image would then fit into a predefined UI for the GB screen. This would require manual artistic work though, and is likely to be a bottleneck in the project. (Assuming it's a goal of the project to catalog existing homebrew.)

PinoBatch wrote:

Ensure someone doesn't upload something that could get the server operator in trouble
The browser could be set up such that the user can add a repository's base URL. Then the repository administrator decides whether to accept it or send it back for changes. There'd need to be some sort of means of submission for this.

I'm unsure what "repository" and "it" mean in these sentences. I can interpret the first sentence in two ways:
1) The user is free to add any repository they want, to their local copy of the browser software, essentially like how an RSS feed works online. But this interpretation clashes with the second sentence.
2) ROM creators can submit a repository containing their project. It is then vetted by the administrators. This sounds like the more likely interpretation. However, this also means that the browser relies on those maintaining the main repository to both keep it online and to trust them to curate content correctly.
For this reason, it may be a good idea to separately define the database format and guidelines for content curation, and the official repository. It may also be a good idea in this case to define different terminology for the type of channel used by a homebrew author to distribute their works, and the type of channel that is used for end user distribution of curated content.

Is this project intended to be a completionist project, similar to a GoodSet, or mainly to promote actively/recently developed homebrew projects?


Blog: Gameboy Genius
"A journey of a thousand miles begins with one small step"
Old Chinese Proverb

Offline

 

#3 2020-02-02 20:20:47

PinoBatch
Member
Registered: 2018-03-22
Posts: 64

Re: Designing a homebrew directory

Please allow for categories to include non-games

[plug]Such as 144p Test Suite.[/plug]

Anything that is a screenshot of something running on the actual hardware could theoretically be reproduced on the same hardware.

It might be trickier to make a full-color thumbnail of a GBC screenshot, and a lot of things (such as the "Up for Chess?" screen two and a half minutes into Mental Respirator, [plug]Libbet's skin color in Libbet and the Magic Floor[/plug], and anything else using the screen blending of Batman or Serpent) might not be reproducible in one frame.

But then a screenshot isn't the only kind of art a front end might want to display. Others include icons, box art, label art, and the manual.

As for the submission thing, I expressed it wrong. The intended interpretation was a combination of both of your interpretations as is the case with (for example) Flathub or Ubuntu PPAs.

1. The user can add feeds of repositories to the client software.
2. At least one repository operates a public submission procedure, which we'd need to define.

Last edited by PinoBatch (2020-02-02 20:22:42)

Offline

 

Board footer

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson