Haiku OS support

[Maes]

Well, if he's going to try a Win32-compatible OS, there are several stripped-down "mostly" Win32 compatible OSes, for use in Real-Time systems, e.g. Phar Lap, RTOS32 and others.

[Agentbromsnor]

On 23-6-2017 at 2:13 AM, TDRR said:

Something you could try, is "ReactOS", it supports programs from Windows NT onwards (And the iso is just 100MB!).

However, it's in development, so better create a new partition.

https://www.reactos.org/es

I'm not sure why you bring this stuff up in an unrelated topic, but ReactOS isn't even close to being as feature-complete as Haiku is. ReactOS is a cool idea on paper, but other than the novelty idea of having a "free" version of Windows, there's nothing to show for it even after more than twenty years of development.

[TDRR]

You are right, i just checked out Haiku on a couple videos and it looks pretty snappy (Even on a 128MB 400MHz machine!) I'd say Go 4 It (pun intended) I might do the same too when the time comes. (Unless Doom Builder 2 doesn't get ported to it)

[TDRR]

I just double posted and i have no idea on how to delete posts so have a nice image

[Remilia Scarlet]

Just now, TDRR said:

Unless Doom Builder 2 doesn't get ported to it

Given that (GZ)DoomBuilder uses DirectX for its rendering and the .NET Framework, I highly doubt it'll be ported to Haiku any time soon.

[TDRR]

7 minutes ago, YukiRaven said:

Given that (GZ)DoomBuilder uses DirectX for its rendering and the .NET Framework, I highly doubt it'll be ported to Haiku any time soon.

That sucks, well, i guess i will stick with old versions of GZDoom/QZDoom/Zandro if this ever happens.

[Agentbromsnor]

13 minutes ago, YukiRaven said:

Given that (GZ)DoomBuilder uses DirectX for its rendering and the .NET Framework, I highly doubt it'll be ported to Haiku any time soon.

I guess we'll have to put our bets on SLADE in that regard.

[Remilia Scarlet]

Or port DoomBuilder to OpenGL. 

[DoctorGenesis]

Slade is on Ubuntu already (and it is just as stable as the Win version) so hopefully it will get ported (unofficial or otherwise) to other OSes.

[VGA]

There is also Eureka, which is less user-friendly but more old-school.

[DoctorGenesis]

33 minutes ago, VGA said:

There is also Eureka, which is less user-friendly but more old-school.

Eureka is a very good alternative for old school stuff.

[Maes]

Or you could always count on good old DEU/Yadex. Can't get more oldschool than that, as far as editors go, besides hex-editing...

[VGA]

1 hour ago, Maes said:

Or you could always count on good old DEU/Yadex. Can't get more oldschool than that, as far as editors go, besides hex-editing...

https://doomwiki.org/wiki/DoomEd

 

What about the original editor? I propose a community project made with legacy editors! The title would be:

Old-School: No Recess For The Living

[Graf Zahl]

I hope nobody ever uses that thing for actual mapping. Due to its odd mapping concept it's just far too error prone.

 

[Maes]

9 minutes ago, VGA said:

https://doomwiki.org/wiki/DoomEd

 

What about the original editor? I propose a community project made with legacy editors! The title would be:

Old-School: No Recess For The Living

Not sure how POSIX-compliant that is....and unlike DEU, which has been around almost as long as Doom itself and has been open source and studied and ported etc., DoomEd is still more of a curiosity, with the full source released barely two years ago. Not even the language it's written in is available for all platforms.

 

Interesting, sure, but not the #1 choice if you want something going, fast. OTOH, an OpenGL or even software-rendered version of the original DoomBuilder would be a much more appreciated alternative, assuming of course that it can break completely free of its Visual Basic legacy...

[chungy]

On 6/27/2017 at 2:37 AM, Maes said:

DoomEd is still more of a curiosity, with the full source released barely two years ago. Not even the language it's written in is available for all platforms.

It's just Objective-C, which has been available on all relevant platforms (Windows, Mac OS X, Linux, *BSD) for decades...

[Csonicgo]

1 minute ago, chungy said:

It's just Objective-C, which has been available on all relevant platforms (Windows, Mac OS X, Linux, *BSD) for decades...

I know I'm stirring a hornet's nest, but llvm/clang was the only compiler with full Obj-C support until very recently.  GCC "supports" it, but doesn't understand some new "conventions" added to the language.

 

Apple shares some of the blame.

 

DoomEd code was written way before the new Swift-like features were added, so, your point still stands.

 

 

[Maes]

2 hours ago, chungy said:

It's just Objective-C, which has been available on all relevant platforms (Windows, Mac OS X, Linux, *BSD) for decades...

But for something like Haiku OS he'll probably have to build it himself into some GCC distro, as for those platforms pre-built distros only include C, C++ and, if you're lucky, up to date binutils. If your taste in languages us somewhat more exotic (Fortran, Ada, Objective-C....), you'll be pointed to the source tar or repo, given a pat on the back, and off you go. Surely not the kind of effort you go through to verify that "something just works" (unless you're paid to... ;-) or for shits and giggles.

Edited June 29, 2017 by Maes

[Rachael]

I've done a little bit more work on GZDoom today to get it Haiku-compatible. I've decided to branch my work since the changes I'm starting to make could be seen as a bit disruptive and I want to minimize that as much as possible.

 

The issue I am running into right now is thread-local storage not being supported. There was an issue with that regarding OpenBSD, too, and unfortunately I can't find what the OpenBSD guy did to get it to compile on his system (or if he even did). It's a bit daunting to encounter a system that has this issue.

 

For now, I am keeping development in the Haiku-develop branch. However, unless the BSD's and Haiku decide to pick up thread-local storage, we may have to deprecate all of them preemptively, because this is something that's going to be counted on in future development for GZDoom.

[Graf Zahl]

1 hour ago, Rachael said:

The issue I am running into right now is thread-local storage not being supported. There was an issue with that regarding OpenBSD, too, and unfortunately I can't find what the OpenBSD guy did to get it to compile on his system (or if he even did). It's a bit daunting to encounter a system that has this issue.

For now: Just ignore it. The VM isn't being used multithreaded right now. This was just a precaution for later, but since 'thread_local' is part of the spec I didn't expect some platforms to be such laggards about it.

 

[Breeder]

Haiku Beta 1 has recently been made available. All pre-compiled programs can be downloaded through the included Haiku Depot application. Within it you will find a release for Retroarch, which contains PrBOOM, and Chocolate DOOM. Retroarch seems to be very unstable at the moment, though Chocolate DOOM runs perfectly fine!

If you turn on support for development files in Haiku Depot, you can grab all the files required to compile Crispy DOOM also. To compile Crispy, I had to use the following commands.

setarch x86

./autogen.sh

./configure

make

I believe Odamex should have all the dependencies it needs in Haiku, but I can not get it to compile. Zdoom seems to lack 2 or 3 dependencies yet, and GzDOOM and Zandronum may not be work tackling until we have accelerated hardware support for OpenGL.
I also believe that PrBOOM and PrBOOM-Plus should also compile, but alas I am getting no where.

On a side note, Hexen II, Half-Life, Aleph One, Quake 2, etc. are also available from Haiku Depot.

[CacoKnight]

Reviving an old thread but..

 

https://depot.haiku-os.org/#!/?bcguid=bc1-KOLN&repos=haikuports&arch=x86_64&incldev=false&viewcrttyp=FEATURED&srchexpr=doom