Slight issue

[Kitsumi]

Whenever I try to do
currentScreen = gb.doFrame();
it just returns an empty array...

[danShumway]

Hrm, well that's definitely not supposed to happen.

As a point of reference, I haven't actively maintained this project in a while (though I may pick it up again soon). That being said, I can look into this.

Just to help me out, there's three versions of Serverboy floating around (github, gitlab, and npm). Can you confirm which of them you're using?

[liebig]

I have the same problem. I am using the npm repo and the serverboy.js/examples/streaming/server/index.js code. The currentScreen is always empty array.

[danShumway]

Thanks a ton. It's probably going to be a week or two until I get a chance to look into this, but this is pretty helpful.

I'll also set up the main repo to mirror to the Github version so new updates get reflected here automatically.

[danShumway]

Was able to take a quick look and confirm the issue. This was introduced in version 0.3, probably in commit 484e742. If you want to mess around with the emulator now and don't want to wait for me to fix it, update your package.json to depend on version 0.2.

The code here is a bit of a mess. I think high priority is getting some basic unit tests included so that I can speed up development/testing in the future.

Past that, there's (high) potential that the API will change since I know more now about API design than I did 3 years ago. I'm going to leave this bug open until I get time to fix the regression, and I'm going to leave this bug focused on this specific regression. If either of you want to open a new issue talking about what specifically you're planning to use Serverboy for, I can start to get a bearing on what I'd want to support in the future.

[liebig]

Yes, you're right, with version 0.0.2 it works. Which test framework do you want to use? Maybe I can help you test it.

[danShumway]

I'm using Distilled, it's a relatively young framework I built and am maintaining myself. It's designed to handle highly asynchronous code and to be adaptable for complicated projects like Serverboy that can't be easily broken into smaller modules.

For documentation, I'm going to be using a combination of Dormouse once I settle on a final API. I'll probably be making use of Asciidoctor as well.

I'd be glad to have some help, although I'll want to organize the main repo first and figure out what my immediate development goals are. If nothing else, what would be really helpful is to have people I can bounce an API off of as I start to rethink it.

Since I'm planning on using Serverboy with Piglet, my goal is to have something that's very focused on scripting (there are already a ton of much better emulators if you're just looking to play a game locally).

More than that, I'm looking to enable controlling and reading output from Serverboy across multiple servers. Right now, Serverboy makes a lot of problematic assumptions: that it will be handling streaming entirely on its own, that it will be controlled synchronously by the same process it's running in. That won't really work for my uses (Piglet), so I'll be trying to turn it into something that's much more asynchronous and that can handle things like shared pools of memory or databases that are distributed among multiple servers.

If you stick around during that process and advocate for your own needs, it'll be easier for me to make something that's flexible enough for other people to use.

[liebig]

Which framework do you want to use for test mocking? I would like to use serverboy to play online with friends. It is important to me that it has almost no dependencies, requires as little resources as possible and can be transferred to the client without any lags. I want to host more than one instance per server in order to play different games with several friends at the same time. These would be my wishful thinking. The transmission of games sound or even a link function would be great for the future.

[danShumway]

So... what exactly do you gain by putting this on a server?

I would like to use serverboy to play online with friends.

To me, the point of running on a server is centralization - that multiple clients can connect to and read from the same instance, and that the emulator can be scripted to run regardless of whether or not anyone's connected. I'm putting Serverboy on a server because the server itself will be controlling the emulator. It won't be the clients that are controlling it.

I'm giving up some functionality and some performance so that Piglet can be running as a cluster of servers, and so I can get low level automated access to RAM and system monitoring for stats, in a relatively low-cost system to cut down on my hosting bill.

To be sure, you could connect a client to the server and control it, but I don't know why you would deal with the hosting costs, added complexity, extra lag, and lack of sound, when pure-JS emulators that run in the browser already exist.

Unless you wanted to do something like Twitch Plays Pokemon, where the keypresses of several clients are piped into the same instance of the game?

I want to host more than one instance per server in order to play different games with several friends at the same time.

There's technically nothing to prevent you from doing this even right now, but again, I'm not sure why you'd want to. Running an emulator through a server means you need to have a centralized computer somewhere managing and running all of your instances. In contrast, if you have the emulator running completely clientside, you can just put it up on any static web host. If you've only got a few friends connecting, your hosting costs basically drop to zero.

You'd lose the ability to host the emulator in a browser, but there are also Android Emulators that are more accurate and support a great deal more features than Serverboy likely ever will, and that are in a form factor that's a lot more intuitive. I'm developing Serverboy, and even I just use the Android emulator when I want to play a ROM hack.

What are you looking to do with Serverboy that isn't replicable with a local emulator?

[liebig]

Yes, I would like to do something like Twitch Plays. There are already libraries there, but they use a canvas emulation, which is quite complicated to compile and hungry for hardware. Furthermore, scripting extension for the emulator would be a consideration to access e. g. game information (number of captured pokemon). But you're right, the whole thing is quite expensive to use. I have spent the last few days working with JavaScript peer to peer networks and maybe they would be more suitable with the taisel/GameBoy-Online library. What do you think?

[danShumway]

That seems like something that would be reasonable for Serverboy to handle - get a centralized emulator running, get a lot of clients connected to the same instance of a game. Having metadata about the game available to you is also kind of a cool idea.

In terms of cost... I dunno. With Piglet, I want Serverboy running on a server, not the client; this is because while there's no legal issue distributing an emulator, there would be legal issues if I distributed a ROM - and in order for me to run the code locally, I would need to do so. It would certainly be a lot cheaper, and if you're project's small enough maybe you just assume that right's holders won't care. But in my case legality overrides cost.

My goal with Serverboy is to try and minimize that cost, but I won't be able to drop it to zero. This is something to think about, and I'm still researching it. We have pretty good resources online to get static websites running without much (if any) cost, we don't have great resources for servers.

Another consideration you might look into is just putting the up-front $35-40 into a Raspberry Pi and running the emulator from there. In theory, Twitch has good APIs for streaming, which would make that part of your project a lot less complicated. Not needing to worry about bandwidth, or securing an open server, etc... would mean that your daily cost would just be the electricity the Pi uses.

However, that would bind you into Twitch's APIs and overlays as your interface, which may not be desirable. For Piglet, I want to be able to stream without Twitch.

I'll keep thinking about this. Technically, Serverboy should work fairly well for your use-case, and I'll keep it in mind as I develop, but there are other open questions that I'm still answering myself.

[danShumway]

The major difficulty with applications like Serverboy is dealing with the entire web architecture. You need a server with ports exposed that can handle the traffic.

What you'd really like is a cheap Raspberry Pi that you can scale up, move around, etc... without a lot of effort.

Lately I've been looking at IPFS as a way to address some of these problems. It's still in early stages of development and many of the most useful parts for Serverboy (pubsub, private networks) are still experimental. But I'm especially encouraged by conversations like this.

Of course, this is all completely unrelated to Serverboy itself, but there is some (albeit small) potential that you could set up a small server or cluster of servers (maybe a few Rasberry Pis) to handle emulation, video output, etc... coordinating with each other using pubsub, and that clients could similarly publish requests to the network without over-taxing your server. If you could get it low-latency enough, that would significantly reduce costs and you wouldn't need to worry about opening up a port on your network.

I'm really swamped right now, but I want to experiment with this. Again, it shouldn't directly affect Serverboy.