Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
87 user(s) are online (68 user(s) are browsing Forums)

Members: 0
Guests: 87

more...

Headlines

 
  Register To Post
« 1 ... 6 7 8 (9) 10 11 »

Re: ScummVM and AmigaOS4.1 F.E.
Home away from home
Home away from home


See User information
@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.

Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Home away from home
Home away from home


See User information
@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)

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
Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Home away from home
Home away from home


See User information
@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

Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Just popping in
Just popping in


See User information
Great video!! Liked on youtube

Keep up the good work you guys!

AmigaOne X5000 -> 2GHz / 16GB RAM / Radeon R7 250 / M-Audio 5.1 -> AmigaOS 4.1 FE / Ubuntu Linux
Amiga 1200 -> Recapped / 68ec020 ACA 1221ec / CF HDD / RetroNET connected to the world
Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Just can't stay away
Just can't stay away


See User information
@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 R9 270X

http://www.tinylife.org.uk/
Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Home away from home
Home away from home


See User information
@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 ?

Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Just can't stay away
Just can't stay away


See User information
@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 R9 270X

http://www.tinylife.org.uk/
Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Home away from home
Home away from home


See User information
@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
Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Just can't stay away
Just can't stay away


See User information
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 R9 270X

http://www.tinylife.org.uk/
Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Home away from home
Home away from home


See User information
@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 ?

Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Home away from home
Home away from home


See User information
@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 Interruptexception
Alert number
0x80000003

Register dump
:
GPR (General Purpose Registers):
   
07F86BA40 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 RegistersNaN 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
:
DATA00000000 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:95Tools:Games/ScummVM/sobjs/libpthread.so:__init_threads()+0xf4 (section 8 0x6530)

PPC disassembly:
 
7f86ba3c4e800421   bctrl             
 7f86ba40
38800000   li                r4,0
*7f86ba44907f000c   stw               r3,12(r31)
 
7f86ba4838610038   addi              r3,r1,56
 7f86ba4c
480005fd   bl                0x7F86C048

System information
:

CPU 
 Model
P.ASemi 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).

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
Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Just can't stay away
Just can't stay away


See User information
@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.

Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Home away from home
Home away from home


See User information
@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
Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Home away from home
Home away from home


See User information
@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

Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Home away from home
Home away from home


See User information
@Capehill

Oh...thank you so much

Will test too

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
Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Home away from home
Home away from home


See User information
@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

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
Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Home away from home
Home away from home


See User information
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)

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
Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Home away from home
Home away from home


See User information
@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 ?:)

Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Home away from home
Home away from home


See User information
@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

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
Go to top
Re: ScummVM and AmigaOS4.1 F.E.
Home away from home
Home away from home


See User information
@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.

Go to top

  Register To Post
« 1 ... 6 7 8 (9) 10 11 »

 




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




Powered by XOOPS 2.0 © 2001-2016 The XOOPS Project