Using free, open-source art from OpenTyrian. Clever - Tyrian had great artwork, and most people won't notice this anyway :)

View this comment - View article - View full comments

I love this game and am so glad Valve is working on "2.0" version :) Ah, how great would it be if they put the same number of invites per OS ;)

Quoting: legluondunetIs it a "Magic the gathering: arena" like game cards?

It's a card game, but very different from Magic - Artifact 1.0 was very unique; rules for 2.0 are revamped to make the game more streamlined.

View this comment - View article - View full comments

Let's hope sooner or later they will see there's no practical reason to put those hurdles in place, and Defold will switch to a real Open Source license - their response is encouraging.

Otherwise, the engine looks really interesting, with plenty of tutorials and seemingly quite thorough documentation :) Seems like a great option for people who want to use it for its primary use-case (developing 2D games).

View this comment - View article - View full comments

Quoting: EhvisIs it allowed to make a fork of GCC and sell the resulting product?

Yes. That's why it is called Free software.

View this comment - View article - View full comments

They do not adhere to rule 3, because forks can be distributed only under non-commercial license (unlike Defold itself).

View this comment - View article - View full comments

The Defold License [External Link]

Quoting: The Defold LicenseYou are free to commercialise any software created using Defold

... but:

Quoting: The Defold LicenseYou can not commercialise original or modified (derivative) versions of the Defold editor and/or engine

Therefore I don't think it qualifies according to OSI definition [External Link] due to rule 3:

Quoting: Open Source Defintion3. Derived Works

The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

So in other words: it's not Free (as in freedom), it's free (as in beer), with source released license which is pretty permissive and close to Open Source definition.

I bet it will be a good choice for many developers despite of this.

View this comment - View article - View full comments

Quoting: axredneckIs it better/worse than dosbox-x ?

Neither.

DOSBox-X and dosbox-staging are two, non-competing projects with different goals. If your use case requires perfect hardware emulation (there are many such use-cases!), then DOSBox-X is the way to go; many people use DOSBox-X for gaming and there's nothing wrong with that either. dosbox-staging is for people, who want to play DOS games without a hassle; our goals are stated here [External Link] :)

Stars indicate, that both projects will cooperate by sharing expertise and patches (but our code diverged a lot, so projects are unlikely to merge). Hope this clears things out :)

View this comment - View article - View full comments

Quoting: legluondunetI tested several of my dos games and I observed a performance boost and less graphic tearing (SDL 2 gains?). But we still need a vsync feature to avoid completely graphic tearings. I saw they are working on it.

Yeah. We decided to disable the user's ability to change vsync setting for now - turning it on causes severe problems (mostly because emulator code is targetting output of CRT refresh rate - usually 70FPS). If someone is feeling adventurous, then vsync can be forced via OpenGL (using e.g. MangoHud), but the results are likely going to be terrible.

We're going to work on this again, but old "simple" implementation inherited from SDL2 patch is not robust enough, more effort is required.

View this comment - View article - View full comments

Quoting: voyageurHopefully MT-32 and 3dfx integration will be there soon!

Due to popular demand, FluidSynth 2.x integration is in front of those two in the queue, but we'll get to it :) People who want to follow (or contribute):
- MT-32 work is tracked here: #257 [External Link]
- 3dfx emulation work is tracked here: #339 [External Link]

View this comment - View article - View full comments

Quoting: Purple Library GuyI was wondering, and then seeing you here clearly involved gives me a hint that the answer is fairly positive--so, what's the relationship between this and Boxtron?

They are really close - dosbox-staging started when I found bugs in DOSBox, that I couldn't work around in Boxtron. I plan to bring those two projects closer, but very likely they will stay as 2 projects (we'll see). dosbox-staging is much bigger with many more contributors at this point.

Quoting: ripper@dreamer_, what are the chances of eventually merging your changes to the original dosbox? Or merging those two projects? Is dosbox development completely dead - so dead, that it can't be even revived? Can you share some background regarding this? I'm extremely happy for your project, because I long felt that dosbox was missing user friendly features (like window resizing). But of course it would be even better if you could the same change in the original project instead of starting a new one.

I agree - the best outcome would be if all the improvements landed upstream and fork could be avoided. I spent a lot of effort (and grew few more grey hairs) trying to avoid creation of the fork (while wanting to get some work actually done), but failed at that :( You can find context in this /r/emulation thread [External Link].

At the moment chances of merging the projects are close to 0, but maybe in few dosbox-staging releases, when everything will cool-down, we could pick up the topic again. But this time the upstream would need to show initiative - and willingness to restructure their workflow.

But I need to be clear here: DOSBox SVN project is not dead. They are doing their own thing, on their own terms and schedule.

View this comment - View article - View full comments