IPB

Benvenuto Visitatore ( Log In | Registrati )

 
Reply to this topicStart new topic
> 0.144u6 Out!
Frankie
messaggio 15 January 2012, 23:50
Messaggio #1


Mame dipendente
*****

Gruppo: Members

Iscritto il: 31 March 2006, 04:36
Da: Ginevra (Svizzera)
Utente Nr.: 4.962



CITAZIONE
0.144u6
-------


MAMETesters Bugs Fixed
----------------------
- 03685: [Sound] reaktor: No sound (hap)
- 03568: [Crash/Freeze] lockload, gunhard: Access Violation after OK (hap)
- 04189: [Gameplay] fireshrk: Inputs aren't read consistently (hap)
- 04601: [Speed] vimana: game suffers major slowdowns (hap)
- 04602: [Documentation] pb_l5 and clones: The correct description is
"PIN-BOT..." and the exact year of production is 1986.
- 04600: [Documentation] pfevr_l2, pfevr_p3: The correct descriptions
are "Pennant Fever (L-2)" and "Pennant Fever (P-3)".
- 04599: [Documentation] pz_f4 and clones: The correct description is
"The Party Zone...".
- 02234: [DIP/Input] chboxing: Unable to navigate Test Mode menu (hap)


Source Changes
--------------
softlist: Fix entry count tracking issue [O. Galibert]

vamphalf.c: Added correct speedup for Toy Land Adventure. Demoted Mr.
Kicker to not working again. There is a serious bug with the nvram
handling (possibly due to a core bug) which causes the game to break
entirely if you get a high score and it rewrites nvram. [Dave Haywood]

i386: Made a start at Virtual 8086 Mode. Not fully working yet,
though. Fixed an issue where two address or operand size prefixes
would cancel each other out. [Barry Rodewald]

Optimized PGM video rendering for a speedup in some video heavy cases
[David Haywood]

Reinstated the old KOV protection simulation given that the ARM still
hasn't been dumped [David Haywood]

arm7: some code reorganization, used a jump table for a small speedup
[David Haywood]

i386: Fixed high bits in eflags register from being changed by POPF,
and VM and IF flags from changing depending on privilege level. Fixed
exception error codes in protected mode. Further work on virtual 8086
mode. EMM386 will now load, but will still die a few seconds later.
[Barry Rodewald]

Enabling load of multi part softlist items on all available device
[Fabio Priuli]

ARM7: Gave ARM mode its own file & cleaned up formatting/indenting
[David Haywood]
:
i386: Bit more progress towards getting 386 enhanced mode Windows
running. [Carl]

beaminv.c: added color overlay [MASH]

Added support for 2 drives on IDE controller [Miodrag Milanovic]

Major bitmap-related changes throughout the system: [Aaron Giles]
There are almost certainly some regressions lurking. Let me know if
something seems busted.
Bitmaps are now strongly typed based on format. bitmap_t still exists
as an abstract base class, but it is almost never used. Instead,
format-specific bitmap classes are provided:
bitmap_ind8 == 8bpp indexed bitmap_ind16 == 16bpp indexed bitmap_ind32
== 32bpp indexed bitmap_ind64 == 64bpp indexed bitmap_rgb32 == 32bpp
RGB bitmap_argb32 == 32bpp ARGB bitmap_yuy16 == 16bpp YUY
For each format, a generic pix() method is provided which references
pixels of the correct type. The old pix8/pix16/pix32/ pix64 methods
still exist in the short term, but the only one available is the one
that matches the bitmap's pixel size. Note also that the old RGB15
format bitmaps are no longer supported at all.
Converted model1, megadriv, and stv drivers away from the RGB15 format
bitmaps.
New auto_bitmap_<type>_alloc() macros are provided for allocating the
appropriate type of bitmap.
Screen update functions now must specify the correct bitmap type as
their input parameters. For static update functions the SCREEN_UPDATE
macro is now replaced with SCREEN_UPDATE_RGB32 and SCREEN_UPDATE_IND16
macros. All existing drivers have been updated to use the correct
macros.
Screen update functions are now required for all screens; there is no
longer any default behavior of copying a "default" bitmap to the
screen (in fact the default bitmap has been deprecated). Use one of
the following to specify your screen_update callback:
MCFG_SCREEN_UPDATE_STATIC(name) - static functions
MCFG_SCREEN_UPDATE_DRIVER(class, func) - driver members
MCFG_SCREEN_UPDATE_DEVICE(tag, class, func) - device members
Because the target bitmap format can now be deduced from the screen
update function itself, the MCFG_SCREEN_FORMAT macro is no longer
necessary, and has been removed. If you specify a screen update
callback that takes a bitmap_ind16, then the screen will be configured
to use a 16bpp indexed bitmap, and if you specify a callback that
takes a bitmap_rgb32, then a 32bpp RGB bitmap will be provided.
Extended the bitmap classes to support wrapping a subregion of another
bitmap, and cleaner allocation/resetting. The preferred use of bitmaps
now is to define them directly in drivers/devices and use allocate()
or wrap() to set them up, rather than allocating them via
auto_bitmap_*_alloc().
Several common devices needed overhauls or changes as a result of the
above changes:
* Reorganized the laserdisc base driver and all the laserdisc drivers
as modern C++ devices, cleaning the code up considerably. Merged
ldsound device into the laserdsc device since modern devices are
flexible enough to handle it.
* Reorganized the v9938 device as a modern C++ device. Removed
v9938mod.c in favor of template functions in v9938.c directly.
* Added independent ind16 and rgb32 callbacks for TMS340x0 devices.
* All video devices are now hard-coded to either ind16 or rgb32
bitmaps. The most notable is the mc6845 which is rgb32, and
required changes to a number of consumers.
* Added screen_update methods to most video devices so they can be
directly called via MCFG_SCREEN_UPDATE_DEVICE instead of creating
tons of stub functions.
Added new template device_delegate which wraps a regular delegate and
includes a string pointer to a device tag, which can be simply
resolved later. Converted the screen_update delegates to to be based
on this. Changed the mechanism by which screen formats are auto-
deduced. Converted SCREEN_EOF to use these delegates as well, so now
there is MCFG_SCREEN_EOF_STATIC/ DRIVER/DEVICE just like
MCFG_SCREEN_UPDATE.

Death to SCREEN_EOF, which was ambiguously called either at the start
or end of VBLANK depending on the video flag
VIDEO_UPDATE_AFTER_VBLANK. Replaced with SCREEN_VBLANK callbacks which
are called both at the start and end of VBLANK, so you can operate
either way, and be explicit about it. Updated all callers. Also
updated screen_device to use device timers and some other minor
cleanups.

Beginning to implement page faults [Carl]

Created new testcpu driver that shows how to develop an empty test
driver that (ab)uses the core to single step a CPU executing arbitrary
instructions and capturing before/after state and tracking memory.
Currently this driver is always compiled, but is not referenced in
mame.lst. [Aaron Giles]

Cleanup of bitmap classes now that formats and bpp are dictated
strictly by the type. Also added code to more aggressively align the
bitmap base and rowbytes, and create a resize method which attempts to
re-use existing memory rather than always reallocating. [Aaron Giles]

i386: Added I/O permissions. [Carl]

Added new method screen_device::register_screen_bitmap which allocates
a given bitmap to match the screen size and resizes it as appropriate
when the screen size changes. Updated all the obvious spots in the
code where this could be leveraged. [Aaron Giles]
Move allocate/resize methods in the bitmap classes down into bitmap_t
because they no longer have any dependency on the bitmap format or
type.
Ensured that the bitmap's palette remains set across a resize call (it
is lost doing an allocate).

[N64] Various changes: [MooglyGuy, Happy]
* Converted AI / VI / MI / RI / SI / PI into a modernized device
* PI DMA now takes place after an appropriate delay to simulate
transfer time
- SP DMA no longer rejects transfers of 0 bytes (should transfer one
8-byte word)

x87: fix for single-precision operations [Peter Farrie]

Capcom ZN-1 update [Team CPS-1]:
* Redumped and fixed MASK ROMs in ts2, ts2j to match real pcb
(Smitdogg, The Dumping Union)
* Minor fixes



New games added or promoted from NOT_WORKING status
---------------------------------------------------
Toy Land Adventure [f205v, The Dumping Union]


New clones added
----------------
Gals Panic S - Extra Edition (Europe) [Hartenberger, arcadiabay.de]
Western Gun Part II [Andrew Welburn]


New games marked as GAME_NOT_WORKING
------------------------------------
Shin Nihon Pro Wrestling Toukon Retsuden 4 Arcade Edition
[f205v, The Dumping Union]
Touch de Uno! 2 [f205v, The Dumping Union]


--------------------
Asus Rampage Extreme IV
Intel I7 3930K
Amd Radeon 7970
4x 4GB DDR3 Corsair Dominator GT CMT16GX3M4X2133C9
Dell U2713H

MAME64 0.151 completo
Go to the top of the page
 
+Quote Post
max-holz
messaggio 16 January 2012, 14:21
Messaggio #2


Mame dipendente
*****

Gruppo: Members

Iscritto il: 10 April 2006, 09:05
Da: Novara
Utente Nr.: 5.001



Questo bug risolto non è segnalato nel file.
CITAZIONE
04306: firefox, firefoxa: No video from Laserdisc CHD - gradual performance degradation.

Gioloi sarà cotento.
Go to the top of the page
 
+Quote Post
gioloi
messaggio 16 January 2012, 14:24
Messaggio #3


Nostalgico
****

Gruppo: Members

Iscritto il: 11 December 2008, 11:50
Da: Lugano
Utente Nr.: 8.962



Yesssssssss!!! pangel2.gif yellow.gif yellow.gif yellow.gif pangel2.gif


--------------------
Midi Tower Intel Quad Q6700 @ 2.66GHz, 3x2 GB RAM Apacer DDR2 PC6400 800MHz, HDD 1 TB Samsung + 200 GB Maxtor, ATI XFX HD5770 1 GB
Monitor Samsung SyncMaster 2693HM (orizzontale) + 215TW (verticale)
Windows Seven Home Premium 64 SP1
Mame64 0.154 (fullset+chd+LD) & M+GUI 1.6.0
Archos Gamepad + Mame4Droid 0.37b5/0.139u1
Go to the top of the page
 
+Quote Post
myyvf
messaggio 17 January 2012, 09:06
Messaggio #4


Mame dipendente
*****

Gruppo: Members

Iscritto il: 12 January 2007, 14:28
Utente Nr.: 6.140



Ma tradotto per un final user mellow.gif , tutto quel lavoro menzionato da Aaron che sarebbe??
Go to the top of the page
 
+Quote Post
Osso
messaggio 17 January 2012, 09:18
Messaggio #5


Mame Maniaco
******

Gruppo: Members

Iscritto il: 30 November 2002, 11:54
Da: Bolzano
Utente Nr.: 61



Sta aggiornando e ripulendo il sistema grafico di MAME. I più sfegatati fan dei giochi 3-D possono sognare che sia propedeutico all'introduzione dell'utilizzo degli shader per accelerare i giochi, mentre i più pragmatici possono essere contenti per un sorgente più chiaro e semplice.


--------------------
PC: Intel Core Duo E8400 3 ghz - 8192 MB Ram DDR2 - Geforce 8800 GS - HD Seagate 250 GB 7200 rpm 16mb cache + HD Samsung 500 GB 7200 rpm 16 mb cache - Ubuntu 10.10 X64.

CITAZIONE
Users need to realize that MAME is guided by a set of principles and those are not going to change to fit user desires. (R. Belmont)
Go to the top of the page
 
+Quote Post
max-holz
messaggio 17 January 2012, 10:27
Messaggio #6


Mame dipendente
*****

Gruppo: Members

Iscritto il: 10 April 2006, 09:05
Da: Novara
Utente Nr.: 5.001



Dell'utilizzo degli shader per accelerare i giochi aveva già parlato Haze una volta dicendo che questo approccio non si scontra con il principio di accuratezza in quanto si tratta di cosa ben diversa dall'accelerazione hardware nel senso tradizionale del termine ossia, parlandi di windows OS, mandare i poligoni alla scheda grafica in formato DirectX perché vengano renderizzati usando le stesse DirectX.
Perché sognare?
Capisco che ai fanatici nostalgia del 2-D questi giochi non interessano ma non vedo come questo debba necessariamente tradursi in una corrente di pensiero dominate.
Go to the top of the page
 
+Quote Post
etabeta
messaggio 17 January 2012, 11:52
Messaggio #7


Mame Dev
******

Gruppo: Members

Iscritto il: 26 January 2003, 18:56
Da: Norvegia (per ora)
Utente Nr.: 158



"sognare" per il semplice fatto che c'e' ancora *molto* lavoro da fare prima che sia possibile sfruttare la gpu

e non serve scomodare Haze ed il suo blog: sono due anni che Arbee spiega che usare la scheda e' nei piani di Aaron wink.gif


--------------------
Macbook
processore: Intel Core 2 Duo @ 2,16 GHz
RAM : 2 x 512 Mb
HD: 120 GB interno + 500 GB esterno

(SDL)MAME 0.133u1 * (FullSet - 7CHD)

CITAZIONE
i censori tendono a fare quello che fanno gli psicotici: confondere la realta' con l'immaginazione (D. Cronenberg)
Go to the top of the page
 
+Quote Post
max-holz
messaggio 17 January 2012, 12:11
Messaggio #8


Mame dipendente
*****

Gruppo: Members

Iscritto il: 10 April 2006, 09:05
Da: Novara
Utente Nr.: 5.001



e per quanto riguarda il multicore?
E' assolutamente certo che non sia possibile utilizzare il calcolo parallelo nell'emulazione delle cpu?
Go to the top of the page
 
+Quote Post
etabeta
messaggio 17 January 2012, 12:13
Messaggio #9


Mame Dev
******

Gruppo: Members

Iscritto il: 26 January 2003, 18:56
Da: Norvegia (per ora)
Utente Nr.: 158



il problema e' sincronizzare i processi. avevamo aggiunto una libreria di byuu che potrebbe migliorare l'uso del multicore ma le varie CPU andrebbero aggiornate per supportarla e nessuno ci ha messo mano, quindi al momento non se ne fa nulla (ed il multicore resta usato solo per alcuni giochi poligonali che mandano alla seconda CPU l'output dei poligoni)


--------------------
Macbook
processore: Intel Core 2 Duo @ 2,16 GHz
RAM : 2 x 512 Mb
HD: 120 GB interno + 500 GB esterno

(SDL)MAME 0.133u1 * (FullSet - 7CHD)

CITAZIONE
i censori tendono a fare quello che fanno gli psicotici: confondere la realta' con l'immaginazione (D. Cronenberg)
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 utenti stanno leggendo questa discussione (1 visitatori e 0 utenti anonimi)
0 utenti:

 

Modalità di visualizzazione: Normale · Passa a: Lineare · Passa a: Outline


RSS Versione Lo-Fi Oggi è il: 20 October 2014, 14:01