We're using cookies to ensure you get the best experience on our website. More info
Understood
1,430 Replies made

KGRAMR wrote:
This one is from Club Nintendo (Issue 47 – Year #5/No. 7)

Heh, they put “Dragon Hooper” in the caption 😀

That would be cool if they still had the source image for those screenshots in their archive, and someone could get a high-res scan of it…

I approve of this 😉

KR155E wrote:
Not sure why your padder was not on the site yet, RunnerPack, but I just added both yours and thunderstruck’s to the database.

Thanks, KR155E!

thunderstruck wrote:

I think it would be best to have the padding as part of the programmer firmware.

That’s a good idea. It would minimize the data sent down the wire (or space on the SD card). Supporting compression would be even nicer, perhaps using LZO or LZ4.

thunderstruck also wrote:

I keep confusing this but I think 16 Megabit are 2 Megabyte. 64 Megabit would be 8 Megabyte.

You’re right, of course… I divided when I should have multiplied (or vice versa).

Anyway, nice work on the padder. It’s a great way to use otherwise-wasted meeting time 🙂

  • This reply was modified 6 years, 1 month ago by RunnerPack.
  • This reply was modified 6 years, 1 month ago by RunnerPack.

Not that I have a problem with it, but I don’t see why this program was necessary. The existing padding tools (DogP’s and mine – which I made around the same time as the ROM shrinker, but doesn’t seem to be hosted on PVB) have both always supported padding to theoretically any “power-of-two” size (limited, of course, by RAM and HDD space, among other things).

I just did a test with mine (which is attached), and I was able to pad to 128MB (16Mbit) and 512MB (64Mbit) easily. I even used my shrinker to automatically reduce the 128MB to 64MB. I started with a 128KB ROM.

Run the tool by itself to see how to use it. For reference, passing a value of 27 results in a 256MB ROM (adding one will double the size, subtracting one will halve it, and so on). Passing no number (e.g. dropping the ROM on the executable) should automatically pad the ROM to the next power-of-two size.

The source is included with both programs (the shrinker is here on the site), and they should, in theory, also be cross-platform, since they use the C standard library.

Attachments:

mellott124 wrote:
The Onyx prints I do are FDM just like for the link cable parts.

Oh, I just assumed they were done on some kind of fancy SLS printer. I looked up Onyx, and it’s a nylon filament with bits of carbon fiber mixed in.

Have you tested any of your parts designed for Onyx in regular ABS or PLA, to see if they still function properly? I’m mostly concerned about little locking tabs and things not being flexible enough, or the pins being too hard to insert.

I have a little piece of black nylon I bought as a test, but I haven’t installed my all-metal hot-end, yet, so I can’t try it out. Some of these would be a good use for it, if I have enough.

mellott124 wrote:

VB controller pins are d-sub pins.

Are these just standard “solder-cup” type pins? Male and female?

Yes I’m going to post all the design files.

That’s very generous! Do you think they’ll be printable on FDM? They won’t look as good, but I only need “functional”.

1. What are you using for contacts?
2. Will the models ever be downloadable?
3. Would you sell (parts for) individual connectors?

Morintari wrote:
It was on 2d to 3d conversion

Just to clarify for those who weren’t there: It wasn’t as much about 2D-to-3D conversion as it was about the development of thunderstruck’s 2D-to-3D converter (in C#).

It was informative, though… for those who want to know how a modern Windows app is written (using MS tools).

If pulling them out slightly still doesn’t fix it, another thing to try is putting packing tape on the white side of the cable, at the connector end, to make it a bit thicker.

Also, I’ve never tried it, but maybe something could be used to carefully bend the contacts back out into the cable slot, kinda like (temporarily) repairing an old NES cart connector, back in the day 😀

furrtek wrote:
Only the VB really worked for me.

I wonder if that’s because the VB lets you adjust the IPD, and that you actually have to have the IPD set “wrong” to see it right. I also wonder if the VB could be used to “correct” your eyes to make other 3D displays work better by adjusting the IPD gradually over a period of time.

Technically speaking, it could be done on my board with just an additionnal wire and maybe a larger CPLD. Might try proposing it for people who are sure that the effect works for them.

If it ends up being cheaper than two of the standard boards, I would seriously consider getting one or two.

I believe this is normal. I have opened a LOT of VBs, and they have all looked similar (although with various amounts of exposed wire).

I think it’s just a side-effect of how they prepared the wires for insertion in the connectors. The wires inside are plated, anyway, so it shouldn’t affect anything, really.

If you’re super-paranoid about it, you could paint on some kind of conformal-coating or liquid electrical tape, but do a neat job, and make sure whatever you use cures thoroughly before you close the VB back up.

furrtek wrote:

when it clearly does…

So you tried it, right ? You tried anaglyph mode in fullscreen on a 24″ monitor or projector, standing less than 3 meters away and the depth illusion worked ?

Yes, I have used Mednafen in both anaglyph and passive polarized mode, on a 23″ monitor (ASUS VG23AH), sitting at my desk, with the monitor about 3′ away, and the depth worked perfectly. It even works with your cam footage on the YT video (although not as well since you’re at an angle to the screen). There should be no problem with the separation, since it just overlays the screens pixel-for-pixel, which is the way VB games were designed to be viewed (with the IPD set correctly).

I’m honestly curious about why it doesn’t work for some people; especially VB fans. Maybe the real reason 3D displays never catch on is because those of us it “just works” for are in the minority of the population…

Are there any options for 3D output? e.g. could one buy two of these and output the R channel of one and the G & B channels of the other to one monitor and use anaglyph glasses, or would they not sync up? Could you make a version that could talk to each other and output a half side-by-side or over/under video signal, for use with 3D-capable displays?

EDIT: I just found the video you posted. It looks like a perfectly fine anaglyph output, like you’d get from an emulator. I have no idea why it’s listed under “no, it won’t work” in the FAQ, when it clearly does…

  • This reply was modified 6 years, 2 months ago by RunnerPack.

Lester Knight wrote:
The 3D goggles are super expensive!

Ben Heckendorn made some: https://www.youtube.com/watch?v=Cv0xo0-SdFU

I have an Atari vector monitor from an Asteroids cab that I’ve been wanting to use in either a custom vector system of my own devising, or with VectorMAME.

It didn’t take me long to learn cross-eye, and it comes very easily to me now.

It gives me no eye-strain, unless the images are quite far apart, or don’t correlate very well (I like to hunt for “accidental” stereo pairs online :-)). It helps to sit farther away from the screen.

I can do wall-eye in certain situations, but it’s much harder to achieve and maintain fusion.

Very nice! I’m glad you were able to get the controller wiring figured out :thumpup:

The only thing I might change is the white T-molding. It doesn’t really go with the VB color scheme, and it’s a bit garish. Probably looks wild under a blacklight, though 🙂

Question: does having the buttons under your wrists make it hard to play any of the games? I suppose there really isn’t a better layout without making the cabinet wider, though, huh?

PS: The Game&Watch cabinet is pretty cool, too! 😉

Do you mean a constant buzzing noise, or just a single click?

If it’s the former, it’s likely a dirty sensor causing the servo driver to overload. You can clean it with clean, dry compressed air, or one of those “canned air” dusters they sell in computer stores.

I posted about it: http://www.planetvb.com/modules/newbb/viewtopic.php?post_id=28999#forumpost28999

Let us know how it turns out. If that doesn’t fix it, maybe posting a video would help diagnose it.

It would be also handy for controlling a drone or hexapod 😀

nmalinoski wrote:
How, precisely, should such a mod handle the 3D convergence? I agree that players should be able to turn off 3D for some type of 2D play. Would it be possible to make the convergence be adjustable, as it is with the 3DS?

There’s no need to adjust the convergence, because the parallax is fixed on most games. Once the pixels are made and sent to the LED displays, there’s no way to change the convergence.

What kinds of 3D modes would be supported? Color anaglyph? Over/under? Active shutter? (Admittedly, I have a poor understanding of how 3D is handled over HDMI.)

I found the 3D portion of the HDMI 1.4a spec. as a downloadable PDF, here: https://etmriwi.home.xs4all.nl/forum/hdmi_spec1.4a_3dextraction.pdf

HDMI supports most 3D formats, including over/under (half-height frames), side-by-side (half-width frames), full (packed) frames, and line-, field-, or frame-sequential. And, obviously, any HDMI display would support anaglyph…

What kind of scaling should be used?

I would go with simple nearest-neighbor. It’s the easiest, lowest-latency, and true to the original image. If it wouldn’t be too hard to implement, HQ2x or 3x would be okay, I guess.

What resolutions beyond (I assume) 720×480, 1280×720, and 1920×1080 should be supported, if any? I would hope 16:10 and 4:3 resolutions would be available.

It’s possible to make this automatic with EDID.

Since the VB runs at 50Hz, and I can imagine that wouldn’t be a problem in PAL regions (where the VB wasn’t sold), what can be done to enable compatibility on NTSC TVs that don’t support 50Hz? Would there need to be frame-rate conversion to enable compatibility on 60Hz displays? How would that look, and would it involve dropped frames?

50->60Hz would actually require inserting a frame after every fifth one.

How would the output options be configured? Simply with the proposed switches and watching the output for changes? Or would this have some sort of OSD, and, if so, would that OSD be visible on both the HDMI output and the native displays (since it’ll be fitted between the main and the display boards), or just the HDMI output?

Overlaying on the internal displays would be exceedingly difficult, and, IMHO, unnecessary. In fact, I like the switches idea better than an OSD, since they won’t need to be changed often, anyway.

I have an actual 3D display I could test this on, if anyone is going to work on it. I can even supply my own VB.

Personally, I would rather have the stand-alone version. Trying to cram everything in the original case, and having to use a mini-HDMI to get it to fit in the speaker plate, doesn’t sound like the best idea (though probably doable). Plus, with no vibrating mirrors, DogP’s experiments with over-clocking could be incorporated, and we could make a “VB Pro” to run more processor-intensive games made specifically for it.

Request regarding 3D:

Would it be possible to include a scanline interleaved mode? My PC monitor is passive 3D, which uses the same type of polarized glasses you get at the movie theater to send every other scanline to one or the other eye. I’ll be fine with anaglyph, but if it’s not too much trouble, this mode would be nice to have. Also, you should include a swap button, since the vertical position of the window will determine which eye sees which image (and some people have anaglyph glasses with red on the wrong side).