Homebrew Batterycheck - Remake of an old PC platformer

[Archerite]

My fault. The dir is /data/batcheck and not DATA/BATCHECK. The name is correct, but i forgot in mention that the .dol file is in SD´s root and im running it via wiiexplorer because the homebrew channel not recognize it like app.
Thanks for your support

I did make a small mistake in the path name in case you would have used the sd:/apps/batcheck/data which should be sd:/apps/batterycheck/data. But since you said you used sd:/data/batcheck that can not be the issue. Either way I have updated the instructions above to have the correct path it looks in.

On the wii there are two paths checked to look for files:
1 - "sd:/apps/batterycheck/data/%s"
2 - "sd:/data/batcheck/%s"

This comes directly from my sourcecode and the "%s" part is replaced at runtime by the file the game needs at that moment. It should work when the files are in one of these paths but since they are small you could also just put it in both and see if that helps. I have personally only used the developer method to launch the game directly from my PC with a tool called wiiload, but this is helping me see the point of giving better feedback when things go wrong and making the installation process more user friendly.

Your welcome, but for me it's natural to give support if I ever want more people to be able to enjoy my version of this great game. Thank you for helping me improve on the installation instruction and making them more clear.

@Archerite Maybe you could put the next preview into a zip containing subfolders like many homebrew apps:

ZIP:/apps/batcheck/boot.dol
ZIP:/apps/batcheck/meta.xml
ZIP:/apps/batcheck/icon.png
ZIP:/apps/batcheck/data→[empty folder]

How about this icon?
View attachment 157940

I think that will indeed make it more user-friendly for the next release. Until now it was more a proof-of-concept demo but now it has become a playable game it makes sense to conform to the standards I guess. Thanks again for the tip!

I am a bit careful to include any icons made from the original graphics to prevent copyright issues at the moment. I was thinking of generating an icon at run-time just like I already do for the textures and then save that as a PNG image or something, but It's not really a priority and the extra graphics libraries will increase the size of the DOL file. Having said that...it does look really cool and professional to have it. I do feel batteryman is a little out of place in that icon for some reason. That blue looks very familiar, did you make this your self by taking screenshots of the title screen?

@niuus: I have been working on the "overscan settings" and it's almost finished!

 

[Ericsonanzois]

@Archerite Maybe you could put the next preview into a zip containing subfolders like many homebrew apps:

ZIP:/apps/batcheck/boot.dol
ZIP:/apps/batcheck/meta.xml
ZIP:/apps/batcheck/icon.png
ZIP:/apps/batcheck/data→[empty folder]

How about this icon?

That should not make any difference.
Starting "batterycheck-wii-preview-2.dol" from the SD root with WiiXplorer as Wii Homebrew works for me.

For the Homebrew Channel to show anything it must be renamed to boot.dol:
correct:
SD:/apps/batcheck/boot.dol
wrong:
SD:/apps/batcheck/batterycheck-wii-preview-2.dol

Try another SD if possible.



@Archerite Maybe you could put the next preview into a zip containing subfolders like many homebrew apps:

ZIP:/apps/batcheck/boot.dol
ZIP:/apps/batcheck/meta.xml
ZIP:/apps/batcheck/icon.png
ZIP:/apps/batcheck/data→[empty folder]

How about this icon?
View attachment 157940

AH! This sound more familiar to me. Im sure that i missed something but i will see all suggestions here.

 

[niuus]

@niuus: I have been working on the "overscan settings" and it's almost finished!

I am patiently waiting to test those GC/Wii dols!

 

[KleinesSinchen]

After some digging I found one of the companies that worked on the game and I contacted them. The game is licensed as Creative Commons but I need to ask them which specific version.

You have no idea how long I've been thinking about copyright before even uploading a 128*48 graphic containing something from the game. Indeed it's necessary to know if they chose a "no derivatives" license of Creative Commons. I'm not an artist and therefore not able to make a good symbol from scratch.

I am a bit careful to include any icons made from the original graphics to prevent copyright issues at the moment. I was thinking of generating an icon at run-time just like I already do for the textures and then save that as a PNG image or something, but It's not really a priority and the extra graphics libraries will increase the size of the DOL file.

Hmmhm. I would say the problem stays the same. The complete artwork is licensed on Creative Commons version ??? Rendering something from the original files and putting parts of it into an icon file is a derivative as well. Grrr. Copyright sucks at times – having to think about a tiny graphic. We are missing something like the American "fair use" in Europe.

Having said that...it does look really cool and professional to have it. I do feel batteryman is a little out of place in that icon for some reason. That blue looks very familiar, did you make this your self by taking screenshots of the title screen?

It's a part of a screenshot when closing the game. I took the part with the text
Battery

Check​

and it turned out to be just good: It was possible to get the text with 384*144 so scaling down to 128*48 does not look awkward. The upper right corner was the only place big enough to include the smallest symbol of Batteryman – as recognition factor. He looks hilarious but it's not easy to fit him in when having only ultra low resolution.

 

[Archerite]

You have no idea how long I've been thinking about copyright before even uploading a 128*48 graphic containing something from the game. Indeed it's necessary to know if they chose a "no derivatives" license of Creative Commons. I'm not an artist and therefore not able to make a good symbol from scratch.

Hmmhm. I would say the problem stays the same. The complete artwork is licensed on Creative Commons version ??? Rendering something from the original files and putting parts of it into an icon file is a derivative as well. Grrr. Copyright sucks at times – having to think about a tiny graphic. We are missing something like the American "fair use" in Europe.

It's true that copyright for old games make fan remakes like this really complex and tricky. I have been looking at the exact reply I got from the company I contacted and there might be some room to allow the icons. The e-mail is in dutch but roughly translated they said: The graphics and designs are not allowed to be used separately or for other purposes.
it's a big guess and it might be better to ask for permission before I actually do this myself....but an icon based on the original graphics is only meant to identify the game (or my remake to be more exact) and nothing else right?

I have been waiting with my reply to them until I had something to show that actually worked, and now it's been almost three months it feels a bit late. Either way I will contact them soon to clear up the license version and their view on using parts of it as an identifying icon. They explained it to me like this when asking how the game was licensed: The license is Creative Commons, you can mention the game, refer to it,link to it, but not use it for commercial purposes.
I have been very clear from the beginning that this is a remake and I do not own the graphics which is why the installation of the original game is required. I have absolutely no intentions to sell it or claim that I created those graphics or designed the levels and music. I can only claim that the engine that makes it run on other platforms is my own to do with as I please and choose a license for that I am comfortable with. (it will be open source eventually)

I know generating the icon and writing it to png is not much different but at least I am not "distributing" those graphics directly. Same as the sprites are converted into textures for the wii and loaded at runtime from the original files. It's going to help maybe that the same engine in a different configuration will be able to also load levels from Jazz Jackrabbit2 or SuperTux 2. In a way I think it's about the same position as OpenRCT2 is using the Rollercoaster Tycoon 2 graphics and deeply reverse engineered the original game engine. I have not done the reverse engineering part but the original graphics requirement is about the same. And their site is loaded with graphics and video's that use the original graphics but since it's mostly for the same game and they require/advise you to buy and install the original side-by-side I guess they are "allowed" to use it like that.

It's a part of a screenshot when closing the game. I took the part with the text
Battery

Check​

and it turned out to be just good: It was possible to get the text with 384*144 so scaling down to 128*48 does not look awkward. The upper right corner was the only place big enough to include the smallest symbol of Batteryman – as recognition factor. He looks hilarious but it's not easy to fit him in when having only ultra low resolution.

I have actually played around with an icon myself for the GameCube banner while I was still trying to make a disk image out of it. Also on the 3DS I had an icon while it was still unreleased I only removed them for the reasons above.

I hope you are not offended by my worries about copyright too much...It's really cool you took the effort of creating the icon and I did not mean for you to remove it. I was only saying I would not be proving on with the next preview release without actual permission to do that. I think the different shades of the batteryman color's made him look out of place since the logo was kind of "blurry and fuzzy" in a good way and he was very sharp and "dull". Hope that makes any sense?

Like I said I will contact them again and explain my progress and how nice it would be to have an icon that looks like it's part of the game. But before doing that I want to improve a few things so it wont look like total crap ware or something I will keep you all updated on the progress and when I have send them a message.

 

[Ericsonanzois]

Well i would like say that i did the instructions:
1 - Created a sdd:/apps/batterycheck/data dir;
2 - I copied the files in data dir;
3 - I copied the battery...dol file in /apps/batterycheck dir.
4 - I renamed the dol file to boot.dol
5- HBC recognized like a app and it worked.
I hope that we can have soundtrack in preview game in future. Congratulations.
Thanks a lot for all here that helped

 

[Archerite]

Well i would like say that i did the instructions:
1 - Created a sdd:/apps/batterycheck/data dir;
2 - I copied the files in data dir;
3 - I copied the battery...dol file in /apps/batterycheck dir.
4 - I renamed the dol file to boot.dol
5- HBC recognized like a app and it worked.
I hope that we can have soundtrack in preview game in future. Congratulations.
Thanks a lot for all here that helped

I am glad it all worked out and you got it running. As much as I would like to add the background music, there is no library directly available for to wii to use for that. I did get it working on the 3DS but it slowed the gameplay down far too much, like in slow motion! It did give me hope to get there one day since I learned what format the files are in.

I said earlier I would not release a new version very soon, but I might have changed my mind a bit. Your issues actually made it clear to me I need some more checking if the files are there and give proper warnings about it if they are not.

Or to be more precise I need to make them visible on a real wii, as I can see them while debugging on Dolphin. The 3DS has the bottom screen and on Linux I have the terminal output directly so it was not a big priority to fix it.

Thank you, and I hope you are enjoying the preview so far.

EDIT: In an attempt to improve level loading and make the code more readable I have changed nearly 1000 lines of code a few weeks ago. Unfortunately this same change broke the Wii port somehow...so that's going to take a while to figure out!

 

[Archerite]

The last few weeks I had less time for this project because of other priorities and being sick (just a flu and cold) also does not help getting things done efficiently. Now that I am feeling better and it looks like I might have some more time to work on it again I hope to hunt down the bug I mentioned in my last post!

The changes I made were required to improve loading and parsing of the level so that in turn it would be easier to use for the collision detection. Testing on Linux and 3DS gave no issues and since my time was limited I moved on with trying to add a PSP port. Luckily I am using GIT to manage the source code so I know which commit is causing trouble but it changed over a 1000 lines of code in multiple files, which I will admit is bad practice. Do not do that again!!! I will try fixing it this week and if I can't I might just branch of from the last known good point and later redo the "big change" in smaller steps.

If all goes well preview 0.3 will be ready within a couple of weeks and have the following improvements:
- Adjustable HUD overscan settings
- Error messages on screen when files are missing
- Basic "wall detection" so you can not walk into a wall anymore.
... I wanted to include even more....


So that is my little progress report for now.

 

[Archerite]

I have finally figured out the problem was related to incorrect conversion of the level data into BigEndian! Or to be more precise it was incomplete

Glad to get this out of the way!

 

[Archerite]

I have been playing around with the menu and adding English captions. I am not happy with it yet as yellow letters on a yellow button is not such a good idea...but it's what's already in the game files.

So here is menu 1:


And menu 2 (ingame):


Selecting an option is already working as I reused most of the code I wrote for the NDS last year. Even the blinking 'light' works!

Now I need to look at some resource management to clean up the textures and free memory when the menu "hides away in the background". But anyway the next preview release is going to have this menu enabled

 

[niuus]

I have been playing around with the menu and adding English captions. I am not happy with it yet as yellow letters on a yellow button is not such a good idea...but it's what's already in the game files.

So here is menu 1:
View attachment 159777

And menu 2 (ingame):
View attachment 159778

Selecting an option is already working as I reused most of the code I wrote for the NDS last year. Even the blinking 'light' works!

Now I need to look at some resource management to clean up the textures and free memory when the menu "hides away in the background". But anyway the next preview release is going to have this menu enabled

Looking nice, man! It's exciting to see how this is taking shape.

 

[Archerite]

Looking nice, man! It's exciting to see how this is taking shape.

Thanks!

While some more tweaks to the colors are required I have a first sample with orange:


I might try it in a darkblue variant but at least this is already much more readable than the original Yellow I think.

 

[niuus]

I might try it in a darkblue variant but at least this is already much more readable than the original Yellow I think.

Totally! I dig it.

 

[Archerite]

I have been trying to make the menu work on the 3DS but for whatever reason it keeps crashing. I did finally manage to get something done that was on my whishlist for a long time....release a raspberry pi (linux) version without the need for a windows PC to get the gamefiles! To make that happen I had to reverse engineer the Setup.exe and figure out what kind of compression they used in their custom archive format. I made a few blog posts about my findings and last night I finally discovered how they did it!

Spoiler: The very technical details for those interested....it's REALLY long!!

As I said in my blog the archive format itself was not that difficult as it's very structured and knowing the filenames helped a lot. I noticed that the typical ZLIB header signature 0x78 0xDA did appear on some of the files but not on others. And even where it did it was at a different position so I thought it might just be a coincidence inside the data or something.

I spend many hours debugging the executable inside ollydbg (a windows debug tool) and watched how the x86 assembly instructions got executed and I could single step through them, set breakpoints and more nice stuff. It's just that I have no experience with x86 assembly but some instructions looked similar to Motorola 68K which I do know a little better. The hard part is following which part of the code was actually windows DLL libraries and function calls and what came from the installer.

While the debugger lacks a nice modern user interface it does have a lot of cool features that really helped me figure things out. One of the things it did was match memory addresses in registers to strings, and that is how I saw error messages that ZLIB throws at you. After tracing from where that function got called I found the loop that goes through each of the files. But other than that I could not figure out where it parses all the fields from the archive format and how they are used.

It was actually a linux tool 'strace' that I used in combination with wine to log system calls. It showed a detailed log of how many bytes it read from the archive for each file. This helped me see the header's for each file is 30 bytes and I had already seen the uncompressed file size, uncompressed filesize, and filename length in there. It also contains a few mystery bytes that are the same for all files and probably some kind of CRC of the uncompressed file, but I did not check that yet.

The ultimate key that lead me to successfully unpacking the files with a python script was that each file has a number of compressed deflate stream chunks that are of different size and prepended by a crc32 checksum of that chunk. After the filename there is a sort of index or table that holds the size for each block, but since every file has a different amount of blocks this table is of different size too. I have not been able to find out yet how the installer knows how many blocks are listed inside the table, it's not inside the file header anywhere!

So knowing this I put together a simple python script that unpacked one of the smaller files but it failed. I had seen some of the files do have the zlib header and some do not so I just thought let's start with one of those. Uncompressing the first block from Battery.exe resulted in the correct data of the file!!!! Adding code for the second block and that too was correct! So now I knew for sure it was a ZLIB stream and just had to take the chunk table and loop through that to get the complete Battery.exe....and it worked flawlessly! Comparing the just uncompressed file with the "normally installed" version said "Files are identical".

Now I was really motivated to unpack EVERYTHING! It did not really occur to me until I tried it that maybe the zlib context was shared between some of the files, but that is how they did it! Probably to make use of the dictionary from the previous file for better compression or something. I even noticed a byte in the header that indicates the zlib context should be refreshed that I could use, but for now I just do it manually since I know when it should happen. I will optimize that before converting the python script into C++ for more compact code.

Maybe I left out a few details but this already became a huge wall of text full of low level technobabble, which is why I put it inside a spoiler block. Hopefully it was interesting to some of you to know how it works, and I apologize if it sounded like a foreign language to you. But I did warn you with the spoiler title

The idea is to integrate some kind of installer into my preview versions that will search for the required game files and when they do not exists yet it will look for the "batterycheck.zip" or Setup.exe in the root of your SD card. Then it will unpack the files into the correct location and give the option to remove the installation files. I am not sure yet how I will make it look but at first it might be a simple text based interface. When all files are found or successfully extracted the game will start normally as it does now.

I will post a list of updated features that will be implemented in v0.3 in a few days.

 

[Archerite]

After a successful conversion of my python script into C++ I have released a preview of the installer for the 3DS yesterday....with instructions how to use it and a big warning that it's an experimental feature and lacks a few things. Last night I have been working on improving it with more visual feedback, file integrity validation and checking if the Setup.exe actually exists. I have also made the necessary changes (remember the byte ordering?) to make it work on the Wii and hopefully GameCube. While it's working fine I kind of disliked that a user was still required to perform manual steps like having to unpack the Setup.exe from the ZIP file and creating empty directories, things an installer are supposed to do right! In the 3DS thread I already said something about maybe having the installer unpack the Setup.exe directly from the ZIP file and I have been looking into how that might work.

To simplify things a lot I did not want to rely on an actual ZIP library since I can pretty much assume the installer only needs to care about the exact same version of "batterycheck.zip" every single time! Doing a bit of research on the zipfile structure and knowing the size and position of the compressed Setup.exe inside the ZIP there is no need for anything else than just plain simple zlib that I was already using anyway! A new user would only need to copy "batterycheck.zip" to the root of the SD card and then my custom installer would decompress Setup.exe, extract the game files into the proper directories and also install the embedded preview version of my game engine! How is that for user friendliness?

So here are some of the new features planned for v0.3:
- Adjustable HUD overscan settings
- Error messages on screen when files are missing
- ability to stand on belts, floating platforms, and elevators
- Basic "wall detection" so you can not walk into a wall anymore.
- Mostly functional menu system (see screenshots a few posts back)
- Custom installer that unpacks the required files directly from the "batterycheck.zip" on the console itself!

Not all of these features are implemented yet so no promises on how soon it will be available. But since the custom installer is about 80% done and a separate build at the moment that I have also released already for the 3DS I will also do that for the GameCube and Wii versions here too, but I really like to add the ZIP file decompression first and have the installer create the directories. Hopefully it will only take a few hours but it could also be a few days

EDIT: I have almost finished the installer and just need to find some time to test it on my real Wii before I upload it. Dolphin is giving lot's of graphics issues because of the text only output my installer uses, from what I know the real Wii hardware should work fine. I also need to cleanup the code a little bit and add a few more checks here and there to prevent some possible crashes if batterycheck.zip does not exists.

 

[Archerite]

The installer had a few issues that needed to be resolved first, but I have finally been able to test it on my real Wii hardware it's working great! Here is how it looks in dolphin:



It's only text output for now and I will at some point replace that with a more graphical GUI, but that is going to take a very long time and this is working already. Those weird looking numbers are the CRC-32 checksums of the files when uncompressed and those are validated for each of them. When it does not match the known value it gives an error on that file.

To create the required directories I need to look into either blindly creating them or some kind of smart way to recursively create them. There does not seem to be a standard C function to do this. I have also been trying to embed the boot.dol and meta.xml into the installer and it seems to work, it just makes the binary really large and I want to look into compressing it first, but this needs to be automated and only embed the correct version for each platform so I have disabled that for now.

When I am confident enough this will work for others I will release it for: Wii, GameCube and 3DS with an experimental warning next to it. I am hoping this will make it easier for people to install the gamefiles and enjoy my version of the game....eventually...when it's completed.

 

[Archerite]

I have been too busy to get anything worth mentioning done for BatteryCheck. I did some research on free to use game assets so I can make the installer make use of the GPU and look nice. The same library that I will build for this could potentially be used for in game debugging or other stuff that needs a GUI outside of the game. I'll start with just plain simple interface like the one used on my IPTV setup-box. It's made up from simple different color rounded rectangles and some text. I am not planning on making a clone of this GUI but it did inspire me to do a little more research on how to do this. To give an idea of what I mean I borrowed a screenshot from my providers reset instructions. (text is in Dutch and not important)


The plan is to make a universal "GUI library" with a few helper functions to draw the required graphics using the GPU of the console. This also makes it possible to resize elements when required on the 3DS for example. And since there are no textures in use it does not make it more difficult with swapping and mapping those around. I have actually used a similar technique to implement the transparent water effect that is already in preview v0.2 right now! Every pool of water is drawn with 6 quads at different layers with a transparent color.

I talked earlier about creating directories and detecting existing files. I have been looking into how the actual linux "mkdir -p" command works and it basically goes through the path a single character at a time, and when a "/" is found it tests if that path exists. If it does not it creates it and continues to the end of the string. It's too bad that newlib which is used for the Wii has not included this extra option for it's mkdir() function. I decided to take the quick-and-dirty method and just create each directory required and ignore any errors returned by mkdir().
I did found a nice and simple fileExists() function that I want to use to check for the existing files and give the user an option to cleanup after installation. For the Wii I could check in "/data/batcheck" and present a question or checkbox to "Remove files from old paths" and "Remove BatteryCheck.zip" in an attempt to cleanup the mess I made for exiting users.

Since the installer is going to be a separate binary was also thinking of using the GD library to have it extract, rotate and convert the graphics from the menu into a logo.png for use in the homebrew channel. Since it's generated by the installer from the installation files I am not distributing.

What I also want to do is have the installer auto detect either Setup.exe or BatteryCheck.zip so it can be used by new, existing and original CD users. I know the CD is not readable directly by the Wii and requires a manual copy to the SD card. I have not tested running the installer or the game from a USB stick but this might work since it's supported by the Homebrew Channel right?
I might also change the display of CRC-32 values to SHA-1 instead since I have posted those a few months ago, or just hide them entirely and just say "OK" or "FAILED" for the users.

So this was my weekly status update I guess

EDIT: I have a little proof-of-concept screenshot from Dolphin showing that my idea actually works! I am still looking at either using FreeType fonts or just a small spritesheet, for now the blue blocks stand in for the characters. Rounded corners took some time to figure out but using a "triangle fan" and some fixed coordinates helped to draw some "buttons". Lot's of room for improvement but here is how it looks...

 

[Archerite]

I have done some more research on how the Wii hardware works at a lower level for a few future projects, which distracted me for a while. I did improve the GUI drawing functions a little as you can see on the screenshot below. It's much easier now to position the window and it's widgets where I want but the corner radius is fixed. I also don't really like how it looks with these colors so I might change to a spritesheet based on a desktop theme or free to use game-ui assets after all.

Spoiler: Steps the installer will take under the hood...might not be interesting for everyone

Whatever I decide to use for the GUI here is a few steps, actions and questions the installer will go through:

1. Search for existing installation in: "sd:/data/batcheck/" or "sd:/apps/batterycheck/data"
2.   if not found:
3.     Search for "sd:/batterycheck.zip", "sd:/apps/batterycheck/batterycheck.zip", "sd:/Setup.exe" or "sd:/apps/batterychec/Setup.exe"
4.       If not found: "ERROR: Installation files not found!"
5.     Extract or open Setup.exe and load into memory
6.   Jump to #12
7.   When exiting files are found:
8.     Ask: Upgrade or remove old installation?
9.       If Upgrade:
10.       Jump to #15
11.      If "remove":
12.        Remove all old files found in #1
13.        Info: "All BatteryCheck files have been removed"
14.        Exit
15.  Create/verify required directories
15.  Unpack files from Setup.exe
16.    show progress bar during unpacking for each file
17.    check file integrity with CRC32 and SHA1 hashes
18.  Extract "boot.dol" or replace exisiting one
19.  Write "meta.xml"
20.  Generate "logo.png" using game files
21.  Info: "Installation complete"
22.  Ask: "Do you want to remove the installation files and/or older installations?"
23.    If "Remove All":
24.      Remove installation files listed in #3
25.      Jump to #12
26.   If "Remove old files":
27.     Jump to #12
28.   If "no":
29.     Exit

Almost looks like pseudo-code now that I look at it! :lol:

I have also been looking into using dolxz to create a smaller installer executable since embedding the game DOL makes it almost double it's size! The embedding is already working and it's written to the SD card during installation. It did take a few tweaks to the source of dolxz to make it compile under linux and use the Devkitpro compilers. It seems that it was originally made for windows users but since it's opensource and uses Makefile's for the important parts I only had to change a few paths. Thanks to FIX94 for creating and sharing this on github! (I will contribute my changes later so others can use it on linux too)

I hope all these technical explanations are not too boring or distracting anyone from the main project......I will get back onto improving the actual game really soon. I just felt the installation requirements could use some improvement to have more people get interested in my project(s)

 

[niuus]

I have done some more research on how the Wii hardware works at a lower level for a few future projects, which distracted me for a while. I did improve the GUI drawing functions a little as you can see on the screenshot below. It's much easier now to position the window and it's widgets where I want but the corner radius is fixed. I also don't really like how it looks with these colors so I might change to a spritesheet based on a desktop theme or free to use game-ui assets after all.
View attachment 165418

Spoiler: Steps the installer will take under the hood...might not be interesting for everyone

Whatever I decide to use for the GUI here is a few steps, actions and questions the installer will go through:

1. Search for existing installation in: "sd:/data/batcheck/" or "sd:/apps/batterycheck/data"
2.   if not found:
3.     Search for "sd:/batterycheck.zip", "sd:/apps/batterycheck/batterycheck.zip", "sd:/Setup.exe" or "sd:/apps/batterychec/Setup.exe"
4.       If not found: "ERROR: Installation files not found!"
5.     Extract or open Setup.exe and load into memory
6.   Jump to #12
7.   When exiting files are found:
8.     Ask: Upgrade or remove old installation?
9.       If Upgrade:
10.       Jump to #15
11.      If "remove":
12.        Remove all old files found in #1
13.        Info: "All BatteryCheck files have been removed"
14.        Exit
15.  Create/verify required directories
15.  Unpack files from Setup.exe
16.    show progress bar during unpacking for each file
17.    check file integrity with CRC32 and SHA1 hashes
18.  Extract "boot.dol" or replace exisiting one
19.  Write "meta.xml"
20.  Generate "logo.png" using game files
21.  Info: "Installation complete"
22.  Ask: "Do you want to remove the installation files and/or older installations?"
23.    If "Remove All":
24.      Remove installation files listed in #3
25.      Jump to #12
26.   If "Remove old files":
27.     Jump to #12
28.   If "no":
29.     Exit

Almost looks like pseudo-code now that I look at it! :lol:

I have also been looking into using dolxz to create a smaller installer executable since embedding the game DOL makes it almost double it's size! The embedding is already working and it's written to the SD card during installation. It did take a few tweaks to the source of dolxz to make it compile under linux and use the Devkitpro compilers. It seems that it was originally made for windows users but since it's opensource and uses Makefile's for the important parts I only had to change a few paths. Thanks to FIX94 for creating and sharing this on github! (I will contribute my changes later so others can use it on linux too)

I hope all these technical explanations are not too boring or distracting anyone from the main project......I will get back onto improving the actual game really soon. I just felt the installation requirements could use some improvement to have more people get interested in my project(s)

I do enjoy your explanations, even if i am not an expert. Keep it up!

 

[Archerite]

I do enjoy your explanations, even if i am not an expert. Keep it up!

Thanks niuus, but I think you know more than you give yourself credit for...how else could you manage to modify the Snes9x GX emulator into the new RX version. (I must admit I have not really looked into what you have changed about it)

Like I said before I did not really like how my simple blue window theme looked, maybe I can fix it with different colors but it would just be too much work for what I need right now. I have been researching how the themes work in my XFCE4 Linux environment and it has been a lot of trial and error figuring it out what the images are used for. There are literally 140+ windowing themes on my system and even more could be downloaded if I would want too. Since Batterycheck is orginally a Windows game I thought it would be fun to try out a Windows XP theme to use with the installer for my game...here is an early mock-up I made using PyGame in Python3.


The top theme is called "RedmondXP" using "Windows XP Luna" widgets and should be familiar to everyone who have used WindowsXP before. The bottom one is "Windows XP Royale Dark" using "Greybird" widgets which is a mix of old and modern style. I am not sure which one of these I prefer yet or if I might choose an entirely different theme...maybe more like old style MacOS? I have put this screenshot as a static "background" into a test DOL and run it on my really small 36cm CRT TV on my Wii and it looks surprisingly authentic from what I remember WinXP looked like, hahahaha. I have been using Linux as my main OS for almost 12 years now so I have a few mixed feelings about using this theme, but it's also more fitting for the original game somehow. Another option I have been considering is using libwiigui or at least the looks of that to make the installer feel like an actual "Wii Menu App" or something like that.

I am curious how others think about making the Wii (and Gamecube) look like an old WinXP machine during the installation of Batterycheck.....

Edit: I have been digging into the blob of data in Setup.exe again that I had discarded earlier and found the graphics used by the installer inside of it. I changed the prototype window to look more like the original setup with a few checkboxes and the image extracted from the blob. And here is how it looks when the dumped screenshot is shown by the Wii on my CRT:

It's not functional or finished yet but I definitely think this looks great already and how I might do it. Next thing I will add is a cursor that can be moved with the wimote, nunchunck or Gamecube analog stick. I hope to release it in this style really soon...my plan is within 2 weeks. Always good to have a deadline right?