This is going to be a similar thing as my blog form August last year - the mystery console which was the PlayStation 2! 
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.
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 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! 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
Take a guess on what it might be
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! So the results after those 8 hours was this screen:
View attachment 266829
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:
View attachment 266830
The transparency issue remained but at least the rest of the colors were correct now. 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:
View attachment 266831
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!
View attachment 266832
I also have the controls working so I can walk around the level just like on every other platform I have ported it too. 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.
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! 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. 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
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.
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
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!
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! HahahaTake a guess on what it might be
Obviously because I can! 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.
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.
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!. I also have more than one PSVITA console: Both handheld versions and a VitaTV! 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!
With the Makefiles working now I tried compiling my game.....and while the GPU driver is disabled. The game actually compiles just fine! 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.
- 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!
. I also have more than one PSVITA console: Both handheld versions and a VitaTV! 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! With the Makefiles working now I tried compiling my game.....and while the GPU driver is disabled. The game actually compiles just fine!
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. 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:
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.
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);
}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! 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?
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!
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?
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 )
View attachment 266782
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!
)View attachment 266782
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!
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!
View attachment 266783
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! 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.
View attachment 266783
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!
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. 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!
So the results after those 8 hours was this screen:View attachment 266829
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:
View attachment 266830
The transparency issue remained but at least the rest of the colors were correct now.
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:View attachment 266831
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!
View attachment 266832
I also have the controls working so I can walk around the level just like on every other platform I have ported it too.
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. 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!
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.
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
