| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
this better fits the drivers from MESS (which have always illogically used the GAME_ flags despite not being games) and also fits fine with arcade machines.
|
|
|
|
| |
unavailable msdos to boot (nw)
|
| |
|
|
|
|
| |
use m_palette (nw)
|
|
|
|
|
|
| |
gfxdecode devices must now be assigned a palette in MCFG. Added palette devices to several MESS drivers and devices to comply with this requirement. This palette is assigned as a default to the gfx_elements created by the device (but still not used for drawing yet, except in the UI graphics viewer)
Tilemaps now have a pointer to a palette device and use that palette for rgb32 drawing, rather than the palette of the screen or bitmap they are drawing to (since rgb32 screens don't have palettes now). When a tilemap is created, it takes its palette from the gfxdecode device it was created with, but you can change a tilemap's palette device with set_palette() at any time (doing this does not mark the tilemap dirty, since all tilemaps use indexed bitmaps internally)
|
| |
|
|
|
|
| |
optional_device<palette_device> m_palette out of driver.* (nw)
|
|
|
| |
note: Aaron please give more descriptive text for release log I have no more strength :)
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Milanovic]
Updated all devices and drivers for using it.
out of whatsnew:
Note that it is made to work same as before, in some cases it can be more
logic to move gfxdevice into subdevice itself then to keep it in main driver.
|
| |
|
| |
|
| |
|
| |
|
|
|