I took a C++ version of Heboris C7-EX, modified/upgraded it, ported it to C, and have gotten it working on the three big desktop platforms, Windows, Mac, and Linux. And the Mac version is Universal Binary for Intel and Apple Silicon. Maybe it's not that exciting for Windows users though, old versions still work fine on Windows. But as far as I can tell, this is the only version native for current Macs and macOS. Though the Windows version is 64-bit, which is kind of neat. An interesting side effect of it being so portable is that it works fine unchanged on many odd Linux systems, so long as everything needed is available. I find it to perform very well on my Raspberry Pi 3, running the latest Raspberry Pi OS. I've not changed the "content" of the game (modes, gameplay, etc.), and never plan to. The "content" code is really badly designed, and a complete headache to work with. I'm just doing what's necessary to get the old code working on today's systems. Downloads GitHub page (for the source code)
Is it possible to compile Heboris for RaspberryPi with GPIO input, as done by Report for Texmaster 2009?
Theoretically, sure, all the source code is there, so the support could be added; though it's not merely a matter of rebuilding it, the support has to be added with new code. But I don't possess any means to develop that myself, I only have USB keyboards/game controllers, no GPIO hardware. I don't really like the idea of trying to add the support and being unable to test it, then you find it doesn't work, I try again, etc.; that just sounds annoying and counter-productive.
Oh, after a bit of research it seems I could test if GPIO support is working, by just shorting GPIO pins with a wire, so I don't have to get anything new. So I'll add the support. But I think the support should be available only if enabled at build time, most people probably don't need it, and of course many systems can't use it.
This is very good news. Having two sacred monsters like Texmaster and Heboris on a RaspberryPI with no input lag is a dream. It is essential to use the pin scheme set by Report.
Been messing with this. some of the files from the original YGS2k port were missing (some of the mission and tomoyo mode stages) were missing. The next release will have these. BTW, anyone manage an Item Mode GM yet? It's actually quite challenging, because of the new items. Some items are really bad, and must be avoided by collecting the following item instead. Items that are GOOD include Fever Reflect Copy Field (no effect, small time penalty) Exchange Field (no effect, small time penalty) Double (essentially no effect, and no time penalty) Hold Lock (A very minor inconvenience) Reverse Up/Down (also a very minor inconvenience) Transform (you can use IRS to avoid the transform effect, and if you need to 180 the piece, put it into hold instead) Boost Fire, when you are before 500 (slow 20g, which you should be able to handle if you can GM without Item Mode) Delete Even/Top/Bottom (these help you fix your stack, with a minor time and score penalty) Free Fall, when your stack is already fixed Color Block (a very minor inconvenience) Move left/right (usually improves your stack) The following items can be taken, but require special handling Grandmother Block (hides other item blocks, which can interfere with avoiding the ones you NEED to avoid) Mirror Block (can cause some trouble, but it's not THAT bad) Magnet block, but only at VERY low gravity. (zero lock delay is VERY rude!) Remote Control (this makes certain placements very difficult, but doesn't interfere with others very little effct once you get to 20G) Death Block (likely to mess things up unless you set up your stack to handle it) X-Ray (you can play through it, but it tends to be more inconvenient than color block) Time Stop (5 second delay increases the pressure) Dark Block (even worse than x-ray, but you can still play through it) Laser (you can usually move it to column 1 or 10. if you fail to do that it can cause issues) Shuffle (as long as your stack is flat (not a pyramid) it's manageable) Free Fall,when your field really needs it. it gives you garbage equal to the number of lines it cleared, and it's usually overstacked. But it's not the worst All Clear. it can fix anything, but the time penalty is significant, so you may not want to collect it. But will recover nicely form Nega field, 180 field or shot gun. 16t weight. This can take out a hard block, but unless you stack is low, it hurts your score significantly. The following items are very difficult to handle, but not impossible. Take only if the other option is something even worse Roll Roll. At low gravity you need to slow down a lot to deal with it. At high gravity it can be brutal. Hide Next. In theory you can play through this. In practice, you will probably have to slow down a lot. Boost Fire AFTER level 500. Lock delay is halved. This require a lot of effort to handle. And this is with G1 Reverse Left/Right (this is much more annoying than reverse up/down is!) Hard block (tends to mess up your stack in a way that takes time to fix) Fake Next (this seriously messes with your head even more than Hide Next, and takes a lot of practice to play through) Random (can give you something worse, only ever take if the alternative is one of them) 180 field (with a flat stack, not so bad. with one not so flat, really hard to deal with) The following items will usually REALLY ruin your day, and you usually need to leave them on field. Miss (reflect and fever won't help you here, and it eats 30 seconds or more off of your timer! Also it WILL force you to deal with another item. this can end your run) Nega field. (The removal of so many cells without gaining levels or score tends to be very toxic to your run. only mangeable with a low stack) Magnet block, at high gravity. two forced misdrops in the center is a killer, and usually messes up your stack beyond rapid repair, when it doesn't kill you outright. Shot Gun. With a high stack, this ruins you run singlehandedly. Requires free fall, move left, or move right to fix. Only take if you can SEE one of those in your next queue, AND can't put off taking it long enough. Or if your stack is VERY low. Rotate Lock. While it's possible to get very lucky, more often than not, this ruins your stack to the point that it takes too long to fix, and will cause you to fail the next checkpoint all by itself. Try G1 first, and good luck making GM
Alright, the latest code in my repo now has initial GPIO input support, as you requested. It's not the final version though, it's entirely hard-set to the Texmaster-based pin layout, only for Raspberry Pi-compatible GPIO setups; I want to add full in-game configuration of GPIO pins, not just for setting the layout you want on Raspberry Pi systems, but any Linux system with GPIO. Unlike Texmaster, my GPIO support doesn't require you run the game as root. It uses a modern library for GPIO access, libgpiod; this page was a great resource for figuring out how to use libgpiod. Check the readme for how to build with GPIO support, it's not included by default. The readme shows the full pin layout, including an addition beyond Texmaster, for the Heboris "give up" button.
From what I can tell, Minibian is terribly outdated and no longer maintained, and likely is too old to be usable. I use Raspberry Pi OS Lite, as I'm fine doing everything at command line, not needing any GUI apps just to get Heboris working. I'd always recommend using currently-supported operating systems. Raspberry Pi OS might be heavier than Minibian, but the Lite version isn't excessively heavy. The "bloat" doesn't make it slower, it just makes the install size bigger. If you launch the game right from the terminal, with no desktop running, you don't have much of anything slowing down the system while the game is running. Also, the Raspberry Pi 3 models have 4 CPU cores, and Heboris mostly runs on one core, so in all likelihood Heboris' gameplay/graphics would get one core to itself if ran from terminal/no GUI, but audio might run in a separate thread unavoidably.
Been working on this. I've made some fixes in my fork. 1) gravity behavior for 1G+ is fixed. original lets you jump gaps you had no business jumping at awkward g. 2) CW and 180 rotation removed from Sega Old Style. 3) levelup behavior for Old Style fixed. was one behind. (still not very accurate for fake G 4) new speed table specifically for Sega Old-Style. As close as you can get to the real thing using 60 based gravity. Replays from 1.0.0 should still play back without the fixes applied. https://github.com/zaphod77/HeborisC7EX-SDL2 Not sure how much of this will be implemented in main.
I'd recommend trying to run games from the command line, with no desktop running. It might improve performance/reduce latency, but maybe performance is the same when you run games fullscreen. Likely running in a window or fullscreen desktop has poorer performance than exclusive fullscreen. Texmaster only supports exclusive fullscreen, but my Heboris port does support fullscreen desktop, which is convenient if you're running the game on a regular PC with a desktop. Also from what I can tell vsync has little to no extra latency on Raspberry Pi 3 in fullscreen, which means you can have no tearing without the tradeoff of more latency. When you run from command line, there's no "fat" around you don't need just for the game, like the desktop/X11.
You didn't say how you installed SDL; running these commands at the command line is how I recommend to do it in Raspberry Pi OS: Code: sudo apt-get update sudo apt-get upgrade sudo apt-get install gcc cmake libsdl2-dev libsdl2-mixer-dev libsdl2-image-dev libphysfs-dev libgpiod-dev Those commands will install everything required of Heboris with GPIO input supported, not just SDL. On my Linux PC, I don't have GPIO available, so I don't need to install libgpiod and enable it for builds. As a best practice, I always do an apt-get update and then upgrade every time I start up my Raspberry Pi, then rebuild my software when packages my software uses are upgraded. An upgrade sometimes requires a restart, of course, such as for Linux kernel/driver upgrades. But upgrades of only the tools and packages Heboris requires don't require a restart, like upgrades of SDL. The key thing is to use the "-dev" packages for libraries, that's just how things work on Debian-based Linux distributions, Raspberry Pi OS being one such distribution. The library packages lacking the "-dev" postfix don't include what's required for building software, only what's required for running software that uses the libraries, like a game you've installed via apt-get.
Good news and bad news. After the upgrade of the packages that you have indicated Heboris has been executed and it works. Unfortunately, however, it works for about thirty seconds and then crashes! Soon I will try to repeat the procedure after installing the Raspi Os Lite system (Legacy).
I just tested the latest code on my Raspberry Pi 3 running the latest non-legacy Raspberry Pi OS Lite, I was able to complete two games up to level ~900 without issue. So it could be a case of the desktop eating up too much memory, and there being no memory contention without a desktop. The default video settings are suboptimal though, setting it to FULLSCREEN at my monitor's native resolution works better than the default WINDOW mode. The version of CMake in Raspberry Pi OS (Legacy) is too outdated for my Heboris port, but current Raspberry Pi OS includes a recent enough version. I'm not going to reduce the minimum required CMake version, because there are extremely useful features in the minimum version I've selected, and I simply will not give them up just to get it working on outdated systems. Plus, there's not really any disadvantage to running the latest, non-legacy version if you're not using a desktop, or not dependent on software that only works in the legacy version. There are other benefits to the latest version of Raspberry Pi OS too, like a more recent version of SDL. Just be sure to install the 32-bit version, as I believe Texmaster requires that one.
I loaded the RaspiOs Lite Bulleye 32-bit system. I followed the build procedure and ran Heboris. Again it ran for thirty seconds, maybe a minute and then crashed. This time the console reported the problem: segmentation fault. I specify that when I started Heboris I let it go without giving any input. After the initial screen the demo starts and at the end of the demo (sometimes not quite at the end but a little later) it crashes.
I guess I'm terribly sorry, I have no clue what the issue is, nor how I could possibly help. You seem to have done everything correctly, exactly as I have, yet are getting different results. I could only assume it's some hardware issue, like a bad SD card, or worse, an issue with the Raspberry Pi itself, but I can't be certain of any theory as to what the issue is. If other games run fine, then we can at least say it might be something in the Heboris code. But if it is in the Heboris code, it's quite confusing why it crashes for you but not for me.
Brilliant! Works great on my end for Linux. Thanks Edit: tips on getting music to play? I enabled it in the settings, but that doesn't seem to do much.
