* Remove broken scanline uniform from post_pass
* Add 3D LUT to HLSL
* Allow individual LUTs for screen and UI
* WIP: Port 3D LUT to BGFX
* Finish porting LUT to BGFX
* Add individual phosphor color conversion for HLSL
new file: hlsl/chroma.fx
Shader for converting xyY3 to sRGB
modified: hlsl/phosphor.fx
Minor changes to emphasize idea that phosphors are color
agnostic
modified: hlsl/post.fx
Conversion from signal RGB to xyY3
modified: src/osd/modules/render/d3d/d3dhlsl.cpp
modified: src/osd/modules/render/d3d/d3dhlsl.h
modified: src/osd/windows/winmain.cpp
modified: src/osd/windows/winmain.h
* Add phosphor examples and update presets
* Port phosphor color shaders to BGFX
* Fix missing newlines at EOF
On branch scanline
Changes to be committed:
modified: hlsl/post.fx
Remove scanline effect
new file: hlsl/scanline.fx
Separate scanline effect into its own shader
modified: src/osd/modules/render/d3d/d3dhlsl.cpp
Add scanline effect
modified: src/osd/modules/render/d3d/d3dhlsl.h
Add scanline effect
* interpro: notworking -> networking
These changes combine to make InterPro networking work on Windows with the TAP-Windows6 driver.
* osdnet: add a receive delay (1 frame) after transmit to avoid a time-travel problem
* taptun: pad short Ethernet frames and append FCS (Windows-only until Linux taptun behaviour is verified)
* clipper: fix bugs in carry flag handling, prefer sign bit for tests
* i82586: fix transmit bug, handle reset
* networking: delayed transmit/receive
A second attempt to fix networking on InterPro systems, by introducing somewhat realistic delays into network transmit and receive paths. This version works by adding functions to device_network_interface which enable a device to be informed when the transmit or receive completes. The delay is only crudely approximated based on the specified bandwidth and the number of bytes being transmitted, but it should be good enough in practice. Existing drivers should not be impacted by these changes; overriding the new functions (and no longer overriding recv_cb) is necessary to obtain the new behaviour.
Changes from the previous commit:
* i82586: improve interrupt handling, implement delayed transmit/receive behaviour
* dinetwork: add transmit/receive delay timers, handlers and logic
* osdnet: remove receive delay, add the ability to start the receive timer
* 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
* Eliminates the need for the horizontal/vertical/LCD/SVG layout files
* Screens can now have orientation and physical aspect ratio specified
* RASTER/VECTOR defaults to 4:3, LCD/SVG defaults to square pixels at config time
* System orientation is applied on top of screen orientation
Automatically generated single-screen views and orientation flags in XML
output now work correctly for systems with multiple screens in different
geometries/orientations, e.g. housemnq, rocnms, stepstag, or netmerc.
The "core rotation options" only interact with system orientation.
Allowing multi-screen systems to work well with one monitor per emulated
screen is a complex topic. System orientation also affects the GFX
viewer while screen orientation doesn't. The orientation displayed in
the system selection menu is from the system orientation.
Let me know if I've broken any systems or use cases.
Also, add save state support for std::array/C array nested to any depth.
Without it you have to wait until the socket is moved
out of the TIME_WAIT state, which can take quite a while.
This is pretty anoying when using mame with serial ports
forwarded via TCP.
Signed-off-by: Sven Schnelle <svens@stackframe.org>
* Fixed building using system utf8proc
* Fixed building using system portaudio
* Allow using system-wide asio headers (1.11.0 or higher required).
* Allow using system-wide glm headers
* Allow using system-wide rapidjson headers
This shader uses the equation described by R. Keys in the paper 'Cubic Convolution Interpolation for Digital Image Processing' which is, in this case, the same as a Catmull-Rom spline. This produces a sharper upscaled image than bilinear filtering.
The new shader is selected by setting gl_glsl_filter to 2. Consequently, gl_glsl_filter is now treated as an int rather than a boolean.
Also fixed a variable name problem in the code guarded by GLSL_SOURCE_ON_DISK.
1. Off-by-one pixel coordinates
2. Sampling of wrong pixels at some non-integer stretch factors
First was noticed while comparing screenshots of the software and opengl w/glsl renderers (opengl output was shifted up and to the right). Fixed by subtracting a 1/2 pixel from the texture coordinates when calculating the bottom left pixel to use for interpolation.
Second was apparent when running pac-man fullscreen on a 1920x1080 screen and allowing non-integer stretching. Manifested as irregular horizontal 'steps' in the output. Fixed by sampling from the center of all pixels which should avoid any funny business in regards to pixel coordinate rounding.
please people, remember to keep source UTF-8 and if you're committing on behalf of others, clean up indents to meet MAME conventions
anyone can run srcclean over a submission and see what will get hit
- reset scheduler savestate to what it was for years before rewind
-- changing saved variables should be done after thorough testing. right now, adding some vars breaks some machines, adding other vars breaks others
- switch to megabyte-wise capacity
-- savestate size greatly differs between machines, relying on state count is unstable
- switch to internal indexing
-- no longer depends on inaccurate machine time
- rewind accelerator key in debugger (Ctrl+F11)
- report capacity hit (once), with some useful info
- make error reports saner
- mention rewind and rewind_capacity in the docs
The DirectInput Z-axis trigger merger seems more widely considered a bug than a feature, and probably should not be the default MAME behavior.
This reverts commit 80a64430a3.
This crash (discovered by Wizz) had the following symptoms:
1. Start MAME
2. Choose "Configure Machine"
3. Choose "Video Options"
CRASH
This was the result of the options editor not having a fully formed list of options where it was expecting one. The fix is to change the declaration of emu_options to one that have full OSD options (it is possible that SDLMAME needs something slightly different)
I created a osd_setup_osd_specific_emu_options(emu_options &) function that given an emu_options, will slap on system specific options. I see this as only marginally less gross, and I have zero opinion on whether this should be changed to return an emu_options (rather than have a reference parameter), be a static method on emu_options, or what have you.
Specifically, this creates a call osd_get_command_line() that returns UTF-8 command line arguments as std::vector<std::string>. On non-Windows platforms, this does nothing more than build the vector. On Windows, this invokes GetCommandLineW() and CommandLineToArgvW(). This also attempts to unwind usage of wmain()/_tmain() on Windows, which is not standard.
Related to this, this fixes a bug in Imgtool; specifically, non-7 bit ASCII was not being handled correctly in Windows.
This is really an admission that the way that Windows handles Unicode and command line arguments sucks, and it is my belief that having a wmain() or _tmain() declaration specific for Windows is a worse solution. C'est la vie.
I'm very open to the idea that src/osd/osdcore.[cpp|h] is not the best place to do this. Let me know if I should move it.
