1st contact with sdl2...

[Tux]

And forgot something again : the new "game controllers" api as they call it. I thought 1st you got it without doing anything just by linking with sdl2, but no, it's a new api on top of the old joystick api... Meaning I need to test this. Well without it, we have exactly the same joystick handling as with sdl-1.2.
With it, it handles joysticks which are added or removed during the emulation, and it's easier to convert dpad to joy movements (because they are standardized to the xbox/playstation model, one dpad, 2 sticks, 4 buttons on the right, plus the triggers and left and right buttons.
It doesn't look too complex...

[Augusto]

"It would be nice to test the opengl "anisotropic filtering", some kind of filtering which is supposed to work better, I am not sure it's good for 2d though, that's the kind of thing which is used in 3d games to make things readable in the 3d world"
I remember running MAME with a Radeon HD 3300 enabling anti aliasing. Anti aliasing not is possible for MAME video output , but enabling anti aliasing the colors look better.
Trying with a Geforce 600 not has the same result.

"And I noticed the display of commands from the command.dat is broken, it's been broken for a few versions actually but nobody noticed"
Using Raine 32 current version the menu works. Only is being listed correctly the commands. Have others details not being rendered.
Related with https://www.1emulation.com/forums/topic/36571-samurai-shodown-iii-neogeo-cd-soft-dips-glitches/ ?

"now the game starts as soon as it's loaded behind the main menu"
Thanks very much.

[Tux]

Sorry not sure to finish today finally, underestimated the amount of work for that again.

The api is quite simple, but it obliges to make big changes to handle it, plus there is a lot of testing to be done, I plugged again my old sidewinder joystick to have something which is not a gamepad, and it was a good idea, some functions like player indexes are not supported with this kind of joystick !

Also I forgot the inputs are recognized by name now, instead of button 0, you have A for xbox pads, etc... Simple changes, but which take time.
And there are 3 indexes for joysticks now, the base index which is the order in which they are opened, the player index which is the index of the joystick for raine (which finally allows that a joystick stays in its position and doesn't change if something else is plugged), and the instance index which is the number used to identify it in events, and it changes everytime it's plugged/unplugged. So all that creates quite a mess, but I am starting to see the end of it...

Also if you wonder why it wasn't easy to automatically map the cross, or digital pad on the left of a game pad to the left joystick, it's because there are no standard in the way these gamepads are built. For my old ps3 gamepad, this cross is just 4 buttons (!). For the xbox compatible game pad, it's a "hat" + some axis movement which is not related to the left stick ! So it was quite risky to try to map an input to some other input in these conditions. What they did in sdl2 is they added something to map and recognize the controls of all these gamepads, now you know exactly where an input comes from when you receive it, and so you can link it easily to some other input... !

[Pingouin]

On 11/20/2021 at 5:22 PM, Tux said:

One of the biggest reason to upgrade for non windows users is simply the fact that this sdl2 is actively maintained contrary to sdl-1.2...

 

Ah also it might allow to make an android version... well it would be a non asm version of course, but it should work.

 

I remember years back you said that porting it would be difficult sicne a lot of code is asm.

However, I just checked Github, and it seems the only asm is the video filters.

Does that mean Raine is quite portable now, and an Android version is possible? I'd much rather have Raine (or FBA) over MAME these days.

Thanks!

[Tux]

10 minutes ago, Pingouin said:

I remember years back you said that porting it would be difficult sicne a lot of code is asm.

However, I just checked Github, and it seems the only asm is the video filters.

Does that mean Raine is quite portable now, and an Android version is possible? I'd much rather have Raine (or FBA) over MAME these days.

Thanks!

Yes, said on the topic for raine 0.92, it's now possible.
But you are wrong, the 32 bits version is still full of asm everywhere, video functions, cpu cores, plus small pieces of asm everywhere, but the 64 bits version had to do without this, so it's not the sdl2 version which made it portable, it's the 64 bits version.
But sdl2 is more widely ported, and it's probably easier to make an android version with it.
If someone wants to try that, he's welcome to, I'll eventually try that one day but I am not in a hurry for that (I don't think an android device is the ideal console for arcade games, lacks real controls, you would need at least some kind of real joystick, the virtual ones would probably lack too much precision for most games).

[Pingouin]

1 hour ago, Tux said:

But you are wrong, the 32 bits version is still full of asm everywhere, video functions, cpu cores, plus small pieces of asm everywhere, but the 64 bits version had to do without this, so it's not the sdl2 version which made it portable, it's the 64 bits version.
[...]
If someone wants to try that, he's welcome to, I'll eventually try that one day but I am not in a hurry for that (I don't think an android device is the ideal console for arcade games, lacks real controls, you would need at least some kind of real joystick, the virtual ones would probably lack too much precision for most games).

I'm sure I missed something, I only checked the stats on github, I didn't actually browse all the code to find out where asm was used.

You're right that on a touch screen Android device, emulation is not very attractive. I was thinking more about Android TV boxes (e.g. Minix).

I was also thinking about handheld gaming devices based on ARM9 (e.g. AllWinner) or MIPS (e.g. Ingenic jz47xx), but as far as I know those are all using 32bits CPU cores, so not much chance of porting the 64 bits version to them.

[Tux]

17 minutes ago, Pingouin said:

I was also thinking about handheld gaming devices based on ARM9 (e.g. AllWinner) or MIPS (e.g. Ingenic jz47xx), but as far as I know those are all using 32bits CPU cores, so not much chance of porting the 64 bits version to them.

Nope, you misunderstood, now that this 64 version is made using pure C everywhere, nothing forbids to use this code in 32 bits, gaining an absolute portability.

I don't do it for the pcs, because I like my asm, it was a lot of hard work after all, even if it creates problems sometimes (use of VirtualProtect in windows to allow self modifying code to work without crashing !), but it's easy to do.... !

[Pingouin]

15 hours ago, Tux said:

Nope, you misunderstood, now that this 64 version is made using pure C everywhere, nothing forbids to use this code in 32 bits, gaining an absolute portability.

I don't do it for the pcs, because I like my asm, it was a lot of hard work after all, even if it creates problems sometimes (use of VirtualProtect in windows to allow self modifying code to work without crashing !), but it's easy to do.... !

Oh, right, yes of course, I get it now. The C code written for 64 bits doesn't preclude compiling it for a 32 bits target. Thanks!

Edited December 3, 2021 by Pingouin