Recent Posts

Almost ready for testing.  Just wiring up a jamma interface temporarily for testing it.  Should know soon if it works.

Love it that you are committed, balls 'n all. I'd at least test the TV with something known first, like a TPG or PC CRTEMU setup!

But hey, sometimes I take that dive-in approach too and everything works out in the end

In letsgo jungle outputs, gun recoil or ctm recoil are activated in demo when a gun is fired and the room reacts the same as in demo. Is there a way to stop it in demo mode or a patch?

Moving between RGB modding TVs and cutting timber always takes me a little internal adjustment

BTW, how is the mod going?

Almost ready for testing.  Just wiring up a jamma interface temporarily for testing it.  Should know soon if it works.

Moving between RGB modding TVs and cutting timber always takes me a little internal adjustment

BTW, how is the mod going?

great job,i wonder if rgb moded tvs could also have a mod to add pots for vertical and horizontal size

That would be a very handy mod!!

Spent an hour or two cutting some timber...

 

Holy ---steaming pile of meadow muffin--- Inoki san.   Japan much be crying an ocean.   Kick ass politician and master of the strong style.   RIP.

You are in the need not only for a software sending rumble informations and a driver to deliver current to the motor, but also a hardware capable of receiving those rumble info and actuating the driver

It's all theory, assumes perfection in the function of all components and ignores how things actually work in practice.  If a camera can pick up subtle shade and color changes with pixel precision, then the border of the standard system wouldn't need to be a bright color.  But it does.   Cameras also get very noisy in low light conditions.  Noise means inaccuracy. In fact, the troubleshooting wiki calls out a dim screen as a possible cause for jitter.  In a perfect world, the camera should be able to pick up the subtle illumination of the leaked backlight in the black areas to define the screen.  But this is not a perfect world.

And another thing standing in the way is that only LCD's use this type of polarization.  What about OLED, CRT and Plasma screens?  This suggestion simply adds more hardware and complexity, and hobbles display compatibility while IMHO, delivering zero gain.

Well I agree there. I didn't say it was possible, I was just trying to explain his idea. The amount of time needed to process the images would make this unfeasible for its cost. Frankly if we a back to adding IR borders, well we may as well stick with Gun4ir. Personally I've found it to be incredibly accurate no matter where I stand. The sight on my gun always lines up. Jaybee has created quite an impressive system.

Interesting!

Now I'm super curious about the history of LEDBlinky!

But this is all good information to know. Yeah, I'll send what I have when I'm finished. The only thing I considered, which I haven't done yet, was removing games from controls.ini and colors.ini that I'm omitting from my build (i.e. Mahjong games, non-english games, non-functional games, etc) simply to speed up the loading of everything. All that seems like a lot of data for LEDBlinky to parse. But for now I haven't done that, and if I share the stuff back with you, I'll keep what's in there and just update the games that A) don't have entries, or B) the lighting is clearly wrong / incomplete.

Basing some of the lighting of the buttons off of pictures from online sources or manuals so far. For the games that don't have that information, I usually just stick with white or red buttons, or base it off of game colors (i.e. Pacman might have yellow buttons or whatever if I couldn't find pictures of cabinets online).

Anyways, thanks for the explanations! That helps a lot!

Now if I could just figure out what the dang HyperSpin button does within HyperSpin. Their documentation on that function is lacking.