Do we have fast, accelerated, bug-free, supporting scaling SNES emulator ?

@Maijestro
Sounds good

@smarkusg
Maybe share what you have now ? In the end of all, GUI can be done on top of it by someone else easy.

@kas1e

I have not changed anything in the sources yet. I compiled as it was originally for the test.
Added amigaos.c amigaos.h and started writing something, and have been playing around with compilation flags to see if it speeds up the program. But that's just testing...
It needs to be adapted for AOS4, e.g. the "Unix" paths need to be replaced with Amiga ones, etc. I did not have too much time to do it yet.
It currently runs only from the console.

But no problem if you need the source - here is the link

https://we.tl/t-hlT1j4DnvE

There is ./dgen and dgen-12(sdl2). I don't know how it will work for you.
DGEN under sdl1 is built with my sdl compilation where I have ALT+ENTER rigidly added - it currently conflicts with dgen sources where this sktórt also occurs.
dges-12(SDL2) is built by sdl12-compat - it works for me. But I don't know how it works on real hardware.

You can check or rebuild dgen on your libraries.

As for the version under SDL2 on sm502 under qemu it runs slow. But that's obviously not a SDL2 problem just a weak 2D graphics card.

@smarkusg

Quote:

kas1e wrote that he had already ported DGEN with SDL2 and it was slow, so it's not because of sm502's 2D acceleration. Of course anything that accesses 3D acceleration is very slow with sm502/2D accelerated. And of course we only use the 16 bit screen, Qemu or the host has to downsample everything from 32 bit to 16 bit.

@kas1e

Smarkusg could certainly use some help, maybe you can look into that as well and we should stick with SDL1/sdl12-compat for now, the trial version of DGEN works really well and is very fast and should run fine on older real machines below the x5000.

I think you have a bit more experience with Amiga paths and could implement it well. One more thing, I've already found someone who could write a GUI for it, but it would be in Hollywood, which I don't think is a bad thing.

@Maijestro

about weak card using SDl2 I meant mainly hardware acceleration

https://wiki.libsdl.org/SDL2/SDL_RendererFlags

Here it is fairly well described in the first part of what is involved.

https://dev.to/noah11012/using-sdl2-2d-accelerated-renderering-1kcb

"The release of SDL2 added the ability to use the GPU. All this time, we've been doing software rendering which is where the CPU is doing all the graphics calculations. The CPU is fast but is not optimized for the doing the necessary calculations to output graphics onto the screen."

dIn addition, as I noticed myself with sm502 on qemu is still 16bit -> 32bit.
You can have a look in those files I sent @kas1e are executable files:
dgen = sdl1
dgen-sdl2 = sdl2
you will run the rom from them in the console. in my case sdl2 does not look terribly tragic it is around 33 frames.
sdl1 i have 54 frames. You will get this information when you close the application window in the console.
sdl1 will make you swich mode and sdl2 will stretch the window to the native screen. This is where you see the slowdown caused by using sofrware render.

I hope I have now explained it well.

and as for the "test" version - I will make the rest for myself regarding paths and other things
surely someone is able to do it better so anyone can do it who has the knowledge and desire.
everything is given on the platter


and as for the GUI if someone has the time and inclination it's very cool how they do

edit: 17.02.2024

https://github.com/smarkusg/dgen/releases