DS-Homebrew / TWiLightMenu

DSi Menu replacement for DS/DSi/3DS/2DS
https://wiki.ds-homebrew.com/twilightmenu/
GNU General Public License v3.0
3.15k stars 197 forks source link

Bare-bone (minimal) version of TWLmenu++ for 3DS #1204

Open vulpes-vulpeos opened 3 years ago

vulpes-vulpeos commented 3 years ago

TWLmenu++ became very heavy and overloaded, so I have a suggestion of creating bare-bone version of TWLmenu++ for 3DS. It can be described as "DS games and nothing else". The main goal is to drastically reduce files number and number of available options. Just boot into the menu and play DS games.

Main points:

Homescreen:

Settings screen:

Sound: • Theme music: Default or DSi Shop. • Sound/Mic frequency: 47.61 kHz or 32.73 kHz.

Game settings: • DSi Mode: on or off (option for the future). • ARM9 CPU Speed: 67 Mhz (NTR) or 133 Mhz (TWL). • VRAM boost: on or off. • Boostrap: Release or Nightly.

Developer options: • Debug: on or off. • Logging: on or off.

Edit: Updated some points.

RocketRobz commented 3 years ago

I disagree with this point:

No AP-cheats - it's not a problem to AP-patch roms on PC. Also it seriously reduces numbers of files.

Not everyone can either use a tool, or want to use a tool to AP-patch their ROMs. At the same time, they don't want the AP measures causing issues when running those ROMs.

While I agree that it'll reduce files, it'll cause issues for those that just want to run DS games.

vulpes-vulpeos commented 3 years ago

I agree that this is questionable point in context of "Just boot into the menu and play DS games". Maybe it wasn't good idea to include it in the list 🤔 At least it's easy to delete ap-cheats for games you won't play.

NightScript370 commented 3 years ago

Most of these are removable thanks to TWiLight's modular system and the rest accumulates in so little that there's effectively no need to remove it.

No splash screens - no need to make booting time longer.

Just delete main.srldr and replace it with dsimenu.srldr

Only alphabetical sorting.

It costs next to nothing to implement the other sorting methods

Only DSi theme.

This is the only one that kind of makes sense. You can shave 2 MB off the overall theme count by removing r4menu.srldr and for users on older versions, 4 MB by removing akmenu.srldr

No hidden files, rom hiding or rom deletion.

The functions for hiding and deleting files will be there regardless, due to the library used. This is inescapable unless you want us to maintain our own fork of whatever SD card library we'd use. That leaves to just checking it, and if you remove that, you're just saving like, what, 42 bytes or so?

No boxart.

This has more reason than the other removals suggested, but still accumulates to nothing.

No widescreen.

File renamings cost next to nothing. Just delete the widescreen cheat files

No emulators - 3DS has good standalone emulators.

Just delete the emulator files and hide the options in the TWiLight Menu++ settings

No Slot-1.

Just delete the slot-1 file on your own

No AP-cheats - it's not a problem to AP-patch roms on PC. Also it seriously reduces numbers of files.

It is a problem when some people can't access a PC or don't know how to. Also, just delete the unused files

No manual.

Just delete the file on your own.

You could have listed a lot more than this and it would have made sense. However, you only listed things that cost next to nothing even when piled up, with the exception of only one redeeming point. There are a lot more things you could have listed, such as:

If we do ever make a lite version of TWiLight Menu++, I recommend just removing files rather than making specific "lite" builds

vulpes-vulpeos commented 3 years ago

Yes, I can delete files, but this won't remove options from settings menu or whole select menu. Also I don't want to delete files every time I need to update TWLmenu (that's one of the reasons why I'm not on the latest version). Even if function costs nothing or is included into library it still have options in settings menu.

I already wrote that AP-patch point is questionable. Maybe it will be easier to move this cheats into DeadSkullzJr's NDS Cheat Database?

  1. GBARunner2 DSi Files
  2. Unlaunch backgrounds
  3. DSTWO Plugin booter
  4. Gameboy Advance switcher
  5. the extra skins (which should go in the extras repo)
  6. DS Classic Menu

1-4. I didn't know about their existence in 3DS builds. Sure, they need to be removed in bare-bone version.

  1. It's the point of "Only DSi theme".
  2. It's already in the list with whole select menu in homescreen section.

For me it will be easier to move back to flash card then delete files every time TWLmenu updates 🤔

rashevskyv commented 3 years ago

I agree with OP. It would be great have core bare-bone version

teakhanirons commented 3 years ago

Define bare-bones. One could leave out AP because it bloats the package while it's important to one other. I for one only dump my games and preserve them unpatched. Same goes for themes, wide-screen patches, slot 1, sorting, emulators... Will you make a new version for each combination of that? Doesn't that get solved by modular approach as it is right now? Is it a habit of normal people to browse the settings when they are bored and get angry when they see an option that is something that they do not use?

Have you considered forking it and removing stuff you see as bloat, as this is an open source project?

vulpes-vulpeos commented 3 years ago

Bare-bones = essential minimum?

One could leave out AP because it bloats the package while it's important to one other. I don't say that bare-bone version should replace full version. Need more functions - install full version.

For me, the problem of AP is mostly in the number of files. Combine them into 1, move it into DeadSkullzJr's NDS Cheat Database and the problem is solved.

Doesn't that get solved by modular approach as it is right now?

No, it doesn't. It's not fun to delete files every time TWLmenu updates.

Have you considered forking it and removing stuff you see as bloat, as this is an open source project?

I don't have enough knowledge to do that.

NightScript370 commented 3 years ago

The original goal seems to be to deminish the size of the package. However, with the response that was given, it seems to be moreso "this exists, remove it because it exists"

I don't want to delete files every time I update twilight menu++

Thats on you, not us

Maybe those widescreen cheats could be added to DSJs database

But his DB is for a more global spectrum such as emulators, which can do 16:10 as well as 16:9, 4:3 and much more. Add for one, wouldn't make much sense to exclude the others. As a result, the package just becomes more bloated

1-4 should be removed from the lite builds

And the general 3DS 7z too? There's no reason why 3DS users would ever want to use that

It's the point of DSi Theme Only

Themes =/= Skins. You never expressed this in your op. What's the harm of skinning?

Part of SELECT screen

My bad, missed it, but it opened up my eyes to this; you'll directly cause confusion with what button prompts to enter when switching between versions. There's no reason not to keep it consistent

Combine AP to 1, move to DSJs database and problem solved

  1. They aren't cheats
  2. That would have a direct reliance on an external database we do not provide or have any control over what goes in
Peter0x44 commented 3 years ago

No, it doesn't. It's not fun to delete files every time TWLmenu updates.

You should simply write a script to delete those files and run it when you update. You don't have to do that manually every time.

vulpes-vulpeos commented 3 years ago

I'll repeat once again. I don't think that bare-bones version should replace full version. There should be 2 versions: bare-bone and full. 1st for users who just want to play ds games and doesn't need any additional features (flash-card replacement). 2nd for users who need/wants full experience.

The original goal "is to drastically reduce files number and number of available options. ". IMHO, it's not normal to have 5 screens in settings menu and to have ds settings/files in 3ds build. Why 3DS users would want to use DS emulators if 3DS has much better emulators?

I never said to move widescreen cheats to DSJs database. The talk was about moving AP patches there or combining all patches into 1 file, or removing them from minimal build.

And the general 3DS 7z too? There's no reason why 3DS users would ever want to use that

If there is no reason why 3DS users would ever want to use that, then there is no reason to include this file into 3ds 7z.

Themes =/= Skins.

Sorry, chose wrong word.

What's the harm of skinning?

It makes update 7z bigger and increase the number of files. Not included by default -> no harm. Especially if user doen't use any skin except Dsi one.

you'll directly cause confusion with what button prompts to enter when switching between versions.

It wan't cause any confusion if you have 1 skin.

  1. They aren't cheats 2.That would have a direct reliance on an external database we do not provide or have any control over what goes in

I saw AP cheats in DSJs database, so I thought they are the same.

RocketRobz commented 3 years ago

I think a bare-bones TWLMenu++ could work, but I wouldn't make it exclusive to 3DS consoles. It would be called TWiLight Menu++ Lite, and it'd be for all DS family consoles.

teakhanirons commented 3 years ago

For me, the problem of AP is mostly in the number of files

And it's the opposite for me. I don't want to have multiple versions of one game in my library, so AP is essential to me. That makes one more version of your request but without the AP removed. You're missing the original problem of replacing modularity with bloating the releases page for each person's need and needing to maintain multiple versions from now on just to save one or two MBs.

The original goal "is to drastically reduce files number and number of available options. ". IMHO, it's not normal to have 5 screens in settings menu and to have ds settings/files in 3ds build.

Why? Why does more options bother you?

vulpes-vulpeos commented 3 years ago

That makes one more version of your request but without the AP removed.

No, it doesn't. You'll just install full version of TWLmenu (if Robz remove AP-patches) or light version (if Robz leave AP-patches and you don't need additional features). I already said that this is questionable point in the list. Let Robz decide, remove or leave - anything is good, as AP don't effect settings menu and can be easily deleted.

Why? Why does more options bother you?

KISS.

teakhanirons commented 3 years ago

KISS also applies to maintaining multiple versions and a codebase for that.

"I don't use this optional feature and I do not want it in my settings list so maintain a seperate version codebase" is not good software management advice.

Seperate small identical function files like AP could be held in a tar file, that is the only part I agree with.

teakhanirons commented 3 years ago

On another note, if you only want the nds-bootstrap updates while deleting other features, can you not only update nds-bootstrap?

MasterGamingYT commented 3 years ago

Honestly, there should be a SEPARATE lite version at this point

unresolvedsymbol commented 3 years ago

I distinctly remember there being a lite version without widescreen and AP patches... Can't seem to find it though.

RocketRobz commented 3 years ago

@unresolvedsymbol That's exclusive to nightly builds. You have to use TWiLight Menu++ Updater.

chyyran commented 3 years ago

I like the idea of moving AP patches to a single file. This might require some work though to properly build a lookup table + actual file data.

Appending the TID4 to the front of the IPS data then concatenating everything is probably the easiest solution. Another solution is a LUT + offsets which will take a bit more effort to build the table but less effort when reading the patch.

teakhanirons commented 3 years ago

@chyyran That's over complicating it. A tar file would perfectly do that with no lookup tables, no decompression while being easy to read from.

chyyran commented 3 years ago

@chyyran That's over complicating it. A tar file would perfectly do that with no lookup tables, no decompression while being easy to read from.

Without a LUT you will have to read the TAR file sequentially (up to n headers). A fixed sized LUT at the beginning of the file can be easily binary searched through for TID4, and no wasted buffer (since we know the exact size of the patch from the LUT entry) will be needed to write out the patch into its own file for nds-bootstrap.

lifehackerhansol commented 2 years ago

Since this issue's creation, AP patches have been consolidated into one file. The option to use a specific AP patch remains, but otherwise all of those files are just one packed file now.

An idea I had, if we were to remove bundled emulators, is for TWiLight to detect whether a supported emulator exists in where it used to be bundled, and if it is, it automatically shows the related ROMs, and if it doesn't, hide them. Thus removing the need for the emulator settings entirely save for a few options such as GBA for DS/DS Lite, or a selection of either PicoDriveTWL/jEnesisDS should they both exist.