diff options
author | 2023-03-08 00:16:47 +1100 | |
---|---|---|
committer | 2023-03-08 00:16:47 +1100 | |
commit | 27fc20067867039d185d99db754ee0dc9af47b40 (patch) | |
tree | d67cf40741cacb8971e5479a27b1f02bb03ba72d | |
parent | 5b5b5019109ea177b54266910df923e1692d95e1 (diff) |
Tie up a few loose ends:
* msx2_flop.xml: Fixed a couple of Japanese titles.
* plugins/layout: Added a couple of things to the layout script sandbox.
* Tidied up Hyper Neo Geo 64 code (srcclean etc.).
-rw-r--r-- | hash/msx2_flop.xml | 16 | ||||
-rw-r--r-- | plugins/layout/init.lua | 7 | ||||
-rw-r--r-- | src/mame/snk/hng64.cpp | 6 | ||||
-rw-r--r-- | src/mame/snk/hng64_3d.ipp | 38 | ||||
-rw-r--r-- | src/mame/snk/hng64_sprite.ipp | 4 | ||||
-rw-r--r-- | src/mame/snk/hng64_v.cpp | 62 |
6 files changed, 68 insertions, 65 deletions
diff --git a/hash/msx2_flop.xml b/hash/msx2_flop.xml index eb729152a7b..aedff8763f3 100644 --- a/hash/msx2_flop.xml +++ b/hash/msx2_flop.xml @@ -1182,10 +1182,10 @@ The following floppies came with the machines. </software> <software name="arcusyu"> - <description>Arcusyu - A-kusu Bangaihen (Japan)</description> + <description>Arcshu: Arcs Bangai-hen (Japan)</description> <year>1989</year> <publisher>WolfTeam</publisher> - <info name="alt_title" value="あーくしゅ[アークス番外編]"/> + <info name="alt_title" value="あーくしゅ[アークス番外編]"/> <info name="serial" value="HG13"/> <info name="gtin" value="04988160920146"/> <part name="flop1" interface="floppy_3_5"> @@ -1197,10 +1197,10 @@ The following floppies came with the machines. </software> <software name="arcusyua" cloneof="arcusyu"> - <description>Arcusyu - A-kusu Bangaihen (Japan, alt)</description> + <description>Arcshu: Arcs Bangai-hen (Japan, alt)</description> <year>1989</year> <publisher>WolfTeam</publisher> - <info name="alt_title" value="あーくしゅ[アークス番外編]"/> + <info name="alt_title" value="あーくしゅ[アークス番外編]"/> <info name="serial" value="HG13"/> <info name="gtin" value="04988160920146"/> <part name="flop1" interface="floppy_3_5"> @@ -13681,10 +13681,10 @@ The following floppies came with the machines. </software> <software name="tirnanog"> - <description>Kindan no Tou: Tir-na-nóg (Japan)</description> + <description>Kindan no Tou: Tir-nan-óg (Japan)</description> <year>1990</year> <publisher>System Soft</publisher> - <info name="alt_title" value="禁断の塔ティルナノーグ"/> + <info name="alt_title" value="禁断の塔ティル・ナ・ノーグ"/> <info name="gtin" value="04988697620113"/> <info name="usage" value="Requires a Japanese system."/> <part name="flop1" interface="floppy_3_5"> @@ -13708,10 +13708,10 @@ The following floppies came with the machines. </software> <software name="tirnanoga" cloneof="tirnanog"> - <description>Kindan no Tou: Tir-na-nóg (Japan, alt)</description> + <description>Kindan no Tou: Tir-nan-óg (Japan, alt)</description> <year>1990</year> <publisher>System Soft</publisher> - <info name="alt_title" value="禁断の塔ティルナノーグ"/> + <info name="alt_title" value="禁断の塔ティル・ナ・ノーグ"/> <info name="gtin" value="04988697620113"/> <info name="usage" value="Requires a Japanese system."/> <part name="flop1" interface="floppy_3_5"> diff --git a/plugins/layout/init.lua b/plugins/layout/init.lua index bcb374b8e67..861e0a697b3 100644 --- a/plugins/layout/init.lua +++ b/plugins/layout/init.lua @@ -17,19 +17,22 @@ function layout.startplugin() local env = { machine = manager.machine, emu = { + attotime = emu.attotime, render_bounds = emu.render_bounds, render_color = emu.render_color, print_verbose = emu.print_verbose, print_error = emu.print_error, + print_warning = emu.print_warning, print_info = emu.print_info, print_debug = emu.print_debug }, file = file, print = print, pairs = pairs, ipairs = ipairs, - string = { format = string.format }, + string = string, + tonumber = tonumber, tostring = tostring, - table = { insert = table.insert, remove = table.remove } } + table = table } local script, err = load(script, script, "t", env) if not script then emu.print_verbose("error loading layout script " .. err) diff --git a/src/mame/snk/hng64.cpp b/src/mame/snk/hng64.cpp index 607e0cab48b..21d80ee8402 100644 --- a/src/mame/snk/hng64.cpp +++ b/src/mame/snk/hng64.cpp @@ -1062,7 +1062,7 @@ void hng64_state::hng64_dualport_w(offs_t offset, uint8_t data) /* The following is guesswork, needs confirmation with a test on the real board. */ // every sprite is 0x20 bytes -// +// void hng64_state::hng64_sprite_clear_even_w(offs_t offset, uint32_t data, uint32_t mem_mask) { auto &mspace = m_maincpu->space(AS_PROGRAM); @@ -1097,7 +1097,7 @@ void hng64_state::hng64_sprite_clear_odd_w(offs_t offset, uint32_t data, uint32_ if(ACCESSING_BITS_16_31) { mspace.write_dword(0x20000000+0x04+0x00+spr_offs, 0x00000000); - // mspace.write_dword(0x20000000+0x0c+0x00+spr_offs, 0x00000000); // erases part of the slash palette in the sams64 2nd intro when we don't want it to! (2nd slash) + // mspace.write_dword(0x20000000+0x0c+0x00+spr_offs, 0x00000000); // erases part of the slash palette in the sams64 2nd intro when we don't want it to! (2nd slash) mspace.write_dword(0x20000000+0x14+0x00+spr_offs, 0x00000000); mspace.write_dword(0x20000000+0x1c+0x00+spr_offs, 0x00000000); } @@ -1105,7 +1105,7 @@ void hng64_state::hng64_sprite_clear_odd_w(offs_t offset, uint32_t data, uint32_ if(ACCESSING_BITS_0_15) { mspace.write_dword(0x20000000+0x04+0x20+spr_offs, 0x00000000); - // mspace.write_dword(0x20000000+0x0c+0x20+spr_offs, 0x00000000); // erases part of the slash palette in the sams64 2nd intro when we don't want it to! (1st slash) + // mspace.write_dword(0x20000000+0x0c+0x20+spr_offs, 0x00000000); // erases part of the slash palette in the sams64 2nd intro when we don't want it to! (1st slash) mspace.write_dword(0x20000000+0x14+0x20+spr_offs, 0x00000000); mspace.write_dword(0x20000000+0x1c+0x20+spr_offs, 0x00000000); } diff --git a/src/mame/snk/hng64_3d.ipp b/src/mame/snk/hng64_3d.ipp index 221c3dbf99b..fe7dd6a5340 100644 --- a/src/mame/snk/hng64_3d.ipp +++ b/src/mame/snk/hng64_3d.ipp @@ -251,7 +251,7 @@ void hng64_state::set3dFlags(const uint16_t* packet) // PACKET FORMAT // [0] - 0011 ... ID // [1] - ???? ... texture scrolling x (c000 - ffff) - // [2] - ???? ... texture scrolling y (c000 - ffff) + // [2] - ???? ... texture scrolling y (c000 - ffff) // [3] - ???? ... // [4] - ???? ... // [5] - ???? ... scale? @@ -386,8 +386,8 @@ void hng64_state::recoverStandardVerts(polygon& currentPoly, int m, uint16_t* ch currentPoly.vert[m].worldCoords[1] = (currentPoly.vert[m].worldCoords[1] * m_modelscaley) / 0x100; currentPoly.vert[m].worldCoords[2] = (currentPoly.vert[m].worldCoords[2] * m_modelscalex) / 0x100; - // if ((m_modelscalex != 0x100) || (m_modelscaley != 0x100) || (m_modelscalez != 0x100)) - // logerror("maybe using model scale %04x %04x %04x\n", m_modelscalex, m_modelscaley, m_modelscalez); + // if ((m_modelscalex != 0x100) || (m_modelscaley != 0x100) || (m_modelscalez != 0x100)) + // logerror("maybe using model scale %04x %04x %04x\n", m_modelscalex, m_modelscaley, m_modelscalez); } } @@ -410,7 +410,7 @@ void hng64_state::recoverPolygonBlock(const uint16_t* packet, int& numPolys) // c = set on objects a certain distance away (maybe optimization to disable clipping against camera?) // ? = roadedge: all vehicles ingame + select screen (also 3d maps on select screen), vehicle lights+windows only in attract, nothing else? // all vehicles ingame + select screen, vehicle lights+windows only in attract, NOT on vehicles between stages, nothing else? - // nothing on other games? + // nothing on other games? // none of these bits appear to be connected to texture size to solve the road/banner problem in xrally/roadedge // // @@ -532,7 +532,7 @@ void hng64_state::recoverPolygonBlock(const uint16_t* packet, int& numPolys) size[2] = threeDPointer[9]; size[3] = threeDPointer[10]; - + // the low 8-bits of each of these is used (or at least contains data, probably one byte for each hunk?) //if (threeDPointer[11] != 0x0000) logerror("3dPointer[11] is %04x!\n", threeDPointer[11]); // ???? [11]; Used. //if (threeDPointer[12] != 0x0000) logerror("3dPointer[12] is %04x!\n", threeDPointer[12]); // ???? [12]; Used. @@ -637,16 +637,16 @@ void hng64_state::recoverPolygonBlock(const uint16_t* packet, int& numPolys) // bbust2 has m_paletteState3d & 0x40 set, which takes the palette out of range // used for 2nd car on roadedge, used for 2nd player on buriki // used for buildings in fatfurwa intro and characters - explicitPaletteValue |= ((m_paletteState3d >>8) & 0x3f) * 0x80; + explicitPaletteValue |= ((m_paletteState3d >> 8) & 0x3f) * 0x80; } currentPoly.palOffset += explicitPaletteValue; //if (chunkOffset[1] & 0x4000) - // currentPoly.palOffset = machine().rand()&0x3ff; + // currentPoly.palOffset = machine().rand()&0x3ff; //if (packet[1] & 0x0006) - // currentPoly.palOffset = machine().rand()&0x3ff; + // currentPoly.palOffset = machine().rand()&0x3ff; if (chunkOffset[1] & 0x4000) currentPoly.blend = true; @@ -939,12 +939,12 @@ void hng64_state::recoverPolygonBlock(const uint16_t* packet, int& numPolys) // Final pixel values are garnered here : float windowCoords[4]; // Mapped ndCoordinates to screen space - windowCoords[0] = (ndCoords[0]+1.0f) * ((float)(512.0f) / 2.0f) + 0.0f; - windowCoords[1] = (ndCoords[1]+1.0f) * ((float)(512.0f) / 2.0f) + 0.0f; + windowCoords[0] = (ndCoords[0]+1.0f) * (512.0f / 2.0f) + 0.0f; + windowCoords[1] = (ndCoords[1]+1.0f) * (512.0f / 2.0f) + 0.0f; windowCoords[2] = (ndCoords[2]+1.0f) * 0.5f; // Flip Y - windowCoords[1] = (float)512.0f - windowCoords[1]; + windowCoords[1] = 512.0f - windowCoords[1]; // Store the points in a list for later use... currentPoly.vert[m].clipCoords[0] = windowCoords[0]; @@ -1204,7 +1204,7 @@ void hng64_state::hng64_fbunkbyte_w(offs_t offset, uint32_t data, uint32_t mem_m /* this is a table filled with 0x0? data, seems to be 8-bit values - + roadedge 08080808 08080808 08080808 08080808 08080808 08080808 08080707 08080909 (ingame) 08080808 08080808 08080808 08080808 08080808 08080808 08080808 08080808 (hyper logo) @@ -1283,14 +1283,14 @@ void hng64_state::setIdentity(float *matrix) float hng64_state::uToF(uint16_t input) { float retVal; - retVal = (float)((int16_t)input) / 32768.0f; + retVal = float(int16_t(input)) / 32768.0f; return retVal; #if 0 - if ((int16_t)input < 0) - retVal = (float)((int16_t)input) / 32768.0f; + if (int16_t(input) < 0) + retVal = float(int16_t(input)) / 32768.0f; else - retVal = (float)((int16_t)input) / 32767.0f; + retVal = float(int16_t(input)) / 32767.0f; #endif } @@ -1299,9 +1299,9 @@ void hng64_state::normalize(float* x) double l2 = (x[0]*x[0]) + (x[1]*x[1]) + (x[2]*x[2]); double l = sqrt(l2); - x[0] = (float)(x[0] / l); - x[1] = (float)(x[1] / l); - x[2] = (float)(x[2] / l); + x[0] = float(x[0] / l); + x[1] = float(x[1] / l); + x[2] = float(x[2] / l); } diff --git a/src/mame/snk/hng64_sprite.ipp b/src/mame/snk/hng64_sprite.ipp index 501af726c1b..c85f872d264 100644 --- a/src/mame/snk/hng64_sprite.ipp +++ b/src/mame/snk/hng64_sprite.ipp @@ -20,7 +20,7 @@ * 7 1c | ---- ---- ---- ---- ---- ---- ---- ---- | not used ?? * * in (4) ggg seems to be either group, or priority against OTHER layers (7 being the lowest, 0 being the highest in normal situations eg most of the time in buriki) - * + * * (*) Fatal Fury WA standard elements are 0x1000-0x1000, all the other games sets 0x100-0x100, related to the bit 27 of sprite regs 0? ** Sprite Global Registers * ----------------------- @@ -403,5 +403,5 @@ inline void hng64_state::draw_sprite_line(screen_device& screen, const rectangle zoom_transpen(m_sprite_bitmap, m_sprite_zbuffer, cliprect, m_gfxdecode->gfx(gfxregion), tileno, pal, xflip, yflip, xpos, ypos, dx, dy, dstwidth, 0, zval, zsort, blend, checkerboard, mosaic, mosaic_count_x, curyy, srcpix); xpos += dstwidth; } - + } diff --git a/src/mame/snk/hng64_v.cpp b/src/mame/snk/hng64_v.cpp index 6a3d884607c..59e323e31c0 100644 --- a/src/mame/snk/hng64_v.cpp +++ b/src/mame/snk/hng64_v.cpp @@ -4,12 +4,12 @@ #include "hng64.h" /* - final mix can clearly only process 2 possibilities for any screen pixel; a 'top' and 'bottom' pixel option - one of those can be blended. - blended pixels can't be stacked (only one still appears as blended, the other becomes solid) + final mix can clearly only process 2 possibilities for any screen pixel; a 'top' and 'bottom' pixel option + one of those can be blended. + blended pixels can't be stacked (only one still appears as blended, the other becomes solid) - many examples can be found where using alpha effects just cuts holes in sprites/3D or erases other alpha - tilemap layers due to this + many examples can be found where using alpha effects just cuts holes in sprites/3D or erases other alpha + tilemap layers due to this */ #define HNG64_VIDEO_DEBUG 0 @@ -382,7 +382,7 @@ void hng64_state::hng64_tilemap_draw_roz_core_line(screen_device &screen, bitmap xinc2 = 0; yinc2 = 0; } - + } uint32_t startx = xtopleft; @@ -592,7 +592,7 @@ void hng64_state::hng64_tilemap_draw_roz_core_line(screen_device &screen, bitmap | 0000 0011 - road edge alt 1 | dd = global tilemap dimension selector | 0000 0111 - road edge alt 2 | ? = Always Set? | | Z = Global Zoom Disable? - | | u = bit 0 is explicitly cleared from initialized value in sams64, both bits turned on for buriki 'split' effect + | | u = bit 0 is explicitly cleared from initialized value in sams64, both bits turned on for buriki 'split' effect * 1 | oooo oooo oooo oooX ---- ---- ---- ---- | unknown - X is sometimes used (1 in demo of xrally, 0 in game) not always initialized whole register gets set to 0xffff during mosaic bit of roadedge intro. Also buriki intro * | ---- ---- ---- ---- oooo oooo oYoo oooo | unknown - untouched in sams64 games, initialized elsewhere Y gets set to 4 at some points in xrally attract * 2 | xxxx xxxx xxxx xxxx ---- ---- ---- ---- | tilemap0 per layer flags @@ -852,20 +852,20 @@ uint32_t hng64_state::screen_update_hng64(screen_device &screen, bitmap_rgb32 &b Each framebuffer has enough RAM for 24 bits of data for a 512x256 layer (screen is interlaced, so it doesn't really have 448 pixels in height) - + theory: 11 bit palette index (can use either half of palette) - 1 bit 'blend' - 4 bit 'light' - 8 bit depth? + 1 bit 'blend' + 4 bit 'light' + 8 bit depth? */ // 3d gets drawn next uint16_t palbase = 0x000; - if (m_fbcontrol[2] & 0x20) - { - if (!m_roadedge_3d_hack) - palbase = 0x800; - } + if (m_fbcontrol[2] & 0x20) + { + if (!m_roadedge_3d_hack) + palbase = 0x800; + } rectangle visarea = m_screen->visible_area(); int ysize = visarea.max_y - visarea.min_y; @@ -923,7 +923,7 @@ uint32_t hng64_state::screen_update_hng64(screen_device &screen, bitmap_rgb32 &b // this correctly allows buriki intro sprites to use regular alpha, not additive // while also being correct for sams64, which wants additive, but appears to be // incorrect for Fatal Fury's hit effects which want additive - // + // // the 6 regs around here have the same values in fatfur and buriki, so are unlikely // to control the blend type. //uint8_t spriteblendtype = (m_tcram[0x10 / 4] >> 16) & 0x10; @@ -967,7 +967,7 @@ uint32_t hng64_state::screen_update_hng64(screen_device &screen, bitmap_rgb32 &b popmessage("%08x %08x %08x %08x %08x", m_spriteregs[0], m_spriteregs[1], m_spriteregs[2], m_spriteregs[3], m_spriteregs[4]); // see notes at top for more detailed info on these - if (1) + if (0) popmessage("%08x %08x\nTR(%04x %04x %04x %04x)\nSB(%04x %04x %04x %04x)\n%08x %08x %08x\nSPLIT?(%04x %04x %04x %04x)\nAA(%08x %08x)\n%08x", // global tilemap control regs? m_videoregs[0x00], m_videoregs[0x01], @@ -991,7 +991,7 @@ uint32_t hng64_state::screen_update_hng64(screen_device &screen, bitmap_rgb32 &b (m_tcram[0x08 / 4] >> 16) & 0xffff, (m_tcram[0x08 / 4] >> 0) & 0xffff, // 0200 01b0 (fatfurwa) 0200 01c0 (bbust2, xrally) // is this 2 groups of 3 regs? - (m_tcram[0x0c / 4] >> 24) & 0xff, // 04 = 'blend' on tm1 + (m_tcram[0x0c / 4] >> 24) & 0xff, // 04 = 'blend' on tm1 (m_tcram[0x0c / 4] >> 16) & 0xff, // 04 = set when fades are going on with blended sprites in buriki intro? otherwise usually 00 (m_tcram[0x0c / 4] >> 8) & 0xff, // upper bit not used? value usually 2x, 4x, 5x or 6x // 2nd group? @@ -1017,8 +1017,8 @@ uint32_t hng64_state::screen_update_hng64(screen_device &screen, bitmap_rgb32 &b m_tcram[0x20 / 4], // unused? - (m_tcram[0x24 / 4] >> 16) & 0xfffc, - ((m_tcram[0x24 / 4] >> 16) & 0x0002)>>1, // 0002 gets set in roadedge during some transitions (layers are disabled? blacked out?) 0001 + (m_tcram[0x24 / 4] >> 16) & 0xfffc, + ((m_tcram[0x24 / 4] >> 16) & 0x0002)>>1, // 0002 gets set in roadedge during some transitions (layers are disabled? blacked out?) 0001 (m_tcram[0x24 / 4] >> 16) & 0x0001, // 0001 may indicate if to use the 8 below for standard fade, set on SNK logo in roadedge, in FFWA // some kind of bitfields, these appear related to fade mode for the registers at 0x28 / 4, set to either 3 or 2 which is additive or subtractive @@ -1064,17 +1064,17 @@ uint32_t hng64_state::screen_update_hng64(screen_device &screen, bitmap_rgb32 &b 0001057f */ - + /* - palette manipulation note - - pal7 pal6 pal5 pal4 pal3 pal2 pal1 pal0 // which fade register those bits relate to? - 00 00 11 00 00 00 10 10 // bits in (m_tcram[0x24 / 4] >> 0) (set to 0c0a in this example) - - an entry of 00 means palette effect not in use? - an entry of 11 means subtractive? - an entry of 10 means addition? - an entry of 01 means?? + palette manipulation note + + pal7 pal6 pal5 pal4 pal3 pal2 pal1 pal0 // which fade register those bits relate to? + 00 00 11 00 00 00 10 10 // bits in (m_tcram[0x24 / 4] >> 0) (set to 0c0a in this example) + + an entry of 00 means palette effect not in use? + an entry of 11 means subtractive? + an entry of 10 means addition? + an entry of 01 means?? */ |