@Capehill

It is the Window's Rastport's Bitmap as far as I can see (I only had a quick look at the code, didn't have time for more yet).

Still I think to check if anything is displayed at all by drawing a red rectangle in or whatever might be the easiest check if something principial goes wrong. If I have the time on weekend I will look in more detail at the code.

What I noticed in the code is that it does

Lock Bitmap
Get address of Video Mem
Unlock Bitmap

And then use the pointer acquired throughout lifetime of the program. Without locking again. I am not sure if this still works as expected. I think locking/unlocking should be around the function copying data to the video mem.

That's something I would try to change first (myselves no time till at least the weekend). Or try to paint when copying a small rectangle in "known colors" to see if there is any video output at all.

Code uses the Window's Rastport.

Hi!

I got the latest source-code now.

I will send it to you @kas1e.

Maybe it would make sense that you look at latest bugs (black screen) first before I update it to latest snes9x code. But probablyl I will still do a compile myselves and check if the black screen issue appears for me before I send you the code.

EDIT: Ah, just saw Per wrote he tries himselves to update to latest SNES9x 1.60 code.

Best regards,
Steffen

@white

???

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.

I sent you an email a few minutes ago.

MagicSN

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).

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.

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.

@Olle

>@TheMagicSN,
>That's nice to hear, congratulations on both marriage and house. >No marriage here but a partner and stepdaughter and also bought a >(tiny) house some 7 years ago.

Thanks

>That's awesome :D , regarding the big-boss signature, hahah i have >a similar one stating that i cannot be disturbed during easter >holidays so i can go to Revision party, and also our local >demoparty (Gerp) is a no-work zone. :D



>I will send you the sources in the weekend as i am not at home >this week, amazingly i managed to time my posting on amigans.net >just as i got coworkers from China arriving and we are sitting >in a cottage deep in the forest crunching for a software pre->release that is supporting Mac OS, Windows, IOS and Android and >is going to be presented to Lidl and Walmart together with a >special hardware. We'll see how it all turns out, if nothing >else a good learning experience.

Good luck and success with the release

Best regards,
Steffen

>Hello all,

>@TheMagicSN,
>Long time no Scene. :) , i hope everything is fine?

Yeah, I am fine. I sort of took a break from AmigaOS (like 10 year long break). I restarted on AmigaOS end of last year (now short before releasing OS4 Version of Heretic 2, and working on Sin for OS4 as well as H2 and Sin for 68k). Not in full-time like before but in "fully accepted part-time by my employer" (believe it or not, actually I got a document with signature of a big-boss for that )

Other things than that ? Married (actually already 10 years ago), bought a house (4 years ago). All fine.

If you want to send me those sources, send to tirionareonwe@gmail.com, email did not change

BTW I disagree that issues on -O3 are a bug. Things are known to sometimes go wrong on -O3 in gcc. It is no coincidence that GNU people compile all their code with -O2. Actually I do too, in most cases.

Though I would like to try with my (probably) more recent gcc installation.

Thanks in advance.

MagicSN/Steffen

@smarkusg

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).

With the mplayer version I had it actually crashed, not produced garbled graphics (but have seen the garbled effect too with other apps). -cpu=G3 had it crashfree then.

Hi!

Sadly I only have 1.42 sources. I was not aware that Per worked on another version after that.

I see "sound added", did the version he did back then not include sound ? I never checked it, but he wrote me he fixed sound, and then sent me this source code which I sent you.

Steffen

I just sent the WarpSNES Source-code to kas1e, who volunteered to work on the open bugs.

I volunteer to update the code to latest snes9x myselves. But might be not before the weekend that I work on that (I asked kas if he can get it running with recent compilers till then, and send me the code back then, after that I will work on updating to SNES9x 1.60 (please note might take some while due to high project load, but still that specific project is dear to me )

@Samo79

Involved ? I am the original author )) Per mainly fixed a few Bugs as I said (though one bug were I was looking ages for it and had not find a solution, and he found it in a matter of days only).

I mainly have the source of WarpSNES were I was the original author (that's why I got the source code - and Per of course sent me his changes back once he was finished with fixing). I probably also still have WarpMAME somewhere, maybe even a OS4 version (not sure), but updating that to more recent is a HUUUUUGE issue. They changed to a new build system which seems to not work on cross compilers but also requires commands not available on native AmigaOS.

I remember I have a half-finished port of tgemu (Per's port was based on mine which again was based on the MOS version of tgemu). I only got my own code of tgemu though which was lacking sound, I could provide it but somebody would need to add back in the sound (unless Per can be reached).

Don't think I had to do anything with the other Emulator ports. But I might still have some source code for some other emulator ports on my backup drive, likely all still WarpOS source code.

I am not sure if I can reach the tgemu code still, gmail blocks me downloading the file I sent myselves because it is "an evil zip". I probably still have it on my backup drive, just not 100% sure.

Best regards,
Steffen

@samo79

>I've tried many times to contact the author about the white >borders problem in WaspSnes, but he doesn't seem to be reachable
>anymore... a hack to fix the issue would be more than welcome...

I could provide the source code of WarpSNES. I am the original author of WarpSNES, and once Per finished his changed, he sent the source-code back to me.

With the whole project overload right now (Project for main job, then Sin for OS 4 and 68k, H2 for 68k) I do not really have the time to look after WarpSNES, but if someone wants to fix issues with it, I would be willing to send him the source code I got.

And I am pretty sure it could be adapted to more recent snes9x source code (I did that several times, when I was still actively working on WarpSNES, using diff).

Or I could look after this once I am finished with the games...

Best regards,
Steffen

I did not mix hardfloat and softfloat i know you
cannot mix them.

I compiled the complete renderer in softfloat.
Renderer is a full executable (dynamic object).

Note it did not break in obvious fpu calculations but
in the image cache somewhere.

>You don't need to change any sources to disable FPU usage, simply >recompile everything with CFLAGS += -msoft-float.

EDIT: tried it compiling the renderer with softfloat
breaks the game completely.

I see. Yeah, would be worth a check. Obviously not for H2 release, *IF* it is faster that would require a QEmu-specific update for later (if it is faster probably a softfloat version of the renderer would be enough, maybe clienteffects still).

As to the SDL crash, anyone ever tried to insert debug output into the SDL compile to find out where inside SDL it crashes ?

I know of course it is OpenSource

Just after the third Amiga related project where I got told "use integer math".

No. It is not an option ...

Hi!

>If you're using QEMU Windows builds from weilnetz.de that are >linked from the qemu.org download page you may also try the builds >from emaculation.com instead which are closer to actual QEMU >source and were tested to run PPC MacOS so may work better. I'm >not sure though so if you try it please let us know if you saw any >difference.

Thanks for the hint.


>That it works with G3 but not the default G4 might suggest it >could be something about using altivec but then why that's not

As it happens before even the screen opens it sounds doubtful to me to be related to Altivec but no idea.

>One known limitation with QEMU PPC emulation is that FPU >operations are slower so if your workload uses floating point a >lot but there's an option to use integer math instead that might >help.

This is not possible. All my games rely massively on FPU performance and this is not possible to change. Probably MUCH easier that they improve FPU support. And they should, really. At least for games integer math doesn't matter anymore. It is only FPU which matters. And without reimplementing the games from scratch (I mean not the port, I mean the basic code of the game) this cannot be changed. Actually I am not even sure if it could be changed then even.

I don't know what this is, all those solutions which have bad FPU things - Apollo Vampire, A1222 (well, not an issue of performance here, but an issue of ABI) and now QEmu too ?

Nobody cares how great integer math you have in your CPU - it is FPU math which matters.

"Avoiding FPU usage" ? At least with modern games (as in "games which were modern 20 years ago and everything more recent") - not possible.

Again - tell them to improve FPU performance

MagicSN

I was busy with other stuff for a while, I answered now. Anyways H2 is pretty imminent. Probably no change to H2 binaries anymore possible, but my idea right now is to add a downloadable fix for the "video on peg2 qemu" issue which could be ready in time for the release.

As to Sin it definitely can be included into the release (where do I get the ffmpeg version which would be ideal to be used BTW ? Is it this "http://os4depot.net/share/video/convert/ffmpeg.lha" ?

The Sin porting project is still at an early stage.

Hi!

>If you have the option use ffplay. It should solve the problem >Qemu pegasos 2 G4 - is ns SDL2 and is based on ffmpeg.
>It should work on any Amiga.

Not in the released version probably but I will go sure to offer an update to fix this for QEmu users (probably just a replacement for the "mplayer" file which then internally calls ffmpeg ). Note you can run the videos if you start qemu with -cpu G3.

>Not everyone will buy it. It is better to make the game work on >any hardware and not make it dependent on the driver. As >@TheMagicSN wrote - it even works acrually on Qemu already.

Exactly. And there are no other options to make it work "better" on QEmu. As to speed - either it runs or it doesn't Not much options to make it faster sadly.

>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.

I see. Have to admit I do not know much about Macs these days

But as you said yourselves an external CD will fix this, and once the CD has been written into an ISO it can be mounted by OS4 - problem solved.

And you actually do not need the CD while playing, only for installation.

>So the only problem that remains at the moment is playing the >video sequences...

Yes.

>Is MPlayer installed when you install your games?

Yes.

>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?

For Sin definitely a later version will be used then. And it only affects the bumper video (Hyperion+Raven+Activision logos), intro video and outro video. Ingame sequences are not affected as those are in game graphics (so they are not affected), not with external video.

>When will you release your game ports for AmigaOs4.1?

H2 - pretty soon (so probably too late to change anything there on the video issue).

Sin - no idea yet, it is still pretty early in the project. Somewhen 2024 I would assume.

MagicSN