4 ms·

> Use your distribution's package manager to install WINE (e.g. apt-get install wine), then launch NES Screen Tool from the command line as above under "Mac" T

> Use your distribution's package manager to install WINE (e.g. apt-get install wine), then launch NES Screen Tool from the command line as above under "Mac" This is something that I find rather off-putting about NESdev. It's very Windows-centric. I'm not used to GNU/Linux being treated as a second-class dev citizen, so I've started a small contribution towards fixing this. I've got a NES tile viewer that I hope will soon be a tile editor, written in PyQt for cross-platform aspirations: https://hg.sr.ht/~jordigh/Tilerswift/ https://hg.sr.ht/~jordigh/Tilerswift/ Development has stalled, but I intend to get back to it.

jeffalyanak 7y ago
I forked TM so it could be built on a modern system. It will run well on any *nix system. https://github.com/JeffAlyanak/tile-monster https://github.com/JeffAlyanak/tile-monster
- jordigh 7y ago
  Was this previously called Tile Molester? (ugh, these names)
  - jeffalyanak 7y ago
    Yes, I thought it made sense to pick a different name for the fork.
busterarm 7y ago
Even the ones that are Linux-centric really are mostly Ubuntu-centric. Nobody seems to care about portability anymore.
famicomparty 7y ago
Good news, there's a project that ported NES Screen Tool to cross-platform Qt, called "NESTool": https://github.com/jpwhiting/nestool https://github.com/jpwhiting/nestool I made Mac and Windows builds, but I'm not sure yet how best to pre-compile a Linux version that works across distributions - any advice would be appreciated. I assume users can install Qt on their own, so I don't need to do static linking, but I'm not sure what needs to happen beyond that. I'm in the process of updating the parts of the book that are already there to use it instead of NES Screen Tool. Looking at a few replacements for FamiTracker as well, so no one will need to use WINE to do NES development.
- jordigh 7y ago
  Personally, I'm happy building from source, especially for niche software. Just give me a working CMake or Qt .pro file and I can figure out the rest. I in fact rather dislike pre-built binaries. I don't trust them to work well and I don't trust them to work for a long time if they happen to rely on libraries that one day change (even the most statically compiled of static binaries still usually rely on libc). And if your software ever gets popular enough, I expect one day my distribution will just package it for me. I'm happy with this arrangement. Source for niche software, apt/rpm for well-established software. For my own Qt project, I decided to use PyQt so I could leverage fbs for distribution for Windows where they're not used to source code (Mac can rely on homebrew, as far as I'm concerned): https://build-system.fman.io/ https://build-system.fman.io/
- AnIdiotOnTheNet 7y ago
  > but I'm not sure yet how best to pre-compile a Linux version that works across distributions - any advice would be appreciated. I like AppImage. Self-contained portable application bundles that should work on most Linux distros. https://docs.appimage.org/packaging-guide/index.html https://docs.appimage.org/packaging-guide/index.html

jeffalyanak 7y ago

I forked TM so it could be built on a modern system. It will run well on any *nix system. https://github.com/JeffAlyanak/tile-monster https://github.com/JeffAlyanak/tile-monster

jordigh 7y ago
Was this previously called Tile Molester? (ugh, these names)
- jeffalyanak 7y ago
  Yes, I thought it made sense to pick a different name for the fork.

busterarm 7y ago

Even the ones that are Linux-centric really are mostly Ubuntu-centric. Nobody seems to care about portability anymore.

famicomparty 7y ago

Good news, there's a project that ported NES Screen Tool to cross-platform Qt, called "NESTool": https://github.com/jpwhiting/nestool https://github.com/jpwhiting/nestool I made Mac and Windows builds, but I'm not sure yet how best to pre-compile a Linux version that works across distributions - any advice would be appreciated. I assume users can install Qt on their own, so I don't need to do static linking, but I'm not sure what needs to happen beyond that. I'm in the process of updating the parts of the book that are already there to use it instead of NES Screen Tool. Looking at a few replacements for FamiTracker as well, so no one will need to use WINE to do NES development.

jordigh 7y ago
Personally, I'm happy building from source, especially for niche software. Just give me a working CMake or Qt .pro file and I can figure out the rest. I in fact rather dislike pre-built binaries. I don't trust them to work well and I don't trust them to work for a long time if they happen to rely on libraries that one day change (even the most statically compiled of static binaries still usually rely on libc). And if your software ever gets popular enough, I expect one day my distribution will just package it for me. I'm happy with this arrangement. Source for niche software, apt/rpm for well-established software. For my own Qt project, I decided to use PyQt so I could leverage fbs for distribution for Windows where they're not used to source code (Mac can rely on homebrew, as far as I'm concerned): https://build-system.fman.io/ https://build-system.fman.io/
AnIdiotOnTheNet 7y ago
> but I'm not sure yet how best to pre-compile a Linux version that works across distributions - any advice would be appreciated. I like AppImage. Self-contained portable application bundles that should work on most Linux distros. https://docs.appimage.org/packaging-guide/index.html https://docs.appimage.org/packaging-guide/index.html