* New abbreviated types are in osd and util namespaces, and also in global namespace for things that #include "emu.h"
* Get rid of import of cstdint types to global namespace (C99 does this anyway)
* Remove the cstdint types from everything in emu
* Get rid of U64/S64 macros
* Fix a bug in dps16 caused by incorrect use of macro
* Fix debugcon not checking for "do " prefix case-insensitively
* Fix a lot of messed up tabulation
* More constexpr
* Fix up many __names
Use standard uint64_t, uint32_t, uint16_t or uint8_t instead of UINT64, UINT32, UINT16 or UINT8
also use standard int64_t, int32_t, int16_t or int8_t instead of INT64, INT32, INT16 or INT8
m_. Rewrote code accessing members to use seconds() and attoseconds().
The changes were triggered by a test how gcc __int128_t would perform as
the internal representation. This test revealed that the current
implementation is still faster. (nw)
as follows:
MAKE_RGB(r,g,b) == rgb_t(r,g,b)
MAKE_ARGB(a,r,g,b) == rgb_t(a,r,g,b)
RGB_ALPHA(data) == data.a()
RGB_RED(data) == data.r()
RGB_GREEN(data) == data.g()
RGB_BLUE(data) == data.b()
RGB_BLACK == rgb_t::black
RGB_WHITE == rgb_t::white
Implicit conversions to/from UINT32 are built in as well as simple
addition, subtraction, and scaling (with clamping).
As a result of being a class, some stricter typing was needed in
a few places but overall not too much.
subclass serial_eeprom_device. Moved the latter into its own file
eepromser.c and significantly cleaned up/simplified the code. The new
code should be functionally the same as the previous code, but expect that
to change soon. As a side-effect, the size and bus width of the EEPROM is now
specified in the ADD macro rather than in the interface structure.
Tilemap system: numerous changes:
* Moved remaining legacy macros and typedefs to tilelgcy.h. This revealed
a few drivers mixing and matching modern & legcy, which have now been
fixed.
* Changed get info callback signature to no longer pass the user_data
pointer, but instead pass a reference to the tilemap object itself.
Updated those few drivers using user_data to pull it out of the
tilemap object with the new user_data() getter method.
* Changed get info and mapping callbacks to be device_delegates so that
they can be described at config time.
* Added tilemap_memory object that is used internally for reading/
writing to memory that backs a tilemap. This object is used to track
a memory pointer that backs tilemap memory, and also is designed to
transparently handle all bus width and endianness associated with
reading and writing data in a tilemap.
* Incorporated two tilemap_memory objects (basemem and extmem) into the
tilemap object and added accessors to them, as well as read/write
handlers for reading/writing to entries stored in the memory. This
means that tilemap get info callbacks can now easily read data out of
the tilemap in a generic way.
* Rejiggered the initialization sequence for tilemap objects so that
the tilemap_manager is not required to be present at instantiation.
* Created a new tilemap_device, which can be used to declare a tilemap
in the machine config, and which also is a tilemap object itself.
The tilemap device will look for shared memory regions called
"<tag>" and "<tag>_ext" and automatically plug them into the tilemap.
The device also provides write handlers that can be used to write
to the tilemap memory and mark tiles dirty, saving the need for each
driver to write their own.
Device system: moved required/optional device finders to a new header
devfind.h.
Atari drivers: removed all playfield and alpha memory and tilemap
variables, apart from those needed by atarivc-using games (this will
become a device in a future update). Updated all Atari 16-bit drivers to
use the new tilemap_device instead, which provides all the needed
functionality in a more generic way.
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.
macros with bitmap->pix* functions, and moved bitmap_fill() to bitmap->fill()
among other similar changes. Bitmap fields now only available via accessors.
Replaced sect_rect with &= and union_rect with |= operators for rectangle
classes. Some general cleanup as a result of these changes. [Aaron Giles]
out of log:
This way it is possible to link two or more separated executables with different
copyright/xml out/name/... in one compilation, just one step closer...
cases, we can get rid of the postload function entirely and just
call directly to the target function. Drivers eventually should
just override device_postload() instead of registering for callbacks.
