Welcome to the personal blog of Archerite

  • Archerite

    Devblog: How I handle multiple platforms in my game engine. (WARNING: very long and technical!)

    Just a friendly warning that this is a very long and technical blog post. My main reason for writing it was that I needed to rethink what I had done and how this stuff came into existence. You have been warned! :D

    My homebrew game project started around June 2018 shortly after discovering some essential documentation of the Jazz2 file formats. The earliest prototypes were written in Python3 since that was easy to modify and run without any headaches about compiling or memory leaks and memory pointers. In a few months I had an almost playable game running in Python (using Pygame/SDL) but it had some issues I did not like very much. Things like screen tearing and not being able to show the game to anyone without a full PC or laptop bugged me the most.

    While I wanted the game to be portable, as in on a portable device, I actually wanted to write a game for the GameCube after having bought my first one and reading a lot of technical documentation about it. I still had no idea how to do it but I did try looking at examples and stuff and how I could actually compile something for the gamecube. I am not sure if I tried devkitpro right away for something on the gamecube....but during my research I kind of looked at the NDS. The graphics part of the GameCube scared me and gave me headaches...I really did not understand how it worked! :rofl2:

    The NDS is off course less powerful than a GameCube but the way it's GPU works is very similar to what I knew form the Sega Mega Drive/Genesis...that I had wrote a demo for once but that's a story for another time. :wink:. Goging through the examples in devkitpro and compiling them, tweaking them, adding my own stuff...I managed to get the BatteryCheck menu mostly working and it could show the splashscreens. The problem was that all graphics had to be converted into png first, then resized to fit on the small NDS screen and the resized images looked awful. Until I learned about the lanczos algorithm that took out a lot of the rough edges. This still did not really feel like what I was looking for and the compromises for the small screen was not something I could live with. Which made me move to the 3DS!

    Now the 3DS is a whole different story! The examples looked a lot more complex but a lot of the complexity was handled by the citro2d and citro3d libraries that come with devkitpro for the 3DS. There was still the requirement to convert the graphics into textures at compile time on the PC but this time they at least looked normal and it was not required to scale them down! Sure, the lower resolution of the 3DS compared to the original 640x480 is still noticeable. But now I had a portable version I could work on and show to anyone who did not really want to see it!!! :ha::rofl2::rofl2:...some people got a little tired of me :shy:
    To make the screen move in a way I wanted though I had to use something deeply hidden in the citro3d library and it took me a few days to workaround it. I even had a thread on here about that and shared my solution really had no idea that was in September 2018! Time really goes fast! :O

    Within a couple of weeks I actually had a pretty good working and playable demo in a level I designed myself. It was a copy-paste version of the first BatteryCheck level I put together to test out a few things like: walking, jumping, falling, collisions, etc. I made it in the Tiled level editor with help of exported graphics from my python scripts. Then I converted the saved level and converted that back into something I could use on the 3DS. While this was working there was a really big flaw in my workflow....debugging was just impossible! If the game crashed on the 3DS I had no good way to figure out what happened and which bit of code caused the problem. If the jump was off that was "fixable" but an actual crash into a memory dump screen (forgot the exact name) is really taking guesses of what might be it.

    While working on the 3DS and reading into how citro2d and citro3d actually did things I learned about textures, vertices, UV coordinates and all that fun stuff normally used in 3D games. I tried a few weird thing in python to see if I had understood the concepts and had great results actually! Then I did a few OpenGL tutorials to learn how to use it and make a PC version of my game. But I also still wanted to run it on the 3DS! So what was my solution to this? I created an abstraction layer that is just a thin wrapper around either OpenGL on the PC or citro2d on the 3DS....and that is how that all started!:D

    The main thing I really needed after having worked a lot on a 3DS version was a way to easily debug the code on my PC. Running it in the Citra emulator helps...but that is not exactly what I wanted to do. I wanted to use Linux tools to find memory leaks, fix them and figure out where in the code things crashed on the 3DS! To make this possible I would need a way to compile the same code for both 3DS and Linux with very little difference between them. To do this I had to start over from scratch!

    I created a new makefile and created a directory called 'ports' and made sub directories for each platform: 3ds, gc, linux and wii! For the consoles I used the "sprites" demo's as a basis and on Linux it was OpenGL from the start but I tried glut and glfw before settling on glfw. I just wanted to do "make 3ds", "make gc", "make linux" and "make wii" to get my code compiled for those platforms. Then adding "-emu" for the consoles to start the emulator with the executable compiled just before. For linux I chose "-run" as that made more sense.

    There is a main Makefile that I use at the "root" of my project folder that in the beginning had all these command's as compile targets. But that became a little complex to maintain so I split those up into smaller ones for each platform.
    Code:
    ### Choose which type of engine to build
    #export APPNAME :=batterycheck
    #export APPNAME:=jazz2
    export APPNAME := squares
    
    
    PORTSDIR := ./ports
    include $(PORTSDIR)/make-linux.mk
    include $(PORTSDIR)/make-gc.mk
    include $(PORTSDIR)/make-wii.mk
    include $(PORTSDIR)/make-3ds.mk
    
    clean:
        @$(MAKE) --no-print-directory linux-clean
        @$(MAKE) --no-print-directory   wii-clean
        @$(MAKE) --no-print-directory   3ds-clean
    
    It took me a month or two to switch to this structure actually but essentially this is still what I use today! It just grew a bit with more platforms now :D

    Then for example the specific "makefile-3ds.mk" holds the actual commands for the 3DS:
    Code:
    3ds:
        @cd $(PORTSDIR)/3ds && $(MAKE) --no-print-directory
        @cp $(PORTSDIR)/3ds/$(APPNAME).3dsx ./$(APPNAME).3dsx
    
    3ds-emu:
        @citra $(PORTSDIR)/3ds/$(APPNAME).3dsx
    
    3ds-link:
        @3dslink ./$(APPNAME).3dsx
    
    3ds-demo:
        @cd ./source_/3ds && $(MAKE) --no-print-directory
        @cp ./source_/3ds/batcheck-demo.3dsx ./batcheck-demo.3dsx
    
    3ds-clean:
        @cd $(PORTSDIR)/3ds && $(MAKE) --no-print-directory clean
        @rm -fr ./*.3dsx
    
    And in the "./ports/3ds" directory is the "real" makefile that is the same as in the devkitpro examples with a few tweaks here and there. But that same idea is repeated for all the other platforms I have added over the years. Only for Linux I had to write the Makefile from scratch to work in a similar way to how Devkitpro is setup so it gives the same per-file output and same recursive search of source files and to put all compiled .o and .d files into a "build-linux" directory and stuff like that.

    The "ports" directories also hold the source code that is unique for each platform. Think of it like a miniature driver to access the GPU, AUDIO, FileSystem and INPUT of a system. There is (or should) not be ANY game or application specific code in these directories!
    To make a game or application work on any of the platforms that are supported in the "ports" directory without actually using any native function calls we need "abstraction functions" that are commonly implemented into the "platform drivers" to give access to Graphics, Audio, Storage and Input. The only exception to this rule is when a platform uses a big-endian architecture that needs byte swapping or other methods to make shared assets readable. Most notable currently supported big-endian platforms are: GameCube, Wii and Wii U. If in the future support is added for: XBOX 360 or PlayStation 3 then they benefit from the big-endian compatibility since all these consoles have a PowerPC CPU.

    Here is a nearly complete list of the functions that are in each "platform driver":
    - sysMainLoop() - called in the main loop of the code to do whatever the platform requires for that. Returns false if the app should exit.
    - sysExitLoop() - called just before exiting your game or app to do a clean exit
    - jzGPU_init(width, height) - This name should already imply what it does obviously, but besides initializing the graphics it also does FileSystem stuff in most cases.
    - jzGPU_startFrame() - called at the start of a frame
    - jzGPU_endFrame() - called at the end of a frame. this is where the framebuffers are swapped and updated on screen
    - jzGPU_exit() - does whatever a platform requires to be done for shutting down the graphics. And the FileSystem if that was done in init().
    - jzGPU_createTexture(img) - creates a texture from an image and returns the ID. On most platforms this creates real GPU textures.
    - jzGPU_drawQuadRGBA(x,y,width, height, r, g, b, a, depth - draws a colored rectangle using the GPU. It has MANY aliases to not having to specify all these parameters every time
    - jzGPU_drawQuadTex(sheet, x, y, tx, ty, w, h, flip_h, depth) - This draws a specified part of a texture on the screen. It's the basis of every sprite and tile that is drawn!
    - jzGPU_translate(x, y, z) - translates the offsets to the current matrix (see glTranslatef for detailed info)

    jzCONTROL:
    - jzCONTROL_init() - does what is required to setup input
    - jzCONTROL_GetButtons() - reads the buttons on the platform and translates them into something common and shared among platforms.

    jzFS:
    - jzFS_File::jzFS_File(filename) - part of a class that opens files and provides useful Jazz2 related functions, this function only opens the file using a platform specific path prefix. (and also default dir)

    jzAUDIO:
    - jzAUDIO_init() - setup and initialize the audio system on a platform
    - jzAUDIO_update() - While not required on all platforms, this function is called in the mainloop of the game or app in case it's required!
    - jzAUDIO_exit() - does whatever is required to shutdown the audio
    - jzAUDIO_loadMusic() - not very flexible yet, but on platforms that support it the background music is loaded
    - jzAUDIO_initSample(soundID, data, length) - loads a raw audio sample into the audio driver (for sound effects)
    - jzAUDIO_playSampleID(voice, soundID) - plays a sound effect loaded with initSample on the specified voice/channel

    There are many aliases defined in a header for the GPU functions for specific situations, and there are actually a few very complicated jzGPU functions that draw trapezoids specific to the water effect in BatteryCheck. I should really try to rewrite those to be less complex so the GPU driver's for a platform do not have to care about them so much. For a few of them I already did that by merging it but that needs to be shared over to the others. Complex stuff...sorry :blush:. But I guess if you even made it this far in you must be either a developer or very interested in the subject anyway :wink:

    Other than that, these are ALL the actual function calls that make my "multi-platform game engine" magic work really. :lol::D. On top of these low-level driver functions are many macro's and classes that help make things easier to use. For example to draw a tile there is a function simply called "jzGPU_drawTile(x, y, index, flip_h, depth)" to draw a tile at the specified coordinates. :D There are a lot of assumptions behind those helper functions though and that is part of the reason my code is not public and open source yet. It's a mess and needs refactoring and documentation! :shy::wink:

    This abstraction layer is the only reason it has been possible to port my game to as many platforms as I have. All that's really needed to add a platform is setup it's makefile environment I explained in the spoiler block above, and then for each of these "driver functions" you need to write the platform specific code to make it perform the required functionality. Whether that is initializing graphics, reading the buttons of a controller, drawing a rectangle or drawing a sprite.....that is all it really takes!

    Usually I just copy one of the existing platforms and then clean out all the code in the functions related to the platform. Remove or comment is kind of the same. It's just a way to make the compile happy that the driver function exists and does not complain about missing functions that belong on the other platform. If I release this "ports" driver library on github one day I would include a "template" that is empty but contains comments to instruct what should be happening in that function.

    With the abstraction from native libraries and details provided by the "drivers" it actually becomes really easy to make a game or app that works on multiple platforms. You just call a few functions at certain times and you are already running something that you can compile for any of those platforms supported! It's true that right now I am only really using it for a single game, but the Installer I also made on certain platforms is actually a separate "app" using the same "libraries" I have described above. :D It's true that the three newest platforms have not gotten the installer yet, but in theory it should compile for them just fine. It's more that I have tried rewriting the installer to have a nicer GUI and that kind of failed and needs repairs. :shy:

    Working on the Wii U was quite difficult as I could not find understandable examples that I could translate and rewrite into my driver structure. The startup code worked fine and inputs are working too, but graphics and audio were not that simple! Since I saw that SDL2 was ported to the WiiU I though why not try it anyway....I am not a fan of SDL because of my issues from the Python experiments. It has it's place for simple things...but I liked the performance of using OpenGL and similar systems a lot more. :wink: Now the WiiU port is using SDL2 for both graphics and audio....it even supports the background music! Because of a stupid mistake the SFX sound horrible....I fixed that by the way but only shared that copy on discord! Whoops! :blush:

    Then I gave myself a challenge last week to port the game to the Nintendo Switch in 8 hours! That would have been nearly impossible if I did not have this driver and build system infrastructure ready! Setting up the makefiles took less than an hour but getting graphics working was about as difficult as it was on the Wii U! Not because there were not enough examples....but more that my understanding of the more modern method of using OpenGL is not there yet! I mean stuff like shaders, draw buffers and whatever it's all called! :rofl2:
    The difficult part of making it work on the switch using only the yuzu emulator was that I could not get any debug info if the game crashed! Also my usual method of "printf" seemed to be invisible! Making it hard to pinpoint the trouble spots! The work I did on the Wii U by using SDL2 actually saved my challange...without it I would not have succeeded! There was one issue though with the colors...for whatever reason everything had a red shade over it. I had to tweak my texture generation to swap the RGBA values arround until it looked normal. Also the transparency needed some tweaks not required on the WiiU but whatever...it WORKED! :D Getting the music working was a bit more work as that seems to crash yuzu...or at least it triggers something that makes it not work. Then someone on discord
    offered to run it on his switch and a few versions later it had working sound effects and background music on a real switch!!! but not in yuzu! :( I have found a different switch emulator called Ryujinx that has it's own issues with stability....but at least there it works and plays the music! :D
    My issues against SDL2 have not been a secret in my other posts I think....but using it also gave me a change to rethink how my "Drivers" currently work. I have looked at the sourcecode for SDL to see how it does things and how it abstracts platforms and other libraries. Some might say it does it better than me....they might be right...but I want to be closer to the hardware. :P What I was thinking about is that on some platforms it might be possible to use different libraries or back ends to do certain things! What I mean is that now that I have a GPU driver for my game engine that already works on WiiU and switch...maybe I can reuse it on other new platforms too. Then make the platform work faster if it has SDL2 support and later use the native libraries! That might save some time!

    The way I am thinking of doing it is making a new directory structure that separates the platform drivers and the backends! For example the GameCube and Wii can share the GX backend. Linux and PSP both use libmikmod directly. It's little things like that....but really complex to explain actually. I really hope I am not boring people with this enormous blog post...hahahaha:rofl2::rofl2::rofl2:. But among the GX, OpenGL and Citro2D backends for graphics I could add SDL2 and maybe rewrite it a bit for SDL1 too. Then the platform drivers would became a bit simpler by just selecting backend drivers instead of having the entire implementation. It prevents duplicated code I think...and that in turn makes things easier to understand and maintain. But at the same time I would need to keep an eye on making sure that this separated code idea does not introduce slower code! maybe I could use compiler macro's and just include some headers to select a certain backend on a platform. I am really not sure yet how to implement it :rofl2:

    Please forgive me for writing so much text to explain how my multi-platform code is structured and working. I hope it was not boring or complicated and you enjoyed it...and maybe even learned a thing or two! ;)

    Thank you for your time, and until next time. :D
    niuus, IC_, KleinesSinchen and 2 others like this.
  • Archerite

    Devblog: There are some obviously missing platforms on my list!

    I was talking about my game project a bit with my cousin and that I ported it to the switch and all the other platforms it already runs on. Then she said: So it runs on everything?....it was only then that I started looking at my current list of platforms:
    - Linux
    - GameCube
    - Wii
    - Wii U
    - 3DS
    - PlayStation 2
    - Switch

    and having worked a bit on:
    - PSP
    - NDS
    - GBA

    Its kind of obvious which one is missing but while writing this I see there are more brands missing, but the one I am talking about is XBOX! The other is DreamCast in case you were wondering :wink:. The original XBOX I bought in 2007 mainly for XBMC, but since it was a game console I also got a couple of games for it. Not that many since I was more into Nintendo and PlayStation even then :rofl2: I used it a couple of years and I think the last time it was even on must have been more than 8 years ago, hahaha:D

    The thing has a modchip so running homebrew should be quite easy to do. No idea how it even worked...remember something about uploading over FTP to the harddrive and stuff, hahaha. Then I started thinking about why I have not made an attempt yet for the XBOX and I concluded it must have been because it's more targeted to windows developers or something. I tried once to compile XBMC in visual studio and failed...I know that much. Hahah:rofl2:. I did a tiny bit of research on the subject and found something called nxdk which seems to be similar to devkitpro, ps2dev and pspdev in providing multi-platform cross-compiling tools. meaning I could write some code from my Linux desktop and compile into whatever type of binary the Xbox has. :wink:

    I even got an Xbox 360 from my cousin (not the same I talked to today :lol:) for my birthday a few years ago....helped her with the getting the xbox one ...something whatever it was. it was white I think. Hahah:rofl2: I thought it was a nice thing to try modding it and compile my game for it....the list of platforms was a little shorter then btw...but looking into it there was just not a lot I could figure out on getting it to run homebrew. It's possible but only with an unobtainable modchip....no softmods if I remember correctly. I did get a harddrive for it so I could install and play original xbox games....take a wild guess how many times I have tried that? Exactly ZERO times, hahaha. The main reason for it was actually that the controller battery dies in like 2 hours...I did get the AA adapters but by the time they arrived...I lost most interest in the machine and it got shelved!

    And now I think of it....PlayStation 3 is also not there but for a whole other reason. Most of my modded consoles I have at least one of...or I don't care about the online stuff. Or the mod has very little risk of bricking the machine. Why I did not work on PS3 yet is because I used the same account on my PS4 and PS VIta.....and I fear multi-conole bans for even attempting something like homebrew! I could buy a second one but they are quite expensive at the moment. Not as much as the Wii U....but there I "justified" it to myself by saying....the white one is not exactly the same as the black one! :rofl2:..right?:ha:

    This was just a thing that I had to get out of my head again....not any real plans to work on these consoles for my game engine any time soon. Like I said in my previous blog post there is already enough to work on to make the engine itself much better! Let's make that work first, add some more "fun and things to do" into game! Then I can go back looking at these platforms....and who knows, maybe then they will be more easy to mod or make homebrew for. It turned out that way with the Wii U...since the current tools and exploits did not exists yet in 2018 when I started my project. :wink:

    Have a good day / night /morning whatever is the case for you :D
    alexander1970 likes this.
  • Archerite

    Devblog: Improving my homebrew game engine.

    Currently my homebrew game engine I have been working on for about three years in my spare time only supports BatteryCheck. I have talked about that game so much that it barely needs more explaining I think :wink:. The original BatteryCheck game engine is an early version of the one used in Jazz Jackrabbit 2, a game that is far more popular and well known than BatteryCheck is (or was :P). The version of Jazz2 that is compatible with BatteryCheck is 1.10o and it includes a special level editor (JCS) that can also open and edit BatteryCheck levels! Or you can even create new ones! :D The bad news about this version is that it was a leaked press release....I found it "somewhere" :shy::ha:...and use it to learn more about what the levels should actually look like in detail!

    Screenshot_2021-06-16_09-32-12.png

    One of the things missing in my version is parallax backgrounds! These are moving layers in the background or even foreground that add a sense of depth and atmosphere to both Jazz2 and BC! For example in BC there are tiny elevators in the background that constantly move up and down, and while you walk they also move at different speeds. There is also a chain in the foreground that also adds a sense of direction and where you are in the level!

    I really have not played enough of Jazz2 to give a similar explanation of it's backgrounds, but there is one level with MANY moving things that are realized by using a few moving backgrounds at different speeds. Just for fun I tried loading them into my BC engine and this is what that looks like:
    Screenshot_2021-06-15_17-44-49.png Screenshot_2021-06-15_17-45-03.png Screenshot_2021-06-15_17-46-22.png

    The red squares in those screenshot are objects which my engine does not know! Which is quite a lot since BC only has about 35 events/objects and Jazz2 has close to 255!!!! :O So it's going to take VERY LONG before every single object is going to be implemented in my version of Jazz2 on my game engine! While Jazz2 is an old commercial game and it would require a player to obtain the game assets just like is required right now for BC...Jazz2 is still for sale on GOG! And more importantly....it has a MASSIVE discount at the moment! As I said I never really played it...but already bought the bundle three years ago for a slightly higher price. At this moment you can buy it for about 1,69 euro!! That game has about 68 levels (some are locked or special use for the menu's I think) and has shooting, collecting, multiple characters and a great community. If you like old style platform games...and if you read this far I am guessing you do :lol:...I can not recommend it enough to buy the GOG version now! (to make it clear: I am not affiliated or whatever with GOG or Epic games! Just pointing fellow games to a great deal! Hope this is ok and not seen as advertising or something ;))

    Let's just say there is enough research and rewriting stuff to keep me busy for a few weeks. :D
  • Archerite

    BatteryCheck: Porting it to yet another platform in less than 8 hours! (personal challange)

    This is going to be a similar thing as my blog form August last year - the mystery console which was the PlayStation 2! :D While I did not release it back than because of several issues, I did solve a few of them and about a month ago I upload a preview of it here. In the last couple of weeks I have been working on the Wii U version...which has been on my "todo list" for years! Let's just say the available tools are not as easy to use and not many libraries have documentation or examples on how to use them! Eventually I decided to make use of SDL2 which was ported to the WiiU and while it has it's issues....BatteryCheck on the Wii U is working now! It even has background music and sound effects thanks to SDL2!

    Those who follow my journey know my main intterest is the game console's themself and learning how they work! Using a library like SDL takes a lot of the "fun" away to really learn the hardware it runs on. But it also gives the ability to get something running a lot faster/easier when required. I am not sure if there is a performance hit by using SDL yet...might also be that I am using it wrong. I would say compared to the smooth Wii version this is about 10 fps less maybe? There is also some scaling going on so the graphics don't look as good as I would like them too. With some experimentation and talking about it on Discord I managed to reduce the artifacts greatly on the gamepad LCD. On the TV it still shows glitches. I will be updating the download for the Wii U soon in my thread here too. :wink:

    With those two platforms added and functional there is still one other potential platform I have not worked on yet. I looked at the available libraries and the environment looks nearly identical to what I am using on Linux! And no...this is not the Raspberry Pi version I have promised and talked about a few times! Really should look into that :shy: Because of this similar libraries and environment I think I can make it a personal challenge to get it working in less than 8 hours!

    There is only one slight problem! I do have this new mystery platform....but I have only one of it! And it's not yet modded for homebrew yet...and I am kind of scared to do that! :shy: So my only way to test it is going to be the emulator...which has a native Linux version and example code seems to be running great in it! My main goal would be that my code will compile though...if it runs in the emulator that would really be a bonus! Hahaha:rofl2:

    Take a guess on what it might be :P:D

    Obviously because I can! :ha::lol: But the main reason is that this is one of the last few that I have not tried yet...and it's the only one that might be this simple! That is if my expectations were correct that it's highly compatible with the Linux version offcourse ^_^

    To give a hint: It's not one of there platforms: PSP, DSi, DS, GBA and also not SNES, Gennesis or NES.:lol:
    The good news is that the new system's makefile's are setup just the way I like them! meaning I can run "make {console}" and "make {console}-emu" to run the latest build in the emulator! This is working for all current platforms I have now:
    - 3ds
    - gba (not working with my game)
    - gc
    - linux
    - nds (not working with my game)
    - ps2
    - psp (incomplete)
    - wii
    - wiiu
    and...
    - {new-mystery-console}

    I have actually forgotten to mention one other platform I have not worked on yet and because of the complexity to mod on my firmware, I am too scared to do it! That platform is the PSVITA....and not the one I am porting to right now! :wink:. I also have more than one PSVITA console: Both handheld versions and a VitaTV! :D But because they are linked to the same account as my PS4 I am too scared of modding them. Don;t want to be banned on either PS4 or VITA. That I barely use either system is beyond the point! :rofl2:

    With the Makefiles working now I tried compiling my game.....and while the GPU driver is disabled. The game actually compiles just fine! :D It needs more work and testing to see if the emulator wants to play the music and sound effects. Then I will know reading from the storage works and that the game is really running. :D
    Because my project started with the GameCube and Wii in mind I am using some OpenGL techiniques that are considered outdated. I'll have to look into what it was called again but this is what I normally do to draw a colored rectangle:
    Code:
    static inline void jzGPUi_drawQuadRGBA(
          uint16_t x0, uint16_t y0, uint16_t z0,  // # Top Left
          uint16_t x1, uint16_t y1, uint16_t z1,  // # Top Right
          uint16_t x2, uint16_t y2, uint16_t z2,  // # Bottom Right
          uint16_t x3, uint16_t y3, uint16_t z3,  // # Bottom Left
          uint8_t r, uint8_t g, uint8_t b, uint8_t a) {
     
      glDisable(GL_TEXTURE_2D);
      glColor4ub(r,g,b,a);
      glBegin(GL_QUADS);
        glVertex3f(x0, y0 ,z0 ); // # Top Left
        glVertex3f(x1, y1 ,z1 ); // # Top Right
        glVertex3f(x2, y2 ,z2 ); // # Bottom Right
        glVertex3f(x3, y3 ,z3 ); // # Bottom Left
      glEnd();
    }
    
    Code:
    static inline void jzGPUi_drawQuadRGBA(
          float x0, float y0, float z0,  // # Top Left
          float x1, float y1, float z1,  // # Top Right
          float x2, float y2, float z2,  // # Bottom Right
          float x3, float y3, float z3,  // # Bottom Left
          uint8_t r, uint8_t g, uint8_t b, uint8_t a) {
      
      GX_SetNumTexGens(0); //texturing is of so no textures
      GX_SetTevOrder(GX_TEVSTAGE0, GX_TEXCOORDNULL, GX_TEXMAP_NULL, GX_COLOR0A0);
      GX_SetTevOp(GX_TEVSTAGE0, GX_PASSCLR);
    
      GX_Begin(GX_QUADS, GX_VTXFMT0, 4);
        GX_Position3f32(x0, y0 ,z0);// # Top Left
        GX_Color4u8(r,g,b,a);
        GX_TexCoord2f32(0.0f, 0.0f);
    
        GX_Position3f32(x1, y1 ,z1);// # Top Right
        GX_Color4u8(r,g,b,a);
        GX_TexCoord2f32(0.0f, 0.0f);
    
        GX_Position3f32(x2, y2 ,z2);// # Bottom Right
        GX_Color4u8(r,g,b,a);
        GX_TexCoord2f32(0.0f, 0.0f);
    
        GX_Position3f32(x3, y3 ,z3);// # Bottom Left
        GX_Color4u8(r,g,b,a);
        GX_TexCoord2f32(0.0f, 0.0f);
      GX_End();
    };
    
    Code:
    // static inline void jzGPUi_drawQuadRGBA() is not used on 3DS
    void jzGPU_drawQuadRGBA(uint16_t x, uint16_t y, uint16_t width, uint16_t height, uint8_t r, uint8_t g, uint8_t b, uint8_t a, float depth) {
      C2D_DrawRectSolid(x,y,depth,width,height, C2D_Color32(r,g,b,a));
    }
    
    Code:
    static inline void jzGPUi_drawQuadRGBA(
          float x0, float y0, float z0,  // # Top Left
          float x1, float y1, float z1,  // # Top Right
          float x2, float y2, float z2,  // # Bottom Right
          float x3, float y3, float z3,  // # Bottom Left
          uint8_t r, uint8_t g, uint8_t b, uint8_t a) {
    
        gsKit_prim_quad_3d(
          gsGlobal,
          x0, y0, z0,
          x1, y1, z1,
             x2, y2, z2,
             x3, y3, z3,
          GS_SETREG_RGBAQ(r,g,b, 128-((int) a * 128 / 255) ,0x00)
        );
    }
    
    Code:
    //NOTE: Not using this exact function yet it seems!
    static inline void jzGPUi_drawQuadRGBA(
          uint16_t x0, uint16_t y0, uint16_t z0,  // # Top Left
          uint16_t x1, uint16_t y1, uint16_t z1,  // # Top Right
          uint16_t x2, uint16_t y2, uint16_t z2,  // # Bottom Right
          uint16_t x3, uint16_t y3, uint16_t z3,  // # Bottom Left
          uint8_t r, uint8_t g, uint8_t b, uint8_t a) {
      
        SDL_Rect rect = {x+GPU_Translate_X,y+GPU_Translate_Y,width,height};
        SDL_SetRenderDrawColor(renderer, r,g,b,a);
        SDL_RenderFillRect(renderer, &rect);
        SDL_SetRenderDrawColor(renderer, 0, 0, 0, 255);
    }
    
    Code:
    static inline void pspAddVertex(float x,float y,float z, unsigned int color) {
      //TexVertices[vert_idx].u = 0;
      //TexVertices[vert_idx].v = 0;
      vertices[vert_idx].color = color;
      vertices[vert_idx].x = x;
      vertices[vert_idx].y = y;
      vertices[vert_idx].z = z;
      vert_idx++;
    }
    static inline void jzGPUi_drawQuadRGBA(
          float x0, float y0, float z0,  // # Top Left
          float x1, float y1, float z1,  // # Top Right
          float x2, float y2, float z2,  // # Bottom Right
          float x3, float y3, float z3,  // # Bottom Left
          uint8_t r, uint8_t g, uint8_t b, uint8_t a) {
      unsigned int color = (a << 24) | (b << 16) | (g << 8) | (r);
    
      //sceGuDisable(GU_TEXTURE_2D);
      //sceGuEnable(GU_TEXTURE_2D);
      vert_idx=0;
    
      //pspGuBegin()
      pspAddVertex(x0 ,y0 ,z0, color);
      pspAddVertex(x3 ,y3 ,z3, color);
      pspAddVertex(x1 ,y1 ,z1, color);
      pspAddVertex(x2 ,y2 ,z2, color);
      vert_idx++;
      //pspGuEnd()
    
      sceGumDrawArray(GU_TRIANGLE_STRIP,GU_COLOR_8888|GU_VERTEX_32BITF|GU_TRANSFORM_3D,4,0,vertices);
      //sceGumDrawArray(GU_TRIANGLE_FAN,GU_TEXTURE_32BITF | GU_COLOR_8888 | GU_VERTEX_32BITF|GU_TRANSFORM_3D,4,0,TexVertices);
    
    }
    
    
    As you can see it's a little different on each platform but overall it's just drawing a rectangle at some coordinates with a specified color. The main use case in my game is drawing the water and for showing where an event or solid object should be located. Also the little dot's around the player and some of the lines are all drawn by this function! Obviously I have ton of wrapper and macro functions around it so I only need to specify a minimal set of coordinates and color to it.

    I think from all the platforms listed above, the only one that comes close is the PSP! It also requires a vertex buffer to draw anything on screen but I will have to figure out how that should work in OpenGL. Hopefully this is also reusable on the Wii U later when I rewrite the GPU and only use SDL2 for the background music.
    I have been searching OpenGL examples everywhere but most of the function calls are not recognized! Some of them I solved by rearranging the LIBS because that's apparently important in which order they are added! I had the same issue on the Wii U so that was familiar...just not what exact order they needed to be in! I ended up with this {CODE]LIBS := -lSDL2 -lSDL2_image -lglfw3 -lglad -lEGL -lglapi -lGLESv2 -lgd -lpng -ljpeg -lwebp -ldrm_nouveau -lnx -lm -lz -lmikmod[/CODE]
    And yep, since OpenGL does not seem to be possible at the moment I have moved to SDL again! Copied the WiiU GPU driver I already had and removed the WiiU specific stuff out of it off course.

    Still only not getting anything on screen! It's frustrating! I really hoped this was an easy port! I guess most people guessed it's the Switch I am trying to make it work on! :wink: It might just be the yuzu emulator, or because I am using the AppImage version that it does not want to work for some reason. I have even switched to my really basic rotating squares demo! It's literally 8 squares with a color rotating in a round pattern. It's to show that the system and graphics are working and what I usually test on a platform first. It does not require input, sound or files so it's perfect to just test graphics this way.

    So what will happen if it really does not work within 2 hours? Nothing bad off course. I will not delete the code I have since it does compile a switch executable file. The makefiles are setup correctly. I can start the emulator quite easily...but I can not give my executable from the CLI to auto start it. I can also not get debug log output from yuzu to work! At least nothing I printed with printf() so that's not helping to see how far my game actually started up! I think there are text logs somewhere and maybe it's in there. I don't know.

    In any case I will keep the port's files and just finish it some other time. I have actually did the exact same with the PlayStation 2 until it had a release a month ago. And the PSP, NDS and GBA also have mostly working ports if you look at the being able to compile for them point of view. But those three have specific limitation that I need to rewrite a large part of my game engine for. PSP and NDS both need smaller textures for the tile map. But that also requires that all calculation are redone to find the correct tile on the correct texture, instead of just calculating the position on a single texture.

    I do hope to at least get the rotating squares on screen with SDL. That has to be possible! The switch is very powerfull compared to the older systems I have worked on so far...even the buggy emulator should be able to handle that right? :D
    I had to tweak, copy, paste, disable A LOT of stuff to make it at least partially work!! Here is my running code in the yuzu emulator of 8 rotating squares. (making a GIF is just too much work :P)

    upload_2021-6-12_15-54-13.png

    So this is compiled for the switch using SDL2 as the graphics backend! I really have something against SDL in general....but now that it works and I was able to reuse a lot of stuff from the Wii U...maybe I need to rethink my objections a bit. Sure it increases the size of the binary by 600% or more...but with that comes a lot of flexibility that using plain OpenGL or a native similar environment requires you to do by your self! Let's see if I can make my game work too! :D
    I had not expected to make it after all the minor issues I ran into while creating this port! But it seems to have been something with the controller inputs...which I am not using or reading at all at the moment. No compiler errors on it either. really weird. But with the following screenshot it shows that the game has loaded data from SDMC, initialized the graphics, created textures and that the main loop is running! :D
    batterycheck-switch-first-run.png

    I really have no idea what's up with the funky red tinted colours....what matters to me is that the game is actually running! And not even that much over my limit of 8 hours! :rofl2: I am going to try adding controller input so I can actually play it a little and see if all other objects are working too. :wink:
    FINAL EDIT: 12-06-2021 23:00

    Within my goal of 8 hours I have managed to setup the build environment, work through all missing libraries, sorting the libraries for the compiles, looking through examples for native GPU drawing....but settled for SDL2 in the end. I had already written most of it for the WiiU and luckily most of it was compatible! :D So the results after those 8 hours was this screen:
    batcheck-switch-1.png
    While the colors are obviously wrong here, the game is loaded and showing the correct graphics in the correct place! There was also an issue with transparency which is why all sprites have a black border around them. After some fiddling with my texture generating functions I found a workaround for the color issue. For whatever reasion it works correctly if I reverse the colors into ARGB instead of RGBA...which is weird because SDL should take care of that! Anyway...two hours later it looked like this:
    batcheck-switch-2.png
    The transparency issue remained but at least the rest of the colors were correct now. :D It took me a while to figure out what was needed and it's a bit technical. Turns out that SDL needs to know how to blend the colors per texture...separately. This was not required on the WiiU! So either SDL2 on the wiiU or the switch is not working properly. Whichever it is...I do not care as my sprites are drawn correct now:
    batcheck-switch-3.png
    But as you can see there was yet another issue to solve! This is the first pool you encounter and it's there, if you fall in you sink slowly. The liferafts are going up and down as they should with the water level...it's just that the water itself is invisible! I am using the same drawing function for both water and other transparent rectangles here and there...and NONE of those were drawn either! Eventually I noticed I had made the mistake myself by doing the caluclations of where to draw incorrectly! Meaning drawing probably worked just fine....but was done outside the viewport that was actually visible! Luckily I had found this out fairly quickly in about 10 minutes! :wink:
    batcheck-switch-4.png

    I also have the controls working so I can walk around the level just like on every other platform I have ported it too. :D The only thing I have not been able to get working is the sound! I am not sure if it's something wrong with the emulator or with my audio code. Something generates an error as soon as either libmikmod or SDL_mixer is initialized. I have no idea what the problem is and I do not have a way to test it on real hardware yet! It's really to bad that this last step prevents the Switch port from being complete. :sad:

    But looking back on today I think I did fairly well in making it work as far as it does. It was not as easy as I had hoped but also not extremely difficult compared to the WiiU. That one took at least 3 whole days to get graphics to show on screen, hahaha. But I am sure that the work on the Wii U and SDL2 has helped making it easier on the switch today. I have given my view on SDL before....but I would still rather like to use more native libraries to do everything. Just by using SDL blows up the .NRO from 500kb into a 8mb monster! :O But I have to give SDL2 some slack for making the port easier today, and performance is not as bad as I always thought it would be with SDL. ;)

    I thought about uploading the .NRO file but I don't think it's ready for that. I need to test it on real hardware someday myself first. :ha: Unless someone brave enough to ask me for it directly and willing to test it anyway, there will be no shared .NRO of batterycheck on the switch yet. :)

    Thank you :D
    newo likes this.
  • Archerite

    BatteryCheck: Finally fixed the bug that broke events and SFX on the Wii U port!

    While I was adding the port to the Wii U I noticed that all events were basically broken! The pools of water were of the wrong size, the length of the belts was wrong, etc... And I could not figure out what had gone wrong! Since a few days I have been hanging out on discord in various servers to get platform specific help.

    By just talking about some of the issues I looked at some portions of the code in a different way...and there I found it! This stupid error!
    [​IMG]

    Roughly translated for non programmers this means:
    - in red: IF NOT DEFINED "GEKKO" include this code
    - in green: IF DEFINED "GEKKO" OR "__WIIU__" include this code
    Meaning....I had REVERSED this check and it totally messed up how the event configuration was handled! It's fairly technical but related to how PowerPC CPU's are big-endian and the rest of the world is little-endian. Knowing where the problem was made this an easy fix! :D
    upload_2021-6-10_20-5-19.png

    The sound effect issue I had on the WiiU was equally stupid! The sound effects are RAW audio samples in Signed 8bit format at a sample rate of 22050. And I configured it as unsigned 8bit making the effects sound horribly loud and distorted! No pictures of the code change...as I had not committed it in to git yet. :blush:

    With these issues fixed I can continue looking at maybe making the battery holders work! That would give some new game play elements to interact with. The animations that come with this action are HUGE...so I might skip that part at first. Just make the battery swap and activate the battery holder. This will also require that a full battery is swapped for an empty one...so the counters will change. And then I can make freddy the dragon exchange 3 empty ones for 1 full battery too. :D

    Now that I wrote it down like this I realize it's actually going to take some time to implement all that! Hahaha:rofl2: But it will be great to have something functional added to the gameplay, instead of adding yet another platform to run on right? :lol:;)
  • Archerite

    BatteryCheck: Never had any clue there were cheatcodes in the original!!

    This game came out in 1998 and I have played it for years but I have never even realized that it had cheatcodes!!! I have been introduced to discord by @V10lator and I have been looking around for other cool and interesting servers to join. Most notablly: ps2dev, pspdev and jazz jackrabbit!! While exploring how discord works and seeing if something of BatteryCheck was already in the Jazz2 server I noticed that my name was already mention on there, hahaha. At least my username on the Jazz2Online forums :wink:

    Someone known as "Love & Thunder" is working on something similar as me by recreating BatteryCheck's levels and objects inside of the real JJ2. Or actually the enhanced version JJ2+ that allows AngelScript to customize a lot of things in the level and game engine. :D

    In a couple of old messages I discovered these cheat codes for the original windows PC game:
    Code:
    hhklm - fly mode
    hhzondertanden - no enemies
    hhzonderhanden - activate all machines
    hhstroom - full energy
    hhsupbat - all super batteries
    hhvolgende - next level
    hhpluseen - extra life (+1)
    hhsterf - kill yourself
    The "flymode" is brilliant!! KLM is the royal dutch airlines, hahahaha :rofl2::rofl2::rofl2:

    I tested them and they all work...very easy to get to the boss level using these codes. :rofl2:

    Now I really want to implement these codes too!!! Or at least their function for debugging :D
    KleinesSinchen, newo and niuus like this.
  • Archerite

    The problem with my custom installer...

    To unpack the game files for BatteryCheck, which is originally a windows PC game, I have created a custom installer about two years ago. It runs right on the console itself and it was no longer required to run the "setup.exe" on a windows PC first! The installer I have ported to the: GameCube, Wii and 3DS and it has a fairly simple text interface that looks kind of boring. It get's the job done but it's not really amazing to look at! :wink:
    batterycheck-installer-0-1.png
    For a while I had the crazy idea to create a "Windows XP style" experience on the Wii:
    batcheck-xp-style.png batcheck-installer-0-2.jpg

    While the idea for that was amazing, stupid and crazy at the same time....it would also mean I would have to write my own windows manager and handling input events on objects and stuff. Cool stuff actually, but not really important for an installer used only once and then to never be seen again! Which is why I chose not to continue with the idea and just stuck with the text based version.

    Now comes the bad part...:wink:...over the past two years I have been actually trying to get something of a GUI working and putting a lot of "junk code" into the part that actually unpacks the files! It's a total mess now...and that needs to be cleaned up! A LOT! Not only are there platform specific checks for various "testing" I did, but also I abused this project to experiment on the NDS last year to load images into external ram! I have no idea why I put that stuff into the installer app!!!

    I am thinking it's the easiest to kind of start from scratch on the setup source, and cherry pick the useful parts of the current "bc_setup" app I have. This means that when it's done the app will still be completely text based but also clear of all the extra junk it collected over the years! What I really want is that the function that actually does the unpacking does not print anything to the screen at all! It will only accept callback functions to be called when the percentage done changes. That function is than responsible for either writing it on screen as text or advancing a progress bar in a gui!

    The new installer should also be compatible with the different types of installation files. Or more specifically where they came from:
    - 1 - The original CD-ROM
    - 2 - From the previously linked site as a ZIP file.
    - 3 - The extracted or copied "Setup.exe" from option 1 or 2 that is about 12MB
    - 4 - From archive.org as ISO
    - 5 - From archive.org as EXE
    - 6 - From digiex.net as ISO
    - 7 - From digiex.net as ZIP
    - 8 - Maybe the freeware version download from Stibat? (I don't have this version so I can't test it)

    Right now only option 2 and 3 are directly supported by my installer. Option 1 is cool to have on a console, but most of them can't read the CD-ROM directly....unfortunately! For option 5 to work all that's needed is that it recognizes the capitalized name of the file as valid. Option 7 is similar to option 3 in that they are both zip files...but for option 4 I have looked at which offset the compressed data stream is located and just use zlib on that blob! I am not using any kind of ZIP library to locate the file in there. Making option 7 work just requires me to figure out it's different offset and then it should work.

    The ISO files from both sources have the same SHA1 hash of 4a7343bc0257d18e777fca9ad340573c4ca9a92f meaning they are identical! I feared I would have to use some kind of iso9660 library before I would be able to access the Setup.exe that is embedded in the file, but the same trick I used for the ZIP files is possible here! The files is just there at an offset without any compression at all! I would just need to recalculate some of the offsets I already use and it should just work! :D

    No matter which version you have the setup.exe should always be exactly 12,308,298 bytes (11,7MB) and have an SHA1 hash of f86f8805e3e39763789400cefda2bf2430ddb4a9. This is the only version that the installer is able to unpack from....but it will do NOTHING to verify it is actually this file version! I know it should...but currently it does not!
    Currently the best option is to just do a google search for: batterycheck game download and then choose either the archive.org or digiex.net from the top results. I have verified the downloaded files and their hashes to be the same as from what I have on my CD-ROM. Here is a list of them in case you want to verify them yourself:
    Code:
    f86f8805e3e39763789400cefda2bf2430ddb4a9  Setup.exe
    96ffaf435157f9067a6a9912fdffacafb3e8b2ca  batterycheck.zip
    4a7343bc0257d18e777fca9ad340573c4ca9a92f  BATTERYCHECK.iso
    f86f8805e3e39763789400cefda2bf2430ddb4a9  SETUP.EXE
    4a7343bc0257d18e777fca9ad340573c4ca9a92f  Battery Check (CD Image).iso
    29f053ef5f6ed118a0e0c27a8ef13a003439269f  Battery Check (Setup Only).zip
    f86f8805e3e39763789400cefda2bf2430ddb4a9  SETUP.EXE
    
    These are the file names and the SHA1 hashes that I have found. While each of them has a slightly different name, the relevant "setup.exe" is always what I said above: 11.7MB with a SHA1 hash of f86f8805e3e39763789400cefda2bf2430ddb4a9

    What the "new installer" is really going to look like has not been decided yet! After cleaning it up and adding support for the new sources as discussed in the spoiler blocks above, I think it will still be the same simple text interface for now. Just rewritten in a way that will make it work on any platform and later be able to fit into a nice looking GUI! :D

    Thank you for reading.:D
    KleinesSinchen and niuus like this.
  • Archerite

    Nobody likes to see ads....but is it just me or are they getting worse every day???

    While I understand that a site like this costs money and needs ads to generate income...WHY do they have to be changing every 30 seconds.....and even worse: CHANGE SIZE!!!! The other day typing a reply I got almost sea sick because my typing window kept moving to a new position!! It's annoying enough that adds are shown....but why are they MOVING all over the place!!!

    There! My rant on the ads are complete! or actually...no I am not! :lol:. I don't click on them anyway because I do not care about what they show me! Ever! I love my YouTube premium and never seeing an add anymore...unless they edited it into the video off course :sad:.

    And I know there is the option of becoming a patreon...which I did and now (im)patiently waiting for the admins to notice me to change my settings or something. Would this post help? :shy: Seriously though...I am patient enough to wait for ads to be gone completely. But why do they have to be so annoying and changing size while I am actively trying to use the site's main features?

    Thank you for your time. I am good now. Maybe:wacko::P:lol::D
  • Archerite

    A wireless SNES controller

    A few years ago way back in 2016 I worked on a wireless SNES controller and it's actually one of the very few projects I have worked on that's mostly finsihed! :rofl2: I made a few video's back then and thought it would be nice to put them on my newly created youtube channel! (got the idea to create one from @jeffyTheHomebrewer and his post on reaching 100+ subs here)

    Finally a video of something I really made myself! :D

    Both the sending and the receiving side are running my own written arduino sketches. But I do use a few libraries for I think the wireless module and to draw the gamepad on that little LCD. The image it'self is drawn using primitives hand placed by me though! :)

    There are more video's of me testing it when it got more "portable" than in this video...but I need to see if they are "youtube ready" first :P Those who follow my blogs might know what kind of video's I am going to post the most there, hahaha :rofl2:. But to start I thought it was nice to show something else for a change. :wink:
    niuus and alexander1970 like this.
  • Archerite

    BatteryCheck: Some roadblocks on the way for the Wii U version!

    In my blog post from saturday I have been explaining that I was working on porting BatteryCheck to the Wii U. During the weekend I have been updating that post with spoiler blocks about the progress and in relatively little time I was able to get it compiled and uploaded over the network to HBL to show "hello world" on screen! Working around various errors and crashes I got the debug output showing on my PC which is REALLY helpfull to see where the code crashed!

    It took a while longer to actually figure out by accident how to get access to the SD card! This is not (yet) explained in any tutorials I have read so far! See my previous post for how I figured it out eventually ;). With access to the game files that I had placed on there manually I could work my way through fixing issues until everything loaded without any errors. Most of them came from the fact that the PowerPC CPU is big-endian, just like the GameCube and Wii are, but the compiler option "GEKKO" gives problems on the Wii U! So I had to rewrite those checks in the code in various places to swap the bytes in the correct order on both "GEKKO" and "__WIIU__" platforms. After that was all done the message "loading complete!" showed in the debug output! :D This means that the level, graphics, animations and sounds were all loaded and converted. Ready to be used!

    By placing a few debug messages I can see that even the game's main loop is working. I can jump...fall....and land on the ground again! I think! The problem is that both the TV and LCD are completely black at the moment! In simple terms the examples that are provided for Wii U homebrew are ..... ehm.... limited. They show how to compile and get some text on screen...but nothing about loading sprites, textures and things like that! Only by looking at other completed working homebrew on github it can be learned how the graphics ...should work. Sort off...kinda...

    Like most people say the Wii U homebrew scene is not that active anymore...most people moved on to the switch I read everywhere! I think my project shows you can work on more than one platform at the same time....:lol:....but anyway there is an other issue that makes it difficult I think. The Wii U is not yet fully exploitable without jumping a few hoops...which is why I had not dared it myself earlier. I just decided to jump in a few weeks ago. But the exploits that did came out had various possibilities for the homebrew they could load. In the early days there was an insanely low file size limit...but it was a start ofcourse. I think by now compiling with WUT into a RPX is the way to eliminate these limitations. But the multitude of exploits and CFW options fragmented the homebrew that was made on the Wii U. At least that is how I figured it out. I might be wrong! :shy:

    What this means for my port is that while loading and the game loop seem to work, without examples of how to convert my loaded graphics into a texture and how to apply it to a quad....I can't show ANYTHING on screen! Or can I???:P While my preferred way to use the GPU is with as little libraries and abstractions as possible....I have no choice on the Wii U I think. The only thing that IS available and hopefully working is SDL2! It's not my favorite way of making it work though...as SDL feels like "bulk" to me. But maybe on the Wii U it's "ok" since it's a powerful machine. :D It's not that I am completely against SDL though, in fact my early prototypes I wrote with SDL and python3 under Linux! That is where my "fear of slowness" comes from. I had a lot of graphical glitches with it...but that might also have something to do with running it in Linux on an Intel integrated graphics at the time. :rofl2:

    While I have my doubts about using SDL for the main game...it might actually be a PERFECT fit for the installer!! The installer is currently fully text based and does it's job of unpacking the gamefiles from the original "Setup.exe" and placing them on the SD card. But I would like to make it a more graphical experience and give the user an option to select where the "Setup.exe" is located. Maybe even give to option to download it from one of the available sources that are remaining after the "official one" was taken offline a couple of months ago. I just need to ask around if such a setup is "ok" to be shared here for downloading a Freeware game from archive.org. :wink: it will allow a more user friendly experience to setup the files the game needs.:)

    That's about it fur the current status of my port on the Wii U. Guess it's time to learn how to do things with SDL again....:(

    Until next time :D
  • Archerite

    BatteryCheck: Maybe even for the switch????

    For a couple of years now I have been posting blogs about my homebrew remake of BatteryCheck. And how I am porting it to many different consoles like: GameCube, Wii, 3DS, PlayStation 2 ..... and tried for PSP, NDS, DSi and GBA. There really are too many on the list already....but while getting my development environment ready to work on porting it to the Wii U I noticed something cool! Nearly all libraries I am using on the Linux version are available on the switch! This could mean porting it to the switch is quite simple!! :D

    For those who don't know about BatteryCheck yet there is a video on youtube where they play through the game:
    Just to be clear this video is NOT of my version of the game engine.


    Just to make sure it's possible I have downloaded the switch-examples from DevKitPro and compiled them and tested them in the yuzu emulator! That all seems to work great! And there are so many examples to see how stuff works that it's not even that difficult I think to port my version of the game to the switch! The only thing I do not have (yet) is a real switch that can run homebrew. But yuzu will have to do for now...

    Anyone think I should do it?:wink:

    Without a response to my suggestion I see three possibilities:
    - Not many switch homebrew users are interested in a 2D puzzle platformer?
    - The people that might be interested do not have a homebrew capable switch?
    - People are just getting sick of my multi-platform BatteryCheck stuff:P

    Either way I think I will keep this as an idea only for now. I have many platforms to support already and the recently added Wii U is giving me enough challenges to keep busy for a few weeks! Maybe when it's working on Wii U I can think about the switch again. ^_^ But the biggest reason not to do it actually is that I myself do not have a homebrew capable switch! I have one but I do not have the gut's yet...even when I barely play the games anymore. I still don't want to get banned on a current console I have only one off! This is the same for the PS3 and PS4 that I am using the same account on!

    It does look interesting though....writing something for the switch. With the amount of libraries and examples available I think porting my game engine is very easy! Especially since OpenGL is available!! And that's what I am using on Linux anyway!! :D
  • Archerite

    BatteryCheck: Comming to a Wii U near you in the future...

    Yep, that's right! Yet another platform that my homebrew remake of batterycheck is going to run on! While I would like to give a better estimate I am still in the research phase of finding examples to show graphics and stuff! It looks like the only homebrew that's still being worked on are either emulators or hacking/dumping/backup loader related! It's fine I guess....the wii U is generally believed to be a failed console and not many people are interested in writing homebrew for it. Well...I AM! :D

    At least I know that my Wii U works fine with homebrew now. I never dared to do it but about 2 weeks ago I just decided to dive into it! While it's a gray area...I figured out how to use disc2app and wup-installer to dump my own physical owned discs and install them onto a USB drive. Only to realize that my save games are stored separately! Some hours of fighting with Saveiine later I figured out how to backup and transfer my saves to SD and even the USB installed game! Been playing some more "expedition days" in Pikmin 3 this way and it worked perfectly! :D

    Best way to start I guess is porting the Wii and GameCube sprite examples! And to do that I will be looking at the sourcecode of some of the GX2 homebrew that I found on github. Loadiine is one of them, maybe the homebrew launcher etc... What I need to figure out is quite simple:
    - How to setup my Makefiles DONE!
    - Which libraries to load and include PARTIALLY
    - How to initilize the GPU
    - How to create textures
    - How to create Quads and Textured Quads
    - How to "move the camera"
    - How to start and end a frame
    - How to use the TV or gamepad for output
    - How to read the controller inputs DONE!

    Oke, that became quite a list actually. But the idea is simple! Why does devkitpro...or anyone else...not just port all the graphics examples to all the platforms they support. It's what they say I guess.....if you want to make it happen...DO IT YOURSELF! Oke then....also had to do this for the GBA a year ago. So why not now for the Wii U too....maybe I'll share the examples for both GBA and Wii U on my own github one day. And really contribute to the tools that make my project possible. Right? :wink:

    All that's left now really is to just dive into compiling at least a hello world example! That will show the tools are setup correctly at least...even though it's not that impressive....still would be awesome! :D

    No promisses....but I might post a few more blog posts along the way to share the progress. :wink:

    I did not think this was worth an entire new blog post, since it's just a tiny update. ^_^

    The makefiles are setup to compile for the wiiu and I have provided a bare bones implementation of the platform drivers! As in....just the function declaration to make the compiler happy. Hahahah :rofl2: I integrated a simple "helloworld" example into my code and it all compiled into an ELF and RPX file. Really cool I can just use "wiiload" to upload the binary to the wiiu homebrew launcher! :D

    While it's a small step...my code actually compiles and runs the "embedded" example code perfectly. Took me only two tries to realize that my "empty" gamecode was preventing it from returning into HBL! The difficult part of how this example seems to work is that it creates a thread for the application to run in. While that is actually really great....and something I wanted to include...it also makes it a little more complicated. My code is not optimized yet to run in multiple threads and I have a weird way of keeping it all portable between platforms. Need to rewrite that crap sometime....the game engine part is supposed to one day be made public so it should be easy to use right? ;)

    Anyway, with the compiling and testing on hardware steps complete I can continue on adding more functional code. That means I need to write "drivers" to get controller input, sound and graphics working from my own code. It might take a little while...but that's ok. :D
    I have been looking in the wrong place for wiiu examples it seems! The Wii U Toolchain (or WUT) is a little different from the tools to create wii, gamecube, 3ds, nds, gba and even switch homebrew! For those other platforms the examples are in a separate github repository but this is not the case for the Wii U. It seems that the "wut-tools" repository also contains the examples..which I did get the "Helloworld" from earlier. But I did not notice that it has examples using two different build systems! There is the regualar old "make" and the modern "cmake" that works quite differently, but is also way more flexible! The thing is though that in the "make" examples there is only a single "C" and "C++" hello world example! Looking in the "cmake" dir I see a lot more examples and even one for drawing a triangle on screen!!!!! :D

    What's so exciting about drawing a triangle you might be wondering? Well...the basic element of a modern 3D capable GPU is .....triangles!! :rofl2: So with this example I should be able to figure a couple of things out on how to use the GX2 library and how drawing a triangle to the screen....and later a textured quad! That last one I have to figure out on my own though...as there is no example provided!

    The good news is that these Cmake examples do not seem to use threads like the helloworld I took code from. While threads are cool....and I really want to use them! It's also really complex to do right and make efficient use of them! Creating one seems easy as you just "call a function as a thread". In my game engine I could use this to speed up converting the assets during loading, or other cool things. I am just glad that I do not NEED to use it right now! :D

    Also found this really cool tutorial: https://github.com/yawut/ProgrammingOnTheU
    And even a wii U emulator called decaf: https://github.com/decaf-emu/decaf-emu

    Lot's of new information today. maybe a good idea to take a break from it. :wink:
    For now I have given up on compiling the decaf-emu on my old ubuntu 18.04.....it complains a lot about missing stuff! Taking too much time! I'll look into it later since it would be awesome!!

    While the examples for WUT are limited...it's progressing nicely and I can now receive debug messages from the Wii U on my PC! :D This is VERY helpful when something breaks and the screen stays black for whatever reason on the TV and/or gamepad! I have a function called "fatal_error" that has an infinite loop in the Wii U code...and I could not figure out why before this! Then I noticed that it was the FileSystem driver that can't find the files!!!

    The function is fixed and it shows as message, waits 5 seconds and then does a "clean exit" into the HBL. That at least takes care of the tedious forced shutdown and performing the browser exploit all over again!

    I have placed the game files on the SD card manually to make things easier for now. The SD card obviously needs to be opened somehow but it seems every app I looked at so far does it in a different way! This might also have something to do with the various methods off exploits requiring a different way to open it. I might have to look up how some of the gameboy and SNES emulators read the files, and hope they are updated enough to make use of the recent WUT.

    When I have file reading working the real fun starts...as then I can finally show some graphics on the screen! :D
    Getting SD card access involves quite a bit it seems! I have been reading up on various wiiu homebrew and I have a sense of how it works....but not entirely yet. I was thinking at first that maybe the SD card is already mounted somewhere but I just don't know the correct path to use, right? Then I throught....HEY, SaveMii can make backups of savegames to the SD card and shows the full paths while it's doing it's thing! I prepared it to backup a savegame from Pikmin 3 and before pressing A I started filming with the slowmotion cam on my phone....totally unesseary since the backup process takes a couple of seconds. But at least now I had a path to try loading my files from! It was "/vol/storage_sdcard/" for those who are also struggling with this issue! And what do you know!!! I can read the first file from the SD card!!! well, I can read the header of the file as I am having issues with setting up buffers in memory for ZLIB to use. It exits before even calling ZLIB so it's not an issue with the library at this point.

    Then ofcourse my app crashed again and I had to force a shutdown of the console! While rebooting into HBL with all the browser exploit stuff is "convenient and easy enough" it does feel like it takes about 40-50 seconds each time! Not blaming anyone involved in the exploits or the HBL, your work is awesome and greatly appreciated! It's just that when debugging homebrew it's a tiny little annoying that a reboot takes this long.:shy: At least it's less of a hassle than what I had to do on the GameCube with the SD media launcher disc! That thing alone took 20 seconds or so! :rofl2:

    With my little rant about the reboot out of the way...I noticed that after rebooting I got an error the file could not be found anymore! What!!??? Why did it work before??? Ohhh...right! I tried it AFTER running SaveMii! Maybe it did something to mount the SD card that got left behind after exiting. Yep, that was it! Why not add another 30 seconds to the boot time hey? :cry:

    To be honest though, I am glad to even HAVE SD card access now so I can work out the following errors with memory allocation and stuff. That it takes 2 minutes (or whatever) to boot after a "crash" is annoying....but at least it;s working! Man....how did I ever dare complaining about Homebrew Channel on the Wii to take 5 seconds to reload the network driver so I could upload a new build! Hahaha:rofl2: I have to say...that is a great feature of HBL that after my app "exits gracefully" it returns to HBL and I can upload a new one immediately!

    Just for fun some debug output:
    Code:
    INFO          gpu_wiiu.cpp:111  |========================================
    INFO          gpu_wiiu.cpp:112  |  BatteryCheck - WiiU - v0.3.5
    INFO          gpu_wiiu.cpp:113  |========================================
    INFO      batterycheck.cpp:96   |Searching for game data...
    DEBUG          fs_wiiu.cpp:32   |jzFS::open(Binnen.j2l): /vol/storage_sdcard/apps/batterycheck/data/Binnen.j2l
    DEBUG              j2l.cpp:37   |libjz2::J2L(Binnen.j2l)
    DEBUG              j2l.cpp:38   |                    ID: 4c 45 56 4c LEVL
    DEBUG              j2l.cpp:39   |          PasswordHash: 00 ba be
    DEBUG              j2l.cpp:40   |             HideLevel: 00
    DEBUG              j2l.cpp:41   |             LevelName: Battery Check
    DEBUG              j2l.cpp:42   |               Version: 514
    DEBUG              j2l.cpp:43   |              FileSize: 26046
    DEBUG              j2l.cpp:44   |               FileCRC: f369afff
    DEBUG              j2l.cpp:45   |           HdrPackSize: 798 0000031e
    DEBUG              j2l.cpp:46   |         HdrUnPackSize: 33517 000082ed
    DEBUG              j2l.cpp:47   |        EventsPackSize: 2148
    DEBUG              j2l.cpp:48   |      EventsUnPackSize: 174660
    DEBUG              j2l.cpp:49   |      SectionsPackSize: 7545
    DEBUG              j2l.cpp:50   |    SectionsUnPackSize: 21592
    DEBUG              j2l.cpp:51   |        LayersPackSize: 15473
    DEBUG              j2l.cpp:52   |      LayersUnPackSize: 73082
    DEBUG          fs_wiiu.cpp:32   |jzFS::open(Binnen.j2t): /vol/storage_sdcard/apps/batterycheck/data/Binnen.j2t
    ERROR     jzFileSystem.cpp:89   |readZ: allocation error- packed
    
    Those are log messages generated by my own code, send over wifi to my pc running "udplogserver" to catch the messages. Not sure how the protocol works and if it's spamming my entire network with these messages...but whatever. I am getting output that is NOT shown on screen as there it crashed before it could update the screen! What is a slight problem is that when I started I used "printf" to show some debug stuf on the terminal in linux. This is mostly portable on many platforms....but unfortunattly on the WiiU it is not! I have replaced MANY of those messages already with my own LOG_DEBUG() macro's and that saved me here...hahaha. I only had to check if it's compiling for the WiiU and then instead of printf() use WHBLogPrintf(); For the already rewritten parts it now works completely transparent...only some of the older stuff dealing with the game files still uses printf's. ^_^

    It's not a big problem as I wanted to replace those debug messages anyway to use the new macro's. It gives me those nice message types and the exact file and line number so I know where it was generated from! Really helpfull! :D

    It's almost time to post a new blog entry I think, but I want to show a picture from the game on the WiiU gamepad LCD. Maybe even as a video...proof it works or something. Hahaha. And I was also thinking about creating a "BatteryCheck - Wii U" thread yesterday....and I almost did! But that would be far to early in the current state! Yeah, I am working on it but almost NOTHING of the game is actually working yet!

    I do have BIG plans with the Wii U version though! Obviously there will be an option to switch gameplay between the Gamepad and TV, or on both at the same time. But for debugging...showing the game on the LCD as normal...and then on TV show detailed info on the state of internal stuff. Or the ENTIRE level at once. Or just zoomed out? Options to show the individual textures that are generated on screen.....many possibilities:D
    Because I just HAD to know I used my phone to record the boot time and all steps involved....(not putting it online though)...but here is the list:
    - 00:05 - power on console
    - 00:30 - press "ok after forced shutdown
    - 00:33 - double tab internet browser
    - 00:45 - click on exploit bookmark
    - 00:55 - click on "Run Homebrew Launcher" (took longer since my touch was not registered or something.
    - 01:12 - run Mocha CFW
    - 01:32 - Launch "SaveMii Mod" (again slower because of touchscreen issues)
    - 01:50 - Exit from SaveMii after it detected 10 titles from NAND and USB
    - 01:55 - Run "wiiload" from the PC
    - 01:59 - Game crached again, hahaha

    Even if you take of maybe 10-15 seconds for my clumbsyness during recording with the touchscreen....that is still well over 1,5 minutes to reboot into HBL with the SD card enabled! To be fair that can be reduced by about 40 seconds if I can figure out how to not depend on mocha and savemii to access the SD card! It's just a minor inconvenience that booting into a state that works takes this long...but in case my app does a "gracefull exit" it only takes about 5 seconds to be able to upload another build! Because if it does....it returns to HBL with everything still in the correct state! Although I have no idea if there are memoryleaks and other nasty stuff left over from a "crash". I hope not! :lol:

    Most crashes I had were related to the PPC architecture and that the compiler flag I use for the GameCube and Wii "GEKKO" does not work when compiling for the WiiU! The biggest thing that needs to be done is convert the numbers read from the game files into BIG-Endian format. It's what the PPC in the WiiU needs to have it's numbers in. In simple terms it reverses the byte order. So a 4 byte uint32_t with the values 1234 becomes 4321. Remember....BYTE values as in HEX...just wanted to keep the numbers short :P

    You know what the best part is?? It loads all game files!!! And the gameloop is working already!!! YAAAY!!!:yayu:

    Now comes the time to look into the graphics examples and load some actual graphics!! The splashscreens should be easy since they are just bitmaps. But setting up the GPU is going to take some time again....well...progress is made right? :D
    There I was looking at the WUT example to draw a triangle using the GPU and gx2 library to figure out what's needed to initialize it...and I found this little snippet hiding in there!!!!
    Code:
     if (!WHBMountSdCard()) {
          result = -1;
          goto exit;
       }
    
       sdRootPath = WHBGetSdCardMountPath();
       sprintf(path, "%s/wut/content/pos_col_shader.gsh", sdRootPath);
    Are you freaking serious!!! That's all!!!! Why was there not just a simple example that lists the SD card contents or something!!! Or more detailed documentation...whatever. I have slightly modified this code into this:
    Code:
      if (!WHBMountSdCard()) {
        LOG_FATAL_ERROR("Could not mount SD card!");
      }
      __sd_path = WHBGetSdCardMountPath();
      LOG_DEBUG("sd: %s",__sd_path);
    That will mount the SD card and if it fails generates a "FATAL ERROR" that does a clean exit into HBL after 5 seconds. Otherwise it sets the __sd_path variable that I use in the FileSystem driver to open the files....and....BAM!! Loading files from SD card without having to run mocha and savemii first after a cold boot! Reduces the reboot time to about 60 seconds! AWESOME!!!! :D:lol:

    Now I need to continue setting up the GPU and graphics functions to make it actually show stuff on screen. I had disabled all the previous stuff that dumped the logs to the screen. It now logs to the udpServer only...which I can see on my PC. I have enabled too much debug messages but I can see it's loading the files and entering the main loop. There is an issue with the collision detection....not surprised actually....but I have seen debug messages that show JUMP and FALL that eventually stop. Meaning the player landed on solid ground. At least it did in memory...as the TV and LCD are both black at the moment, hahahaha:rofl2:

    I think I am going to contact that guy who wrote the tutorials but never continued after number 4. Based on my notes here maybe we can setup lesson 5 to load a simple image from the SD card. Or just list the SD contents. This is so simple and basic...it NEEDS to be included with the WUT examples! There is not even a valid reason for the triangle example to use the SD card...it tries to load a shader...that I do not have on my card anyway. But whatever! It did help me figure out eventually how to properly mount the SD card....that's what counts I guess. ;)

    On to the graphicssss. yeah!!! :toot:
    While I completely suck at Flappy bird...and therefore I do not like it as a game on whatever platform...I installed it anyway to see how it runs. And it runs silky smooth with scrolling sprites and backgrounds, stuff fading in and out....LOTS of cool stuff from a technical point of view! I am not loading graphics from a PNG file like Flappy Bird does but I am sure I can figure out a way to at least show my own splashscreens on both the TV and the gamepad! I really don't care how it looks....warped out of shape....wrong colors...etc...as long as it's recoqnizable that it is indeed the correct graphics! Just look at my PlayStation 2 adventure from last year...I continued with the sprites having a color issue. Made the game work and fixed a few of the memory alignment issues. Later the color issue was fixed and it looks great on the PS2!

    Flappy Bird GX2 is the perfect example I was looking for and it should have all the info I need! All that's required for the splashscreens is create a texture that is full screen and convert the pixel data into something that the GPU will show on screen! Hopefully it will not take too long....I really like the speed I am progressing but it's also exhausting! :D
    ploggy, KleinesSinchen, newo and 2 others like this.
  • Archerite

    BatteryCheck: Maybe learn a few things from JJ2+ scripting??

    The original game is using the same game engine that was used for Jazz Jackrabbit 2, or actually an earlier version of it if I remember correctly. That's why I have been able to use the documentation on the Jazzz2Online website to unlock the secrets of the BatteryCheck files. There are minimal differences between Jazz2 and BatteryCheck files. Only the version number and a copyright message in the header if I remember correctly...(I have not really looked at it for over 2,5 years now ;))

    Last weekend I have been reading more information from the Jazz2Online website about a very popular mod to the original Jazz Jackrabbit 2. It's called JJ2+ and among bug fixes it added scripting abilities with a language called AngelScript. It's very similar in syntax to C++ and the way they used it in JJ2+ let's a custom level creator have complete control over the game play! You can read more about it if you want in the JJ2 Plus AngelScript readme over here

    Most of my game engine is currently based on many hours of reading tutorials and what I could figure out from the file format documentation. While I have managed to make that big mess of code behave somewhat like an actual game....there are countless bugs, issues and missing things!! I was doing some more research on stuff last weekend with jumping on platforms and collision detection....again...when I realized that JJ2+ allows a lot of customization through the scripting they added. That is when I started reading the readme page...which is quite long and detailed btw....to get an idea of what kind of objects and properties the real game uses. It was a really big surprise that I was actually doing stuff in a very similar way....giving me hope I am doing it right! :D

    The scripting readme also revealed a concept to me that I was working on....but never fully implemented yet. In simple words everything that moves or can be interacted with is an object! The object is a class that has methods and properties that allows it to be positioned and/or moved around. It also holds information about the current animation and the frame of the animation that is currently shown. It has more stuff in it but these are the basics that got me thinking....why did I not do that!!!???

    Over a year ago I had already posted a really long blog post about the "event map" being a little inefficient here. I explained there how much memory the event map uses when loaded into memory and an idea on how to reduce that significantly by 97%!! ( see that post third paragraph below the spoiler block for more info about it :wink:) I think back than it was just an idea but over the months after that I have actually implemented something that looks very similar to what JJ2+ scripting exposes! Basically an array of all objects in the game with properties for position, movement and animation!

    My idea now is to follow the JJ2+ scripting details a lot more to get more insight how to do things a little more efficiently. One of the things I need to do is make every "event" become an object and a few basic methods to position, move and animate the object. Everything else related to it's behavior needs to move into the BatteryCheck specific parts and out of the "libengine" code base. This will also make the engine more universal to use for other games and apps in the future! This will not happen over night off course, hahaha. It will take a couple of weeks to fully grasp the massive information in that JJ2+ readme document! :D

    What I really want to get out of all this is to REALLY separate updating and drawing the objects on screen! Right now things are still far to much mixed together and depend on certain conditions related to drawing! For example the collision detection and responding to collecting items....all done DURING drawing! There are multiple advantages if I get this right, but one of them is running collision detection and correction separately from the drawing code! Even keeping a history of the object states over the past few seconds might be possible! All it would take is dump the object array somewhere else after each game loop.

    One of my weirder ideas that would be possible after separating drawing from the gamestate is that I could send it over the network to another console to test it's rendering code! Even a synchronized gameplay maybe of ALL supported consoles at the same time!!!! hahahaha:rofl2: Like show it on my Linux desktop with all kind's of debugging enabled, or showing the ENTIRE level with a little "view" moving arround where the cammera is. Then send that state to A Wii, GameCube, PlayStation 2 and multiple 3DS systems ALL AT ONCE!!! hahahaha. I know...I am crazy! But it would be cool...and possible I think! :wink::rofl2:
    But seriously....having a "savable gamestate" makes it possible to implement saving and loading where you left in the game too. maybe those who played the game have seen the battery holders with a crystal ball next to them? Those are the "checkpoints" in the original game when activated with a battery swap. Actually saving the game is a manual step in the menu!

    About the collision detection and graphics glitches in the latest v0.3.4 release on some systems I can only say....to be continued! :shy: I want to fix the sprite drawing that makes some things disappear when they should not first. Mostly with the recharge gate which is missing some parts and animations currently. And I do have some ideas on how to fix the "falling through thin platforms" issue.

    Thanks for reading, hope it makes a tiny little bit of sense. Otherwise I am sorry. :wink:
    newo and smallissue like this.
  • Archerite

    I have been playing: Pikmin 3 on the Wii U - That game is addictive !!!

    Now that my WiiU is hooked up again....and I got a hacked together charger for my GamePad :rofl2::rofl2:....I have finally committed myself to do some actual gaming on the thing! When I just got it I know I have played a bit of Captain Toad and Donkey Kong but other than that...not so much. I did get quite the collection over the last few years....at some point it became even MORE than my regular Wii games!!

    I started a few days ago with the idea of playing a bit of Pikmin 3. I have played it a few times with the GameCube version but not that long really. I still liked it a lot though, which is why I got it for the Wii U and just never even played it! Anyway, the story is a little different but the idea is pretty much the same. You find pikmin and make them do stuff for you...while you just stand around watching them! What's up with that!!! But just exploring the world and finding fruit, fight animals, mourning the lost pikmin at the end of each "day". Just makes you want to go for just...one more....and another...and another.....! I have been playing it for like 6 hours in one session!!! :O:O....and no...my gamepad battery did not last that long! Had to recharge it while playing! More on that later :wink: One it got to the point I looked at the clock and it was 01:00 AM I though...ehm..maybe I should go sleep or something! :rofl2: My hands were also really painful from holding the gamepad that long....man that thing is heavy if you think about it! Might be just one other reason people did not like the Wii U as much!

    Before getting my Wii U ready for homebrew I had been thinking for month about getting another one....just in case something happens. It might fail, it might become a brick....who knows right. And my favorite webshop had enough of them for a good price....so I just went with it! This was after modding my gamepad cradle to charge it over USB...with loose wires everywhere and stuff, hahaha. I also ordered a pair of USB GamePad charge cables with the idea that might come in handy....and it sure did last night!! While playing the LED started blinking really nervously that it was almost empty.....just when I was fighting a boss....or rather the Pikmin were fighting him I guess :lol:...but I did not want to stop! So I grabbed one of those cables....and a powerbank! Charging...and continue playing!!!! hahahaha:rofl2::rofl2::rofl2:

    I think it took about two or three hours to fully charge....while playing the game at the same time. It seems to have taken about half the charge of my powerbank which is 10000mAh....but also about 5 years old. Still...not bad I think for using it and charging at the same time...and not being required to use the actual charger to the wall! :D

    I have received the "new" white WiiU with all the essential cables with it. I had doubts about which one to get....the white one or the black one. The only real true difference between them I have been able to figure out is obviously the color and the internal storage. 8GB for white vs 32GB for black. The price difference between them was less than 20 euro's....and I got one of the "more used" white WiiU's now that has a few scratches on the gamepad screen. I have not looked at it in much detail yet....since I have been playing Pikmin on the black Wii U I already had. I also like to clean them a bit more when I receive them....especially these days. It's not like they are really gross...but in the edges I can see the dirty stuff...I don't want to touch that...you know! :( I might even have to take the gamepad apart completely to give it a good clean! But just a quick surface cleaning will have to do for now so I can at least test it out.

    So that was my solution to not finding the charger for my gamepad....buy a second console! Hahahah:rofl2: Just kidding ofcourse, I was already thinking about it long before that. I am sure that stupid charger will show up in a few days. It's just that for almost all other consoles I have plenty of spares....since they are cheap enough to get. The WiiU is just a bit "Too much" to have a lot of laying around. To give an idea....I stopped counting Wii's at 10+...that might include at least 3 Wii mini's. Then there is 4 GameCube's. And 6 3DS's one of each different model, but not variation. Maybe like 3 DSi's and 5 DS's. Then 3 GBA SP's of which one is an AGS-101, and two non backlit GBA's. It get's more modest with the PlayStation's though....only a Slim and Phat model for those. Yep, I REALLY need to sort out my stuff.

    You might be wondering why I even have so many consoles at all? The 3DS's are a different story....I just wanted all models there were. But not so much every color variation. Having this many turned out to be useful while testing the 3DS version of my homebrew game. When one of them was empty I could use another one that did have some power left. The GBA's I got mostly last year when trying to port my homebrew and to have the option...to one day...when we are allowed again....try one of those multiplayer gba link games to the GameCube.
    The many Wii's are simple to explain....they are just DIRT CHEAP! Easy to mod! And I had plans to mod them into portable wii's.....and then thought it would be a good idea to have a couple of spares around! And the PS2 phat I got simply because I think it looks cool....but its HUGE compared to the slim! I would like to have a few more PSP's for the same reason...spares if it breaks. But the one's I can find are just a bit to expensive I think.

    Finding out about the easy FreePSXboot for the PlayStation 1 makes me want that one too.....but I have been able to control myself so far! First put the "extra's" I currently have into storage so there is more space! Then make sure to fix a couple of bugs in the homebrew game! Make background music and sound effects work on ALL of them!! Then....maybe....I give my self permission to start looking for a PSX again! Hahahah:rofl2: (I don't think I will keep myself to this BTW...but it's nice to have goals and rewards right? :D)

    This one got all over the place and really long. Hope it was fun to read. :D
    WiiMiiSwitch likes this.
  • Archerite

    BatteryCheck: Finally fixed floor collision detection bug! ....and created two new ones!!!!!!!!!

    Almost since the beginning of my homebrew project the collision detection has been really bad! I have made that clear, but still it makes it feel a bit of a "bad game" too me. One of the biggest issues I had was that when jumping or falling from a higher platform the player sings into the ground a couple of pixels. The amount varies with the falling speed but it's like between 2 and 16 pixels I think. Enough to notice and being annoying! Having released a couple of proof-of-concept demo's over the past 2 weeks makes the issues even more important to fix! Once and for all!! ...kind of anyway, until I find an even better way to handle collisions in my game engine! :D

    Yeah, this post got long...leave now if you don't like to read it. Thank you :D

    It took me quite literally DAYS to even find the problem that makes you sink into the floor. Part of the problem was that a collision with the ground is detected, but it was never corrected! The newer versions 0.3.x have a little "correction" code but it's not good. Especially on the edges of platforms it made you sink into the floor until you were on the ground "with both feet" in a way. I added debug statements, extra markers on screen all over the place and then I finally noticed that both feet sensors were actually measured from the center!! :O
    That explains why the "sinking" did not happen until the center of the player sprite, since that is where the "correction" took place. On top of that there were some minor pixel calculations that were off by just 1. When I moved these sensors into the correct positions the player is correctly placed on the ground and does not sink into it half way on the edge! But for some reason jumping and falling away from the edge still made you sink in a little like before. And when you approached the edge...the correction took place to the right ground level!! :wacko:

    After a few more hours of debugging I finally noticed what I had been missing ALL THIS TIME!!! There was a check to see if "A < B" and for "B < A" but NOT for "A == B"!!!!! Meaning that if both sensors reported the same height the floor was correctly detected...but the player's position was NOT corrected to ground level!!:shy: So when I included this last check...finally...the floor collision correction code behaved as it should! Unless off course when the platform is less than 8 pixels thick....in which case you "might" fall right through them as if the things were not even there AT ALL! sometimes! Yep, in a few cases they do work as they should, including the corrections and stuff. But if you jump a certain distance or fall from a certain height....you jump through!
    The good news is that this is an issue I have read a lot about in tutorials for 2d platforms. The solution is to look ahead if a platform is nearby, but that is easier said then done! ;)

    If you were thinking that "falling through thin platforms" was one of the new bugs...your right! So what's the other one? I am going to tell about it right now! :ha: I am really happy that the floor detection is working better now....but during testing and debugging that I noticed the walls became an issue again! In the last version it was already happening that you could "stick to the wall" and jump into places you normally should not be able to! It's like Batteryman learned a few tricks from SpiderMan or something, hahaha. :lol:
    The second new bug is that when you're close to the wall, it's still detected, but the floor detection incorrectly kicks in and tries to "correct" the player UP! So it detects the wall as the edge of a platform! Which is ofcourse very wrong!

    As for the graphics corruption on the Wii and GameCube.....I just did not have time to look at them yet! I am pretty sure that it's an issue with my less than efficient way of using too much memory! On one of the crash screens on the GameCube I could see that it was using around 19-20MB of RAM. That does not sound like a lot these days right? Well, consider that the GameCube only has 24MB of RAM in total and that some of it is reserved for the BIOS and double framebuffer (not sure exactly about the numbers here....but somewhere like 3-5MB I think) and you could see the problem! There is in theory 16MB or ARAM meant for the audio....and some games used it to store temporary data in there other than sound. The downside is that this memory is much slower to access that main ram.

    That explains it for the GameCube a little, but the Wii had a lot more RAM right? True it has 88MB of RAM in total but it shares a lot of the GameCube architecture! It still has the 24MB (1T-SRAM) known as MEM1, and an additional 64MB (GDDR3) known as MEM2. While I am sure MEM2 is faster than ARAM I do not yet know how to specify in my code to make use of it! So I think everything I am currently doing with BatteryCheck on both the Wii and GameCube is happening all in MEM1 which is now running out of space!

    While I called it a "surprise" before in the list of features with v0.3.4 I think I can just say now that it has "splashscreens" just before starting the game. First the actual menu background is shown for 2 seconds followed by the splashscreen that belongs with level 1. The real game shows it too...just REAL short on modern PC's so you barely notice it before it's gone! It's a shame really as the artwork is amazing! These "splashscreens" are working on: Linux, PS2, Wii and GC.....but the 3DS has issues with them and I had to disable it! I have no idea why yet but it might just be another memory issue on the 3DS. It has much more main RAM but only a limited VRAM...and that one might be a bit full. I think I am not using paletted textures yet which increase the size of them a lot...and it might be too much for the 6MB of VRAM. I am not sure if I tested it on a New 3DS actually....since they are supposed to have 10MB of VRAM if I remember correctly.

    That's about all I have to say todo....I know it's a lot. Deal with it! :ha:
    alexander1970 and KleinesSinchen like this.