While I have made a few blog post's now about making a video and that it's coming soon....still nothing! 
One of the main reasons is a bad audio connection....and I really need to search for the right adapter cables to fix it! Searching for those cables is made difficult by the high temperatures the last few days....at least to me they are high. But I have done a couple of other useful things on the BatteryCheck code!
It had been a while since I last committed all the changes into my local GIT repo! AGAIN! I'll never learn I guess
....anyway everything is committed and the work tree is clean again. So I went with fixing the 3DS build and figure out why the splashscreens make the emulator crash! Or at least have it output a TON of error messages about memory access not being ok! Because of those errors I thought maybe they splashscreens were to big or some memory was not initialized properly or something. After a couple of experiments I found out that it does work if I copy the 640x480 image into a 1024x1024 texture and than display that! So it seems that texture sizes need to be a power of 2 or something. So now the 3DS has splashscreens shown but they are not scaled yet....making it zoomed in a lot. I have not tried it on hardware yet but I'll do this later.
The idea is is that before I record a video of any of the consoles I can compile the latest version of the code and run it in the emulator and on hardware! Hopefully with at least the same functionality (or more) as previous versions so I can upload them as a new ALPHA for every one of them! I have decided that preview v0.4.0 will not be released until EVERY current platform has a working installer! With the current agreement from the owners I think I can even provide the download of the gamefiles in a more convenient way than was possible before. Most likely I will upload the installation files here in the Download section with a disclaimer that the owners gave permission but are not responsible for it. Stuff like that.
I have been thinking of another option for the installer that is even more convenient for new users....embedding the files directly into my own installer! The original installer is a bit over 12MB but it also contains DirectX and other libraries that it can optionally install on a windows machine, but the actual required files for just the game are less than 5-6MB in the compressed blob! My idea is to extract this blob from the Setup.exe and embed it directly into my own installer. A readme.txt included in the archive will fully explain this and how to verify the files yourself in case someone might want to do this. While it's an awesome option in the future I think it's going to take a few months to build a version like this. So at first it will just be the v0.4.0 installer which is the same as it is now on: GameCube, Wii and 3DS but will then also be ported to: Wii U, PlayStation 2 and the Switch!
Now as to the title of this blog post....sorry it got a bit long again. The best way to actually compare the original and my version is to run them side-by-side and make them use the same controller inputs. Or do a similar action in both separately and then using some video editing magic overlay them to compare the frames to the pixel! I know that's extreme but I wanted to go for a near 99.9% replica of the original game where ever possible! Especially when it comes to where objects are placed in both "normal" or "mirrored" mode this is important to me. Also walking speed, animation and sound effects need to be as close to what they should be as possible.
The third thing that really needs to be rewritten from the ground up is collision detection and correction! AGAIN! I need to simplify it and make everything on screen that could be moved a game object. There are a few places where this was done already but most of the collision events are handled for every object on it's own! There are common functions offcourse but it's not enough to make it really all happen in a single function. I did some research on the topic again and I have planned this:
- stage 1 - Do a quick hitbox check with AABB rectangles.
- stage 2 - If the AABB hitbox of two objects collide only then do a pixel perfect detection on the overlapping rectangle only! (hopefully this reduces computation time)
- stage 3 - When pixel collision is detected the object::collide() event should be called I guess.
This would mainly be required for the collectibles like batteries and extra life. I do not think this same scheme would work for the tilemap! There is for every image and tile also a "mask image" which is basically a black and white version of it. But tiles are special as they also have a mask specifically to indicate which parts of it are solid! I am not using those at all right now! The way I did collision detection on the map is looking at the tilemask manually and then making a math equation out if it! It was complex to setup....but I regret this choice more and more! Because it limits my gameengine to just this tilemap and no other! That's the reason I can not test the second level yet or even the boss level.....they each have their own tilesets with a different tilemask. Making parts of the map that "look" solid actually be "clear" making you fall through the floor. Or there might be invisible walls where there should not be anything!
For making the Jazz Jackrabbit 2 levels working correctly this is an essential change! They do already load and visually the colors are correct and tiles are in the right places, but it's rare to have tiles with the same mask as the first batterycheck level. Giving the issue of invisible walls or getting stuck inside an invisible one!
As always those are some big plans but it does not have to happen overnight ofcourse....I try to keep it realistic but those are a few of the things I have planned or that I did already. At least this helped to clear my mind a little from this stuff...and it got even longer and longer....hahahah
Until next time
One of the main reasons is a bad audio connection....and I really need to search for the right adapter cables to fix it! Searching for those cables is made difficult by the high temperatures the last few days....at least to me they are high. But I have done a couple of other useful things on the BatteryCheck code! It had been a while since I last committed all the changes into my local GIT repo! AGAIN! I'll never learn I guess
....anyway everything is committed and the work tree is clean again. So I went with fixing the 3DS build and figure out why the splashscreens make the emulator crash! Or at least have it output a TON of error messages about memory access not being ok! Because of those errors I thought maybe they splashscreens were to big or some memory was not initialized properly or something. After a couple of experiments I found out that it does work if I copy the 640x480 image into a 1024x1024 texture and than display that! So it seems that texture sizes need to be a power of 2 or something. So now the 3DS has splashscreens shown but they are not scaled yet....making it zoomed in a lot. I have not tried it on hardware yet but I'll do this later.The idea is is that before I record a video of any of the consoles I can compile the latest version of the code and run it in the emulator and on hardware! Hopefully with at least the same functionality (or more) as previous versions so I can upload them as a new ALPHA for every one of them! I have decided that preview v0.4.0 will not be released until EVERY current platform has a working installer! With the current agreement from the owners I think I can even provide the download of the gamefiles in a more convenient way than was possible before. Most likely I will upload the installation files here in the Download section with a disclaimer that the owners gave permission but are not responsible for it. Stuff like that.
I have been thinking of another option for the installer that is even more convenient for new users....embedding the files directly into my own installer! The original installer is a bit over 12MB but it also contains DirectX and other libraries that it can optionally install on a windows machine, but the actual required files for just the game are less than 5-6MB in the compressed blob! My idea is to extract this blob from the Setup.exe and embed it directly into my own installer. A readme.txt included in the archive will fully explain this and how to verify the files yourself in case someone might want to do this. While it's an awesome option in the future I think it's going to take a few months to build a version like this. So at first it will just be the v0.4.0 installer which is the same as it is now on: GameCube, Wii and 3DS but will then also be ported to: Wii U, PlayStation 2 and the Switch!
Now as to the title of this blog post....sorry it got a bit long again.
The best way to actually compare the original and my version is to run them side-by-side and make them use the same controller inputs. Or do a similar action in both separately and then using some video editing magic overlay them to compare the frames to the pixel! I know that's extreme but I wanted to go for a near 99.9% replica of the original game where ever possible! Especially when it comes to where objects are placed in both "normal" or "mirrored" mode this is important to me. Also walking speed, animation and sound effects need to be as close to what they should be as possible.The third thing that really needs to be rewritten from the ground up is collision detection and correction! AGAIN! I need to simplify it and make everything on screen that could be moved a game object. There are a few places where this was done already but most of the collision events are handled for every object on it's own! There are common functions offcourse but it's not enough to make it really all happen in a single function. I did some research on the topic again and I have planned this:
- stage 1 - Do a quick hitbox check with AABB rectangles.
- stage 2 - If the AABB hitbox of two objects collide only then do a pixel perfect detection on the overlapping rectangle only! (hopefully this reduces computation time)
- stage 3 - When pixel collision is detected the object::collide() event should be called I guess.
This would mainly be required for the collectibles like batteries and extra life. I do not think this same scheme would work for the tilemap! There is for every image and tile also a "mask image" which is basically a black and white version of it. But tiles are special as they also have a mask specifically to indicate which parts of it are solid! I am not using those at all right now! The way I did collision detection on the map is looking at the tilemask manually and then making a math equation out if it! It was complex to setup....but I regret this choice more and more! Because it limits my gameengine to just this tilemap and no other! That's the reason I can not test the second level yet or even the boss level.....they each have their own tilesets with a different tilemask. Making parts of the map that "look" solid actually be "clear" making you fall through the floor. Or there might be invisible walls where there should not be anything!
For making the Jazz Jackrabbit 2 levels working correctly this is an essential change! They do already load and visually the colors are correct and tiles are in the right places, but it's rare to have tiles with the same mask as the first batterycheck level. Giving the issue of invisible walls or getting stuck inside an invisible one!
As always those are some big plans but it does not have to happen overnight ofcourse
....I try to keep it realistic but those are a few of the things I have planned or that I did already. At least this helped to clear my mind a little from this stuff...and it got even longer and longer....hahahahUntil next time
