ScummVM and AmigaOS4.1 F.E.

	Bottom Previous Topic Next Topic
Register To Post	« 1 ... 5 6 7 (8) 9 10 11 »

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/12 13:00 #141

Home away from home

@Raziel
Oh, and btw, we do find why there were issues with Myst3 : we nede to set "Vsync" on to make effects works as expected.

Also, we do find that one latest issue with GRIM happens also and on Linux too, so Lephilousophe should deal with soon.

In other words, we need to wait for next enhancer update (should be soon enough, preparation work already goin), and we can build scummvm and release and all will be fine.

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

samo79

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/12 15:22 #142

Home away from home

@kas1e

I know stupid question maybe but.. in the internal check what will happens if you have for some reason installed that ogles2 on libs, but you don't have the proper hardware to use it for?.. for example you are using an old Sam440/AmigaOne with an older Radeon R200 cards only
Even in that case It will fall back to MiniGL in automatic?

Sam440ep Flex 800Mhz 160GB HD + AmigaOS 4.1

Raziel

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/12 19:07 #143

Home away from home

@kas1e

Nice...so i can finally get rid of the four different builds

Thank you so much for spending time to find and fix the issues.

I already asked, but i have one more request.

AGS is a fairly new supported library, which coughs up an error message every time i try to run a free game. It has to do with ogl (i guess it fails to use the correct driver)

Games is here

See here for the error message
Quote:

WARNING: SearchSet::add: archive 'gui-icons.dat' already present!
User picked target 'sq45' (engine ID 'ags', game ID 'sq45')...
Looking for a plugin supporting this target... Adventure Game Studio
Running Space Quest IV.5 - Roger Wilco And The Voyage Home
SQ4,5.exe: 5cd8db602cedc8f04cd3ca290a4a2693, 6886082 bytes.
WARNING: TODO: SetCurrentDirectory: Games:ScummVM/AGS/Space Quest/The Voyage Home/!
Initializing backend libs
Initializing game data
Located game data pak: SQ4,5.exe
Opened game data file: ac2game.dta
Game data version: 32
Compiled with: 2.72
Startup directory: Games:ScummVM/AGS/Space Quest/The Voyage Home/
Data directory: ./
Setting up game configuration
WARNING: AmigaOSFilesystemNode::createDirectory() -> Not supported!
Voice pack found: speech.vox
music.vox found and initialized.
Initializing TTF renderer
Initializing mouse: number of buttons reported is 3
Install timer
Initialize legacy path finder library
Game title: 'Space Quest 4.5'
Game GUI version: 115
WARNING: font 'agsfnt2.wfn' has mistakes in data format, some characters may be displayed incorrectly
WARNING: font 'agsfnt3.wfn' has mistakes in data format, some characters may be displayed incorrectly
WARNING: font 'agsfnt4.wfn' has mistakes in data format, some characters may be displayed incorrectly
WARNING: font 'agsfnt5.wfn' has mistakes in data format, some characters may be displayed incorrectly
Checking for disk space
Game native resolution: 640 x 480 (16 bit) letterbox-by-design
Graphic settings: driver: OGL, windowed: no, screen size: 0 x 0, game scale: proportional
Requested graphics driver 'OGL' not found, will try existing drivers instead

and here for the crash log (probably not really useful)


Crash log for task "ScummVM"

Generated by GrimReaper 53.19

Crash occured in module ScummVM at address 0x7F4CD00C

Type of crash: DSI (Data Storage Interrupt) exception

Alert number: 0x80000003



Register dump:

GPR (General Purpose Registers):

   0: 7E00C28C 6C4315F0 395C0008 00000000 548C0928 000001E0 00000020 00000000 

   8: 00DF0110 7E00C258 00000002 7F4CCFE4 44222428 648BCD74 6C431B04 6C431B24 

  16: 6C431AE4 6C431AA4 6C4319BC 64884190 6C431A84 6C431838 551D91F0 0000005D 

  24: 6C431628 6C431694 00000020 548EAE6C FFFFFFFF 548C0927 5FDEFAC4 00000000 





FPR (Floating Point Registers, NaN = Not a Number):

   0:              nan                1                0                0 

   4:                0         0.941667         0.992188              0.5 

   8:               -1              0.5              nan              nan 

  12:                1                0                0                0 

  16:                0                0                0                0 

  20:      2.02203e+07      2.02203e+07                0                0 

  24:                0                0                0                0 

  28:                0                0              0.1       4.5036e+15 



FPSCR (Floating Point Status and Control Register): 0x82020000





SPRs (Special Purpose Registers):

           Machine State (msr) : 0x0200B030

                Condition (cr) : 0x6BD90000

      Instruction Pointer (ip) : 0x7F4CD00C

       Xtended Exception (xer) : 0x5F90D134

                   Count (ctr) : 0x00570001

                     Link (lr) : 0x00000000

            DSI Status (dsisr) : 0x85027002

            Data Address (dar) : 0x6BD94A44







680x0 emulated registers:

DATA: 96C56800 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

ADDR: 6FFA4000 97BF8600 00000000 00000000 00000000 00000000 00000000 6C430B90 

FPU0:                0                0                0                0 

FPU4:                0                0                0                0 







Symbol info:

Instruction pointer 0x7F4CD00C belongs to module "ScummVM" (HUNK/Kickstart)



Stack trace:

    module ScummVM at 0x7F4CD00C (section 9 @ 0x6B41A8)

    module Tools:Games/ScummVM/plugins/libags.so at 0x7E00C28C (section 0 @ 0x1ACD68)

    module Tools:Games/ScummVM/plugins/libags.so at 0x7E00FE74 (section 0 @ 0x1B0950)

    module Tools:Games/ScummVM/plugins/libags.so at 0x7E028BA0 (section 0 @ 0x1C967C)

    module Tools:Games/ScummVM/plugins/libags.so at 0x7E028D48 (section 0 @ 0x1C9824)

    module Tools:Games/ScummVM/plugins/libags.so at 0x7E028F70 (section 0 @ 0x1C9A4C)

    module Tools:Games/ScummVM/plugins/libags.so at 0x7E029024 (section 0 @ 0x1C9B00)

    module Tools:Games/ScummVM/plugins/libags.so at 0x7E029854 (section 0 @ 0x1CA330)

    module Tools:Games/ScummVM/plugins/libags.so at 0x7E01FC34 (section 0 @ 0x1C0710)

    module Tools:Games/ScummVM/plugins/libags.so at 0x7E021660 (section 0 @ 0x1C213C)

    module Tools:Games/ScummVM/plugins/libags.so at 0x7DE634D8 (section 0 @ 0x3FB4)

    module ScummVM at 0x7EE23854 (section 9 @ 0xA9F0)

    module ScummVM at 0x7EE25B98 (section 9 @ 0xCD34)

    module ScummVM at 0x7EE22378 (section 9 @ 0x9514)

    native kernel module newlib.library.kmod+0x000025fc

    native kernel module newlib.library.kmod+0x000032d8

    native kernel module newlib.library.kmod+0x0000384c

    ScummVM:_start()+0x1e0 (section 10 @ 0x3280)

    native kernel module dos.library.kmod+0x0002a458

    native kernel module kernel+0x00059e04

    native kernel module kernel+0x00059e7c



PPC disassembly:

 7f4cd004: 48000008   b                 0x7F4CD00C

 7f4cd008: 41de002c   beq-              cr7,0x7F4CD034

*7f4cd00c: 8c7c0001   lbzu              r3,1(r28)

 7f4cd010: 48087629   bl                0x7F554638

 7f4cd014: 7c7f1b78   mr                r31,r3



System information:



CPU 

 Model: P.A. Semi PWRficient PA6T-1682M VB1 

 CPU speed: 1800 MHz 

 FSB speed: 900 MHz 

 Extensions: altivec 



Machine 

 Machine name: AmigaOne X1000 

 Memory: 2097152 KB 

 Extensions: bus.pci bus.pcie

People are dying.
Entire ecosystems are collapsing.
We are in the beginning of a mass extinction.
And all you can talk about is money and fairytales of eternal economic growth.
How dare you!
– Greta Thunberg

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/12 20:12 #144

Home away from home

@samo79
Is not that simple "check on ogles2.library" it normal check on functionality, so if things not works as expected, the fallback on minigl, and if not works as expected fallback to software.

@raziel
That one need to test.. do you ask anybody about , or is there any ticket about where i can find some more info ?

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

Raziel

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/12 21:28 #145

Home away from home

@kas1e

I did ask, but didn't get any valuable response as this seems to be one of those problems solely affecting AmigaOS.

I already created two tickets, but as i said, no one else seem to face the problems but us:
https://bugs.scummvm.org/ticket/12802
https://bugs.scummvm.org/ticket/12806

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/13 6:59 #146

Home away from home

@Raziel
Did i understand right that with software rendering all fine, that happens only with opengl rendering (be it minigl or ogles2) ?

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/13 8:18 #147

Home away from home

@Raziel
Tried with opengl_with_shaders (so ogles2) : no crash when running Running Space Quest IV.5, i pass well after "OGL" not found (and the same "OGL" not found happens on win32 too , btw).

But then , after a little bit more output, it just says :

ERROR: Unalbe to load the room file 'room74.crm'.

Exactly the same happens with software rendering.

So that can mean that maybe your crash happens because of that ? I.e. there just some basic endian issues in the AGS engine now not related to the rendering driver at all.

I will try some other game AGS game now to see if it will be the same.

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

Raziel

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/13 8:47 #148

Home away from home

@kas1e

I was too tired yesterday to follow up, but yes, it could easily be an endian issue, since
a) it's a rather new engine addition and
b) it seems we are the only (active) big endian platform on scummvm (more or less)

It would be great if you could add your findings to the tracker i posted.

Thank you

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/13 9:19 #149

Home away from home

@Raziel
I create instead new one (as previous ones maybe a bit misleading):
https://bugs.scummvm.org/ticket/13417

But once it will be fixed we can close all of them.

Will ask Lephilousophe maybe he can help with. And i also ask beworld on morphzone if he have the same issue on morphos, so we will know if it big-endian or platform specific

Edited by kas1e on 2022/4/13 17:40:12

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

Raziel

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/13 9:54 #150

Home away from home

@kas1e

Thank you

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/15 17:15 #151

Home away from home

@Raziel
Did i undersand it correctly, that AGS engine never works on big endian before ? I talked with lephilousophe and he says that AGS engine is really huge, and it's currently ported on a whole Windows based stuff, but he suppose it works on little endian. In other words he didn't know, but he know for sure than engine is huge, and were written for windows mostly.

Beworld also test it on moprhos, they failed even early than we, so can't say if they have same issue or not.

Probably it worth to test firstly on: 1). x86 linux, 2). ppc linux (on x5000). Then we will know much more about.

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

joerg

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/15 17:54 #152

Just can't stay away

@kas1e
Quote:

Probably it worth to test firstly on: 1). x86 linux, 2). ppc linux (on x5000). Then we will know much more about.

Linux PPC may not help any more. Like MIPS, ARM, etc. PPC CPUs support both big- and little-endian, and most still active Linux/PPC developers switched from using big-endian to little-edian (PPCLE).
It's slower and generally unusable, like any little-endian OS it requires a lot of workarounds for the wrong byte order, but a lot of current Linux software has endian bugs and only works in little-endian mode

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/15 19:25 #153

Home away from home

@Joerg
Quote:

Linux PPC may not help any more. Like MIPS, ARM, etc. PPC CPUs support both big- and little-endian, and most still active Linux/PPC developers switched from using big-endian to little-edian (PPCLE).
It's slower and generally unusable, like any little-endian OS it requires a lot of workarounds for the wrong byte order, but a lot of current Linux software has endian bugs and only works in little-endian mode

As far as i know, Flenix (linux ppc for x5000 i have) are big-endian still.

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

Raziel

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/15 23:02 #154

Home away from home

@kas1e

Quote:

Did i undersand it correctly, that AGS engine never works on big endian before ?

Mostly yes.
In the process of that engines integration there were builds were I was able to start and even play the first screens of Space Quest 4.5, but with every new addition it changed and the game crashed again.

Other games never worked, but I also didn't try many due to time constraints.

I talked to dreammaster, one of the main engine devs, he told me he wants to first get the code upto par with upstream before turning to bug reports.

So, time to sit back and watch for now.
I'm pretty sure it's another Endian issue, just as with Total Flush.

Thank you for looking though

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/16 15:21 #155

Home away from home

@Raziel
Btw, lephilousophe fixed latest bug in Frim today (not os4 related, but in scummvm), and if everything will be ok, he will merge all the latest changes to master trunk. So we will only need to wait public release of new ogles2/warp3dnova and made a new release.

Through, what i noticed : with shared objects, the startup of the scummvm is much longer. By much i mean +2-3 seconds taked out from startup just because shared objects used.

Maybe for time being we still can go "static" build route ? Or with all the engines enabled it's already out of memory ?

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

joerg

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/16 17:09 #156

Just can't stay away

@kas1e
Quote:

Through, what i noticed : with shared objects, the startup of the scummvm is much longer. By much i mean +2-3 seconds taked out from startup just because shared objects used.

Of course shared objects are slower, instead of linking the libraries just once with the compiler/linker when building the executable using static link libraries, that part hast to be done each time an executable using shared objects is loaded.

Quote:

Maybe for time being we still can go "static" build route ? Or with all the engines enabled it's already out of memory ?

There should be no difference in the memory usage between static and shared libraries, everything is loaded in both cases.
Only if the shared objects are only loaded on a demand basis, i.e. using some kind of plug-in system, using shared objects requires less memory. But that needs special support using elf.library functions, just building the executables with gcc -use-dynld doesn't do that.

The only benefit of using shared instead of static libraries on AmigaOS 4.x is that the users can update shared objects without all developers using them having to rebuild their executables.

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/16 18:40 #157

Home away from home

@joerg
Quote:

The only benefit of using shared instead of static libraries on AmigaOS 4.x is that the users can update shared objects without all developers using them having to rebuild their executables.

We know it all, just we already go through that in last years , and in reality, all those shared objects without proper versioning only make a mess on os4. Native amiga libraries are much better, and shared objects should't be used at all, but only in some very rare cases where plugins need it. At least that IMHO based on what we have in end in those last 10 years of os4. It only sounds like it can be good, but in end it was not.

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

joerg

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/16 18:53 #158

Just can't stay away

@kas1e
Quote:

Native amiga libraries are much better,

There is no difference, for example powerpc.library:
There are/were at least 4 different implementations of it (even if my implementation and it's predecessor, an even much older one which required patching WarpsOS executables, are obsolete now) the version numbers of the library don't help at all.

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/16 19:03 #159

Home away from home

@joerg
Quote:

There is no difference, for example powerpc.library:
There are/were at least 4 different implementations of it (even if my implementation and it's predecessor, an even much older one which required patching WarpsOS executables, are obsolete now) the version numbers of the library don't help at all.

They didn't have soft links, and relinks on eacht others. There is not powerpc.library.12.0 , powerpc.library.13.2, powerpc.library.xx.xx , then one single powerpc.library which softlinks on them, and software, which want exactly powepc.library, which will not works if it links to one or another version of previous libraries.

Amiga libraries while have limitations, doing by logic the same, but still, they not produce for us "dll-mess". Add to that realisation without versioning of those sobjes and we end up with a mess.

I know what i talk about : we already have that kind of mess with some jpeg and png sobjes coming with AOS4 updates, which make a mess.

Another example shared version of SDL-1.2, some old apps works _only_ with old one. And once you put new one to sobjs: , then everything crash with some other apps. If it was library, there can be check on version, but as it sobjs, you can check nothing.

Really, sobjs on os4 should be used only in necessary cases, like for plugins. But it should't be like something we all need to use to bloat things.

Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

joerg

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 4/16 19:21 #160

Just can't stay away

@kas1e
Sorry, but there is no difference.
IIRC I created the first AmigaOS 4.x version of z.library (a shared, AmigaOS native library port of libzip, not a .so one) and someone later implemented a different one, intentionally incompatible to my version.
Any software which was built using the includes of my z.library, but with the other, incompatible z.library installed in LIBS: instead, started crashing for no obvious reason.
It's exactly the same "dll-mess" as with shared objects.

Edit: Maybe it wasn't z.library but bzip2.library, but in any case it was one of the compression libraries for which someone created a version incompatible to my initial AimgaOS 4.x port.

Edited by joerg on 2022/4/16 19:37:09

Register To Post	« 1 ... 5 6 7 (8) 9 10 11 »
	Top Previous Topic Next Topic

Currently Active Users Viewing This Thread: 1 ( 0 members and 1 Anonymous Users )