MorphOS port

[ETLegacyTeam]

Author: @BSzili (BSzili) Date: 2013-10-18 Redmine Issue: 371, https://dev.etlegacy.com/issues/371

---

Create a port for MorphOS: http://morphos-team.net This possibly includes a GLEW port, or some workaround for that, because TinyGL has a fixed feature set.

---

Related commit(s): a22eb57057ddd3a0e4512241c00d9bf6ca176072 - general: initial MorphOS support refs 371 355e9ef16541921f1784afc3a32a663bbce19959 - general: everything builds now on MOS refs 371 a67b340c4643bef19873e1cb4cca02c821786b24 - client: fixed syscalls on MorphOS refs 371 dc1601e2544abfba2b69b739a9c3f9e5abbd7595 - general: fixed wrong capitalization of MorphOS ref.. c87ef328aadd70377325c0e457f0ddd5bcbabd2e - client: now AROS and MorphOS has a separate fs_hom.. 4d75c3c3b18273b10c812d74cd45ac7f321320f8 - general: fixed string to float conversions on Morp..

[ETLegacyTeam]

From: @IR4T4 (IR4T4) Date: 2013-10-18T10:05:09Z

---

glew is already available in the lib path

[ETLegacyTeam]

From: @BSzili (BSzili) Date: 2013-10-18T10:22:44Z

---

IR4T4 wrote:

glew is already available in the lib path

I know, but the way TinyGL is implemented makes it a bit hard to port GLEW. It has a fixed function set, there's no getprocaddress and the GL functions are declared as macros like this:

define glBegin(mode) GLBegin(__tglContext, mode)

where GLBegin is the "real" library function. There are also tons of nasty namespace clashes with glew.h. I'll probably go for the workaround, since TGL on MorphOS a nice homogeneous environment.

[ETLegacyTeam]

From: @IR4T4 (IR4T4) Date: 2013-10-19T06:38:26Z

---

Is there no separate fs_homepath on MOS and AROS - see FS_Startup()?

[ETLegacyTeam]

From: @BSzili (BSzili) Date: 2013-10-19T06:56:25Z

---

IR4T4 wrote:

Is there no separate fs_homepath on MOS and AROS - see FS_Startup()?

No, both are single-user systems. There was a 3rd party multi-user extension to amigaos-classic, but it never caught on, and it's not implemented in any of the NG AmigaOS-like systems.

[ETLegacyTeam]

From: @JanSimek (Radegast) Date: 2013-10-19T10:12:14Z

---

BSzili wrote:

No, both are single-user systems. The point of homepath is not that it is different for each user, but that it is separate from basepath, so if files get deleted or corrupted in homepath, there is always backup at basepath.

I still don't like that ET:L forces this behaviour for clients instead of just printing a warning, but if we are going to do this then it should be the same on all our supported platforms.

[ETLegacyTeam]

From: @BSzili (BSzili) Date: 2013-10-19T10:30:30Z

---

Radegast wrote:

BSzili wrote:

No, both are single-user systems. The point of homepath is not that it is different for each user, but that it is separate from basepath, so if files get deleted or corrupted in homepath, there is always backup at basepath.

I still don't like that ET:L forces this behaviour for clients instead of just printing a warning, but if we are going to do this then it should be the same on all our supported platforms.

Okay, I fixed this to make it consistent with the other supported platforms.

[ETLegacyTeam]

From: @IR4T4 (IR4T4) Date: 2014-12-22T07:06:42Z

---

Is there any progress? 2.71 release is tagged: https://github.com/etlegacy/etlegacy/tags

[ETLegacyTeam]

From: @BSzili (BSzili) Date: 2014-12-24T09:51:07Z

---

IR4T4 wrote:

Is there any progress? 2.71 release is tagged: https://github.com/etlegacy/etlegacy/tags

Unfortunately no. There is a serious bug which prevents online play that I couldn't fix.

[ETLegacyTeam]

From: @rmarquis (Spyhawk) Date: 2015-08-22T10:40:50Z

---

The code for other platforms has been removed from master - it's not maintained.