Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QoL improvements suggestions #27

Open
Yrouel opened this issue May 15, 2022 · 3 comments
Open

QoL improvements suggestions #27

Yrouel opened this issue May 15, 2022 · 3 comments

Comments

@Yrouel
Copy link

Yrouel commented May 15, 2022

Here's a few suggestions for small(ish) but nice enhancements:

If no custom path (-p) is specified and the path of the input rom is not on the microsd (no "Nintendo 3DS" folder detected) use /nds as default (and tell the user) and/or have a settings file to specify it once.
This will enable a really quick generation with just ./generator rom.nds

If no makerom/bannertool are in the folder try to use the ones installed in the system in the PATH

Local assets repository? Try to use local custom banner assets from the data folder (same existing folder structure) to streamline testing of new assets (this even if no -b and or -s options are specified) (also again tell te user)

Asset validation? This might be less trivial but it'll be nice to know with reasonable confidence if the image and/or the sound file are the correct size/format when creating a forwarder

@lifehackerhansol
Copy link
Member

First one sounds "ok", atm it is doing exactly what Forwarder3-DS is doing. But I suppose doing /roms/nds isn't bad since TWiLight provides something like that by default.

I haven't thought about makerom/bannertool in PATH, but I provide one anyway so I'm not sure why it'd be necessary. Might stop macOS from complaining, maybe.

I've been thinking about local assets, should I disappear and my API dies. Perhaps as a sort of "cache". That one is on my to-do list.

For asset validation, I may do it with sound. For images I can just resize the hell out of them. Which is already being done unless the banner is pulled from the custom assets repo. I think how I'm doing is working though.

@Yrouel
Copy link
Author

Yrouel commented May 15, 2022

I thought Forwarder3-DS had a default path but perhaps I'm misremembering. Anyway having a default one basically means the process gets super streamlined (and yeah /roms/nds is tidier),

makerom/bannertool in PATH came in mind when I was trying the generator directly from a checkout.

Regarding local assets you also make a good point. I was thinking more from the point of view of making new ones it'll be easier to dump them in such local repo and have the generator pick them up automatically and also combined with point one will streamline this part of the process as well

I agree that asset validation is mostly for sound

@lifehackerhansol
Copy link
Member

For now, I think we've reached feature parity with Forwarder3-DS. Custom path input is now possible in the GUI in the next release.

I will work on these points afterwards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants