@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.
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?
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)
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
@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 ?
@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.
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.
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
@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.
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
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.
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.
@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 ?
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.
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.
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.
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.
@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.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
