ScummVM and AmigaOS4.1 F.E.

	Bottom Previous Topic Next Topic
Register To Post

« 1 ... 6 7 8 (9) 10 11 12 ... 35 »

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/16 20:39 #161

Home away from home

@joerg
There were same issues and with z.library and with bzip2.library (later come from mui arhive, overwrite some other, and co), yeah.

Anyway, while its not about scummvm much: sobjes didn't have proper versioning inside, but only in the name + those softlinks, both of which adding unnecessary complication which we don't need. Also, loading/reloading sobjes taking time, while when you run one time single binary and everything in the memory , it always faster.

By idea that all good and fine, but in reality everything which use sobjes, always a little bit slower and giving potencialy more issues.

Join us to improve dopus5!
AmigaOS4 on youtube

Raziel

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/16 21:53 #162

Home away from home

@kas1e

wrt static, no

The problem is NOT the memory consumption *during* the apps run (that would only happen, if a game consumes too much memory and would be the same with static builds), but the memory consumption WHILE linking the static binary (and it will only get worse with the ever so growing library of new engines)

I already run out of memory when linking ScummVM static, even with 2 GB of RAM on my x1000 due to the infamous "last 300 mb of ram will crash if accessed" bug.

If anyone should/would take over ScummVM maintenance and only do cross compiles (where memory isn't a problem) I'll gladly step back from annoying anyone, but as long as I get the chance to do native builds I'll do that (and I actually like the idea and implementation of plugins - as long as the needed shared objects are provided).

So no, no static builds from me anymore (maybe when 4 or more GB of RAM will be supported, but I won't hold my breath for anything anymore)

--

game box/art scans
scummvm infrequent builds

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/18 11:10 #163

Home away from home

@All
Made a normal-big video about ScummVM on shaders where shown those shaders-based games, how they works, making some comments there and there to explain all the things, and os on. Maybe some of you will find it interesting: https://youtu.be/vgo_hIOauEk

Join us to improve dopus5!
AmigaOS4 on youtube

Skateman

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/18 14:14 #164

Not too shy to talk

Great video!! Liked on youtube

Keep up the good work you guys!

AmigaOne X5000 -> 2GHz / 16GB RAM / Radeon RX 550 / ATI X1950 / M-Audio 5.1 -> AmigaOS 4.1 FE / Linux / MorphOS
Amiga 1200 -> Recapped / PiStorm CM4 / SD HDD / WifiPi connected to the NET
Vampire V4SE TrioBoot
RPI4 AmiKit XE

ddni

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/20 18:58 #165

Just can't stay away

@kas1e

Good video.
Does this need RadeonRX? I use a Southern Islands card.
I have the same versions of ogles and warp3dnova as you.
I got the 20/04/22 branch of ScummVM, however Grim gives me the error cannot open grim_primitive.vertex.

Any ideas?

AmigaOne X1000.
Radeon RX550

http://www.tinylife.org.uk/

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/20 19:40 #166

Home away from home

@ddni
Quote:

Does this need RadeonRX? I use a Southern Islands card.
I have the same versions of ogles and warp3dnova as you.

RadeonHD also ok of course, just things will be slower.

Quote:

however Grim gives me the error cannot open grim_primitive.vertex.

Shaders should be place in the correct place of scummvm in the "engines" directory. I.e. you should have:

scummvm_dir/engines/grim/shaders/
scummvm_dir/engines/myst3/shaders/
scummvm_dir/engines/stark/shaders/
scummvm_dir/engines/wintermute/base/gfx/opengl/shaders/

And you can take them from the same place in the source archive

Through, as far as i aware, those shaders should be copied automatically now for os4 build if you use their daily builds, isn't it happens ?

Join us to improve dopus5!
AmigaOS4 on youtube

ddni

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/21 12:24 #167

Just can't stay away

@kas1e

Thanks, no the AmigaOS4 build that i got from here https://buildbot.scummvm.org/#/dailybuilds
has the shaders in scummvm_dir/shaders/

I created the engines/grim/shaders/ drawer and copied the grim shaders to there. All seems good now.

AmigaOne X1000.
Radeon RX550

http://www.tinylife.org.uk/

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/22 14:12 #168

Home away from home

@ddni
Alternatively (and what is more easy way) you could just moving the shaders directory (with all shaders) as it was originaly, to extras folder, that should help as well.

lephilousophe say that he will fix it today/tomorrow, so daily builds will be fine too.

What is left for now (and what with us for all the time in scummvm), it's issues with GUI and that issues with themes changes and non finding of valid translations.dat, while it here. That need some debug.

Edited by kas1e on 2022/4/22 14:34:36
Edited by kas1e on 2022/4/22 14:35:10
Edited by kas1e on 2022/4/22 14:38:44

Join us to improve dopus5!
AmigaOS4 on youtube

ddni

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/22 18:15 #169

Just can't stay away

I now notice that clicking on the gui forces toggling between window and full screen. Not sure what happened. Will try a reinstall to see if it resolves the issue.

AmigaOne X1000.
Radeon RX550

http://www.tinylife.org.uk/

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/24 9:59 #170

Home away from home

@ddni
Can't reproduce, can be just some mess with memory need it reboot. Or alternatively if it builds with .so version of SDL2, you may have some older one.

@Raziel

What issues we have left with this ScummVM ? I mean os4 side and not engines related ?

I count now:

1). On running we always have "WARNING: You are missing a valid 'translations.dat' file. GUI translation will not be available. Through translations.dat surely in the "themes" directory where it should be.

2). We have something with themes choose. Changing in the config directly make all works, but from GUI it feels like something wrong. Even if i set all the correct patches and save, we still have issues with.

What else ?

Join us to improve dopus5!
AmigaOS4 on youtube

Raziel

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/24 10:33 #171

Home away from home

@kas1e

Uh, where to start?

Ok, your points first

1 - Not always. I, for one, don't get it.
You just need a "sane" directory structure.
As i said before the problems seems to stem from a bug in "mkdir", where it messes something up directory/filesystem/protection bit/your-guess-wise (since i don't know the inner workings of filesystems or similar, i don't know what could be going wrong).

An "easy" workaround would be to create a new directory structure (with AmigaOS board tools, like "makedir" or ASyncWB's "create new dir" and copy the stuff there - extras, themes etc.), that *always* fixes this for me.

That is a genuine AmigaOS4 issue (but pretty sure not a ScummVM one)

2 - I don't really know what you are trying to say. What issues?
Again, if 1 is working, 2 will be as well, i guess.

These are my issues (which i'm not good enough to tackle myself)

1 - I get a warning sometimes that createDirectory() is not supported, especially when an engine tries to create it's own save files/subdirs etc.
Reason for this is:
in backends/fs/amigaos/amigaos-fs.cpp, lines 386-389


bool AmigaOSFilesystemNode::createDirectory() {

    warning("AmigaOSFilesystemNode::createDirectory() -> Not supported");

    return _bIsValid && _bIsDirectory;

}

is a stub.

This needs to be fleshed out to be working.
@capehill gave me an example once, but i couldn't even get my head around understanding what's happing in the example and got no chance to adapt it for ScummVM.

2) I still get a crash on either the first start or the second start with plugins, so there still seems to be something in the shared code that needs to be taken care of. But as long as i don't have a decent debugger, i'll probably never find out what is happening.
It could be the amount of engines, it could be the size of one or two engines, it could be something completely different...

I got this one time (starting from shell):
Quote:

terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
***Command 'debug' returned with unfreed signals 1E000000!

and this one other time


Crash log for task "ScummVM"

Generated by GrimReaper 53.19

Crash occured in module libpthread.so at address 0x7F86BA44

Type of crash: DSI (Data Storage Interrupt) exception

Alert number: 0x80000003



Register dump:

GPR (General Purpose Registers):

   0: 7F86BA40 596F2C20 00000000 596F2C28 00000000 62B2FB78 00000001 FFFFFFE0 

   8: 00000000 02A9ACC2 02A9AEC2 7776A4A4 00000ADC 4E180E5C 58202F00 00000001 

  16: 66406790 DFBF46D0 6C396280 00000000 596F2DA8 7F865514 0290EC20 0290EC80 

  24: 0290EC5C 4E1181A8 0290EC20 662BC764 596F2C30 00000001 0290EC04 0290EC40 





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

   0:              nan     -4.4678e+307     -4.4678e+307     -4.4678e+307 

   4:     -4.4678e+307       4.5036e+15              420              140 

   8:              280              140             2550       4.5036e+15 

  12:                1      2.14748e+09                0                0 

  16:                0                0                0                0 

  20:                0                0                0                0 

  24:                0                0                0                0 

  28:                0                0                0                0 



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





SPRs (Special Purpose Registers):

           Machine State (msr) : 0x0000B030

                Condition (cr) : 0x62720000

      Instruction Pointer (ip) : 0x7F86BA44

       Xtended Exception (xer) : 0x58102134

                   Count (ctr) : 0x00570001

                     Link (lr) : 0x00000000

            DSI Status (dsisr) : 0x85027002

            Data Address (dar) : 0x62722A44







680x0 emulated registers:

DATA: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

ADDR: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 

FPU0:                0                0                0                0 

FPU4:                0                0                0                0 







Symbol info:

Instruction pointer 0x7F86BA44 belongs to module "libpthread.so" (PowerPC) 

Symbol: __init_threads + 0xF4 in section 8 offset 0x00006530



Stack trace:

    [source/linklib/lib.c:95] Tools:Games/ScummVM/sobjs/libpthread.so:__init_threads()+0xf4 (section 8 @ 0x6530)



PPC disassembly:

 7f86ba3c: 4e800421   bctrl             

 7f86ba40: 38800000   li                r4,0

*7f86ba44: 907f000c   stw               r3,12(r31)

 7f86ba48: 38610038   addi              r3,r1,56

 7f86ba4c: 480005fd   bl                0x7F86C048



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

but it's quite random

---

I built the latest sources and need to say thank you for all the work you and @lephilosouphe put into the 3D/OpenGL/OGLES2 stuff.
It works (to an extent, but at least rock stable for now), with some glitches still displaying in the 3D games (but that was covered on the Enhancer tracker and will probably be already gone with a new ogles2.library?)
The speed is great (at least 40 FPS on every game i tried, some even higher).

--

game box/art scans
scummvm infrequent builds

Capehill

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/24 11:07 #172

Just can't stay away

@Raziel

About creating a directory, I tried to adapt my example to ScummVM, it's not compiled or tested:


bool AmigaOSFilesystemNode::createDirectory() {

    BPTR lock = IDOS->Lock(_sPath.c_str(), SHARED_LOCK);

    if (lock) {

        IDOS->UnLock(lock);

        debug("AmigaOSFilesystemNode::createDirectory() -> Directory '%s' exists already", _sPath.c_str());

        return _bIsValid && _bIsDirectory; // TODO: should we examine is it really a dir?

    }



    lock = IDOS->CreateDir(_sPath.c_str());

    if (lock) {

        IDOS->UnLock(lock);

        debug("AmigaOSFilesystemNode::createDirectory() -> Directory '%s' created", _sPath.c_str());

        _bIsValid = true;

        _bIsDirectory = true;

    } else {

        warning("AmigaOSFilesystemNode::createDirectory() -> Failed to create '%s'", _sPath.c_str());

    }    

    

    return _bIsValid && _bIsDirectory;

}

It probably needs some improvements.

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/24 11:39 #173

Home away from home

@Raziel
Quote:

1 - Not always. I, for one, don't get it.
You just need a "sane" directory structure.
As i said before the problems seems to stem from a bug in "mkdir", where it messes something up directory/filesystem/protection bit/your-guess-wise (since i don't know the inner workings of filesystems or similar, i don't know what could be going wrong).

An "easy" workaround would be to create a new directory structure (with AmigaOS board tools, like "makedir" or ASyncWB's "create new dir" and copy the stuff there - extras, themes etc.), that *always* fixes this for me.

That is a genuine AmigaOS4 issue (but pretty sure not a ScummVM one)

Can you describe what you mean by "sane" directory structure, and what wrong with current one ?

And why there is issues with "mkdir", if we just tried to use exiting diretories and exiting translations.dat file ? Or scummvm use mkdir() in some unusual way ?

Quote:

An "easy" workaround would be to create a new directory structure (with AmigaOS board tools, like "makedir" or ASyncWB's "create new dir" and copy the stuff there - extras, themes etc.), that *always* fixes this for me.

I build myself scummvm on crosscompiler, and then copy all the stuff via zita-ftp (so it create dirs/files by "amigaos") and still i have same issues.

Edited by kas1e on 2022/4/24 12:00:46

Join us to improve dopus5!
AmigaOS4 on youtube

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/24 11:44 #174

Home away from home

@Capehill
Quote:

About creating a directory, I tried to adapt my example to ScummVM, it's not compiled or tested:

Added that, and it surely compiles fine, need to test now

Join us to improve dopus5!
AmigaOS4 on youtube

Raziel

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/24 12:10 #175

Home away from home

@Capehill

Oh...thank you so much

Will test too

--

game box/art scans
scummvm infrequent builds

Raziel

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/24 12:27 #176

Home away from home

@kas1e

Quote:

Can you describe what you mean by "sane" directory structure, and what wrong with current one ?

"Sane" as in "created by AmigaOS board tools".
It's hard to explain, see below

Quote:

And why there is issues with "mkdir", if we just tried to use exiting diretories and exiting translations.dat file ? Or scummvm use mkdir() in some unusual way ?

ScummVM doesn't care about mkdir.

Let me try to explain:
In
backends/platform/fs/sdl/amigaos/amigaos.mk
we automate the installation process by creating mandatory directories and copy the stuff over to those.
In our case, see lines 30 and 41


makedir all $(AMIGAOSPATH)/themes

Originally "makedir" (AmigaOS board tool) wasn't there, instead the SDK tool "mkdir" would do the job.

BUT ... if i let "mkdir" do the directory creation (on a vanilla install, read, no directories there in the first place) i end up with all the problems you describe, no themes accessible, no extras, all kind of strange errors regarding file access.
(Hell, i can even force those errors by replacing "makedir" with "mkdir" dir again)

I wrote up quite some findings in some of the github issue trackers, but can't find my post (probably was on the gcc tracker, don't know anymore)

Quote:

I build myself scummvm on crosscompiler

I don't know what happens when "copying it over", i also don't know if you use


gmake amigaosdist

on compiling, but since cross-compiling involves "mkdir" again, i'm pretty sure that is the problem.

But please, try to create your own themes/ subdirectory (with "makedir"), copy/move the stuff in there, point ScummVM to it and try.

I'm completely stumped about what could be the problem, but i'm pretty sure something is not right.

Heck, maybe ScummVM *does* something weird while reading, i don't know, but i also don't believe it.

There is a common base to this bug, we just need to find it

--

game box/art scans
scummvm infrequent builds

Raziel

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/24 12:51 #177

Home away from home

In game videos (renders) are still slow (except Grim Fandango, but those look like they used in-game graphics and not pre-rendered stuff).

Here's hoping for the gfx driver to support video hardware decoding soon(-ish)

--

game box/art scans
scummvm infrequent builds

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/24 13:17 #178

Home away from home

@Raziel
Quote:

we automate the installation process by creating mandatory directories and copy the stuff over to those.

I am not. I build manually only binary of scummvm, and then i use my own directories created manually via copying them to os4 (i.e. i not use automatic stuff from makefiles to create directories, i use ones coming with scummvm source code, and just copy them).

Quote:

In game videos (renders) are still slow (except Grim Fandango, but those look like they used in-game graphics and not pre-rendered stuff).

Which game videos you mean ?

Quote:

Here's hoping for the gfx driver to support video hardware decoding soon(-ish)

What one ?:) I mean, what should be accelerated and where ? Video hardware decoding available, but who said it will support anything in scummvm ?:)

Join us to improve dopus5!
AmigaOS4 on youtube

Raziel

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/24 15:18 #179

Home away from home

@kas1e

Quote:

I build manually only binary of scummvm, and then i use my own directories created manually via copying them to os4 (i.e. i not use automatic stuff from makefiles to create directories, i use ones coming with scummvm source code, and just copy them).

As i said, i don't know the steps to reproduce.
Try to still do the test setup i described earlier.
Manually create the dirs and copy the stuff to them, point scummvm to the new dirs and see what happens.

Quote:

Which game videos you mean ?

All pre-rendered stuff, i can only quote some games.
e.g.
1 1/2 Rittter - in game movie trailer
J.U.L.I.A. - all videos
I'll try to find one that is freely available or has a demo showcasing it.

edit:
Here you go
Just let the intro movie roll after you picked "New Game"...the sound is way faster than the video...and this is with all pre-rendered stuff.

Quote:

What one ?:) I mean, what should be accelerated and where ? Video hardware decoding available, but who said it will support anything in scummvm ?:)

Is it though? For everyone, or only betatesters?
I can't really test since i don't own Emotion

--

game box/art scans
scummvm infrequent builds

kas1e

Re: ScummVM and AmigaOS4.1 F.E.

Posted on: 2022/4/24 15:34 #180

Home away from home

@Raziel

I think we mix everything there about videos.

For first, yes, hardware decoding publicaly available only for RadeonRX , and not for RadeonHD. But that mean, that only software which use this hardware decoding API (va.library) are able to use GPU for hardware decoding. That what do Emotion and DvPlayer.

Now, if you want "hardware acceleration via GPU" in any other software, you need to write code to support it. Automatically it will not make anything anywhere use new API.

Now about that:

Quote:

All pre-rendered stuff, i can only quote some games.
e.g.
1 1/2 Rittter - in game movie trailer
J.U.L.I.A. - all videos
I'll try to find one that is freely available or has a demo showcasing it.

edit:
Here you go
Just let the intro movie roll after you picked "New Game"...the sound is way faster than the video...and this is with all pre-rendered stuff.

That all can be slow or fast, but it all depend on the ScummVM and their code. For things you mention, if i remember right i read that it slow everywhere (JULIA for example).

And in general, all those "trailers" in no way pure "mp4 files", but some rendered crap, or whatever else used by their engines. If some engine still do use pure video files, then to support harware video decoding of them you need to use new API, or it will be still CPU based, and then, again, x1000/x5000 CPU is good enough to play via CPU those videos, and if they slow, it mean ScummVM there to blame.

Join us to improve dopus5!
AmigaOS4 on youtube

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

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