It's broke.

Can somone recommend a Playstation type controller?

I have an actual one, but they all fail and I am not sure I can be bothered to get the soldering iron out.

I have a cheap Chinese one, but the D-Pad is awful.

Is there a good USB controller that looks/feels like a Playstation controller that someone uses?

@amigakit
Thanks for the update.

@kas1e
I use Enhancer on my X5000 and pure Hyperion on my X1000.

I am not sure if this has been updated since, but it seems as though attempting to copy a non-existent file(s) (at least, in a non-extant parent directory) results in silent output and return code of 0.

For example:

There is no such folder


In case it matters, z420_2: is a samba share.

Does anyone have an ISO layout X1000 keyboard they are willing to sell?

Right. It is something that needs fixing in CLIB4.

Regards,

Given a program that creates mutliple threads and each of those threads writes to STDOUT and if we have a wrapper script that does something like:

Only the "parent" thread will write results to the file named "stdout". The created thread's stdout is not sent to "stdout".

I get that there are no such thing as threads in AmigaOS4. It is just a separate process.

Is there a workaround for this? Should this be something that we fix?

When running the executable, standalone, the effective results are fine. But for the script, this is not the case.

===
Test file: STDOUT.lha

FTP: tellusregio.duckdns.org
PORT: 32463
Anonymous login

Run: run_test_22_ThreadLocalStorage_clib4_STATIC.script

Right. The x5000 is not even at the limits for Mednafen, and yet I personally describe the PSX side of it to be "barely playable", which means it runs at the absolute minimum for me to enjoy playing my old PSX games, but if it was 1 fps slower, it wouldn't be worth it.

Yeah, I have never noticed a big difference between fs and window, perhaps a little.

BTW, I know the configuration is complex. It looks like you are creating a configure file first and then running thr PSX game. It may be that Mednafen overwrites it with default values, disregarding yours.

Don't know if it is in the documentation, but it is best to run a PSX game first, let Mednafen generate the configuration, then modify the rather large config.

Even with the period values, the sound is not perfect, but just noticed that the values I mention in the readme are the ones that worked best for me.

I will soon get around to rebuilding the whole thing with, what I believe, will be a much faster version of clib4, or try newlib again. Regardless, Mednafen is always going to be CPU intensive, as the owners concede themselves in their documentation.

Hey. Sorry, this is never going to work at any playable level on anything but an X5000.

FPSE is the best option in all cases, its only issue is compatibility games.

@DigitalDesigns

Thanks. Are you creating a lighter version of every dark icon that you make?

If anyone is interested in declaring a technical preference for CLIB4 distributed programs, you may want to contribute to https://github.com/AmigaLabs/clib4/discussions/212.

Okay. Now it makes sense. In your SOBJ you will have a libstdc++.so of a newer version of GCC.

You will need the version 4 GCC libstdc++ in the same directory as where the game binary is. I am surprised thar Huno has not also provided that SO along with the game.

@Walkero

What about a pinned thread here at Amigans named Guides ... or something.

If they link to intuitionbase... I am not sure it matters.

@Maijestro

I guess you got anywhere ?

@Maijestro
@All

I have figured out why I am getting these "micro-jerks". Firstly, my ToolTypes are the same as yours.

It is caused by the program trying to resynchronise the video and audio. So, every so often I will notice the following output from Serial (this represents 3 "micro-jerks" about 1 minute apart):



Or, sometimes it may be something like:


For those that are not witnessing "micro-jerks" - either you never have a synchronisation problem, or, if you do - it is a lack of capturing any serial output that is causing it to not be noticeable.

===

Does the developer of Emotion ever visit this site?

===

EDIT: I have disabled any serial debugging. To make double sure, I have removed the serial cable and just deleted my os4_commandline in the startup environment. Still, I get "micro-jerks". So, either you guys are not seeing any lack of sync', or you are and you are just not as OCD as me and don't notice it as well.

Well, I sent an email. Let's see what happens.

I see that with:

skipping forward with an AVI file results in starting the whole AVI file from the beginning.

File type:


Is there an A-EON bug site I can report this to?

So far, all of your suggestions work great.

The only thing I do notice is something that is quite nitpciky. So, I have videos that open with Emotion and I have an RX 560 and no matter what the quality of the video, every so often there is a .3 / .5s delay in video - a very slight freeze that is hardly noticeable. I am wondering if anyone else sees this?

I repeat: it is nitpicky.

I also see it in vidoes that are played over my NAS share or even if the videos are copied to a local partition and played.

My version of Emotion is:

I also have Frameskip set to Disabled.
===

This seems to be something specific to Emotion. When I use DVPlayer I do not see this hardly-noticeable freeze.

Has anyone tried opening YouTube (etc) videos directly with DVPlayer?

@DigitalDesings
Anyway to grab hold of one of the backgrounds right now? Perhaps with an annoying watermark that would only be removed with purchase? I like the BG.

@Maijestro
@HunoPPC
I am interested in this exact error. I am attempting a game port where I have the same error.

Since this is coming from HunoPPC I am surprised to see this error because I was always under the impression that he was using GCC 4 - but this must not be the case for this game.

This error happens due to GCC 8 and above. In that version, different threading methods were created such as "single" and "native". The whole point of building with the flag "athread=native" means that when you finally link your binary file, "gthr-native.o" (I cannot remember exactly the name of the object file) gets linked in and provides the selected threading implementation. This is never an issue with static linking. The issue comes when there is a binary that relies on something that requires those native methods and when they are linked dynamically. There is no such "gthr-native.so" file.

I am wondering if you found a work-around?