The new version works very well, saving data looks fixed. The only serious problem I get is when I click on the "Sample" button in the Sampler section. The program just stops responding; no freeze but nothing can be selected any more.
I was also able to replicate it under Qemu Pegasos2, the program freezes without any error message. I can also see on the CPU display that the resources such as RAM/CPU are then released. As if the tracker has been stopped and the window is wearing out too. hmmm strange...
32bit is 2x data, If the transfer speed is important for high FPS. Then it makes sense to use 16bit.
Specially if for software rendering, there are other issues like BE and LE, but lookup tables work fine for 16bit (and 15bit), the R and B is easy to shift, but G is the one that’s split in the wrong endian, on 16bit
Thanks for the explanation, then of course the 16-bit support makes more sense in software rendering.
I am not doing anything to change the games for QEmu right now ;) It is just the unmodified OS4 version I am doing anyways ,-)))
So the "Wait a while" comment does not make much sense to me. All I am doing is testing the already existing version on QEmu
This will be no "separate release for QEmu". Just finding out if it runs on QEmu.
Ok, if you don't have to do anything extra to make your game ports available to everyone who can use AmigaOs4.1 in some way, it's of course a good thing.
A MacStudio/MacMini (ARM) does not have a DVD/CD-ROM drive. It's like with the new XboxOne series X you can decide for it or against it. You can see in my signature which hardware I use in conjunction with Qemu and AmigaOs4.1. But that will be the least of my problems since I still have an external CD/DVD drive lying around that I could connect to my Mac.
So the only problem that remains at the moment is playing the video sequences...
Maybe as @smarkusg wrote you could perhaps link to ffplay, or another media player. DvPlayer, Emotion work very well with Qemu/Pegasos2.
Is MPlayer installed when you install your games?
Then you could simply replace it later with a version that causes fewer problems. The option to deactivate the cutscenes would also be an option, but that would certainly lose some of the fun. Does it only affect the intro video sequences or all other in-game sequences too?
When will you release your game ports for AmigaOs4.1?
It is not a matter of "relaying", it is a matter of what is possible with current speed of running stuff like H2 on QEmu.
I think it's really great that they also want to support Qemu with AmigaOs4.1 and make their games available for it.
But at the moment that doesn't make much sense to me, we know that Hans de Ruiter is working on a Virtio driver and if this driver is ever released, the first version could include 32bit support I'm pretty sure and they would have to start again to make their game ports compatible close.
The first version of the driver certainly won't offer 3D acceleration, but 2D acceleration/compositing might be available.
If I were you I would wait a bit until this driver is released and then reassess the situation, we don't know what impact this driver will have for Qemu and AmigaOs4.1.
Then the problem would still have to be solved: how to install Quake2/Sin/Heretic2 on a computer without a CD/DVD drive (MacStudio) if there are no digital versions. Not everyone will have these problems, but it will be my problem
I played Quake2 myself many years ago on an AmigaOneXe, if the result is similar under Qemu AmigaOs4.1, I would buy it again, exactly the same for Sin, I don't know this game and have never played it, but that's what I've seen I might like it.
Regarding your Mplayer problem:
I just wanted to say that MPlayer is currently being worked on and sooner or later there won't be any more problems with it.
kas1e wrote:@Maijestro I tried latest Huno's snes from his page, and while it have new "snesCOMP" binary , meaning to play with compositing, then it still have bugs again (on exit says unfreed signals), and it still too slow. "Chaos engine" just unplayable, only with frameskip like 3 or so.
I don't want to criticize HunoPPC's work, but I think 170 MB for a "simple" Super Nintendo emulator is a bit bloated. Maybe there was no other way, I have no idea about these things.
Quote:
@All Maybe older version where swith to native amiga video output wasn't done, and SDL were used, it was ok for fullscreen ?
Or maybe some screenpromoting utilities can be used to deal with so to stretch it a bit to not have white borders visibly ?
Alternatively i may try to debug the binary, to find out where screenmodes created, and add some backfill flags, so it will not have white borders (if that the case..)
In my opinion, you get the best result with WarpSnes. WarpSnes has a nice GUI, is easy to configure and the ROMs run at a very good speed. I also really like the preview of the Romes.
This work was created in 2006 and is very old, perhaps it just couldn't be done better back then. I would also be very happy if we could fix the full screen mode so that you can no longer see the edges and maybe keep them black, that should be possible, or some kind of stretch function.
Since we don't have a source for the whole thing, I think it will be difficult to fix anything.
TheMagicSN wrote:Hi! >I almost overlooked that, which could mean that even in software >rendering "Sin" "Quake2" at least 800x600 16 bit 30 FPS would be
Remember the 1024x768 22 fps number was on a physical x1000 - not QEmu. QEmu is only around half-speed of the x1000 (QEmu on i7, on i9 maybe a different thing). And yes, if QEmu gets 3D Acceleration this will be a different thing. But right now - Sin in 8 Bit renderer is 25-30 fps in 640x480 on QEmu. So definitely no 30 fps in 1024x768.
Could you please run a test on your x1000 with Quake Timedemo software rendering? In this way you could roughly determine the value of how it could run emulated under Qemu with current hardware and its game ports.
You shouldn't rely on the Intel i9, we've already had a few benchmark tests where the Mac hardware (arm) achieved the best results, followed by AMD Ryzen under Qemu.
The average user will probably use hardware i7, but will surely upgrade in about 2-3 years.
You have to ask @trixie if this version meets his current expectations. He is probably the most involved in the topic to make pt2-clone work as well as possible. It is possible that he has already compiled a better version himself. Updating a not fully working version every few days on os4depot is probably not the best idea.
In my opinion it doesn't matter how often an archive is updated. If this means program xyz works better under AmigaOs4.1. It is better to update a program than to do nothing and leave it unfinished and unusable. There are countless cases of this on os4depot because many people don't care.
It shows people that quick fixes have taken place.
Once a program/game needs third party .so's it should *always* be distributed with exactly that...no user should be forced to hunt for dependancies, it's bad practice doing otherwise...just my 2ct's
I see it the same way you do, it's not user-friendly to have to look for dependencies yourself. Even in the readme there is no information about where you can get these libraries.
TheMagicSN wrote:@smarkusg: I just tried to run a timedemo on my x1000 using 1024x768 - still gave 22 fps in software rendering (obviously much higher in 3D Hardware, around 100 fps or somesuch).
I almost overlooked that, which could mean that even in software rendering "Sin" "Quake2" at least 800x600 16 bit 30 FPS would be possible. (Hardware dependent) If that's the case I will definitely buy these games, if Qemu gets 3D acceleration I won't even have to think about buying it
I'm considering writing a review of Tetris Queen for my blog. The game looks nice and it plays well, but sadly I can't make the music to play in the background. Have done the in-game sound test and that works for sound effects.
If it runs, why should i not check it out And as they do run I wanted people know that they run. If some more games will be sold by QEmu users - good for me.
As you offered QEmu knowledge I already have one question - is it possible to "enlarge" an img file to have more harddrive space ? or can i mount two images instead of just one, for more partitions ? Thanks in advance.
Another thing i am wondering - I am using a Peg2 Install here. I heard there are also Sam installs. Does this matter (speed-wise) ? Or does it not matter at all?
It is possible to use a second drive with Qemu without any problems. Just add:
It should also be possible to enlarge the existing IMG, but it could destroy the content. You should create a backup beforehand.
qemu-img resize vm-image.img +25GB
It is also possible to use a real hard drive with Qemu, I took this step. I'm currently using a 500 GB SSD set up under AmigaOs4.1. Due to the setup (file system) and formatting under AmigaOs4.1, this hard drive is no longer available to my main system and is no longer recognized. Only Qemu with AmigaOs4.1 can still use this hard drive.
You currently get the best experience under Qemu with the Pegasos2 machine, with Qemu 8.2 the AmigaOneXE machine will also be available, but it currently has a few problems with USB support. The Sam460 machine is currently the slowest of all, but that is also being worked on.
I agree with you that we should support every system running AmigaOs4.1 if possible. In order to be able to increase the user base if possible. Exactly the same with AmigaOs3.x 68k. I find their behavior exemplary for others.
There was already a lot of support here in this forum when I registered almost a year ago and we started with the topic of Qemu AmigaOs4.1. Back then, SDL2 didn't have a working software renderer like it does today, meaning many ports could also run on Qemu.
Qemu users with AmigaOs4.1 have also already carried out ports (PT2 clones) that can be used under AmigaOs4.1 with real and emulated hardware. Even though they don't have any real hardware.
If they sell their ports in a nice cardboard box, how is it possible for users to use their games without a CD/DVD drive?
If you have any questions about Qemu, I would perhaps ask you the thread:
I'm currently using WarpSnes under AmigaOs4.1, this sweet little Super Nintendo emulator is easy to configure, but also has a few weak points. In the fullscreen 2x output, the screen output is not stretched. Otherwise, this emulator can be played well with the ROMs.
I have already tried SNES9x, but as you have already written, this emulator is very vulnerable and has many errors.
The version on Os4Depot is a little older than the version that you can download directly from HunoPPC. Maybe there were a few improvements here.
first of all, thank you for this information. I didn't know that their game ports also offer a software renderer and so I never ran 3D games like yours on Qemu with AmigaOs4.1.
The only games I currently use on AmigaOs4.1 are Quake and DukeNukem and those games run really impressively well.
Quake currently runs on my computer at 1280x720 16 bit and 30 FPS. I provided you with an older video:
This video is a bit older and FPS numbers over 30 FPS are already possible under Quake.
If your games can of course also be used under Qemu AmigaOs4.1 without any effort, that would be a great thing for me personally. I've never played "Sin" before, but the trailer I saw is promising and I would have liked to play something like it on AmigaOs4.1. It's exactly the same with Quake 2. However, I would quickly lose the joy of gaming at a resolution of 640x480.
So I still hope that Hans de Ruiter will provide a Virtio 3D driver for Qemu, with such a driver it would probably become really interesting.
Their games ports can be purchased digitally. ?
Edited by Maijestro on 2023/11/11 14:16:45 Edited by Maijestro on 2023/11/11 14:21:04 Edited by Maijestro on 2023/11/11 14:26:40
K-L wrote:@Maijestro 55-60% CPU usage on my X1000 with a fast module. No stereo ?
The CPU load should be okay, although not optimal. Also take a look at the protracker.ini "Audio settings", here you can play around with the settings. If you only use the test binary, the Protracker.ini and its settings are not available and standard values are configured. You should test it in combination with the Os4depot version.
[AUDIO SETTINGS]
; Audio output frequency
; Syntax: Number, in hertz
; Default value: 48000
; Comment: Ranges from 44100 to 192000. Does not apply to MOD2WAV.
;
FREQUENCY=48000
; Audio input frequency
; Syntax: Number, in hertz
; Default value: 44100
; Comment: Ranges from 44100 to 192000. This should be set to match
; the frequency used for your audio input device (for sampling).
;
SAMPLINGFREQ=44100
; MOD2WAV output frequency
; Syntax: Number, in hertz
; Default value: 44100
; Comment: Ranges from 44100 to 192000.
;
MOD2WAVFREQUENCY=44100
; Filter model (Amiga model)
; Syntax: A500 or A1200
; Default value: A1200
; Comment: Selects what kind of Amiga to simulate (lp/hp filters).
; A1200 has sharper sound but more aliasing, while A500 has more
; filtered (muddy) sound but less aliasing. The filter model can
; also be toggled by pressing F12 in the program.
;
FILTERMODEL=A1200
; Stereo separation
; Syntax: 0 to 100 (percent)
; Default value: 20 (good value for headphones)
; Comment: Set to 100 for the hard panning Amiga uses.
; Set to 0 for mono, which might be preferred in some cases.
;
STEREOSEPARATION=20
; Audio buffer size
; Syntax: Number, in unit of samples (not bytes)
; Default value: 1024
; Comment: Ranges from 128 to 8192. Should be a number that is 2^n
; (128, 256, 512, 1024, 2048, 4096, 8192, ...). The number you input
; isn't necessarily the actual value the audio API decides to use.
; Lower means less audio latency but possible audio issues, higher
; means more audio latency but less chance for issues.
;
BUFFERSIZE=1024
That teaches the author for not using libsndfile! If he had used this cross-platform standard library instead of his own code, not only would more sample formats be supported but also endianness would play no role because libsndfile is endian-agnostic.
smarkusg has compiled a new version, it contains some fixes, could you test it again on your machine?
.Mod/Sample (.iff) Saving, loading and playback should not cause any problems. I did a few quick tests and it works as it should.
Otherwise there would still be the possibility that I could contact the PT2 clone developer "8bitbubsy" and point out current problems with AmigaOs.4.1 and MorphOs. Maybe it could be helpful to be able to get a clean port with all functions.
This repeats 216 times and then it stops completely. The logs seems that it tries to wake up input.device but somehow the floppy task is cannot be prempted? QEMU emulates a floppy but maybe not completely and likely not needed so I'll try to disable a1floppy.device for now and see if that changes anything but does anybody have an idea how to debug this further? On pegasos2 the same floppy emulation is also present but maybe that machine does not have a driver so this does not happen there? Also this seems to be related to something like timing or memory layour (Heisenbug) becuase I did not see this before and changing unrelated patches in QEMU also makes it go away.
Edit: I think I've found out what caused this. Looks like PCI BARs are mapped with higher priority in QEMU so the IDE BAR shadows part of the FDC IO ports which causes a1floppy.device unable to communicate with the FDC and hang. This could probably be fixed but just disabling the floppy driver in Kicklayout is probably an acceptable workaround for now when one needs to modify Kicklayout to add siliconmotion502.chip driver anyway.
We had already reported the problem with a1floppy.device back then. Maybe you missed it. It is currently deactivated in my Kicklayout too.
could be a compilation problem, as I used a different gcc, will try using another one.
It would be very nice of them if they could release an updated version of the Silicon Motion chip that works with AmigaOs4.1 FE without Update 1/2. Of course, only if it doesn't cause too much trouble for you.
My current installation instructions describe the route via AmigaOs4.1 Update 3 (before Final Edition), which is no longer accessible for AmigaOs4.1 FE owners, which also makes sense.
As already mentioned, their driver works very well with AmigaOs4.1 Update 2, but we cannot use it for the main installation under Qemu. If you decide to update this driver again, I would offer myself as a beta tester.
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
