In real life, I do audio/video design and support for a university. When visibility is poor in a room, the intuitive solution--and what people typically request--is to simply add more, smaller displays throughout the room. Unfortunately, due to the way perspective works, this solution tends to have little benefit despite significant increased cost. However, I've never seen any breakdown of exactly why this solution is so ineffective, and I didn't really have anywhere else to publish my thoughts on it, so here we go...
To quantify the effects of this intervention, we'll construct a hypothetical room using standard equipment and 15 representative seats/students (most of our classrooms have closer to 40 students, but these results can be extrapolated). Most of our projection screens are approximately 110-120 inches diagonal, while most of our repeater displays are between 55 and 70 inches, depending on age and various constraints (space, cost, etc). For simplicity's sake, we can say that repeater displays are usually about half the size of the main display, give or take, and we would usually place it roughly halfway between the largest display and our furthest viewers:
We install these repeater displays with the hope of improving the visibility for students in the back row, but as we see in the following diagram, the students in the back row have no visibility benefit when looking at the repeater display (that is, it appears no larger or more readable for them than the main display):
Moreover, for the students at the sides of the back row, the viewing angle is slightly worse when compared with the projection screen, making it no better and arguably worse for them to look at the repeater display instead of the main display.
So, who actually benefits from this repeater display? Well, the student in the middle of the second row has a bit better view of it as compared with the projection screen, but really not that much better; maybe 25-30% improvement, tops:
The students one seat to either side may have a slightly better view, too, though the viewing angle is becoming quite shallow for them and could have detrimental effects, depending on the display, while the students farther out have no chance of a better view, since the viewing angle is unusably tight:
So, that leaves us with definitely one, possibly up to three students out of our 15 who actually reap a benefit from the repeater display, and the magnitude of that improvement is not particularly large.
Furthermore, these numbers get even worse if you mount the repeater display at an angle on (or even worse, flat against) the wall, as is typical (i.e., as opposed to the hypothetical example above, where it is floating in the optimal spot for visibility; in reality, we have ADA clearances and vertical viewing angles to contend with), with only one student--maybe two if we're lucky--gaining any benefit:
So, unless your repeater displays are very large or you have the money and the inclination to install many of them throughout the room (which brings its own issues of visual confusion/distraction), it's probably not going to bring you much value.
At this point, you may be asking "so, what's the solution, then?" Unfortunately, I don't have a good answer to that.
There are some software+BYOD solutions, like TopHat (only really useful for slide-based presentations) or Huddle Hub One (bandwidth-hungry; only supports 75 participants, making it ineffective for auditoriums) or even simply Zoom (this can quickly turn into a feedback mess with many devices in the same room), but instructors are often distrustful of anything that has students pulling their own devices out in class, let alone staring at them the whole time.
Separating students into groups/pods with a dedicated large-ish display for each group seems to work pretty well, and this configuration lends itself well to active learning applications, but it's also expensive, requires complex AV and reduces the maximum student density of a room as compared with traditional rowed seating by about 25%.
Tuesday, December 3, 2019
Monday, October 14, 2019
Adding Genesis/MD to MC-Cthulhu
So, about a year ago I had been working on a plan for a universal arcade stick with support for a bunch of retro consoles plus PC and PS3 (via an MC-Cthulhu board), Sega Genesis / Mega Drive via a padhacked 6-button pad from eBay and Xbox 360 via a leftover control board from one of my Mad Catz sticks.
360 and Cthulhu were supposed to share the same USB-over-RJ45 with a toggle switch to go between them and Genesis/MD was going to have a little pigtail that could hook up to an extension cable when needed. When I got the 360 board wired into the Cthulhu, though, everything went haywire with phantom button presses and all sorts of nonsense. This got me pretty bummed out about the whole project and I put it on ice.
However, there's been a lot of interest over on my MC-Cthulhu pinout page from people trying to integrate Genesis/MD input with the Cthulhu board since then, so I figured I'd better at least finish up that part and report my experience, which I finally did last night.
I won't go into a ton of detail in this post, as the "how" bits have already been covered in my other posts (linked above), so instead I'll focus on what worked and what didn't.
First off, I had originally tried swapping between the Cthulhu and the 360 board (before I abandoned it) using a momentary DPDT switch like you find on a guitar foot pedal. I wanted something tough that was hard to press, so it wouldn't trigger accidentally mid-game. This ended up being the wrong tool for the job, though, as it only switched to the other board while the switch was actually held down. So, I switched over to an ON/ON DPDT 2-position switch. I'm pretty confident this would have worked as intended had my 360 board wanted to cooperate.
The way the switch is supposed to work is: from your USB, you have 4 lines--GND, 5v, Data+ and Data-. The 5v and GND are wired onto the extra solder points on the Cthulhu (that is, the 3 sets of thru-holes where you solder on the RJ45 lines) and the Data+/- lines are wired onto the switch, with 2 coming from the Cthulhu and 2 coming the 360 board's USB header. The output lines from the switch (typically the 2 center leads) connect to the RJ45 lines. In normal use, both boards will be powered (whenever you do a multi-board solution, all boards need their voltage and ground lines connected together at all times) but the one that actually sends/receives data will be controlled by the toggle switch.
Once I got the boards wired together and noticed the strange behavior, I did a lot of troubleshooting and determined that just having the 5v and GND lines linked up was enough to break everything, so that was that. I may revisit it another time with a different 360 board, but for now I decided to just drop 360 support altogether. With the 360 board out of the picture, I didn't need the switch anymore, but I just left it on there anyway rather than having a gaping hole in the side of my stick for dust and liquids to sneak in. Plus, now I have a little fidget thingie I can fiddle with between matches.
Moving on to the Genesis/MD pad, there wasn't really anything unexpected. I soldered the padhack's button lines to the secondary soldering points on the Cthulhu (the 2 rows of thru-holes labeled A-H and 1-9) as outlined at the end of my pinout post and it all works great. The crummy pad I used has a very short cable, which made it super-easy to cram into my already-crowded Mad Catz SE chassis.
You'll notice I did a little loop around a screw post before sending the connector out the back side. That's to prevent the wire from tugging on the pad PCB and ripping out my solder joints. I also covered the entire PCB and solder points with electrical tape to prevent any stray grounding/bridging.
You might also notice that I removed the 360 home/LED/turbo panel with a 3D-printed blank, which just barely fits a 24 mm button to serve as the Cthulhu's HOME button.
While I was at it, I took a tip from u/gongfuren on reddit's r/fightsticks board and swapped out some plungers on my short-stem IL competition buttons for a cool "bullseye" look and also removed the springs from the buttons, which gives them a much lighter touch. They're still a lot stiffer than Sanwa buttons (which is good, IMO, as I like to rest my hands on the buttons) but they feel significantly more responsive than with the spring, and they still keep their satisfying cherry click.
Here's the final result:
And here's my other IL stick that I swapped plungers with:
360 and Cthulhu were supposed to share the same USB-over-RJ45 with a toggle switch to go between them and Genesis/MD was going to have a little pigtail that could hook up to an extension cable when needed. When I got the 360 board wired into the Cthulhu, though, everything went haywire with phantom button presses and all sorts of nonsense. This got me pretty bummed out about the whole project and I put it on ice.
However, there's been a lot of interest over on my MC-Cthulhu pinout page from people trying to integrate Genesis/MD input with the Cthulhu board since then, so I figured I'd better at least finish up that part and report my experience, which I finally did last night.
I won't go into a ton of detail in this post, as the "how" bits have already been covered in my other posts (linked above), so instead I'll focus on what worked and what didn't.
First off, I had originally tried swapping between the Cthulhu and the 360 board (before I abandoned it) using a momentary DPDT switch like you find on a guitar foot pedal. I wanted something tough that was hard to press, so it wouldn't trigger accidentally mid-game. This ended up being the wrong tool for the job, though, as it only switched to the other board while the switch was actually held down. So, I switched over to an ON/ON DPDT 2-position switch. I'm pretty confident this would have worked as intended had my 360 board wanted to cooperate.
The way the switch is supposed to work is: from your USB, you have 4 lines--GND, 5v, Data+ and Data-. The 5v and GND are wired onto the extra solder points on the Cthulhu (that is, the 3 sets of thru-holes where you solder on the RJ45 lines) and the Data+/- lines are wired onto the switch, with 2 coming from the Cthulhu and 2 coming the 360 board's USB header. The output lines from the switch (typically the 2 center leads) connect to the RJ45 lines. In normal use, both boards will be powered (whenever you do a multi-board solution, all boards need their voltage and ground lines connected together at all times) but the one that actually sends/receives data will be controlled by the toggle switch.
Once I got the boards wired together and noticed the strange behavior, I did a lot of troubleshooting and determined that just having the 5v and GND lines linked up was enough to break everything, so that was that. I may revisit it another time with a different 360 board, but for now I decided to just drop 360 support altogether. With the 360 board out of the picture, I didn't need the switch anymore, but I just left it on there anyway rather than having a gaping hole in the side of my stick for dust and liquids to sneak in. Plus, now I have a little fidget thingie I can fiddle with between matches.
sorry for blurry pic :( |
Moving on to the Genesis/MD pad, there wasn't really anything unexpected. I soldered the padhack's button lines to the secondary soldering points on the Cthulhu (the 2 rows of thru-holes labeled A-H and 1-9) as outlined at the end of my pinout post and it all works great. The crummy pad I used has a very short cable, which made it super-easy to cram into my already-crowded Mad Catz SE chassis.
Yes, the wiring is a mess. Good thing nobody ever sees it but me (and now you) |
The pigtail. It's pretty unobtrusive without the extension cable attached |
While I was at it, I took a tip from u/gongfuren on reddit's r/fightsticks board and swapped out some plungers on my short-stem IL competition buttons for a cool "bullseye" look and also removed the springs from the buttons, which gives them a much lighter touch. They're still a lot stiffer than Sanwa buttons (which is good, IMO, as I like to rest my hands on the buttons) but they feel significantly more responsive than with the spring, and they still keep their satisfying cherry click.
Here's the final result:
And here's my other IL stick that I swapped plungers with:
Thursday, January 31, 2019
RetroArch Wii U Slang Shaders
RetroArch on Wii U has supported slang shaders for a long time, but it's really hard to find them online. I found a pack of them, though, and decided to rehost it here. Hopefully, more people will get to enjoy them now.
EDIT (11/1/2019): To use these, copy them to your SD card and then go to settings > directory in RetroArch and set your 'video shaders' directory to that location.
Unfortunately, the GPU on the Wii U isn't particularly powerful, so relatively few run full speed, and there seem to be some weird scaling issues going on, leading to slightly uneven scanlines at times and broken xBR/Hqx effects. LUTs are also wonky, apparently, as many of the LUT-based mask effects are just scaled up to fit the screen instead of tiled across it.
EDIT: I thought the scaling issues might have been caused by it rendering at 720p and then upscaling to 1080p, so I changed the Wii U's output res to 720p but it still has a bunch of ugly issues. Mask effects are completely terrible. Currently, I'm just using misc/interlacing at a 2x scale to get even scanlines.
EDIT (11/1/2019): To use these, copy them to your SD card and then go to settings > directory in RetroArch and set your 'video shaders' directory to that location.
Unfortunately, the GPU on the Wii U isn't particularly powerful, so relatively few run full speed, and there seem to be some weird scaling issues going on, leading to slightly uneven scanlines at times and broken xBR/Hqx effects. LUTs are also wonky, apparently, as many of the LUT-based mask effects are just scaled up to fit the screen instead of tiled across it.
EDIT: I thought the scaling issues might have been caused by it rendering at 720p and then upscaling to 1080p, so I changed the Wii U's output res to 720p but it still has a bunch of ugly issues. Mask effects are completely terrible. Currently, I'm just using misc/interlacing at a 2x scale to get even scanlines.