[DEV] M.A.M.E. SDL Plus by F. Lancioni

Qui si parla di M.A.M.E.
Rispondi
Avatar utente
Claus83
Messaggi: 457
Iscritto il: sab apr 25, 2020 12:12 am
Ha ringraziato: 205 volte
È stato ringraziato: 38 volte

Re: [DEV] M.A.M.E. 0.61 SDL

Messaggio da Claus83 »

Ok 👍 non ci avevo fatto caso... :D
"Che strano gioco... la sola mossa vincente è quella di non giocare..."

dal film "Wargames - giochi di guerra" (1983)
--------------------------------------------------------------------------------------
Raspberry Pi 4 Model B Rev 1.2

Avatar utente
Administrator
Site Admin
Messaggi: 435
Iscritto il: gio feb 25, 2016 6:32 pm
Ha ringraziato: 0
È stato ringraziato: 301 volte

Re: [DEV] M.A.M.E. 0.61 SDL

Messaggio da Administrator »

Disponibile Beta1.8.

In questa versione è possibile configurare un joypad USB tramite il menù del M.A.M.E. che si apre premendo Tab sulla tastiera. La configurazione possibile prevede una croce direzionale digitale e 10 pulsanti, allo stesso modo di come configurate i pulsanti di una tastiera. Fatemi sapere ;-)

P.S.: i pulsanti della tastiera invece sono ancora limitati come indicato nel primo post del thread
Questi utenti hanno ringraziato l'autore Administrator per il post (totale 2):
GuybrushClaus83
Reputazione: 20%
"A volte sono le persone che nessuno immaginava potessero fare certe cose quelle che fanno cose che nessuno può immaginare" A. Turing
_____________________________________________________________
Aiutiamo il forum con una donazione :-)

Hardware:
Raspberry Pi Model B Rev 2
Raspberry Pi 3 Model B Rev 1.2
Raspberry Pi 4 Model B Rev 1.2

Avatar utente
Administrator
Site Admin
Messaggi: 435
Iscritto il: gio feb 25, 2016 6:32 pm
Ha ringraziato: 0
È stato ringraziato: 301 volte

Re: [DEV] M.A.M.E. 0.61 SDL

Messaggio da Administrator »

Pronta la Beta1.9. Ho modificato il codice per l'input, adesso potete configurare fino a 4 joypads con 13 pulsanti ognuno. Al momento può essere utilizzato soltanto l'asse principale che ad esempio per il joypad della PS4 corrisponde alla levetta analogica sinistra.

Ho provato contemporaneamente il DualShock 4 e un controller USB generico simil SEGA Saturn, tutto funziona correttamente. In futuro se avrò voglia darò la possiblità di utilizzare anche la croce direzionale, o meglio tutti gli assi possibili presenti su un joypad, è solo mostruosamente palloso scrivere questa parte di codice e non ho voglia :D
Questi utenti hanno ringraziato l'autore Administrator per il post:
Ionic
Reputazione: 10%
"A volte sono le persone che nessuno immaginava potessero fare certe cose quelle che fanno cose che nessuno può immaginare" A. Turing
_____________________________________________________________
Aiutiamo il forum con una donazione :-)

Hardware:
Raspberry Pi Model B Rev 2
Raspberry Pi 3 Model B Rev 1.2
Raspberry Pi 4 Model B Rev 1.2

Avatar utente
Ionic
Messaggi: 513
Iscritto il: ven giu 03, 2016 9:34 pm
Ha ringraziato: 53 volte
È stato ringraziato: 45 volte

Re: [DEV] M.A.M.E. 0.61 SDL

Messaggio da Ionic »

Ciao, ho provato la Beta1.9, tutto ok a parte con il joypad dell'XBOX 360, puoi darci un'occhiata? Ne hai uno disponibile? Ottimo lavoro comunque 8-)

Avatar utente
Administrator
Site Admin
Messaggi: 435
Iscritto il: gio feb 25, 2016 6:32 pm
Ha ringraziato: 0
È stato ringraziato: 301 volte

Re: [DEV] M.A.M.E. 0.61 SDL

Messaggio da Administrator »

Ionic ha scritto:
mer giu 24, 2020 7:39 pm
Ciao, ho provato la Beta1.9, tutto ok a parte con il joypad dell'XBOX 360, puoi darci un'occhiata? Ne hai uno disponibile? Ottimo lavoro comunque 8-)
Ho avuto un flash, forse ho già capito...

Puoi eseguire questo comando con il solo joypad dell'XBOX collegato e fornirmi l'output senza premere niente? Per uscire premi Ctrl+C

Codice: Seleziona tutto

jstest /dev/input/js0
"A volte sono le persone che nessuno immaginava potessero fare certe cose quelle che fanno cose che nessuno può immaginare" A. Turing
_____________________________________________________________
Aiutiamo il forum con una donazione :-)

Hardware:
Raspberry Pi Model B Rev 2
Raspberry Pi 3 Model B Rev 1.2
Raspberry Pi 4 Model B Rev 1.2


Avatar utente
Ionic
Messaggi: 513
Iscritto il: ven giu 03, 2016 9:34 pm
Ha ringraziato: 53 volte
È stato ringraziato: 45 volte

Re: [DEV] M.A.M.E. 0.61 SDL

Messaggio da Ionic »

Eccolo:

Codice: Seleziona tutto

Driver version is 2.1.0.
Joystick (Microsoft X-Box 360 pad) has 8 axes (X, Y, Z, Rx, Ry, Rz, Hat0X, Hat0Y)
and 11 buttons (BtnA, BtnB, BtnX, BtnY, BtnTL, BtnTR, BtnSelect, BtnStart, BtnMode, BtnThumbL, BtnThumbR).
Testing ... (interrupt to exit)
Axes:  0: -9833  1:  2115  2:-32767  3:  6177  4:  1534  5:-32767  6:     0  7:     0 Buttons:  0:off  1:off  2:off  3:off  4:off  5:off  6:off  7:off  8:off  9:off 10:off

Avatar utente
Administrator
Site Admin
Messaggi: 435
Iscritto il: gio feb 25, 2016 6:32 pm
Ha ringraziato: 0
È stato ringraziato: 301 volte

Re: [DEV] M.A.M.E. 0.61 SDL

Messaggio da Administrator »

Come sospettavo... Quel dannato joypad ha i controlli analogici che non indicano 0 quando sono a riposo, devo variare leggermente la soglia, niente di grave, nella Beta1.10 funzionerà anche il joypad dell'XBOX 360 ;-)
Questi utenti hanno ringraziato l'autore Administrator per il post:
Ionic
Reputazione: 10%
"A volte sono le persone che nessuno immaginava potessero fare certe cose quelle che fanno cose che nessuno può immaginare" A. Turing
_____________________________________________________________
Aiutiamo il forum con una donazione :-)

Hardware:
Raspberry Pi Model B Rev 2
Raspberry Pi 3 Model B Rev 1.2
Raspberry Pi 4 Model B Rev 1.2

Avatar utente
Claus83
Messaggi: 457
Iscritto il: sab apr 25, 2020 12:12 am
Ha ringraziato: 205 volte
È stato ringraziato: 38 volte

Re: [DEV] M.A.M.E. 0.61 SDL

Messaggio da Claus83 »

Ciao Administrator! Mentre aspetto la nuova beta, volevo chiederti come funziona il supporto degli artworks, nel senso come si creano? come si caricano? come si impostano? non sono mai riuscito ad utilizzarli...solo tramite retroarch con il formato .png e il file .cfg..e pure qui è un dramma...
"Che strano gioco... la sola mossa vincente è quella di non giocare..."

dal film "Wargames - giochi di guerra" (1983)
--------------------------------------------------------------------------------------
Raspberry Pi 4 Model B Rev 1.2

Avatar utente
Administrator
Site Admin
Messaggi: 435
Iscritto il: gio feb 25, 2016 6:32 pm
Ha ringraziato: 0
È stato ringraziato: 301 volte

Re: [DEV] M.A.M.E. 0.61 SDL

Messaggio da Administrator »

Claus83 ha scritto:
gio giu 25, 2020 12:48 am
Ciao Administrator! Mentre aspetto la nuova beta, volevo chiederti come funziona il supporto degli artworks, nel senso come si creano? come si caricano? come si impostano? non sono mai riuscito ad utilizzarli...solo tramite retroarch con il formato .png e il file .cfg..e pure qui è un dramma...
Mi preoccupa che tu abbia trovato complicato l'uso degli overlay con gli emulatori Libretro perché i files .art sono peggio :lol:

Direttamente dal codice sorgente del M.A.M.E., non spaventarti, fatti un esempio su carta con foglio e penna e vedrai che creato il primo gli altri li tiri fuori in un attimo ;-)

Ovviamente come sempre se non ti quadra qualcosa chiedi pure

Codice: Seleziona tutto

**********************************************************************

	THE ART FILE

	The .art file is very simply formatted. It consists of any
	number of entries that look like this:

	[artname]:
		file       = [filename]
		alphafile  = [alphafilename]
		layer      = [backdrop|overlay|bezel|marquee|panel|side|flyer]
		position   = [left],[top],[right],[bottom]
		priority   = [priority]
		visible    = [visible]
		alpha      = [alpha]
		brightness = [brightness]

	Comments in the .art file follow standard C++ comment format,
	starting with a double-slash //. C-style comments are not
	recognized.

	Fields are:

	[artname] - name that is used to reference this piece of
		artwork in the game driver. Game drivers can show/hide
		pieces of artwork. It is permissible to use the same
		name for multiple pieces; in that case, a show/hide
		command from the game will affect all pieces with that
		name. This field is required.

	file - name of the PNG file containing the main artwork.
		This file should live in the same directory as the .art
		file itself. Most PNG formats are supported. If the
		PNG file does not have an alpha channel or transparent
		colors, it will be loaded fully opaque. This field is
		required.

	alphafile - name of a PNG file containing the alpha channel.
		Like the main file, this file should live in the same
		directory as the .art file. The alphafile must have the
		exact same dimensions as the main art file in order to
		be valid. When loaded, the brightness of each pixel in
		the alphafile controls the alpha channel for the
		corresponding pixel in the main art.

	layer - classifies this piece of artwork into one of several
		predefined categories. Command line options can control
		which categories of artwork are actually displayed. The
		layer is also used to group the artwork for rendering
		(see discussion of rendering below.) This field is
		required.

	position - specifies the position of this piece of artwork
		relative to the game bitmap. See the section on
		positioning, below, for the precise details. This field
		is required.

	priority - specifies the front-to-back ordering of this
		piece of art. The various artwork pieces are assembled
		from the bottom up, lowest priority to highest priority.
		If you want a piece of artwork to appear behind another
		piece of artwork, use a lower priority. The default
		priority is 0.

	visible - sets the initial visible state. By default, all
		artwork is visible. The driver code can change this state
		at runtime.

	alpha - specifies a global, additional alpha value for the
		entire piece of artwork. This alpha value is multiplied
		by the per-pixel alpha value for the loaded artwork.
		The default value is 1.0, which has no net effect on the
		loaded alpha. An alpha of 0.0 will make the entire piece
		of artwork fully transparent.

	brightness - specifies a global brightness adjustment factor
		for the entire piece of artwork. The red, green, and blue
		components of every pixel are multiplied by this value
		when the image is loaded. The default value is 1.0, which
		has no net effect on the loaded artwork. A brightness
		value of 0.0 will produce an entirely black image.

	Once the .art file is loaded, the artwork is categories into
	three groups: backdrops, overlays, and everything else. Each
	of these groups is handled in its own way.

**********************************************************************

	BLENDING

	Conceptually, here is how it all fits together:

	1. A combined backdrop bitmap is assembled. This consists of
	taking an opaque black bitmap, and alpha blending all the
	backdrop graphics, in order from lowest priority to highest,
	into it.

	2. A combined overlay bitmap is assembled. This consists of
	taking a translucent white overlay and performing a CMY blend
	of all the overlay graphics, in order from lowest priority to
	highest, into it.

	3. A combined bezel bitmap is assembled. This consists of
	taking a fully transparent bitmap, and alpha blending all the
	bezel, marquee, panel, side, and flyer graphics, in order from
	lowest to highest, into it.

	4. Depending on the user configurable artwork scale setting,
	the game bitmap is potentially expanded 2x.

	5. The combined overlay bitmap is applied to the game bitmap,
	by using the brightness of the game pixel to control the
	brightness of the corresponding overlay bitmap pixel, as
	follows:

		RGB[mix1] = (RGB[overlay] * A[overlay]) +
				(RGB[overlay] - RGB[overlay] * A[overlay]) * Y[game];

	where

		RGB[mix1] -> RGB components of final mixed bitmap
		A[overlay] -> alpha value of combined overlay
		RGB[overlay] -> RGB components of combined overlay
		Y[game] -> brightness of game pixel

	6. The result of the overlay + game blending is then added to
	the backdrop, as follows:

		RGB[mix2] = RGB[mix1] + RGB[backdrop]

	where

		RGB[mix2] -> RGB components of final mixed bitmap
		RGB[mix1] -> RGB components of game + overlay mixing
		RGB[backdrop] -> RGB components of combined backdrop graphics

	7. The combined bezel bitmap is alpha blended against the
	result of the previous operation, as follows:

		RGB[final] = (RGB[mix2] * (1 - A[bezel])) + (RGB[bezel] * A[bezel])

	where

		RGB[final] -> RGB components of final bitmap
		A[bezel] -> alpha value of combined bezel
		RGB[bezel] -> RGB components of combined bezel
		RGB[mix2] -> RGB components of game + overlay + backdrop mixing

**********************************************************************

	POSITIONING

	The positioning of the artwork is a little tricky.
	Conceptually, the game bitmap occupies the space from (0,0)
	to (1,1). If you have a piece of artwork that exactly covers
	the game area, then it too should stretch from (0,0) to (1,1).
	However, most of the time, this is not the case.

	For example, if you have, say, the Spy Hunter bezel at the
	bottom of the screen, then you will want to specify the top
	of the artwork at 1.0 and the bottom at something larger, maybe
	1.25. The nice thing about the new artwork system is that it
	will automatically stretch the bitmaps out to accomodate areas
	beyond the game bitmap, and will still keep the proper aspect
	ratio.

	Another common example is a backdrop that extends beyond all
	four corners of the game bitmap. Here is how you would handle
	that, in detail:

	Let's say you have some artwork like this:

	 <============ 883 pixels ===============>

	(1)-------------------------------------(2)  ^
	 |                  ^                    |   |
	 |              26 pixels                |   |
	 |                  v                    |   |
	 |     (5)-----------------------(6)     |   |
	 |      |                         |      |   |
	 |      |                         |      |   |
	 |      |                         |      |   |
	 |<---->|                         |      |   |
	 |  97  |      Game screen        |      |  768
	 |pixels|       700 x 500         |      | pixels
	 |      |                         |<---->|   |
	 |      |                         |  86  |   |
	 |      |                         |pixels|   |
	 |      |                         |      |   |
	 |      |                         |      |   |
	 |     (7)-----------------------(8)     |   |
	 |                  ^                    |   |
	 |              42 pixels                |   |
	 |                  v                    |   |
	(3)-------------------------------------(4)  v

	If you're looking at the raw coordinates as might seem
	logical, you would imagine that they come out like this:

		(1) is at (0,0)
		(2) is at (883,0)
		(3) is at (0,768)
		(4) is at (883,768)

		(5) is at (97,26)
		(6) is at (797,26)
		(7) is at (97,526)
		(8) is at (797,526)

	The first thing you need to do is adjust the coordinates
	so that the upper left corner of the game screen (point 5)
	is at (0,0). To do that, you need to subtract 97 from
	each X coordinate and 26 from each Y coordinate:

		(1) is at (0-97,0-26)     -> (-97,-26)
		(2) is at (883-97,0-26)   -> (786,-26)
		(3) is at (0-97,768-26)   -> (-97,742)
		(4) is at (883-97,768-26) -> (883,742)

		(5) is at (97-97,26-26)   -> (0,0)
		(6) is at (797-97,26-26)  -> (700,0)
		(7) is at (97-97,526-26)  -> (0,500)
		(8) is at (797-97,526-26) -> (700,500)

	The final thing you need to do is make it so the bottom
	right corner of the image (point 8) is at (1.0,1.0). To do
	that, you need to divide each coordinate by the width
	or height of the image

		(1) is at (-97/700,-26/500)  -> (-0.13857,-0.052)
		(2) is at (786/700,-26/500)  -> (1.122857,-0.052)
		(3) is at (-97/700,742/500)  -> (-0.13857, 1.484)
		(4) is at (883/700,742/500)  -> (1.122857, 1.484)

		(5) is at (0/700,0/500)      -> (0.0,0.0)
		(6) is at (700/700,0/500)    -> (1.0,0.0)
		(7) is at (0/700,500/500)    -> (0.0,1.0)
		(8) is at (700/700,500/500)  -> (1.0,1.0)

	Alternately, you can also provide pixel coordinates, but it will
	still be relative to the game's native resolution. So, if
	the game normally runs at 256x224, you'll need to compute
	the division factor so that the bottom right corner of the
	game (point 8) ends up at (256,224) instead of (1.0,1.0).

	Basically, if you have the original coordinates shown
	right below the image, you can compute the values needed by
	doing this for X coordinates:

		(X coordinate on artwork) - (X coordinate of game's upper-left)
		---------------------------------------------------------------
		           (width of game in artwork pixels)

	And this for Y coordinates:

		(Y coordinate on artwork) - (Y coordinate of game's upper-left)
		---------------------------------------------------------------
			       (height of game in artwork pixels)

*********************************************************************
"A volte sono le persone che nessuno immaginava potessero fare certe cose quelle che fanno cose che nessuno può immaginare" A. Turing
_____________________________________________________________
Aiutiamo il forum con una donazione :-)

Hardware:
Raspberry Pi Model B Rev 2
Raspberry Pi 3 Model B Rev 1.2
Raspberry Pi 4 Model B Rev 1.2

Avatar utente
Claus83
Messaggi: 457
Iscritto il: sab apr 25, 2020 12:12 am
Ha ringraziato: 205 volte
È stato ringraziato: 38 volte

Re: [DEV] M.A.M.E. 0.61 SDL

Messaggio da Claus83 »

:shock: forse era meglio aspettare prima di fare la domanda... :lol: :lol: grazie per ora..
Sto cercando di studiare da solo nei pochi minuti a disposizione che ho durante il giorno...ho pensato di partire da un manuale di basic per Commodore64...sempre se si può fare su emulatore...sono ottimista..credo che entro la fine dell’anno possa riuscire a capire qualcosa di programmazione... :lol: :lol:
"Che strano gioco... la sola mossa vincente è quella di non giocare..."

dal film "Wargames - giochi di guerra" (1983)
--------------------------------------------------------------------------------------
Raspberry Pi 4 Model B Rev 1.2

Rispondi