I had a few cases where I got the error message about missing directory creation, but I forgot when and how it happened.
I do have one week off of work in two weeks and will try to create a test case.
I did found a case where I still get an error, even with your fix, but I'm not sure if it is the same issue or some other path issue. To reproduce, set the save path to something that doesn't exist, e.g. ram:test/ (change it manually in scummvm.ini)
Ok, so here's a simple test case (haven't tried your addition yet with the test case as it's still building for me)
Create a directory anywhere (e.g. "test"), point the "save path" of ScummVM's options to it. Delete "test" directory afterwards again and start ScummVM with any game and try to save.
WARNING: AmigaOSFilesystemNode::createDirectory() -> Not supported! WARNING: DefaultSaveFileManager::assureCached: Can not cache path 'RAM Disk:test/': 'Failed to create directory 'RAM Disk:test/''!
Not sure if the trailing slash adds to the problem...
if 'ram:test/' is what is seen then it won't create a new directory, since the end of what it sees indicates a already existing test directory and it will try to create "" on AmigaOS. it IS stated clearly in the autodocs for CreateDir and CreateDirTree.
Ok, tried you test case and then hit issue trgswe mentioned. Modified example so that it copies the given path and removes the trailing slash. Tested with BASS and seemed to work.
If you use this, please change log levels back to something reasonable (debug?). I used warning just in case.
I'm getting a 75% reproducable crash on starting ScummVM, always with pthreads and always on the first start (on a second start the crash goes away, but a crashed ScummVM is still dangling in memory). Seems something is not correctly initialized?
Here's the crashlog:
Crash log for task "ScummVM"
Generated by GrimReaper 53.19
Crash occured in module at address 0x7B06C440
Type of crash: ISI (Instruction Storage Interrupt) exception
Alert number: 0x80000003
Actually i have lots of these crashes with debug/non-release builds.
It could probably come from anywhere.
That pthreads crash started roughly back when i switched to gcc 11.3.0, but i wouldn't blame it (yet).
I also get start crashes with libcrypto.so and the ags plugin (but that is to be expected, since that is still heavily in development)
I changed some compiler options to see if that helps.
A question if i have your attention?
Is -mlongcall still a thing on AmigaOS4? What about -fomit-frame-pointer and -fstrict-aliasing for non-debug builds? Or is everything taken care of by the system now?
What about special altivec builds? Would they run on any other hardware too, simply diregarding the fact that there is no altivec or do i hvae to create a special binary?
For non programmers as we are, better to avoid it, to avoid problems. It's only real programmers can make good use of it, and build normal binaries working in parellel where need it with altivec, and where not need it without.
Hmm, ok, putting it back in then (was missing from the non-cross-compiler builds), better safe than sorry.
Quote:
Quote:
What about special altivec builds?
For non programmers as we are, better to avoid it, to avoid problems. It's only real programmers can make good use of it, and build normal binaries working in parellel where need it with altivec, and where not need it without.
Ok, i was under the impression that it would be as easy as adding