Welcome to the personal blog of Archerite

  • Archerite

    BatteryCheck - GBA: Why do I 'like' to make things so hard for myself?

    I have not written or updated anything about my homebrew project BatteryCheck in a while now. I really want to update it with new and improved features but the fundamentals are just not working right. With that I mean the actual game engine I have created. It works alright all things considered but that's only because the current systems (GC, Wii and 3DS) have a bunch of memory and horsepower to make up for my bad and inefficient engine. ;)

    My ultimate dream for BatteryCheck is to have it run on the Sega Genesis and NIntendo SNES! Mostly because the game feels like it belongs on them and it's from about that time period, sort of. Ofcourse it's a grey area with all the legal stuff about the graphics and stuff which I do not own. Converting them "on the fly" and not distributing them with my homebrew was a nice loophole to get around it I think :D And like I said above the systems I currently have it working on all have enough memory and CPU power to handle that. Scaling down to the DSi would still be possible since it has 16MB of build in memory to use for converting the graphics. The DS is a huge challenge with only 4MB and slower speed. The GBA with a tiny 256k (among other smaller special caches) is going to be tough! Going to SNES en Genesis which have even less memory and very slow CPU.....it seems impossible! Right? :P

    Well, I have been thinking about how to get this to work just like on the current systems. It might take longer to load and some libraries have to be ported....but when using a FlashCard on each of the lower speced systems you have a LOT more potential memory available! The slower loading would actually be more accurate and faithful to the original game, because it has very cool graphics to make your wait a little more interesting. I really wish I could share them....but I can't :sad:...yet. Maybe I can find a link to some screenshots later and show them that way.

    Anyway, this idea I have had for a long time since I have Genesis Everdrives and a SD2SNES (never even used it I think :shy:) and while documentation for using the extra memory in homebrew is not very detailed, there are examples with code to show how things work. While on these low-memory systems even the Everdrive will not provide enough memory to keep every thing in it's memory I would like to prevent having to write the converted images to the SD card or whatever storage would be available. Just to avoid legal issues later :) For the time being I have just kept it as a "nice to have" project for the future when most of the game would probably be finished already, hahaha:lol:

    Recently I have been drawn back into the GBA and slowly discovering what that little handheld is capable of. Reading lot's of documentation about it's graphics made me realize my game engine is using a lot if the same concepts already, since I based it on how the NDS works. And that is in turn based on the GBA so that was a nice re-discovery that got many new ideas firing through my mind! Aside from the original/bootleg stuff I talked about earlier in my blogs here I also tried to figure out what might be possible with FlashCarts. Most contain 32MB of SRAM (or similar) that is only used to load a ROM into and patch it to allow saving to SD or savestates and whatever. But if I could somehow use this memory for my own purposes that would mean on the NDS I might have 36MB of memory!!!! On the GBA it would still be 32MB and for conversion I need between 10-16MB on the current platforms. Since the graphics also need to be scaled down a bit they might end up using even less memory than that. Or more depending how I might optimize things of course.:D

    From what I have read until now the cheap crapy Supercard which I have is listed with commands to unlock the SRAM for writing but I have not tested it myself yet. I do still need to find a DLDI patch so that I can read/write to the SD card on it since that I have not been able to figure out yet. I also have an EZ Omega on the way just in case I hit a brick wall with the SuperCard :wink: But the idea in general is the same. Load my homebrew and the orginal game files onto the SD card as on the other platforms, load it and it will unpack the files for first time use. Then when loading the game the second time it will use those files and convert them using the "spare ROM/SRAM" of the flashcard. Just hoping that the SuperCard firmware does not mess up or block control of the hardware too much to prevent it from working.

    The above kind of exxplains what I would like to do already, but I also want to test things NOW!!! I am very impatient when it comes to things like that! :lol: Guess I could try just loading some levels in and show just the collision map and a rectangle for the player on screen. This way I can test and improve the collision detection/correction which will help all the other platforms in the end. And it's a great way to restructure my code tree (again) and clean the helper libraries from BatteryCheck specific code and contants. Eventually the same engine could support Jazz Jackrabbit 2 too since the gamefiles are nearly identical. And bring that game to ALL platforms my gameengine can run on! :D

    My signature gives a hint of supported platforms but here it is again: And I see that the GBA had completely slipped my mind when putting down this list more than a year ago
    • Linux
    • Raspberry Pi
    • GameCube
    • Wii
    • 3DS
    • GBA
    And I have tried to port it to:
    • PSP
    • PlayStation 2
    And originally planned for:
    • DS-i
    • NDS
    • Nintendo Mini's
    • Playstation Classic
    • Sega 32X (requires Everdrive for RAM)
    • Sega MegaDrive (also needs everdrive)
    • SNES (SD2SNES required for RAM)
    • N64

    I have been told before this might be a little to ambitious to have so many platforms it runs on. :wink: The fun in this for me is figuring things out and making them work. Learning how game consoles work at a really low level is my number one priority during this adventure. That's why progress is sometimes a little slow, sorry. :shy:Another advantage of working with multiple platforms that use different architectures and memory contains is that you end up with better solutions. Sometimes because code runs slow or is inefficient, or it runs fine on one platform and crashes on the other for no apparent reason. That's how I learned about CPU Little Endian and Big Endian which is a nice confusing story for another time :wink:. It also helps optimizing overall memory requirements when you need to preserve it which will be the case on the NDS and GBA. If it could run on the GBA stepping down further to the SNES and Genesis should be alot easier since it's already optimized to use less memory at that point.

    I think I would better stop writing now. :D
  • Archerite

    Clearing my conscience and going for the real GBA cartridges! ;)

    In my previous blog post here I talked about how my younger self was ignorant when buying GBA games on ebay 15 years ago. So I ended up with four of my favorite games being bootleg copies without even knowing it all these years.:angry: For multiple reasons my collection of GBA games never expanded that much. One obvious reason was I did not make that much money back then but having a flashcard might also be a part of it :blush:. Saving for my drivers license and a car of my own also limited my gaming budget I guess....but it all sounds like lame excuses right? :teach:

    Whatever the reasons are/were it's time to expand my GBA collection!!! So I looked around on my favorite retro Nintendo webshop and seeing what it would cost to replace the bootleg's for the real thing. It was not going to be cheap I can tell you that...but I also wend a little overboard and got a few extra games :lol:. So here is my current collection (including the bootleg's and...ehm...homebrew carts ;) ):
    gba_games.jpeg
    They might not all be the best jewels but some were cheap enough or interesting as a research object. Since the GBA has a really low resolution I can learn a few things to port my homebrew game Batterycheck to it....eventually. Mostly I want it to look better on the 3DS first but my interest in the GBA has been sparked enormously which also led to this...:
    gba_consoles.jpeg

    Only the NES special edition was my own original store bought version from 15 years ago. Got the grey regular GBA when ordering among other things the zelda minish cap. I had wanted the original version for a long time but the non backlit screen kind of kept me away from it. It has lot's of scratches unfortunately on the screen that makes it really hard to play actually, but that got me looking for replacement parts and screens and other modding options. The grey SP and purple one only got in yesterday together with the new games:D Why do I need this many GBA's? Well I don't to be honest. But zelda fourswords could be an option one day now. Testing multiplayer with the link cable, using the GBA as a controller on the gameboy player on TV, or in the extreme case....replace the screen in one of the GBA's with the one from the grey SP to have a backlight. Neither of the SP's is an AGB-101 though so it won't be as good but it was one of the considerations. That grey SP is even more beat up and was really played and abused over the years it seems, luckily the screen is fine and barely scratched. Purple GBA has a couple of scratches but not as much as the grey GBA but it does have an issue with the power switch.

    My orignal NES edition looks almost good as new since I did not use it that much and I always take care of my consoles. It has always been in it's protective cover...and that one looks like it needs replacing though ;) For my new additions to the GBA family I am considering getting replacement shells and at least one of them will get an IPS v2 replacement! Even though the NES SP is in good condition it's backlight is still crap compared to even the original DS on which I have played through most of the minish cap actually. :wink: And while 50 euro for a screen replacement kit is not exactly cheap, it looks awesome in video's and is a lot cheaper than getting an AGS-101 at the aforementioned store: 160 euro's!!!

    Now I have multiple GBA's it's less of a risk to try multiboot and other stuff that might blow one up. I have been testing an example I found on github with a rapsberry pi (is there anything these things can't do???) since both work on 3.3v and that makes interfacing very easy. Tweaking that example I got a maximum speed of 28KB/s while uploading a 250KB example from devkitpro. Though at these high speeds the link is not very stable so it needs more tweaks and a better more reliable cable and connections. I just cut a link cable and hooked it up through a breadboard right now ;)

    So in the next few weeks/months I might be posting more crazy projects related to the GBA. So many ideas...too little time as always :D
  • Archerite

    Getting the old DS, DS Lite, DSi (in DS mode) connected to wifi......it's like mission impossible!!!

    Ofcourse I am aware the DS is an old legacy system and the WFC network has been offline for a while now. But why can't it even connect to a simple highly unsafe open wifi network anymore???? What kind of black magic is the "connection test" doing to see if there is an internet connection? I am not even seeing a connection attempt in the logs of my Ubiquity Unifi controller! Also using the Nintendo USB Wifi connector on Linux with a software based access point shows nothing that looks like an attempted connection! I mean, it's great modern wifi equipment by default does not allow WEP encryption anymore but an open network is still possible if you want it. But for some reason the DS refuses to connect to it!

    Doing homebrew development on the 3DS and wii got me spoiled with quick uploads using wiiload and 3dslink. Seeing the DS has it's own variant dslink I obviously want to make use of it for my "crazy GBA validator" homebrew app. Swapping SD cards all the time for new uploads is sooooo....not fun :angry:!!!!!

    Anyone else have this issue or is it just me?:lol:

    Whatever the solution is to get the DS connected to....something....ti's going to be less secure than a regular wifi with WPA2 ofcourse. So it's going to be separated on it's own VLAN and only specific traffic is going to be allowed into and out of that VLAN! I have to admit I have not jet tested a homebrew program that uses wifi yet to see if it would work anyway, even with the connection test saying it is not working. Most likely it wants to connected to the servers from nintendo which are now offline. But somehow wiimmfi seems to have discovered a way around it but none of the DNS instructions I could find made it work.

    My only solution seems to be getting an old router which supported WEP and see if that works. What I am hoping for is to at least have a raspberry pi 3/4 stand in for that so it's smaller and uses less power and gives more firewall controls for the unsafe wifi hotspot.

    Just had to write down my frustrations....once again. :)
    alexander1970 likes this.
  • Archerite

    I have been scammed on eBay with my GBA cartridges!!....about 15 years ago ;)

    The short version:
    Bought some GBA games on eBay about 15 years ago and just found out TODAY they are actually not original legit Nintendo carts! Found out that most original carts use FLASH or EEPROM to store saves but the bootleg's use SRAM and have patched the ROM's to make it work. The downside of SRAM battery backed savegames is when the battery runs out...it's bye bye savegame! And you can not save with that cart anymore unless you replace that battery.

    As usual I started having crazy ideas again and plan on writing a simple NDS homebrew tool to detect these fakes!! Because they are patched versions of the original ROM their hash should not match those known for that game. As a bonus this utility will allow you to backup and restore GBA savegames and possibly make a backup of the ROM too! Just need a name for it better than "nds-gba-checker" as my work-in-progress version is called now, hahaha.

    Enjoy the long version if you want, but the above pretty much summarizes what it's about.:D


    The long and hopefully entertaining version: :D
    I think it was around 2005 that I bought my Gameboy Advance SP in the classic NES edition with of course: NES classics Mario bros to go with it. Since most other games were kind of expensive for me back then (don't remember the prices though) I was looking on eBay to what was there. Only buying from local sellers I was assuming people finished those games or just did not like them or something so I bought at least: Supermario Advance, Supermario Advance 2, Zelda: A Link To The Past and Tony hawk's underground after testing them on my flashcard if I liked them or not :shy:...for me that was the reason flash carts were made. Right?:D:lol:

    Anyway....buying them on ebay from local sellers I was assuming the games were original and not copies / fakes / counterfeit / bootleg or whatever which they so obviously are! But in my ignorance of my 15 years younger self I had no idea those existed or just did not see the signs. The games played just fine for years so I had no reason to suspect anything was wrong....until a few days ago when I popped in my Zelda and find my 100% completed savegame to be GONE!!! I have never loaned them to anyone who might have erased them as far as I know, so just to see if it might have been the save battery I played a little and created a save. Turned of the system. Back on...and GONE was my save I had just created! Tested it on my SP, NDS, and NDS Lite same results! Taking the cart apart...this is what I found inside:

    gba_zelda_fake.jpg

    I have opened it a couple of times now and the first time I did not even notice the bad soldering and the epoxy blob. Just to confirm my suspicion of the empty battery which I saw was enough to just accept it won't be saving anymore, until I get replacement batteries. Then I noticed the exact same on Supermario Advance that it would not hold the save anymore. Since I only had about 6 games anyway I just opened them ALL up to check which of them had the ticking timebomb battery inside of them:

    gba_carts_inside.jpg

    Looking at them like this it's just so obvious to spot the fakes, isn't it :blush:...I feel so stupid. And upset!!! So what is the actual problem with these carts aside from being illegal ofcourse?? They have the game inside that's on the label and at least for a few years saving worked fine. But since original legit Nintendo carts with a very small list of exceptions ALL use either EEPROM or FLASH storage for the savegames, these copies are patched/hacked to save to the SRAM (with battery backup) instead! And from what I have read about these fakes those saving patches are not very stable or reliable. Or if they are the battery they put in might be empty before being send out!! And as you can see on the pictures...the soldering is TERRIBLE on almost all of them! I am surprised they worked at all! Or this long actually. If I had knowingly bought these as "copies" for a cheap price it would have been a different story. I am actually looking into getting some from aliexpress since I have read that you can reprogram some of these with your own GBA homebrew!!! Thinking Batterycheck GBA here :D:lol:...although it would be a private cart only. No selling allowed and multiple copyright issues in the way of that ;)

    Well, at least my newest addition to my GBA collection: Zelda Minish Cap is a legit original Nintendo game cartridge:D

    I was already looking into making backups of my carts and their saves to use on the 3DS with mGBA. Multiple options are possible these days from unbearingly slow (using GBA Gamecube cable) to lighting fast with the Retrode 2 and an adapter. I have a retrode 2 and GB/GBA adapter but I read it does not support the savestate dumping/restore so that sucks. Plus I need to find the retrode in my storage box first ^_^. So looking at the GBA cable and the sourcecode of that dumper utility, which I know FIX94 only wrote as a proof-of-concept for those that kept asking if it was possible. And it actually is but it's about a 45min wait to get the data over the stupid cable from the GBA over to the gamecube or wii!! The protocol and electronics in the cable are very inefficient and from what I have seen in the code...FIX94 did a fine job considering the point of his utility:). Only with specialized hardware directly on the GBA expansion port...like the wireless adapter. A higher speed "might" be possible according to the docs I found, which defeat the purpose of the "simple and cheap" method of using the cable.

    Then I started thinking...and thinking...and thinking.....about the NDS! It has a GBA port with direct access and a way to transfer the data over wifi or store it on the SD card of a slot-1 flashcard. Looking around I noticed there is already a tool for this NDS GBA backup tool...but that was the only one and it does not look like it's open source. Then I found this amusing story about how someone transferred a savegame from a bootleg cart (which he got by accident like me) and transfer it back into an original. Let's sumize his story by saying it's not just copy-paste and he had to go through a few hoops, but he succeeded and sharing his efforts on github. Looking through it he really only made an SRAM savegame dumper for his game, but it shows how to access the cart and read the SRAM holding the savegame. Combining this with the headers of devkitpro NDS I figured out most of the stuff he did...and it's AWESOME. Knowing a tool that worked to dump a cart already existed is one thing...but having an example that mostly does what I need already is even better!

    After some more thinking ( I do that to much sometimes :rofl:) instead of a pure GBA dumper it might be usefull to have a utility that could detect these fakes by placing them into an NDS and have it verify the GBA ROM in the cart! I have downloaded a list from the no-intro site that lists all known releases and their ROM hashes in CRC32, MD5 and SHA1 to verify the cart with. To do this my utility will read the GBA header to identify the game with it's 4 letter serial code to lookup these hashes and know the size of the ROM to read. Then read in all the bytes from the GBA cart and push the data through the hashing functions and at the end verify them to indicate if it's real or not! I have no idea how reliable this method will be, but if the fakes with SRAM savegames are patched their hash will NOT match the original release. As a side effect of the ROM validation I might as well include a dump feature right? Unless someone has strong arguments to not do this of course. But at least savegame backup/restore is what I want to include in it. :D

    The best advice when buying used GBA carts is, check the average value of the game and if it's way to low...assume it's not an original cart. To help out others I might do another post later to point out what I know about the fakes and how to spot them with detailed pictures of my own. The pictures above I took quickly just to show the insides in this post ;)

    Wow, this one got long but hopefully it was interesting to read and have a laugh at me. Either for buying fakes or my crazy ideas and project 10.001 :rofl2:

    That's all for now.


    EDIT: After a quick copy-paste and edit I have a little demo that already looks good in an emulator:
    gba_cart_validator__quick-test-in-emulator.png
    This is from DeSmuME with a Zelda ROM loaded in slot-2 :D


    EDIT-2: For those interested in following the NDS app part of this story I have just created a thread for it: https://gbatemp.net/threads/yet-another-way-to-make-gba-backups-with-an-nds.566771/
    tfocosta, tirges, Ryccardo and 4 others like this.
  • Archerite

    A small update and rectification about wii-linux-ngx

    In my last blog post I was complaining a lot about wii-linux-ngx and bashing it a little for not working better. After a long night yesterday of compiling the Linux kernel and a lot of failed boots and looking closer at the wii-linux-ngx kernel. I have to give more credits to the creators because they have done a TON of patches to get the Wii hardware supported and show output on the screen and make it work as well as it does. Even though a lot can be done to make it better.....much respect to you guys: Neagix and DeltaResero...for making it even possible to get Linux running in a usable fashion on the old Wii! The repository has not been updated in the last two years and the keys I mentioned only expired like a month ago.

    I am not sure if my new Linux 5.7 kernel is actually running and not showing output or if it's really crashing. I do know that the wii-linux-ngx kernel patches contain special drivers for the Wii hardware so I just decided to try and compile that one, so I would be able to tweak that version and get a working starting point. It took me a while to figure out why this older kernel would not compile on my Ubuntu 18.04 with GCC 7 and had to make use of my recent Docker skills to setup an ubuntu 14.04 environment that has an older GCC 4 that compiles without issues. The good news is that I can now compile this patched kernel and actually modify it myself and it even boots!!! It performs slightly better than the precompiled kernel actually and I was able to update the package list and install a few extra applications I wanted. :D

    There are still many issues to figure out like why it does not like to make use of the swap I have provided but I have something to work with. I also want to try to use Adelie Linux instead of debian as it's a lot smaller and still updated for the PPC architecture. For those that do not know Adelie Linux is based on Alpine Linux which is designed for running inside small docker containers.

    Another option I am considering to get a filesystem image ready is to run Adelie in a PPC Qemu virtual machine and just setup the system that way. So it will be fully updated and ready for first boot on the Wii or something.....when I have more time to actually work on it. Spend too much on it already. :lol: What I will try soon is accessing the gamecube ports with a native Linux app running on the Wii itself! Just reading the buttons and making the gamepad rumble or something. :D

    It's a good thing I have a long Linux history and know my way around a few of the hoops I had to jump through to get it working at all. And I have an intterest in how Linux actually boots so this is a good learning experiment....again....to get close knowledge of how it works. Some stats for those that like to know: My custom 3.14 wii-linux.ngx kernel is 6.2MB uncompressed and only 2.5 with compression! When I continue optimizing the kernel my priority will be stability but I do hope to also make it really small so it uses less memory by default. I could also try building it for IOS instead of MINI to see what that does for stability and memory usage. I did read somewhere performance would be slower with IOS but if it would than at least work I call that a win ^_^

    I'll stop know :D
    KleinesSinchen and alexander1970 like this.
  • Archerite

    Getting Linux running on the Wii!!!

    It has been tried a lot over the years and I knew it had to be possible but never actually got it running. Until a few days ago when I decided to take a risk with wii-linux-ngx and just write the diskimage to an SD card. It was not plug-and-play AT ALL!!! It would not boot with priiloader complaining about missing bootmii so after putting that on the card I got into the bootloader screen....yay!!

    Then selecting the option to load the Linux kernel I saw actual Linux running on my Wii and I thought it was the coolest thing ever!!!:D It generated an SSH hostkey at first boot which is nice since that would make it unique and being able to login with SSH is even more awesome!!!! After the first boot completed I logged in as root and looked around a bit to see if it was a legit Linux running here, and it sure looks like it is!! Memory and CPU info looks good although memory usage is a bit high to my liking for running on the Wii. And this was a hint to the rest of the issues I ran into......

    The release of wii-linux-ngx was from 2017 and is based on Debian 8 (jessie) which is one of the last that support the PowerPC 32bit CPU of the Wii. Being a little "out-of-date" is not really an issue but when the encryption keys for the package repository expired only a month ago.....that is an issue!!! A huge one to be more exact. Normally "apt-get update" should correct the problem from every guide and forum post I could find about the expired key's but nothing helped. Without apt-get update the package list is out of date, and no new software can be installed.

    Beyond this issue the ext3 partition was only 512MB with a few MB's free space left so I first had to expand it on my desktop to the full 16GB of my SD card. And while I was add it also added a 1GB swap partition to at least add some virtual memory. This process took FOREVER since the card I choose was kind of slow....but after maybe 30min's or something the partitions were expanded and created. After booting the Wii again I saw the swap was not used automatically and I had to manually enable it. So i did. But even then it never got used at all! And the biggest reason I need swap is because everything I tried....including updating the package list....seemed to require more than 20MB of RAM that was free after booting. It resulted in "hanging" processes that did not seem to move anymore but I could still kill the process with CTRL-C so it was not a total lockup. The frustrating part is that Linux runs fine on embeded systems which only have 4-16MB of RAM!!! And since the Wii has 84MB of RAM in total it should at least be more capable of running linux and updating the packelist to install new packages!!!!!

    The the SSH ability I talked about I was able to connect but not login as root. I expected that as it's a safety thing in Linux to not allow this so I created a new user named Wii...and now I could login with SSH remotely into my Wii!!! Awesome right!!!! :yay:......but if you can't do anything useful it's pointless to get into it. I could even use SFTP to browse the filesystem and look at at the configuration files...but not edit them as that needs root permissions. I tried uploading a large 80MB file to it with SFTP and it got stuck around 20MB every single time I tried. The frustrating thing was that a full reboot of the Wii is required to try again....otherwise it get's stuck directly! Even downloading the same file with wget on the Wii directly got stuck around 17-20MB and my frustration level kept rising and rising.....

    Then I thought lets try something funky with a "chroot" environment and try install "adelie linux" into a subdir. Which was the 80MB file I was trying to get on there actually but ended up putting the card in my PC to get it there. Then unpacking it was slow but it worked and after a few other Linux tricks I had network access in the chrooted Adelie linux environment. Having no experience with adelie gave it's own set of problems but let's say "pkg update" is equivalent to "apt-get update" and it should be getting the keys and package list and stuff. While it worked after a little fight with the network settings it hang at 12% updating for the same reason as before.....out of memory!!!!!!!!!!:gun:

    For now I have kind of given up on getting useful things done with wii-linux-ngx since I have a lot of things to do already with the Wii Mini and BatteryCheck of course. But even with my complaining and ranting above.....a lot of respect and credits to everyone involved in getting a modern Linux running on the Wii! (https://neagix.github.io/wii-linux-ngx/)

    I have a lot of ideas of my own to get a clean adelie linux image with a fresh fully custom Wii Linux Kernel up and running but it needs a ton of research. The frustrating part is that Linux should run fine on embeded systems which only have 4-16MB of RAM and they run perfectly fast!!Never compiled a Linux kernel and make it work is one of the obstacles I need to take. But the advantage of a custom build is leaving out everything not required on the Wii, like maybe USB3 and firewire drivers for example. The good thing is that even the latest official Linux kernel source code still contains special Wii hardware support so it's not impossible. ^_^

    My useful goal of Linux on the Wii with low memory usage is the ability to quickly test hardware related testing of stuff I want to know. Like how fast can the memorycard, gamecube controller ports, USB, NAND, SD, etc interfaces transfer data. I can do that with homebrew of course....but doing quick tests with something like python over the network through SSH will greatly speedup the debugging process. And because the Linux kernel will protect against a full system crash reboots should also be much less there. It would just give a segmentation fault when thing go bad. But the kernel and everything else keeps running. I think I will try out a small Linux distro in a virtual machine with only 32MB of RAM... just to see if it could work. If it fails I could increase to 48-64MB and if it still does not work as I want.....just give up on running an actual common distro at all.

    I am sorry if this got to technical or complicated for those who do not know Linux, but I just had to get this out of my head and complain a little. I think it already helped a bit. :D
  • Archerite

    BatteryCheck - Planning for new features and improvements in preview 0.4!

    WIth all the crazy stuff going on and very limited time to do any hobby work....I still want to sneak in some dev time for BatteryCheck again!! My first priority though is getting a list of features that would even be considered deserving a new version. So here are a few things I have in mind but I am definitely open for more suggestions or ideas
    • Parallax moving backgrounds with the elevators and the chain moving very near the camera at certain points. While the movement for that is working for the most part, it only works on tile 0,0! The very upper left part of the level that you can not reach during normal gameplay. The way the backgrounds work to create the illusion of depth is by moving at a different speed than the player. Since the backgrounds are a lot smaller than the entire level itself the tiles used are repeated over and over. But to get this right a LOT of calculations need to be done to figure out where tiles are moving to at the current position.
    • What really needs to be in there before release is working battery holders!!! The animations related to that are kind of easy but for each machine a holder activates I need to write a bit of code to make it work. I might do the elevators first as their logic is quite simple for the movement. Each end of the elevator track has an end-stop indicating it should stop and go the other way. Some elevators only go up and down a number of times which is not that difficult to calculate either I think. It will bring even more life to the game and give the player more to do and not get bored after a while. :lol:
    • The "doors" and "stampers" that should block your way need to start acting like that. And their respective battery holder should activate them for all the parameters that are configured for it. Some go REALLY fast for example that even I can not get through 8-10 times, hahaha. Not that I am an pro player of the original game though :rofl:
    • Water should be damaging and give the player a bit of floating to escape it. If you can't escape your battery drains and you die...sinking to the bottom of the pool like a fish.
    • Some real effort to make the background music work on Wii and Gamecube! I am using libmikmod on the PC and 3DS that can play the native files used by BatteryCheck. Also for later when the game engine is used for Jazz Jackrabbit it can play ALL of the different formats! So it makes a lot of sense to port the libmikmod library myself since it's not included in Devkitpro.
    • Working intro and menu system. Not that it will be useful just yet to load a saved game but it will make it look more like the actual game, just like the stuff above.
    • Pause option!
    • Leaking green drops go to the floor and splash out. And damage when it hits you.
    • Moving enemies with very minimal AI: They will jump into your direction but I am not sure how difficult it will be to write the attack AI. Because it will need to freeze the player, take damage, and run an animation with A LOT off frames. It will be cool though when they work
    • Near the supper batteries are monitors with the end boss on them. In the original game his eyes will move into your direction... to freak you out! Should be really simple to do this.
    And the following bug fixes:
    • Alignment issues with battery pickups need to be fixed!
    • Sticky walls, glitchy 1px shaking, not jumping into -10px platforms.
    • Better movement of the player in general. He walks to fast and not aligned with the distance he travels. Same for jumping and nearly all other things he does.
    One other thing I have been looking into is making a Raspberry Pi release! I have tested it to run flawless on a Raspberry Pi 3B+ but at the time extracting the game files was imposible and something I really wanted to include. The plan is to make it a real .deb package that will auto install any dependencies required to run on the latest Raspbian. Maybe even separate versions for Rpi 2/3 and Rpi 4. The instructions to install it will of course be detailed like I have done for the Wii and 3DS already.

    Special thanks too @niuus for the awesome comment in this thread Best Homebrew Games? and redirecting my thoughts into BatteryCheck again. Thanks man! :yay:
    KleinesSinchen and KiiWii like this.
  • Archerite

    Wow! My batterycheck Wii thread just passed 10.000 views!

    What I consider my main thread about Batterycheck for the Wii has just passed it's second milestone: 10.000 views! :D

    This much interest in my little homebrew adventure project with no real update in a few month's is what keeps me motivated to actually continue. I have a bad habit of jumping into many projects and not really finishing anything....lack of time, complications, or just the new wearing of or something. :( :rofl:

    Thank you all for the support on my longest running project. :D
  • Archerite

    Yet another crazy idea....Raspberryi 4 as an I/O interface for the Wii Mini!

    I just had one of my many crazy ideas again...for a few days actually but who is counting :lol:. Almost a year ago I already thought of a way that a Raspberry Pi could maybe be a modern modchip for the GameCube and make all it's awesome wifi,bluetooth, ethernet, etc..available for homebrew. I came to the conclusion that a microcontroller was needed to translate between the fastest ports on both devices: EXI or MemoryCard slot on the cube and then USB 2.0 OTG on the Raspberry Pi. Then I got to busy to actually design the hardware and software and it kind of got on the bottom of my "todo list"....like sooo many other projects! :blush:

    Last week I discovered that the Wii Mini had the BlueBomb exploit that I had totally missed. And a few days later I read that the Raspberry Pi 4 could actually be a USB OTG gadget on it's "power port" USB-C connector. Yeah I know, the Rpi 4 is probably just powerfull enough to emulate the GameCube/Wii with dolphin but that is not the point here :lol:...just imagine this:
    By connecting a single magical USB device to the Wii Mini it would get:
    - Four USB ports of which 2 are USB 3!!!
    - Gigabit Ethernet!
    - Wifi at 2.4Ghz and 5Ghz (I think at least it has both?)
    - An extra bluetooth interface
    - 2-4GB RAM to do fun stuff with!
    - Micro-HDMI would be kind of useless since the GPU access will be to slow.

    Besides this hardware I/O that would become available the USB gadget drivers on the raspberry Pi could emulate a small Mass storage device from which the initial homebrew could be launched. Then with a custom IOS and drives that could be loaded it might be possible to give transparent access to this new hardware! Just like how cIOS can redirect the diskdrive reads to a USB drive. Ot how Nintendont can simulate GameCUbe controllers and load games from the SD card. All of this is done with a specialized IOS. This also has some similarities with my idea for a "NAS Loader GX" that would use a big NAS harddrive over the network instead of a local drive plugged in directly. Ofcourse I did not actually had a Rpi 4 yet to even give this a try....so I bought a few last week as well. :D

    I am not saying it's going to be easy but the last week or two I have been reading a lot of documentation again about the Wii hardware. I am even thinking of a way to replace the NAND chip in hardware to give zero change of bricking while testing all my crazy ideas...and not having to worry about the NAND getting corrupted or wear out. I have seen an EmuNAND is an option and I might look into this but I also like the idea to just load a real NAND backup from an SD card into a microcontroller or FPGA and have it act like a NAND chip.

    I did find out the NAND can reach a raw speed of 55.000.000 bytes per second on it's interface. That is way to fast for anything I could build that would be able to simulate the NAND....but since writes have to be done in pages you will not ever reach this speed! If I remember correctly you need to divide this number by at least four to account for page write/loading overhead. This leaves a possible speed of a little under 14MB/s which I am not that sure it could reach anyway on the Wii since the Starlet CPU is not fast enough to read/write while also encrypting and decrypting. It may reach about 1/4 of this speed which leaves about maybe 3.5MB/s! Now that might just be enough to let an STM32F4 at high clock speeds to handle and simulate a NAND flash interface that would be compatible. The "Emulated NAND" needs will still need to be encrypted with the console's unique encryption keys so it will be required to have these keys first or work with an original NAND backup.
    This also comes down to my craziest ideas which I have kind of got from the bitbuilt forums....building a portable Wii into a really small enclosure with an LCD and game controls. This has been done sooooo many times already and I do plan on someday taking the jump and cut a motherboard into pieces according to those guides. Although I am still not sure how small I actually want to go but I am thinking in the range of the PS Vita size with GameCube like control's.

    I am not sure if the above is making any sense...just needed the idea's out of my head so I can sleep a little better tonight! :lol: Some other time when I am less tired I might actually talk some more about one of these ideas in more detail. Or report that I have succeeded...or failed...at trying it out, hahaha! :D
    MicmasH_W likes this.
  • Archerite

    Finally an exploit for the Wii Mini!!!

    yeah, I am a bit late to the WIi Mini Bluebomb exploit party, hahaha :lol: After a few hours of searching for a MicroSD card that I could wipe clean just to try this, I wasted a few more in trying to get it working on a Raspberry Pi Zero W! The damned thing just did not want to connect to my WiFi or show up as a USB ethernet gadget!! Eventually I moved on to a Raspberry Pi 3 and that one at least showed up in my network! After enabling SSH I could finally start following the instruction for this exploit, which are not yet noob friendly but it is mentioned on the wii hacks guide though. That's actually where I saw the Wii Mini even HAD an exploit at all!! I did know people were talking about a possible method over bluetooth but I got a bit distracted with other things lately! ;)

    Ofcourse my main goal for a modded Wii Mini is to install the homebrew channel...and directly after that Batterycheck ofcourse!!!!:rofl2::rofl2: And that is just what I did and it works great!!! After that I tried to find some more information about what to do next. I did not dare to install BootMii yet as an IOS since the reset button is not reachable. I tried finding a schematic or table about what all the test point's on the back are fore...or if the required pcb trace are even available. No luck yet, but did not really try it that hard yet.

    The last few weeks I have been fighting with the sprite masks and it took me a while to figure out how the bitmask was stored! It's a little complex to explain but in simple terms each sprite can be an unalignd size of pixels high and/or width. Each bit is held in a byte and so 8 pixels per byte. So for a 16x16 pixel sprite it would be really simple 2x2 bytes, but if it would get to 17x16 things get a bit more complex!!! Pixel 17 would be still comming after 16 but pixel 1 of the second row would be right next to 17!!!! The short story is that each row got shifted a number of pixels and my spritemasks looked like :shit:!!!

    When I had figured this out it took me a while to write a function that could handle and compensate for this. It's not perfect....but it works! And then I got a little busy with other things,...again :blush: No idea when part 2 of my multipart adventure to fix the collisions is going to be ready but it might be a few weeks....but also just a few days ^_^
    KleinesSinchen and alexander1970 like this.
  • Archerite

    Fixing collisions - Part 1: Back to basics!

    This is going to be a multipart journey into rewriting collision detection in my homebrew game engine I am working on. While the primary focus of the engine is to run my remake of BatteryCheck I do have more plans for it to also run other platform games. It should be relatively easy to support Jazz Jackrabbit 2 at some point since they share the level file formats and run on the same game engine, with a very small difference that make both games not accept each others files directly. In fact the only real difference is Jazz2 has a copyright header that BatteryCheck does not have and their version number is different, other than that the data is structured exactly the same! This is what made it possible to use the information I found at the jazz2online wiki explaining how the files are structured and what all the bytes mean for the game. After a couple of weeks of reading that info multiple times and experimenting in Python I succeeded in decoding the files and write a prototype "level browser".

    The levels are stored in the J2L format and it contains the following parts:
    • Settings for the level and 8 layers
    • layer tilemaps
    • event map
    • animated tile frame info
    One of the global settings is the tileset which is stored in a separate J2T file format and holds the following parts:
    • 256 color palette
    • max 1024 tiles (32x32 pixels)
    • Transparency mask (not using it since "black" in the tiles appear transparent. Might be some sort of real transparency but never noticed it being used in the original BatteryCheck)
    • TileMask - Mask of 1bit per pixel "image" that indicates what part of the tile is solid.....and the key to pixel perfect collision detection!!!!!
    • FlippedMask - same as TileMask but flipped horizontally for some reason
    In my last post I explained how I was constructing a "collision map" while loading the map into memory with codes instead of using the TileMask from the Tileset. While I was starting my whole project everything was new and complex so replacing "pixel detecting" with a simple one byte code to indicate solid parts seemed so much more simple to implement. And it was actually.....but it's also very unaccurate for tiles that should only be partially solid. The one-way platforms are a good example of how bad my implementation currently is, since they should actually only be 8 pixels thick when standing on them...but the ability to jump through from below makes things so much more difficult!! Remember the memory calculation examples I wrote about last time?? Well my extra "collision_map" array is using up an extra 43,665 bytes of RAM while the original 1 bit mask data from the tileset is only 5,632 bytes in total!!!!!! This is quite a huge difference and a lot of "TileMaskImages" are shared between tiles which is why it can be this small and also contain the flipped versions somehow. If you played one of my preview's you must have noticed that there is a second tileset which looks dark green on black....this is actually build from the Tilemask data and it shows EXACTLY what is solid!! While most of the above details might not mean much to most of you it is a small step on improving my collision detection for walls and platforms to pixel perfect resolution!

    There a many more ways to optimize the loading of levels into my engine and how it stores and uses this data in memory. One of the first things to do is keep the Mask data instead of discarding it after loading....and then making it accessible for the collision detection. The simple way to do this is to write some helper functions that will match the Mask and Tiles with given coordinates....difficult to explain but I have an idea in my head of what's needed for that. The other thing that's required is dividing the world into smaller pieces which the Sonic Retro Physics Guide calls "chunks" and they are 128x128 pixels in size. Each chunk is broken into 16x16 pixel tiles and those are again broken down into 8x8 tiles used by the Sega Genesis hardware. All of the solidity happens on the 16x16 tiles for sonic levels but in BatteryCheck this is 32x32 pixels. I might choose a bigger chunk size but the idea of breaking a level into smaller parts greatly reduces the amount of checks that have to be done to render each frame and check for collisions.

    Since the levels for BatteryCheck are not stored in chunks like Sonic's I would need to do that either during loading of the level...or just-in-time before a chunk is needed to be displayed. Each chunk would contain a smaller tilemap for each layer and the objects it contain. While I still need to figure out how to make the parallax backgrounds scroll correctly anyway....I do think I should keep them out of the chunks as their rules are a little different. Or maybe I should instead build a ChunkMap separately for each layer. When it's time to check for collisions the chunks will tell what tiles to check for solid pixels...and the Mask assigned to those tiles will give pixel perfect results!

    That's it for now :D
  • Archerite

    Found some really cool Batterycheck concept art!! :D

    While talking with a colleague about Batterycheck I did a google search and found a recent article on the Ranj.com website here: https://www.ranj.com/en/battery-check-free-game-by-empty-batteries/ (I don't think copying the images would be appreciated that much ;)

    For those of you that have gone through the trouble of testing my homebrew remake you might recognize Ranj as the website that the download is on. They are the company that evolved from the group that worked on Batterycheck and Jazz2 so they own the rights on the game. The article is in English and is not that long but it has a picture of some level design that is just awesome! I think it's one of the drafts for the first level as some of it looks familiar but it's not exactly layed out like this. Just thought it was cool enough to share :D
  • Archerite

    Let's get physical!!! ;)

    Got yah!! :rofl2: This is actually going to be about my homebrew game engine that needs a massive re-factoring and redesign before I will be losing my mind!!!! I will try to clear my thoughts and combine what I have been reading the past weeks about "how to write a platform game" and best practices in this blog post. It might get long, boring, confusing, sarcastic, funny or very technical this time but I really need to get it out of my head....sorry! :D

    So physics!!! We all know about gravity right?? The force keeping us and everything around us on the floor instead of floating around the rooms in your house and stuff? No idea actually how this work in the real world though :lol:...but how is this black magic sorcery trick done in classic platform games? Simple, it's all about math ofcourse! :P The number one thing in school (among many) I was terrible at but luckily I only need to tell my code on "how" to do the calculations and I do not have to do it all from my head...thankfully!!! Yeah, this was about the best of my efforts to bring in some humor into this stuff. The rest is going to be pretty much no fun at all.....:D

    When you as the player control the protagonist of the game you assume the floors, walls and other obstacles to be solid. And when you jump into the air you naturally come down again to the first solid object below your feet...right? As a casual gamer you would be right this is how things "just work" when you play any type of game. Now here is a shocking secret about video games....every single thing on your screen is actually NOT solid at all!!! At least not without a lot of work to figure out where in the game world you are. Is there a floor below you? Did you just walk into a wall? Did an enemy attack you? Or did you just collected an item? And that needs to happen every...single....frame!! Now ofcourse I could just adopt a physics library but what is the fun in that ^_^

    I have explained before how I have extended my level browser demo into a monstrosity of spaghetti code that tries to pass for "collision detection" into the graphics rendering code. The number one thing that I have read just about everywhere in all the tutorials is...do not mix drawing, collision detection, and sound code!! And that is just what I have done in the worst possible way and now it's grown into a monster I can no longer maintain. I mean...I probably could maintain it...but I don't want to continue doing it the wrong way!! So I have been trying to figure out the best way to rewrite smaller parts and why my code is so bad to begin with...and then I noticed the problem! Nearly all of my drawing code is based on how the levels are stored in the data files! Partly because I thought it was ingenious how they manged to save disk space and have such a logical structuring....at least for the time...which was 1995 or something like that. While my biggest issue in the game engine is not with the tilemap I just really want to explain how it works..at least a little! :D

    The BatteryCheck level "binnen.j2l" is 355x123 tiles in size for the main three layers and it has a few smaller ones for the background and parallax layers (which do not work yet in my previews). Every tile is referenced by a two byte integer that also specifies the orientation of the tile which means we need more than 87,330 bytes to store each layer, meaning 261,990 bytes for just the three main layers and there are five more! To save space the Jazz2 file formats make extensive use of zlib compression already but they have used an even more cleaver trick to reduce the amount of storage required. By creating a dictionary of unique combinations of four tiles (called a "tile group" in the documentation I found) only 2 bytes are required to refer to the dictionary entry instead of 8 bytes required for the individual tiles we save space! Or they did I guess. With this trick only about 22kb are required per layer resulting in just 66kb for the three main layers. Pretty neat right....if you understand what I am talking about that is :lol: (read all about it here).

    So after I had finally figured this stuff out I tried drawing the tiles using this dictionary lookup directly as it's used in the data files and never really looked back! So you might be wondering how the solid objects like the floor's and walls are defined in the level layers. Surprise!...They're not!!!:huh: It's actually the tileset with the graphics that has a second imagemask for each tile! Actually they used another trick to save memory by reusing the same tilemasks but that is another story I guess! This allows pixel perfect collision detection to be implemented into the game but the only way I could do it would be far to slow, so I cheated a little in my v0.2 preview by just having a "solid" tile or not and checking if the tile below the player is solid or not. I have written a fast pixel perfect solid detection function but again...I cheated by defining the solid parts of a tile not with actual pixels...but with math! It's difficult to explain well but I noticed how the solid parts were mostly rectangular and on the edges so the code below is how I implemented it:
    Code:
              switch(_map_) {
                case 0x01:  if(rx<=5)                  {solid = true;}  break;
                case 0x02:  if(ry>=25)                 {solid = true;}  break;
                case 0x03:  if(rx<=5 &&ry>=24)         {solid = true;}  break;
                case 0x04:  if( (rx<=5) || (ry>=25) )  {solid = true;}  break;
                //////////////////////////////////////////////////////////////
                case 0x06:  if(rx<=4 &&ry>=24)         {solid = true;}  break;
                case 0x07:  if(rx<=5)                  {solid = true;}  break;
                case 0x08:  if( (rx<=5) || (ry>=25) )  {solid = true;}  break;
                case 0x09:  if(rx<=5)                  {solid = true;}  break;
                case 0x0A:  if( (rx==0) || (ry>=25) )  {solid = true;}  break;
                case 0x0B:  if(ry>=25)                 {solid = true;}  break;
                case 0x0C:  if(rx<=5)                  {solid = true;}  break;
                case 0x0D:  if( (rx<=6) || (ry<=10) )  {solid = true;}  break;
                case 0x0E:  if(ry<=9)                  {solid = true;}  break;
                case 0x0F:  if(rx<=3 &&ry>=25)         {solid = true;}  break;
                case 0x10:  if(ry<=10)                 {solid = true;}  break;
                case 0x11:  if( (rx>=21) || (ry>=26) ) {solid = true;}  break;
                case 0x12:  if(rx>=21)                 {solid = true;}  break;
                case 0x13:  if( (rx>=21) || (ry<=19) ) {solid = true;}  break;
                case 0x14:  if(ry<=18)                 {solid = true;}  break;
               
                //case 0x15:  if(ry>=25)                 {solid = true;}  break;
                //case 0x16:  if(ry>=25)                 {solid = true;}  break;
                case 0x17:  if(ry>=25 && ry<=26)       {solid = true;}  break;
               
                case 0x18:  if(ry>=25)                 {solid = true;}  break;
                case 0x19:  if(ry>=25)                 {solid = true;}  break;
                case 0xFF:  solid = true;  break;
                  default:  solid = false; break;
              }
    
    During loading of the tileset the maskaddress assigned to a tile is translated into the magic numbers in each of these case statements.
    Code:
              //Primitive collision map generation
              colmap = 0x00;
              switch(J2T.tileset->MaskAddress[idx]) {
                case 0x000000: colmap = 0x00 ; break;
                case 0x000080: colmap = 0x01 ; break;
                case 0x000100: colmap = 0x02 ; break;
                case 0x000180: colmap = 0x03 ; break;
                case 0x000200: colmap = 0x04 ; break;
                case 0x000280: colmap = 0xFF ; break;
                case 0x000300: colmap = 0x06 ; break;
                case 0x000380: colmap = 0x07 ; break;
                case 0x000400: colmap = 0x08 ; break;
                case 0x000480: colmap = 0x09 ; break;
                case 0x000500: colmap = 0x0A ; break;
                case 0x000580: colmap = 0x0B ; break;
                case 0x000600: colmap = 0x0C ; break;
                case 0x000680: colmap = 0x0D ; break;
                case 0x000700: colmap = 0x0E ; break;
                case 0x000780: colmap = 0x0F ; break;
                case 0x000800: colmap = 0x10 ; break;
                case 0x000880: colmap = 0x11 ; break;
                case 0x000900: colmap = 0x12 ; break;
                case 0x000980: colmap = 0x13 ; break;
                case 0x000a00: colmap = 0x14 ; break;
                case 0x000a80: colmap = 0x15 ; break; //-----------------
                case 0x000b00: colmap = 0x16 ; break; //-----------------
                case 0x000b80: colmap = 0x17 ; break; //-----------------
                case 0x000c00: colmap = 0x18 ; break;
                case 0x000c80: colmap = 0x19 ; break; //-----------------
            }
    
    Using these replacement numbers and fixed calculations instead of the actual masks makes my whole collision detection code very static and tied to this single tileset! Meaning it would be impossible..or a lot of work...to add a second tileset. And eliminate the possibility of ever using a third or fourth tileset without another set of translation codes again! This is not acceptable for the long term and I need to change that really soon if I ever want to support other tilesets than just the one I have now! And this is only to make the basic wall and floor appear solid...this does not even take into account how the objects like: Batteries, Rafts, Belts, etc are handled and checked for solid parts! The simple explanation would be that objects also have a mask image to indicate what is solid or not....and I don't make use of that at all!! The only reason for not using those is that my current collision detection is using the bad coding example above...and it gets even worse!! :shy::cry::sad:

    While drawing layer 3 and 4 an array called the "solid map" is build which is just a little more than the visible area on screen. So to make use off this array it needs a lot of calculations to get the positions right and compensate for the camera offset, and this is part of the reason why at the edges of the map the collision detection get's confused and even worse than it is normally. This already bad method to detect collisions got even worse when I included the objects into the same "solid_map" array using a different ID ofcourse than the floors or walls I can kind of detect batteries, extra life's and all other interactive things that got solid in my latest release. Remember the bug causing allowing you to collect a single battery multiple times at certain places? Errors in the calculations in the offsets of the player's position, the start of the solid map and a few other coordinates translating back into the "Event map" which I still need to explain is why that is possible!

    The objects you can collect and interact with are called events and are loaded into the event map. Each event is four bytes long and could be considered an extra layer the same size as layer 3 and 4 (355x123) where each entry points to a single tile position and the total size is 174,660 bytes for this level. Not every tile has an event ofcourse and for those all four bytes have a value of 0x00 but it still wastes unnecessary space. To see how much RAM is wasted I have counted the events and there are only 459 in total. I have not decided how to implement a solution for this yet but if I would just store the X and Y in two 16 bit integers and a copy of the 4 bytes from the event map I would need just 8 bytes per event. Unless I have miscalculated (8*459) I would only need 3,672 bytes to store every single object in the event map!! That is almost 98% less memory required!!!!! If I would add a width and height for the object into the new structure I might need an additional two bytes...so 10 bytes...that's easy: 4590 bytes!! Still 97% less memory than the full event map!!! Ofcourse most of the current platforms have more than enough RAM to not even care about memory usage that much, but my future plans of also supporting more limited systems will benefit if I can pull this optimization off at the same time of fixing the collision detection.

    Did I say already this was going to be long, boring, and confusing? If you're still reading along here...wow! Congratulations on your patience...and thank you for your interest. Please bare with me...it's almost over. Really! :lol:

    Looking back on my novel above here I think the short version would be that my whole game engine is based far to much on the Jazz2 level file format. And nothing from the tutorials and best practices I have read used the method I have, and combining rendering code with game logic is considered a bad thing. In theory and thinking way out of the box...game logic could run on one machine while the rendering happens on another....which is useful in case anyone would be interested in some online multiplayer action at some point.:lol:

    What I have been trying to design the last few days is a new set of classes that will be much more structured and optimized to be more flexible. My game engine should only provide the very most basic event / object loading and the game using it should implement derived classes that provide the behavior for an object. The most simple event would be the start position of the player when the level loads...but it's not really an event actually. It should just set some coordinates in the world class. The battery would be a better example since that has an animation sequence and when collected by the player it needs to play a sound and remove itself from the map. A recharge gate has animations on different sprite layers and fills up the health bar. It also triggers the players animation and all of this should not be part of the game engine library....which it is right now. I need to move that code out of the game engine and into the specific "batterycheck" part of it. Nothing the player of my game(s) would notice but it makes using the engine for "Jazz2" and "SuperTux" a lot easier in the future. :D

    This blog got far longer than I expected but I hope anyone finds it interesting to read how I did things and why. I have not gone that much into detail as I planned originally about how I had implemented the physics of my engine. Guess that will have to wait for some other time ^_^

    Thank you for your time. :D
  • Archerite

    BatteryCheck - Collision detection is finally improving...

    When I first started on BatteryCheck it was actually just a viewer to browse around the level and make sure I implemented the loader according to the specs. To make my demo a bit more fun and give the player something to do I really wanted a way to control Batteryman and make him stand on platforms. While my very primitive collision detection works it does not do any correction at all! And this is the reason you can get stuck in walls or sink in the floor after jumping. This obviously needs to be fixed for my next version and I have given myself a deadline of at most three months! (hopefully it will be sooner though)

    Reading the Sonic Physics Guide again from the start helped refreshing my knowledge on how collision detection and response work for the older sonic games. If you want to know what I am talking about below you could read the Solid Tiles section until the A and B sensor lines used to detect the floor. The most important part of it is that there are two sensors instead of just one and they work together to detect the floor and slopes in Sonic games. The slopes are not important for BatteryCheck but they might be late when my engine could be used for Jazz Jackrabbit and SuperTux. The ground is only there when both sensors are triggered and if it's just one while walking you are walking on a ledge, and that should trigger a different animation of BatteryMan balancing trying not to fall. I am not sure yet what to do when only one of the triggers is activated while falling but I think I will ignore it until they both detect solid ground. When jumping the A and B triggers should be disabled and only detect again when you start to fall down, the reverse is true for C and D which are detecting the Ceiling.

    The detection of solid pixels with the sensors is already working for the map meaning: floor, walls and ceilings. When this is detected for the floor I force the player to a 32x32 grid aligned position which is actually working much better than I expected. But what is actually required when a sensor detects a solid pixel is finding the surface of the solid object by moving in the other direction. To give an example when running into a wall at a speed let's say 3.5 pixels per frame (the max speed in BatteryCheck it's possible to get stuck into a wall at least that deep. So when the pixel is solid at offset 35 to the right a loop should be testing it at 34,33,32,etc until a non-solid pixel is found and correct the player position accordingly.

    With these improvements in place the collision detection feels a lot more like it should be. The next thing to do is include the interactive elements into the isPixelSolid() function to make the floats, elevators and conveyors solid again too. Combined with the correction explained above the player should then also move when an elevator is moving or a float sinks into the water. Speaking of water...this needs to be detected separately because in water you take damage and can actually survive a while before sinking to the bottom. But let's not jump into that right now :lol:

    Hopefully this technical insight into my progress was interesting enough, please let me know ;)
  • Archerite

    First impressions of the PS Vita

    Last week I posted about my plans to port batterycheck tot the PlayStation Vita and that I got a PS Vita TV for really cheap. I wanted to mod the thing ofcourse but being new tot the Vita I had no idea what's out there and the risks of modding. What I have always wanted a Vita for is remote play of PS4 games...even though I did not even have one until recently :rofl:

    The fear of using my 'actual' PSN account on the vita tv made me look around for a used vita's. After some hunting I found one in a pawn shop about an hour away for an acceptable price. I decided to keep this original for a while since I have some warranty on it. So I tested remote play ofcourse and while the quality and lag surprised me in a good way....the controls are TERRIBLE for racing games that require analog controls on R2 for the gas. Some genius at sony or EA thought the back touchscreen would be 'great' for mapping the L2 and R2 buttons as digital triggers!:gun:
    And the worst of that is it's not just L2 and R2 but also L3 and R3 that are mapped as a tiny square on there without ANY way of customizing the button mapping ofcourse:nayps3::gun::angry:
    In short Remote Play is awesome and terrible at the same time, and while really cool I have not decided if it's worth keeping this Vita original just for that. I have also downloaded some demo's from the store and bought a few PS1 games since they were cheap and I had some money left on my account :lol:
    I only have three physical Vita games but do plan on getting some of the more popular titles like: Wipeout, Gravity Rush, and maybe a few others ^_^

    And while I had two systems at this point I just wanted the slim version as well...and had a great deal on that again so I went for it! Hahaha:rofl: Just a week ago I did not have any Vita system and now I have all three in my collection already!:D This also gave me a change to compare the OLED and LCD screens between the models and at first sight they looked the same to me, until I took the pictures below:
    20200106_074323.jpg 20200106_074353.jpg 20200106_074339.jpg
    The colors on the OLED are much brighter and clear at all angles than on the LCD when they are next to each other like this. But on their own I actually like the Slim version because it is brighter and weighs a little less than the original. Just to be clear: This is the youtube video I have posted before playing on the Vita's and not my actual homebrew version. I just wanted to see what it would look like and this gives a very good impression I think.:)

    I did a lot of research on how the mods and exploits work (or how to perform them) but still my fear of my PSN account is holding me back from actually doing it. I am thinking of creating a 'dummy' PSN account to be used just for the modded Vita's and see what happens later. All three vita's are at 3.73 so I have to take the difficult exploit route for them unfortunately :sad:

    Until next time...
    alexander1970 likes this.