Curiosity got the better of me and I ordered the new OS3 version of Gorky 17 just to see if it would run under MorphOS.

The installation script breaks under MorphOS but the game boots but appears unable to properly "open" a screen. It draws a screen but then crashes with the menu music continuing to play.

The message that appears on the Server Log at the moment is;

Instruction at Address 0x1f2136a4 in <Work:Gorky17/Gorky17> Hunk 2 Offset 0x42aa4

If you use software rendering this changes again.

I presume it is something to do with the graphics drivers but I don't know if this is something fixable in future MorphOS releases.

You can read some comments of the developer about an WarpOS port
Steffen Häuser

Thanks for pointing me in that direction. Definitely looks positive as a WarpOS port should do the business.

No, I don't understand why a WarpOs version should help to fix the issues.
The 68k should really work on Mos without any drawbacks.
I already asked Stefan if I can do a Mos native version which should not be to hard,
because he already has a 68k version with ahi and rtg support.

He rejected my request (because of any license problems) ...

Quote:

Really? This is such an old game I cant imagine anyone including the owners of the IP not wanting new revenue from it!

>> I already asked Stefan if I can do a Mos native version […].
>> He rejected my request (because of any license problems)

> Really?

Yes, supposedly Hyperion's license agreement is restricted to operating systems named "AmigaOS", which would allow for ports to OS3 (m68k and PPC/WarpUP) and OS4, but not to MorphOS.

> This is such an old game I cant imagine anyone including
> the owners of the IP not wanting new revenue from it!

I doubt the licensor will get any revenue from it, or got any from Hyperion's previous Linux, Mac and OS4 ports of the game. Hyperion has usually negotiated lump sum game licenses in the past.

Hi!

I thought it might be best if I reply directly.

- Licence does not allow a MorphOS port (in which I do not have any interest anyways)
- I actively work on a WarpOS version which should run on Sonnet cards, Classic 3.x system with PPC Card and MorphOS systems and if this succeeds will be tested on those three

As to the problems with the 68k version of the game running under MorphOS, some questions from me.

- Is it possible this was due to the movie player ? Gorky17 uses an external 68k-ASM written movieplayer (Riva). This movie player is launched "first thing" after the game starts. If it is just the movieplayer you could try renaming the movieplayer ("rename RivaG17 RivaG17b" or whatever). Then the game skips movieplaying. Note that if it IS the movieplayer which is the problem G17 supports using a different movieplayer. You might be able to check if it is the movie player by trying the movieplayer directly (RivaG17 avi/intro.avi). Please note this is not really a AVI, I was just lazy to rename the fileending in the source code. It really is a MPEG1 named .avi.

For example to replace riva with Frogger you could write into the file env:g17/g17_extplayer the following

c:frogger.040 FULLSCREEN %s

Riva is used by default as for the intended target (PiStorm and Vampire systems) Riva runs much better than any other movieplayer.

So if the problem is just the video player this would be easily fixed (this is listed in the readme BTW how to exchange the movieplayer)

- If it is not the video player could it be stack related (no idea if MorphOS has stack issues or not), if it could be try raising the stack (though the icon for Gorky17 actually has enough stack set)

- As to the Video Refresh I do the following:

* Use CybergraphX LockBitmap to get LBMI_BASEADDRESS and LBMI_BYTESPERROW
* Graphics Data is then copied into the video RAM directly, and at the end UnLockBitMap is called
* Graphics format of the screen is found out using GetCyberMapAttr, all 16 Bit, 24 Bit and 32 Bit formats are supported. 15 Bit Format is not supported.

It is all really pretty standard CybergraphX stuff.

- You can also use Window Mode by editing settings.ini (is generated after the game was started first time) and replace fullscreen=1 with fullscreen=0

MagicSN
tirionareonwe@gmail.com

Hi Steffen

I've just replied to your email to me, but I will also comment on this here.

i. I don't believe it is to do with the video player as I have used the command to disable this and run into the same issue.

ii. Also the game crashes/freezes at exactly the same point when in both fullscreen and windowed mode, although the menu music keeps on playing.

Sorry I cannot be of much more help but I do really think this isn't anything major but just some small difference in the graphics implementation on the MorphOS side.

While I appreciate there cannot be a MorphOS version for licensing reasons, hopefully the WarpOS version might be the fix we need.

Zetec-S

Does the server log give any additional info ? Something like a stack trace (even if no source-code lines but just addresses/offsets are listed) ? Or does it only list the location of the crash itselves ?

And yes, it is possible that there is a small difference in graphics implementation though I really do pretty standard stuff here. It is also possible it is not the graphics output but something like reaction to mouse or whatever. Or even an effect of the 68k Emulation (though this is probably more doubtful).

It will also be interesting if this will happen with the WarpOS port (once this is done) too or not. But I am pretty sure eventually I will work it out. And while I won't do a MorphOS version I will try to fix this issue.

Another question - Zetec-S mentioned the installer script command copyfiles would not work on MorphOS. What could I use instead? It is stuff like

(copyfiles(source "G17Ami:Locals/Gorky17.info")(help "")(dest #dest-dir)(all))

which appearently causes the problem (I use stuff like this all the time, Zetec-S fixed that by copying the needed files manually).

@Zetec-s
You may also try InstallerLG, it's more compatible.

> WarpOS version […] should run on Sonnet cards

If it will run on Sonnet Crescendo 7200 cards, I guess it will run on all the other non-Sonnet cards supported by SonnetLibrary (PowerPMC-250, PrPMC8xx, KillerNIC) as well, as long as there's enough RAM, right? :-)

@Andreas_Wolf: Yes, I meant Sonnet card more like a general term for PCI PPC Card. I do not know which cards in question are supported and which not (but I know people who have such cards for testing, including the guy who created WarpOS for Sonnet PCI).

And yes, around 180 MB free when starting the game is needed (it might work with a bit lower, but no guarantees).

@polluks: Thanks for the hint. Zetec, maybe you can test this, if this fixes the issue ? The big issue is of course still the "graphics issue" if I may call it so for now. But as I said I think eventually I will find this out.

With the help of Zetec-s I could already have a lead on the crash.

If the data from the stacktrace can be trusted (I sent Zetec-s my latest executable to ensure there was no last-minute change changing the indicated location of crash) then what crashed was the function gettimeofday.

Basically this:

static struct timeval tv;

gettimeofday(&tv, NULL);

caused the crash. The crash was illegal instruction (possibly 68k Emu issue with the linkerlib used ?)

If this is a problem and still appears in the WarpOS version I could of course change this code into using GetSysTimePPC from powerpc.library on the WarpOS version (once this is running) to avoid the problem (I am just using it to get the amount of microseconds passed...).

Little Update - since this evening Gorky17 is running on WarpOS too (still an early Beta though).

I can now confirm that the WarpOS Version of Gorky17 runs on MorphOS (tested on a MacMini by one of my Betatesters). Currently it only works if Ingame Videos are disabled, but I hope to be able to fix that still (alternatively to bugfixing SDL setting the env variable to "Use a different video player" of Gorky17 might fix the issue - what video players are normally used for MorphOS ? And can they do a different AHI Unit than 0 ?) The other game I am working on was also tested successfully on MOS (with the WarpUP version), same results. Intro video causes problems, but asides from that the game works fine.

That sounds awesome!

Quote:

MPlayer zum Beispiel

[ Editiert durch ThorstenS 04.11.2024 - 12:05 ]

Indeed, MPlayer supports the SMJPEG codec.

Does Mplayer in the MOS-Version give the option to let it run on a AHI Unit which is not Unit 0 ?

If yes I could provide an option to run it like this. Currently I have two ways to run it:

a) Tries to shutdown game audio before running an intro movie then run the intro through external player - which can be customized by an env variable - and after that restart the game sound

This works "perfect" on real WOS systems with no problems left. On a OS4 or MOS system it leads to the game "hanging" unless you disable the whole videos.

b) Never shutdown the game audio. This leads to after the game sound runs if a video is started this video does not have sound.

Now if theoretically I could run the gamesound on unit 0 and the movieplayer on unit 2 for example, the problem could be workarounded. As SDL WOS (used for the sound output only) is hardcoded to Unit 0 a player which can modify the AHI Unit it uses would be needed. And I have no idea what is available on MOS there (on "real WOS" the only player with that feature was Frogger, but it was pretty slow on my tests and also tended to crashes on quitting the game for some reason).

Alternatively to this I am investigating if it can be found out what causes the bad behaviour on closing Audio of SDL WOS.

MPlayer documentation tells:
Quote:

So, you can select between Music Unit ("-ao ahi" argument) and Unit 0 ("-ao ahi_dev" argument), but I don't think you can select units 1-3. Aren't those different units more like for different audio hardware anyway, if you'd have several audio cards in your machine? At least it's pretty de-facto that programs use either Music Unit or Unit 0, so users may not have configured units 1-3 at all, at least I haven't :)

But would it solve the issue if you'd use Music Unit (exclusive access) for the intro video and then Unit 0 for game sounds? Even though some people may have forwarded music unit to unit 0 for simultaneous output, but if it'd do the trick still?

@JPV: I was not aware of this. Might also be this behaves different on MOS ansd AOS. But I will tell my Betatester to try using the ahi instead of ahi_dev, and how it behaves then.

[ Edited by MagicSN 04.11.2024 - 13:46 ]

@JPV: Many thanks for your suggestion, mplayer did the trick Still have to include some option into the installer so that people can choose to use mplayer. But anyways I just got reply from my MOS-tester that all works fine with the WOS-Version (game and intros) if it gets configured to use mplayer (now we have mplayer for OS4 and MOS, Riva for non-AGA 68k, AGABlaster - at least for the new game, not G17 - for AGA 68k, AMP for WarpOS when NOT on MOS - a configuration-nightmare! One of the two games has a 500 lines installer script with all the different versions, the other one 1000 lines ^^)

[ Edited by MagicSN 04.11.2024 - 16:21 ]

Good that it helped :) I guess everything regarding AHI should be similar on AOS and MorphOS. I guess you'll leave some easy way to disable movie playback still? Just in case if something would fail with the players after all.

@JPV: Yes, there is a env variable called env:g17/g17_disableintros, if this file exists no movies are played (originally I introduced it as having the three intros everytime you start the game can be annoying ^^).

And yes AHI should be similar on both - maybe it is Drivers which are different ? Or the fact that on WarpOS often 8 Bit Settings are used and on MOS/OS4 16 Bit ? (WOSEmu under OS4 seems to "behave" similar to the one under MOS, with similar problems with the game - but of course OS4 users can use the OS4 version of the game to avoid this issue).

One guy suggested it might be an issue if a WarpOS Sub-Task is launched, that this causes problems for AHI under MOS WOSEmu (or on OS4 WosEmu as well).

Anyways from what the tests indicate it works fine now. The trick seems to be:

Normal WarpUP -> shut down gamesound - play video - enable gamesound again
MorphOS -> do not shutdown gamesound - play video with mplayer

I am checking if the file sys:MorphOS/Ambient/Ambient exists (someone told me this exists always on MorphOS) to identify if the game is running on MorphOS or on WarpUP AmigaOS 3.x and then the game behaves as outlined above depending on the result of this check. And before any of this the env variable I mentioned above is checked.

It was tested now with both games (G17 and my new game) on MorphOS/MacMini, AmigaOS/CSPPC, AmigaOS/BPPC, AmigaOS/SonnetPPC, AmigaOS/ApocalypsePPC and seemed to run fine for all of them with the mentioned changes.

The problems I had with timer.device (earlier in this thread) on the 68k Version running on MOS did BTW not happen with the WarpOS version.

If nothing goes wrong (any big bugs found in testing or such...) the WarpUP version should be released early December (I still leave some time for testing, even though I think this version is "it" now).