Recent Posts

Right now probably the most direct route (other than those horrible cables) is to build a gbs control and then get a vga 2 component cable for the output.  I recently did that on a crt I just acquired and it works great.

Hi vicosku,

I can't understand that you have one refresh on Windows and a different refresh on your monitor's OSD. Maybe my knowledge is outdated with regards to newer monitors. Only one of those refresh is real, and it looks like it's 240 Hz. Is there any way you can set both to 180 Hz?

Create a custom resolution of 1920x1079 that only has 180Hz.

Force GroovyMAME to use that resolution.  Problem solved, it will use only that refresh rate instead of switching to the wrong refresh rate.  Since that custom resolution only has one refresh rate (180Hz).

Some News, RetroArch Now Also Supports 180Hz and 240Hz BFI

I've also been encouraging other emulators to implement 180Hz+ and 240Hz+ BFI on a more wider scale.

Github Tracking Item about BFIv2:
https://github.com/libretro/RetroArch/issues/10754

Accepted Github Pull Request With Comments:
https://github.com/libretro/RetroArch/pull/11342

It doesn't yet support the comma-separated BFI feature or the BFI profiles yet, however, it is now in the github master / latest development builds.

You're assuming BFI + frame delay which is not possible yet (don't think it'll ever be).

It should be; though only small amounts of framedelay is useful -- something less than one destination refreshtime's frame delay for the first frame of the BFI cycle.

The higher the Hz, the less useful framedelay becomes.  You could still do 2ms framedelay if your emulator module is capable of rendering a frame in 1ms, plus a 1ms safety margin, saving you about 2ms of input lag.   That's much less savings than for 60Hz.  As soon as you hit 1000Hz, your random halftime to next VSYNC is only 0.5 milliseconds!  So might as well ignore framedelay for simplicity, because using 240Hz + waitable swapchains already guarantees you're no more than 1/240sec lag.

Moving Present() / glxxSwapBuffers() into a wrapper that hands it off to a separate thread responsible for precision present timing

However, if Calamity wishes to architecture the separate-thread technique (to allow software based VSYNC implementations), and pretend the thread (doing its own BFI independently) is just a hardware based VSYNC, then the existing framedelay would work with it with no modifications.   

Read about Separate Frame Presenter Thread which replaces your Present() with a present-wrapper that manages it in a separate thread.   This is also useful for beam racing & electron gun emulators.   This allows you to roll-your-own software based sync technologies and/or virtualized displays or emulating VSYNC ON with VSYNC OFF, and other weird sync technologies in software instead of graphics drivers & display.   

Then you can just continue to use your existing frame delay logic.   And it provides a good future path for beam racing improvements, and CRT electron gun emulators (Temporal HLSL, BFIv3) via brute Hz too.

Advantages of wrapper that hands it off to a separate thread for timing responsibilities
- Reduces BFI flickers
- Can emulate blocking behaviour of waitable swapchains / VSYNC ON in the wrapper (even presenter thread continues executing its own precision) for backwards compatibility, with all sync technologies (VSYNC OFF, G-SYNC, etc)
- Improves compatibility of BFI with G-SYNC / Windows DWM compositor
- Improves frameslice beam racing
- Makes it easier to implement CRT electron gun emulators
- Makes it easier to implement your own custom software-based sync technologies
- Makes certain modes easier to be compatible with other emulator features (e.g. input delay).

Wrapper and threads would have its own independent internal delays / internal busywaits / wait-on-threads, as applicable, where appropriate. Where wrapper emulates the blocking behaviour of VSYNC ON and the thread does its own precision timing for the actual hardware presents (whether be G-SYNC, or for BFI, or for triple buffering like Fast Sync, etc).   And for beamraced workflows, you can have a separate raster for presenting frameslices, or even single scanlines, with its own return after busywait-to-raster -- e.g. PresentScanLine() while passing whole buffer and just letting the wrapper decide frameslice size and when to pass those to the thread.  Infinite granularity flexibility!

Wrapper essentially behaves as a software based VSYNC ON (for full-frame workflows), and/or rasterwaiter (for beamrace workflows).  So calling the wrapper feels just like calling frame present directly on a VSYNC ON system, regardless of what special processing you're doing (BFI, high Hz, low Hz, beam racing, CRT electron gun emulator).

Since the beginning of the age of 1UP arcade machines, Raspberry Pi's with power supplies you wouldn't want to charge your phone with and "mainstream" appeal for arcade related items, I can no longer assume that the end user is technically savvy.  So without knowing the capabilities of the user, it's often wisest nowadays to err on the side of the neophyte.

So, everyone before the 1UP machines you do consider savvy?

Opps double post...Sorry😇

The jointer is for shaping and making router jigs mostly, but also shaving a sliver off here and there, making for an almost perfect fit, (Ply is hard on blades however) I use my little 4"jointer all the time for such tasks,
And is arguably one my most favorite machines in the shop ...The bracing (generally 3/4") Can be cut with a saw yes, but a planer won't leave any mill marks, nice smooth and perfectly sized, But again is used generally for making jigs quickly and accurately.

Why would you need a jointer and planer for working with plywood?

how do I get a vid on here?

Most vids are going to be too big to upload here so your best bet is to upload it to a video site like YouTube, Vimeo, Rumble, etc.

The forum software will auto-embed YouTube videos -- just put the URL without tags in your post.

If you post this:

Code: [Select]

https://www.youtube.com/watch?v=0_aIkkObZWM
It will embed like this:


If you don't have an account at one of the video sharing sites, you can upload to a filesharing site like Mega, Dropbox, Google Drive, etc.
- https://www.sendspace.com/ and https://www.zippyshare.com/ are filesharing sites that don't require an account, but files are only available for a limited time.
- The downside to this approach is that people will have to download the video to view it.


Scott

I know lots of us have nice CRTs with component connections. I’ve been thinking about doing the RBG mod but at the end of the day I don’t think there’s that big of a difference between RGBAnd component. The question is are these cheap ones that you can buy worth it for your home video game collection?

Mostly looking for cheap little plugged in play for testing.

https://www.ebay.com/itm/283932661270

Edit:This looks cool, But not Component Out. Maybe I can merge it with the item I just bought above.

US $39.43 | EUR Mini SCART Distributor Converter Video 6 input 1 output Auto  Adapter Automatic switcher RCA SVHS AV TV Audio Divide
https://a.aliexpress.com/_mrM00D9

If you also have access to a jointer, planer, and or a spindle sander, it will make your life so much easier...As far as construction goes that is actually a good choice of cab if it is your first build, as it is built with simplistic function and high volume production in mind...It is so easy to go all 100% legit original or nothing, but you do have options that don't make it so old school, but modernized a bit...Ms pac for example, you have the option of stenciling or stickers as stencil was original, two bit side art, over blue makes for a fast clean modern build, little pink T moulding and that if done right is a beautiful machine.