summaryrefslogtreecommitdiffstatshomepage
diff options
context:
space:
mode:
author Vas Crabb <vas@vastheman.com>2023-03-08 00:16:47 +1100
committer Vas Crabb <vas@vastheman.com>2023-03-08 00:16:47 +1100
commit27fc20067867039d185d99db754ee0dc9af47b40 (patch)
treed67cf40741cacb8971e5479a27b1f02bb03ba72d
parent5b5b5019109ea177b54266910df923e1692d95e1 (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.xml16
-rw-r--r--plugins/layout/init.lua7
-rw-r--r--src/mame/snk/hng64.cpp6
-rw-r--r--src/mame/snk/hng64_3d.ipp38
-rw-r--r--src/mame/snk/hng64_sprite.ipp4
-rw-r--r--src/mame/snk/hng64_v.cpp62
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??
*/