Forum Replies Created
-
Posts
-
This is the Kickstarter version, right? Please send me an email (jeremy at this domain) and we’ll get it sorted.
Totally optional. Just a bug fix involving a test mode (when rear NEXT button is held on boot) and support for 32-bit BMPs.
You can update using the Teensy Loader application and a USB micro cable.
RE Apple Remote: Some buttons on the Apple remote send two consecutive codes. Try a different button?
Brendelino: Interesting. More than likely the misinterpretation you see is because it’s receiving “repeat” commands, and it’s repeating the last signal it received. When you hold buttons down the IR remote first sends a unique code, and then a generic repeat code over and over. Game Frame just isn’t getting the new code when you first press the remote button, but it is getting the subsequent receive codes so it’s repeating an earlier command. Make sense?
I’m really sorry it’s acting flaky. Send me an email if you want to dig deeper into a solution (jeremy at this domain).
^MuYa^: Thanks for the update.
Okay, the first thing we want to rule out is IR interference. Try taking your Game Frame to another room. Just for testing sake, maybe a dimly lit room with no windows, or at least away from other light sources. See if the remote performs better.
If not, there is something else we can try but you’ll need another IR remote. Something like an old school Apple TV remote works great, but just about any remote should do.
Unplug the Game Frame. Unscrew the four screws on the rear of the Game Frame and remove the cardboard cover. Notice the two buttons on the rear circuit board: MENU and NEXT. (You can always use those if the remote completely fails, and holding down MENU functions as hitting the power button.)
While holding in the rear NEXT button, plug in the Game Frame. The screen will go through some screen & SD tests and then stop at an IR remote test. It looks like a stylized remote icon with three colored pixels inside a gray rectangle. Holding down any of the IR remote buttons should change the image on the screen until you release it.
Now, you can teach Game Frame new IR codes so that it uses a different remote. While at the remote test screen, tap the NEXT button on the rear of Game Frame again. You should see the POWER icon with a red border around the screen. The red border means “recording.” Tap a button on your other remote control that you want to act as the POWER button. The screen should change to a MENU icon. Tap a different button on your remote, and finally do the same thing when the NEXT icon appears.
It will return to the IR test screen where you can test your new remote buttons. If they work, you can press the rear MENU button to boot the Game Frame into normal operation and keep testing it out.
If you ever want to use the original Game Frame remote again, you can go through the same process or edit the REMOTE.INI file on the microSD card inside /00system. You’ll see the original codes there that you can copy and paste into place.
Let me know your results whenever you have a chance.
That’s definitely not how it should work. You do need to be generally in front of the Game Frame, but the buttons should work 100% consistently and from up to 15-20 feet away.
Can you do me a favor and shine a light at the center top of the front screen? You should see the IR receiver there through a hole in the black grid. There should also be no white vellum visible in the IR port.
I’ve attached an example photo. It’s from a prototype where the port doesn’t exactly line up with the interior but you get the idea.
Yes, with the exception of files in /00system, BMP files must have numerical names, starting with 0.bmp. Feel free to peruse the source code.
Things get a little more complicated once you start supporting CONFIG.INI though, and the methods of controlling the sequence of folders. You may not want to go that deep.
Yeah, the SdFat library doesn’t support any concept of alpha numeric sorting but I’d certainly do it on PC since it comes for free.
The default hold value is 200.
It fails for me with GFX2GF 1.5 and 1.6, and with old and new versions of FFMPEG. Something about it just freaks out FFMPEG. I brought the animation into FastStone Image Viewer, exported the frames, and recreated the animated GIF. Attached. Seems to work now.
I still think the graphic you made ground-up for 16×16 looks better. In this case, nearest neighbor is really best for shrinking pixel art that once was 16×16 and then increased.
Sorry, I can’t explain it — some weird caching issue. If I rename the file on the server I can download it correctly. Try this:
@ian.hilton: Grab the latest gfx2gf and see if that works for you:
https://www.ledseq.com/downloads/gfx2gf.zipIt now asks you if you want to use nearest neighbor on launch, and you have to answer Y or N. It will also ask if you want to crop if your source is not square.
NOTE: I had to update my copy of FFMPEG (dated 2013) for nearest neighbor to look correct. There were subtle inaccuracies in my old copy.
Yeah, when I get home tonight I’ll provide a fix. You want to resize using nearest neighbor filtering.
