Looks familiar, yes, have seen similar things. Was not aware this also was the SDL1 thing. Only knew the crash on mplayer was related to it (other versions of mplayer have the graphics bug). Crash disappears with G3 (BTW Heretic 2 and Sin speed seem to be no different whether I call QEmu with G3 or G4) I did not check with the "other versions of mplayer" as I was told there will be a new version which will not crash anyways.
And myselves I only use SDL for Soundcode (and actually SDL2).
maijestro and me compared speed (not with H2/Sin, but with my Q2 port).
Seems his M1 Mac with QEmu is in speed slightly below (comparing software renderers) my x1000 in native speed (1280x720 Q2 demo1.dm2 timedemo was 24 fps on his QEmu setup, 30 fps on the x1000 natively). Will still compare with my i7 with QEmu with the same game and graphics resolution.
TheMagicSN wrote:maijestro and me compared speed (not with H2/Sin, but with my Q2 port).
Seems his M1 Mac with QEmu is in speed slightly below (comparing software renderers) my x1000 in native speed (1280x720 Q2 demo1.dm2 timedemo was 24 fps on his QEmu setup, 30 fps on the x1000 natively). Will still compare with my i7 with QEmu with the same game and graphics resolution.
It runs really smoothly even in higher resolutions beyond 800x600 16bit. There are still some problems with playing the cutscenes, apparently MPlayer uses MiniGL, at least for the main intro, but otherwise it's going really well at the moment. I've noticed other errors here and there, but we'll do that privately. Still, I'm impressed...
The difference between the two intros (assuming Steam install) is the first (id logo) uses q2’s internal .cin format while the real intro uses .ogv in the codec the makers of the Steam version chose (which is appearently a bit slow on mplayer which caused you to think it would use MiniGL i assume).
A workaround would be that you load it into a conversion tool (ffmpeg or anything) and convert it to a “lighter” codec or resolution and then save it by the same filename. Or install the non-ogv version (i could modify the installer of course to install the movies from classic q2 -.cin- instead of the highres ogv movies - or leave a choice to the user which movies he wants to install.
The code in q2 loads movies of either ogv mp4 avi or cin fileending. I would need to check with which priority if several of these files exist but i think it was in the order i just listed.
For in-development Sin we instead converted the movies into mpeg format which plays much better.
TheMagicSN wrote:No, mplayer is not used with MiniGL.
It is called like
mplayer -vo sdl -ao sdl filename
by Q2.
The difference between the two intros (assuming Steam install) is the first (id logo) uses q2’s internal .cin format while the real intro uses .ogv in the codec the makers of the Steam version chose (which is appearently a bit slow on mplayer which caused you to think it would use MiniGL i assume).
Ok, I found the error, in the SDL Prefs under AmigaOs4.1 the SDL output was set to OpenGl. Because I installed Wazp3D on my system, the videos worked, but had a red tint (Wazp3D) bug.
SDL Prefs settings on software works much better, but makes the videos play a little slow,Video and sound are asynchronous. The videos also have a very high resolution of 1920x1080, I checked this with a video converter under MacOs. But with 3D acceleration this shouldn't be a problem anymore.
Edited by Maijestro on 2023/11/23 17:15:45 Edited by Maijestro on 2023/11/24 7:52:26
Only knew the crash on mplayer was related to it (other versions of mplayer have the graphics bug). Crash disappears with G3 (BTW Heretic 2 and Sin speed seem to be no different whether I call QEmu with G3 or G4) I did not check with the "other versions of mplayer" as I was told there will be a new version which will not crash anyways.
Quote:
It is called like
mplayer -vo sdl -ao sdl filename
check the file I sent you on PM use but with "mplayer -vo sdl -ao sdl filename -fs" - as in the video (QEMU Pegasos2) . It runs through sdl-compat (SDL2) and should be ok on qemu and any amiga. this is a work in progress - so only this option may work for you for now. But I don't think you need anything else for now for the test
After further short tests...Quake 2 already seems to work very well under Qemu Pegasos 2 Amigaos4.1. The videos intro/main intro work well with MPlayer-SDL12-compat, although a bit slow, DVPlayer (full version) does a lot better in software rendering.
Nonetheless, their port of Quake 2 is really good, ogg music plays without stuttering, intros work and gameplay in 720p is very, very smooth on my machine.
Water textures look a bit strange, but could be a bug in the Siliconmotion chip emulation. ?
Edit:Ok problem seems to be "stipple alpha" in the video settings, without very it looks better.
@orgin Delete my account I no longer need it. And above all my personal data.
I will check if my data has been deleted.
This is the later sales version of Quake 2 for AmigaOs4.1 and it is not available to everyone, only selected beta testers receive it in order to ensure that this version is tested in detail and that bug reports are submitted to the developer. This isn't just about having a little fun.
With MPlayer-sdl12compat it's a different matter - this software is open source, but I only received this version because I'm working on the German translation, which is currently almost perfect.
@TheMagicSN is currently not active and doesn't respond to my emails, maybe you should just be patient, he's the one who decides.
I am not sure what is going on here, I did not notice anyone getting "unpolite" or "uncivilized" towards you. Of course it might have been in a private message ?
On your other post I am currently not looking for more Betatesters, but I hope to finish the project in a reasonable timeframe. Thanks for your interest. I might look for Betatesters for a different project in reasonable timeframe.
Asides from that everything Maijestro said on Betatesting (not only Q2 but generally) is absolutely true! Some software is not yet available to the public.
@Maijestroy:
>@TheMagicSN is currently not active and doesn't respond to my >emails, maybe you should just be patient, he's the one who >decides.
I usually only check messages on amigans a few times a week. And yes, I have been behind in answering my emails.
@smarkusg About SDL1 image error, in QEMU master there was a fix for an AltiVec bug so maybe check if that did anything but I don't think so as the same G4 CPU is used on amigaone too where it did not appear. So I still think that's the main question what part of code is only running on pegasos2 and not on amigaone or vice versa and why. There does not seem to be anything in SDL itself that could run differently so it may be the AltiVec gfx optimisations in graphics.library that works differently. Even though that's also enabled on amigaone it may have some checks not activated on pegasos2? But if nobody has sources for that library it might be hard to check.
Please try this http://capehill.kapsi.fi/misc/BlitTest.lha and see if you can reproduce visual issues. Sources are included in case you want to experiment with window size or anything.
If it works as designed, it just prints some text and some vertical lines using different bitmaps.
Please try this http://capehill.kapsi.fi/misc/BlitTest.lha and see if you can reproduce visual issues. Sources are included in case you want to experiment with window size or anything.
If it works as designed, it just prints some text and some vertical lines using different bitmaps.
I don't know what this test is supposed to be good for, but I did it and recorded the result.
Is it about the current SDL1 problems that only affect the Pegasos2 machine?
video deleted
Tested with AmigaOs4.1 FE including all current updates. Qemu Master/Pegasos2 CPU G4 7457
@Capehill Not sure what would be the correct output but I've tried it on QEMU amigaone,pegasos2,sam460ex machines just booting the 4.1FE install CD. The 8 bit and 32 bit looks the same on all 3 machines but 8 bit has text in different colors and gray background and 32 bit has all black text on gray background. The 16 bit one has blue-green background with black text and on pegasos2 also the text is broken (endianness issue?) whereas on amigaone (with same 7457 default cpu as pegasos2) and sam460ex the text is OK even in 16 bit mode. Using -M pegasos2 -cpu 750cxe fixes text in 16 bit mode. (This was tested before with SDL that endianness issues only happen on pegasos2 and with G4 CPU.)
To me this looks like some problem with pegasos2 kernel again assuming other components are the same on all three machines.
Maybe it would also be interesting to see how it displays on real sam460ex with the on-board SM502. Anybody could try that for comparison?
Thanks for tests. I can see from Maijestro's video that the rendering was broken in 16-bit bitmap (middle one). Text looks corrupted.
Point of this exercise: I was trying to re-create a test case which doesn't use SDL1, to simplify debugging. There is probably something wrong in Pegasos-related 16-bit blitting routines (or emulation).
Please ignore the colors. It's just using some pens from 1 to 10 or so.
I already thought it was about the pure text output. (distortions)
Balaton described that Pegasos2 and also the AmigaOneXe machine use the same identical code, but there are currently only problems on the Pegasos2 machine.
The Sam460 machine can also run SDL1/2 under AmigaOs4.1 without any problems. As I use the Pegasos2 machine as my main system for AmigaOs4.1 I would of course be happy if we could get the problem solved.
SDL2 works without any problems. Some 19 years ago I could also observe this behavior, it was on an AmigaOneXe G4 800mhz with AmigaOs4.0 pre.