So that’s a no to a native emukit then?
Would be fine to play my old playstation one games on haiku with a good and simple emulator.
The fastest on is Snes9x which is not available on 64bit Haiku.
It is also a old port. 1.4.2
Well looking at FeedKit, IMKit, etc. We could use components that already exist as parts of Haiku. So creating a native emukit wouldn’t be difficult as it’s mainly just the same as writing a mediakit/server like framework with GameNodes instead. I think
1 Like
I did look at bsnes-plus.git. It looks doable, audio and video would be medianodes, input would be a joystick looper, and a native ui, instead of the qt one, or you could just use the qt ui.
It’s looking good for the BSnes+ port. Been looking over the source again. Only need to do all the stuff that’s in the QT directory, but for Haiku/BeOS.
As an aside, where would the cartridges be stored, there’s no Applications/Application/Plugins directory on haiku
I think that it should be possible to port duckstation, I don’t have the experience but it looks possible to me as it only really needs cmake, sld2 and qt5. opinion?
Can do a BeOS UI port, the CMake stuff has to go, as the only module that exists on Haiku is SDL2, Libgbm, Vulkan, etc aren’t on Haiku. Should be trivial enough to generate a Jam build system for it though
The other platform dependant code is really easy to find, i found a simple gpu_sw.cpp/h that could be classed for haiku rendering purposes. I haven’t looked all the way through, but it’s definitely doable.
2 Likes
The cardriges called ROMs can be stored in any folder the user likes.
Like:boot/home/Games/SNES
or boot/home/Roms
Very nice you are looking into it.
But no need for Qt I think.
Yeah they can but they still have to be findable, and It’s easier if there’s a direct path to them.
Yeah, but we’ll just be using the QT directory as a template for the parts we need. The way everything that QT did to get the games on their system, is done for the haiku system, using the native controls.
So far it looks like we need audio, video, launcher, cartridges, platform, and input handling objects. not to mention the usual app stuff like window, view, and app.
1 Like
ah I see, then it would be somewhere in home/Snes/Roms
to use .dot directories is depreciated should not be used in Haiku.
Great if you could manage to port a new SNES9x for Haiku.
There are sources for Zsnes on BeShare.
Snes9x no idea where to get them.
Does SNES9x exist for libretro?
Yes it does just got a new 32bit Version on Haiku Depot Server.
and a Bsnes port.
https://depot.haiku-os.org/#!/pkg/snes9x_libretro_x86/haikuports/1/60_20210314/-/-/1/x86_gcc2?bcguid=bc449-YQKA
I was going to use the gamekit for FileGameSound and GameSoundStream, any ideas where i might get some ideas for FileGameMovie/Video, and GameMovie/VideoStream?
There’s already a native Haiku GameLauncher app, so I’m thinking I can just use that as my template for the launcher. I also need to add a BSnesMediaNodeAddon and I was looking at the example code in Apps for textures and animations.
The OpenGLHardwareRenderers from the older haiku releases could probably be useful here. Any ideas on how to make them more generic?
Maybe #ModeenF can give you more infos than me:
https://www.snes9x.com/phpbb3/viewtopic.php?f=8&t=5083&p=31125&hilit=haiku#p31125
Try on IRC too to get fast answers
IRC? I don’t really do well there! I usually don’t get the conversation.
It is very handy for quick answers from some Haiku developer there.
In Haiku you can use Vision for IRC. It is not difficult to set up.
You can also try to join the Haiku Group on Telegram if you like.
It is where you get quick answers for most questions.
This behavior is a bit inappropriate.
Haiku is also an open source system and everyone is free to experiment with whatever they want.
Maybe we won’t integrate it in the main distribution, but it’s still an interesting thing to do. So, let’s try to be positive about that 
We are not entitled to tell people what to do with their time.
Sorry for the negative vibes from a few members of the community. That was inappropriate.
I am very unfamiliar with the Wayland stack in Linux, so now I need to do some research on that.
I took a brief look at qtwayland, and it seems to be a Qt library that allows to use Qt application with rendering to Wayland. So that doesn’t really answer the question, I think.
The major decision to make is:
- You could implement the Wayland protocol in app_server, making it possible to run Wayland applications directly,
- You could implement some kind of “proxy” that acts as a Wayland server on one side, and as app_server client on the other,
- Or you could remove app_server completely, and replace it with a full-Wayland solution
These three solutions are completely different.
Since you asked about BDirectWindow first, let’s see how a solution based on that would work. The idea of BDirectWindow is that app_server is still in control of the display, but it gives your application direct access to the framebuffer (in Haiku, actually to the backbuffer, because we have double buffering). You could write an app that uses this to draw on the screen, and that’s about it.
You seem to need something more low-level than that. This would be BWindowScreen: The Be Book - Classes And Methods - The Game Kit currently this is the lowest level interface app_server can offer. Basically it gives you full control over the graphics card, with a way to talk to app_server to give it back control when you are done. This API was initially designed for video games in the 90s.
I think the implementation is a bit incomplete in Haiku, and may not in fact give you direct access to the video card, but still proxy some things through app_server. Also, this was never tested with 3D rendering and other hardware acceleration features. But it would be a good place to start, at least for testing: you can let app_server do all the video card initialization, and then take control of an already ready to run (at least for the 2D part) video card, and configure it further as needed (to get the 3D parts running, for example).
5 Likes
Sorry for that, do what you like to do! BeHappy!
The old OpenBEOS app_server code had some good code in it, I know that it’s probably outdated now, but would it still be useful?
Also if there was some way to get the app_server running on the framebuffer, similar to DirectFB, would that be a better way to get the thing running?
The actual implementation details elude me just now.
I mean if there’s a protocol that already speaks to other components in the system, then it might be simpler to build around that - I think your first point. Then it’s just a case of implementing a wayland compositor as a client to the app_server. Utilising the protocol of the app_server as a wayland protocol. If that makes sense
It was not my intention to lecture you on what you can or can’t do, and I am sorry if it looked like it, you are free to experiment with it as you wish as long as you respect the license.
But I am keeping my opinion that Haiku should not become too similar to Linux in the way it works; FreeBSD did, and now most people don’t see why using it instead of Debian.
1 Like