----------------------
18 Wheeler (deluxe) [Ordyne, MetalliC]
18 Wheeler (deluxe) (Rev T) [Ordyne, MetalliC]
Club Kart: European Session (Rev C) [Ordyne, MetalliC]
Ring Out 4x4 [Ordyne, MetalliC]
The House of the Dead 2 (Export) [Ordyne, MetalliC]
Virtua Striker 2 Ver. 2000 [Ordyne, MetalliC]
Zombie Revenge (Export) [Ordyne, MetalliC]
naomi.cpp changes: New dumps added: NAOMI Development / tester BIOS (Nov 1998), Ferrari F355 DLX prototype Japan and Export BIOSes, NAOMI Rev F Export BIOS, Ferrari F355 DLX prototype motor board firmware. Existing Club Kart (Rev C) set was identified as Rev A and renamed accordingly. [Ordyne, MetalliC]
In commit ec325ef14f I did something stupid from
a performance standpoint, which was to select the shading function on a
per-pixel basis even though it can only change on a per-polygon basis. This
commit uses c++ templates and inline functions to so that the compiler's
constant folding can eliminate the switch statement that selects shading
functions (thus making the choice a per-polygon one). I also did the same thing
for the texture and bilinear filtering checks.
This brings back a little less than half of the performance hit on my PC, so
things still aren't as fast as they used to be.
Benchmark (running a full cycle of Crazy Taxi NAOMI's attract) on my PC:
Before ec325ef14f: 30%
After ec325ef14f: 23%
With this commit: 26%
Regarding the other 4% of the drop, that is coming from the pixel shading.
When I hardcode powervr2 to always use shading instruction 0, performance
jumps up to 29.5%, but when I hardcode it to use shading instruction 3
performance falls a bit down to 25%. Shading instruction 3 is the most
complicated of the four and shading instruction 0 is the simplest, so I think
that proves that the shading instructions themselves are a major bottleneck.
I don't have any ideas about how to make them faster yet.
* tlcs870 - takes first interrupt (nw)
still trying to work out exactly how I want this code to be formed, but this keeps pushing the program execution forward at least
* bit of port interface guessing to pass port based shared RAM check (nw)
* (nw)
* add analog ports, fix some tlcs870 exec issues (nw)
The Burning Cavern (31/03/87) [Miguel Bragado, Recreativas.org, ArcadeHacker, David Haywood]
A Day In Space (31/03/87) [Miguel Bragado, Recreativas.org, ArcadeHacker, David Haywood]
new clones marked as WORKING
War Mission (WM 09/04/87) [Miguel Bragado, Recreativas.org, ArcadeHacker, David Haywood]
there was also a disk for Paris Dakar, but the first tracks are damaged beyond repair, and it doesn't work, so haven't added it.
I'm not sure this API is a great idea - see inline comment on 796abaf7f3
I realise it seems intuitive, but it breaks with a use-after-free (not even a
validity error) if you replace/remove the target device. Implementing it in a
way that isn't fragile and doesn't hurt the performance of -romident,
-validate and -listxml seems impossible. If it causes developer confusing and
things start breaking, back to literal tags we go for this case.
* Clean up some corner cases in layouts with repeating blocks
* Make complay.py validate many more elements and attributes
* Make complay.py easier to use for just validating a layout
* Remove redundant view from Sega VMU layout
* Make buttons visually respond to input in whousetc.lay
* Add view with LED displays as well as terminal for aim65_40 and use repeats
* Clean up some outdated "game" terminology in clifront.cpp
* Initiaise a couple of members in tap/tun network module
* Start documenting layout format
* taptun: add support for Windows
Looking for feedback only at this point, because it's the first time I've attempted any OSD stuff - be gentle.
This extends the existing taptun OSD module to support Windows through the TAP-Windows6 driver (https://github.com/OpenVPN/tap-windows6).
* TAP-Windows6 is GPLv2, however only the header file is required in MAME, and the driver itself is entirely optional.
* I've tried to minimise the size of the diff, rather than completely separate the Windows/non-Windows implementations - not sure which is preferable in this case.
* The license file has Mac(?) line-endings - unsure if they should be normalized or used verbatim.
* Uncertain about the non-Windows case (or the Windows SDL case) - existing code uses __linux__, but I'm not clear on how that works with OSX, for example?
* I can't claim this actually "works" yet, because I don't know enough to configure the tap end of it properly to get networking doing something useful, but I will get there and correct anything necessary in a subsequent real PR.
* minor fixes/improvements (nw)
* Use Unicode Windows APIs, and UTF-8 for MAME
* Deal with unterminated registry string values
* Cancel any pending I/O in destructor
