Video editing needs many RAM so it is ok is there is a minimum range set. If you buy a Editor you need to have the right Hardware too. I does not can do it everyone right
I can understand you, but for the moment it would be helping more to have tutorials of available apps, as waiting for a port
I would love to see all available emulators running again right in haiku:
euae, c64, psone, ps2, sega, atari, dos…
and support for:
joysticks (not only in SDL), gamepads, PSone/PS2 adapter/usb…
As in Linux and Windows the king was Xbox360 controller and hardware mapping using its driver, i would make it one of the supported hardware if talking about gamepads.
Iirc, ps4 dualshock 4 pad could be used in Linux through this driver too.
I tried the following emulators, and all works well:
euae
VICE (c64)
Dosbox
for Sega machines (and others), you can use mednafen
About the joypad support, I’m sure in mednafen works. Not sure about the rest.
If you need help, aske me.
Joystick/gamepad support works. SDL uses the native drivers. So if it works in SDL it will work elsewhere.
If your particular device doesn’t work, please submit a bugreport.
Well, it´s probably not the most technical reason, especially as my main haiku machine has only 2GB of RAM. But 64bit Haiku seemed cleaner and easier for me to use because I don´t have to remember to type setarch x86 before compiling anything. Also with the libraries in haikudepot, you always have the libraries double, for gcc2 and the modern gcc (7 at the moment).
But as I said I have a 32bit Haiku VM because I wanted to test TrackGit, which atm only compiles with gcc2. So I’m going to boot up that vm and take a look at Wonderbrush.
I test usb joystick with ppsspp emulator - works fine.
2 Likes
Does anyone know if there’s a list of apps only available on 32 bit Haiku that need modest code rewrites and recompile on 64 bit?
Are these purely on the ports site, or are there some apps considered ‘core’ or ‘featured’ in Haiku Depot that are missing on the 64 bit version?
Being new here, and only running on 64 bit, I’m not sure what the above answers are. Creating modest modifications to apps and getting them to recompile in 64-bit sounds like something I could do on the train to London when bored though…
Steam running on haiku? I would not ask for anything else in life … I have haiku a good few years and I can say with joy that of all the systems I have used it has been the best.
A way to get a list of software that’s not available on 64bit is to grep through the haikuports recipes for “!x86_64” and “?x86_64” (adjust your haikuports path):
find /Source-HP/haikuports/* -maxdepth 2 -name *.recipe | xargs grep [\!\?]x86_64
Of course, then it’s a matter of finding out what’s the issue. Is it a dependency missing for 64bit that’ll have to be tackled first? Or is it just a matter of patching a few locations in the code? The fun begins…
1 Like
Thanks for that. Looks like there a lot (350 ports)… I wonder if ?x86_64 means doesn’t support though - there are a number of recipes with just that in the architecture line.
There are 55 recipes that explicitly have !x86_64. Includes postgres, abiword, gdb (! v7.7, but 8.1 is the latest), tuxracer (surely a priority? ;o) ), archiver, artpaint, jammin, projectconceptor, sgebrush, ffmpeg (weird… v0.10.16) and llvm (v6.0.1 - the latest recipe).
Looks like some of the 55 just have one of the several version recipes that don’t do 64 bit… So the find/grep mechanism doesn’t necessarily give the status of the latest recipe. It also of course doesn’t tell us if the recipe that exists is for the latest version of the library/app available.
I’m wondering if it’s worth writing a quick bash script to extract the SOURCE_URI from the highest version number port recipe file for each package, then listing the remote folder (or git repo) above the source download file, and determine the latest version number, then give a report on which ports are the latest or not.
… useful? (Have I just volunteered myself for a job?)
So I thought I was on a winner for this. Some sites, like gnu.org, you can list the source package’s parent folder and therefore grep its content to determine if there’s a more recent version.
The problem is, not a lot of packages allow listing of the parent folder, or the parent folder is just a website - not an ftp like folder listing.
So for GNU hosted packages or git folders it’s possible to automate discovery of the latest version, but not for more packages that are just hosted at a random URL.
The HaikuPorts wiki has a link to Repology where you can see if there’s a newer version of a package. They offer an API and the HDS provides the version of a package which a talented and industrious web coder could use in collaboration with some cunning scripting…
OTOH, people interested in using some library or porting an app depending on some version of it, will speak up if they need a newer version. Then they either try to update the recipe themselves or open an issue at haikuports…
Hmmm… I’ve played with the API. It seems quite ‘chatty’ in that even if filtering by the haiku master repo, it will return links to all repos for a particular package. I suspect you’d have to inspect the repository, list the packages, and then pull back each package in each repo. This of course increases the number of network trips.
I’ve played around with the local bash script option, just for giggles. It doesn’t work for all packages of course, but does seem to work with quite a few of them. I’ll post the results on here once it completes (It’s not exactly fast given it does 1 http request per package).
Ah yeah so the bash script isn’t that useful. Analyses 1975 ports. Found 245 were up to date, 34 were out of date. The remainder (1696) could not have their remote sources resolved from the information in the recipe file. (I haven’t added git protocol support to the script though, so perhaps the situation could be improved. Currently it just uses http or https).
Ah well… Was an interesting exercise in bash scripting anyway. 8o)
If anyone wants the script just for giggles, just let me know.
Git protocol usage on HaikuPorts is being heavily phased out in favor of HTTPS, so that’s probably not the issue.
A lot of the links seem to be ftp. Some use local paths to downloaded tarballs. A total mixed bag.
In terms of needed apps, I’d like (as well as some people above) to note a RAW image editor, something like RawTherapy or Darktable. The lack of one is one of the few things that keep me as a photoghapher from using Haiku on a more daily basis.
2 Likes