for drivers that used GFX_RAW support for 4bpp systems, and yet
we had a bunch of extra code to support it. Updated these drivers
to do without it and removed all the extra code for supporting
it.
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.
parameters for the global SCREEN_UPDATE callback match the parameters
for the driver_device version. Added allocate() and deallocate()
methods to bitmap_t to permit cleaner handling of bitmaps in drivers
and modern devices. [Aaron Giles]
cliprects mandatory everywhere. In general, cliprects were being
correctly passed through the video side of most drivers already, so
it is mostly a semantic change. Note that with my previous change,
bitmaps have cliprects, so if you just want to clip to the bitmap's
boundaries, pass bitmap->cliprect() instead of NULL (which is no
longer permitted). [Aaron Giles]
Remove redundant machine items from address_space and device_t.
Neither machine nor m_machine are directly accessible anymore.
Instead a new getter machine() is available which returns a
machine reference. So:
space->machine->xxx ==> space->machine().xxx
device->machine->yyy ==> device->machine().yyy
Globally changed all running_machine pointers to running_machine
references. Any function/method that takes a running_machine takes
it as a required parameter (1 or 2 exceptions). Being consistent
here gets rid of a lot of odd &machine or *machine, but it does
mean a very large bulk change across the project.
Structs which have a running_machine * now have that variable
renamed to m_machine, and now have a shiny new machine() method
that works like the space and device methods above. Since most of
these are things that should eventually be devices anyway, consider
this a step in that direction.
98% of the update was done with regex searches. The changes are
architected such that the compiler will catch the remaining
errors:
// find things that use an embedded machine directly and replace
// with a machine() getter call
S: ->machine->
R: ->machine\(\)\.
// do the same if via a reference
S: \.machine->
R: \.machine\(\)\.
// convert function parameters to running_machine &
S: running_machine \*machine([^;])
R: running_machine \&machine\1
// replace machine-> with machine.
S: machine->
R: machine\.
// replace &machine() with machine()
S: \&([()->a-z0-9_]+machine\(\))
R: \1
// sanity check: look for this used as a cast
(running_machine &)
// and change to this:
*(running_machine *)
- Created new central header "emu.h"; this should be included
by pretty much any driver or device as the first include. This
file in turn includes pretty much everything a driver or device
will need, minus any other devices it references. Note that
emu.h should *never* be included by another header file.
- Updated all files in the core (src/emu) to use emu.h.
- Removed a ton of redundant and poorly-tracked header includes
from within other header files.
- Temporarily changed driver.h to map to emu.h until we update
files outside of the core.
Added class wrapper around tagmap so it can be directly included
and accessed within objects that need it. Updated all users to
embed tagmap objects and changed them to call through the class.
Added nicer functions for finding devices, ports, and regions in
a machine:
machine->device("tag") -- return the named device, or NULL
machine->port("tag") -- return the named port, or NULL
machine->region("tag"[, &length[, &flags]]) -- return the
named region and optionally its length and flags
Made the device tag an astring. This required touching a lot of
code that printed the device to explicitly fetch the C-string
from it. (Thank you gcc for flagging that issue!)
osd_free(). They take the same parameters as malloc() and free().
Renamed mamecore.h -> emucore.h.
New C++-aware memory manager, implemented in emualloc.*. This is a
simple manager that allows you to add any type of object to a
resource pool. Most commonly, allocated objects are added, and so
a set of allocation macros is provided to allow you to manage
objects in a particular pool:
pool_alloc(p, t) = allocate object of type 't' and add to pool 'p'
pool_alloc_clear(p, t) = same as above, but clear the memory first
pool_alloc_array(p, t, c) = allocate an array of 'c' objects of type
't' and add to pool 'p'
pool_alloc_array_clear(p, t, c) = same, but with clearing
pool_free(p, v) = free object 'v' and remove it from the pool
Note that pool_alloc[_clear] is roughly equivalent to "new t" and
pool_alloc_array[_clear] is roughly equivalent to "new t[c]". Also
note that pool_free works for single objects and arrays.
There is a single global_resource_pool defined which should be used
for any global allocations. It has equivalent macros to the pool_*
macros above that automatically target the global pool.
In addition, the memory module defines global new/delete overrides
that access file and line number parameters so that allocations can
be tracked. Currently this tracking is only done if MAME_DEBUG is
enabled. In debug builds, any unfreed memory will be printed at
the end of the session.
emualloc.h also has #defines to disable malloc/free/realloc/calloc.
Since emualloc.h is included by emucore.h, this means pretty much
all code within the emulator is forced to use the new allocators.
Although straight new/delete do work, their use is discouraged, as
any allocations made with them will not be tracked.
Changed the familar auto_alloc_* macros to map to the resource pool
model described above. The running_machine is now a class and contains
a resource pool which is automatically destructed upon deletion. If
you are a driver writer, all your allocations should be done with
auto_alloc_*.
Changed all drivers and files in the core using malloc/realloc or the
old alloc_*_or_die macros to use (preferably) the auto_alloc_* macros
instead, or the global_alloc_* macros if necessary.
Added simple C++ wrappers for astring and bitmap_t, as these need
proper constructors/destructors to be used for auto_alloc_astring and
auto_alloc_bitmap.
Removed references to the winalloc prefix file. Most of its
functionality has moved into the core, save for the guard page
allocations, which are now implemented in osd_alloc and osd_free.
> From: Atari Ace [mailto:atari_ace@verizon.net]
> Sent: Sunday, September 27, 2009 7:58 AM
> To: submit@mamedev.org
> Cc: atariace@hotmail.com
> Subject: [patch] More _NAME macros
>
> Hi mamedev,
>
> MAME's idiom for function/data macros is to first implement
> <name>_NAME, then implement the other macros in terms of the _NAME
> macro. Then in principle only a single line needs editing to change
> the naming convention.
>
> This patchset implements this idiom more completely. The first patch
> adds some missing _NAME macros and fixes cases in source files that
> should be using the macros. The second patch then changes header
> files where the macros should have been used, but weren't. This
> required changing the idiom for removing a machine driver function
> pointer from MDRV_<FUNCTION>(NULL) to MDRV_<FUNCTION>(0), to avoid
> problems with NULL being macro expanded. This actually unifies the
> handling of all such cases, as we already had ipt_0 and driver_init_0.
> It also required reworking the devtempl.h implementation in a way that
> triggered a warning on MSVC about using empty macros, so vconv.c
> needed to be updated. The third patch then renames all the _NAME and
> _0 macros to verify that all the cases have been covered, so it isn't
> intended to be applied.
>
> ~aa
to be working reliably.
Deprecated the ROMREGION_DISPOSE flag, as 98% of the use of it no
longer is applicable with on-the-fly decoding, and the remaining
cases are difficult to identify among the others.
gfx_element. Updated the drivers that did this to use the new function, fixing
random crashes.
Fixed a couple of other minor regressions with recent drawgfx changes.
- Added built-in dirty tile tracking to the gfx_element. This removes
the need for all drivers that had dynamically populated graphics
to do their own dirty tracking. Tiles are marked dirty via the
new function gfx_element_mark_dirty(). Any driver that needs access
to the decoded data must call gfx_element_get_data() in order to
ensure that the referenced tile is clean before proceeding.
- In order to support dirty tracking, the gfx_element was enhanced to
keep track of the original source pointer, so that it can go back
and regenerate tiles on demand. For systems that set NULL for the
region in the gfxdecode, they must use gfx_element_set_source()
to specify a pointer to the raw data before drawing anything.
- Changed allocgfx() to gfx_element_alloc(), and added parameters to
specify the source data pointer, base color index, and total colors.
Many drivers had to whack these values in after the fact, so this
allowed for some minor additional cleanup.
- Added a dirtyseq member to the gfx_element struct. This is
incremented on each tile dirty, and can be used to sniff if
something has changed.
- Added logic in the tilemap engine to track which gfx_elements are
used for a given tilemap, and automatically detect changes to the
tiles so that drivers no longer have to explicitly invalidate the
tilemap when tiles change. In the future, this may grow smarter to
only invalidate the affected tiles, but for now it invalidates the
entire tilemap.
- Updated a number of drivers to remove their own dirty handling and
leverage the new internal dirty marking.
- Because the source data must always be present, updated the atarigen
zwackery and mystwarr graphics handing code to support this.
- Thanks to the dirty tracking, this actually allows all gfx decoding
to happen on the fly instead of all at once up front. Since there
was some concern that this would cause undesirable behavior due to
decoding lots of tiles on the fly, it is controlled with a compile-
time constant in mame.h (PREDECODE_GFX). Set this to 1 to get the
old behavior back.
- Moved decodechar() and decodegfx() to deprecat.h. All drivers in MAME
have been updated to simply mark tiles dirty and let the rendering
system decode them as needed, so these functions may go away in the
future.
- Rewrote entirely the rendering code in drawgfx. This code previously
used extensive recursive #includes and tricks to build, and was
very difficult to understand. The new code is based off of a set of
macros defined in drawgfxm.h. These new macros separate the core
rendering logic from the per-pixel operation, allowing the operation
to be easily "plugged" into any of the renderers. These macros are
also available to any driver that wants custom rendering behavior
that is similar to existing core behavior, without needing to
populate the core with esoteric one-off rendering behaviors.
- Added a set of new functions for [p]drawgfx[zoom], one for each
transparency type. The old [p]drawgfx[zoom] functions are still
present, but now switch off the transparency type and call through
to one of these new transparency-specific functions. The old
functions are also now reduced to only supporting TRANSPARENCY_NONE,
TRANSPARENCY_PEN, and TRANSPARENCY_PENS. All other rendering types
must use the new functions.
- All new rendering functions have extensive asserts to catch improper
clipping rectangles and other common errors.
- All new rendering functions automatically downgrade to optimized
versions where appropriate. For example, calling drawgfx_transpen
with an out-of-range pen automatically falls back to drawgfx_opaque.
And drawgfxzoom_* with xscale=yscale=1.0 automatically falls back
to drawgfx_*. And many other examples. In general, this relieves
drivers from needing to make these sorts of decisions.
- All new rendering functions have a consistent parameter order that
is a bit different from the existing functions. The cliprect
parameter is now specified immediately after the destination bitmap,
to match the convention used throughout the rest of the system.
The core parameters are followed by the scale parameters (for the
zoom functions), and then followed by the priority parameters (for
the pdrawgfx* functions), finally followed by any PIXEL_OP*-specific
parameters (such as transparent pen, alpha, drawing tables, etc.)
- Removed drawgfx_alpha_cache, alpha_set_level(), and the inline
functions alpha_blend16() and alpha_blend32(). To render graphics
with alpha, use the new [p]drawgfx[zoom]_alpha functions, which
take an explicit alpha value. To render tilemaps with alpha, the
TILEMAP_DRAW_ALPHA option now takes an explicit alpha parameter.
And to do you own alpha blending, use the alpha_blend_r16() and
alpha_blend_r32() functions, which take an explicit alpha.
- Updated a number of drivers as a result of removing the implicit
alpha in the drawgfx_alpha_cache.
- Removed drawgfx_pen_table and TRANSPARENCY_PEN_TABLE. To achieve
the same effect, build your own table and pass it to
[p]drawgfx[zoom]_transtable, along with a pointer to the
machine->shadow_table to use for shadows. Eventually
machine->shadow_table is likely to go away, and drivers will need
to fetch the shadow table from the palette directly.
- Updated a number of drivers to remove use of drawgfx_pen_table.
- Removed TRANSPARENCY_ALPHARANGE; it was only used by the psikyosh
driver, so it is now moved locally into that driver and built
using the macros in drawgfxm.h.
- Removed TRANSPARENCY_PEN_RAW; to achieve the same effect, call the
new [p]drawgfx[zoom]_transpen_raw() functions. Updated drivers to
make this change.
- Removed the unused mdrawgfx* functions entirely.
- Added new function gfx_element_set_source_clip() to specify a
source clipping rectangle for any element. This replaces the nasty
hacks that were being used in bnstars, ms32, namcos86, and namcos1
to achieve similar behaviors.
- Simplified the copyrozbitmap() functions to match the copybitmap()
functions in having separate opaque and transparent versions. Also
removed the 'priority' parameter which was only used by one driver,
and moved that logic into a custom renderer built using macros in
drawgfxm.h. Updated copyrozbitmap* to use the destbitmap, cliprect
parameter ordering convention as well.
- Simplified the draw_scanline*() functions to always render opaque.
Only one driver was doing otherwise, and it now does its work
internally (draw_scanline is dead-simple ever since we moved
rotation to the OSD code; I almost just removed it entirely).
Other changes:
- Added a cliprect to the bitmap_t type, which describes the full
bitmap.
- Removed tilemap_set_pen_data_offset; unfortunately, this adds a
random tile offset behind the scenes and goes against the dirty
tile detection and invalidation. Updated the mainsnk, snk, and
snk68 drivers to use old fashioned tile banking. (Sorry Nicola.)
- Changed zac2650 gfxdecode to use scale factors.
- Added function video_assert_out_of_range_pixels() to help find
the source of invalid pixels (generally out-of-range palette
entries due to invalid data or sloppy calculations). Place this
after each step in your rendering in a debug build to discover
which code is generating improper pixels.
Sent: Saturday, December 13, 2008 5:07 PM
To: submit@mamedev.org
Cc: atariace@hotmail.com
Subject: [patch] Add machine to allocgfx
Hi mamedev,
This patch eliminates the #include "deprecat.h" from drawgfx.h. It
does so in a fashion similar to my recent tilemap patch, adding the
machine pointer to gfx_element, changing allocgfx to take a machine,
and then adjusting the internals to use the machine field as needed.
The changes outside of drawgfx.[ch] were done with the attached
script.
~aa
integer value, regions are now referred to by a region class and
a region tag. The class specifies the type of region (one of CPU,
gfx, sound, user, disk, prom, pld) while the tag uniquely specifies
the region. This change required updating all the ROM region
definitions in the project to specify the class/tag instead of
region number.
Updated the core memory_region_* functions to accept a class/tag
pair. Added new memory_region_next() function to allow for iteration
over all memory regions of a given class. Added new function
memory_region_class_name() to return the name for a given CPU
memory region class.
Changed the auto-binding behavior of CPU regions. Previously, the
first CPU would auto-bind to REGION_CPU1 (that is, any ROM references
would automatically assume that they lived in the corresponding
region). Now, each CPU automatically binds to the RGNCLASS_CPU region
with the same tag as the CPU itself. This behavior required ensuring
that all previous REGION_CPU* regions were changed to RGNCLASS_CPU
with the same tag as the CPU.
Introduced a new auto-binding mechanism for sound cores. This works
similarly to the CPU binding. Each sound core that requires a memory
region now auto-binds to the RGNCLASS_SOUND with the same tag as the
sound core. In almost all cases, this allowed for the removal of the
explicit region item in the sound configuration, which in turn
allowed for many sound configurations to removed altogether.
Updated the expression engine's memory reference behavior. A recent
update expanded the scope of memory references to allow for referencing
data in non-active CPU spaces, in memory regions, and in EEPROMs.
However, this previous update required an index, which is no longer
appropriate for regions and will become increasingly less appropriate
for CPUs over time. Instead, a new syntax is supported, of the form:
"[tag.][space]size@addr", where 'tag' is an optional tag for the CPU
or memory region you wish to access, followed by a period as a
separator; 'space' is the memory address space or region class you
wish to access (p/d/i for program/data/I/O spaces; o for opcode space;
r for direct RAM; c/u/g/s for CPU/user/gfx/sound regions; e for
EEPROMs); and 'size' is the usual b/w/d/q for byte/word/dword/qword.
Cleaned up ROM definition flags and removed some ugly hacks that had
existed previously. Expanded to support up to 256 BIOSes. Updated
ROM_COPY to support specifying class/tag for the source region.
Updated the address map AM_REGION macro to support specifying a
class/tag for the region.
Updated debugger windows to display the CPU and region tags where
appropriate.
Updated -listxml to output region class and tag for each ROM entry.
longer used. Source needs to be recompiled because of the changed enum.
- Changed copybitmap and copyscrollbitmap:
There are now 2 versions of each, one without and with transparency:
void copybitmap(mame_bitmap *dest,mame_bitmap *src,int flipx,int flipy, int sx,int sy,const rectangle *clip);
void copybitmap_trans(mame_bitmap *dest,mame_bitmap *src,int flipx,int flipy, int sx,int sy,const rectangle *clip, pen_t transparent_pen);
void copyscrollbitmap(mame_bitmap *dest,mame_bitmap *src, nt rows,const int *rowscroll,int cols,const int *colscroll, const rectangle *clip);
void copyscrollbitmap_trans(mame_bitmap *dest,mame_bitmap *src, int rows,const int *rowscroll,int cols,const int *colscroll, const rectangle *clip, pen_t transparent_pen);
The version without _trans is the equivalent of the old TRANSPARENCY_NONE, The *_trans version is the equivalent
of the old TRANSPARENCY_PEN. The old TRANSPARENCY_COLOR mode is done via calling *_trans version and passing in
the pen that has been looked up via machine->pens[].
So for example, copybitmap(..., TRANSPARENCY_COLOR, 0) becomes
copybitmap_trans(..., machine->pens[0])
- Changed all drivers to the new calls. Suprising how few drivers still use these functions.
Most have still not been converted to tilemaps, or they are still writing to a tmpbitmap
which gets copied over to the real bitmap in VIDEO_UPDATE.
- Changed machine->screen[0].visarea to 'cliprect' where appropriate.
While investigating alternate gfx layout schemes, I stumbled across
the fact that some drivers are allocating graphics with one layout and
then decoding them with another (!). There's no guarantee this will
work, but for the drivers that do so (all Konami games), the layouts
are similar enough that it does. A related potential bug is that many
drivers are decoding using the layout provided to allocgfx, not the
layout attached the element returned from allocgfx. If the element
had scaling applied to it, this would be incorrect, but since scaling
is rare these are also benign. It would also be a problem if the
layout data had a different internal representation (which is
something I'm experimenting with), so to reduce the possibility of
coding errors and allow for future changes, I'd like to remove the
layout parameter from decodechar.
So here's two patches, the first fixes the affected Konami drivers to
allocate and decode using the same layouts. It changes the notion of
plane_order and bpp in the functions somewhat to let the start
routines select the appropriate layout, but acceptably so IMHO (I can
clean this up further if there are loud objections). The second patch
then removes the layout parameter from all the decodechar() calls.
I also reviewed MESS to see if it had similar problems and didn't find
any.
0. This patch does minor cleanup to existing layouts, trimming/padding
entries as appropriate and reformating a few layouts.
1. This patch introduces a GFXLAYOUT_RAW() macro, and uses it
throughout. It codifies the requirements for a raw layout in one
place.
2. This patch adds new validation code to the core for some previously
unchecked assumptions about layouts, and reduces the number of
references to the gfx_layout fields in preparation for a change in the
representation.
3. This patch constifies the remaining non-const gfx_layouts in MAME.
It does this by adjusting the code so that the only modification to a
layout ever needed is for the total field, which is then handled by
modifying a stack-based copy of the layout before invoking allocgfx. I
also spent some time consolidating and simplifying the layout code in
konamiic.c.
- removed years from copyright notices
- removed redundant (c) from copyright notices
- updated "the MAME Team" to be "Nicola Salmoria and the MAME Team"
This patch should complete the addition of static qualifiers to all
MAME symbols that aren't explicitly exported. It primarily handles
generated code (e.g. amspdwy.c), plus a handful of cases I'd
previously missed and some new cases introduced in the last update.
One interesting bit was the discovery that the 32-bit scanline
routines in drawgfx.c are unused. I debated eliminating them but
decided instead to just export them. Various internal drawgfx
functions were conditionally removed by examining a new RAW define,
although one routine (blockmove_8toN_alphaone) was determined to be
dead code.
While investigating constifying MESS, I came across a few core APIs
that were missing const qualifiers which this patch fixes. I also
consted up tx1.c while I was at it.
