PS4? Xbox One? Switch?

General discussion for topics related to the FreeBASIC project or its community.
Post Reply
Landeel
Posts: 777
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

PS4? Xbox One? Switch?

Post by Landeel »

I'm making a game in FreeBASIC. A company is interested in publishing it.
Besides fb's rtlib and gfxlib, I'm also using OpenGL (graphics), SDL2 (win32 xinput, gamepad vibration), SDL2_mixer (audio).
I wanted to hear your opinions on how hard would it be to port the game to modern consoles (PS4, Xbox One, Switch).
TeeEmCee
Posts: 375
Joined: Jul 22, 2006 0:54
Location: Auckland

Re: PS4? Xbox One? Switch?

Post by TeeEmCee »

I have previously looked into porting a FB game engine (OHRRPGCE) to these three consoles using SDL2. I had another look.

So you're using fb's gfxlib (aka fbgfx) + OpenGL for graphics?

Summary: Switch and XBox One should be straightforward for me since I'm using SDL2, but fbgfx is a problem for you, and things look pretty bad for PS4 for both of us.

But if you've never ported something to another OS and toolchain you might be surprised how much work it can be even when all the libraries you're using are fully portable.

Anyway, there are two main questions: compiler and OpenGL support.

----- Compiler -----

The PS4 runs FreeBSD. Its SDK uses clang (https://en.wikipedia.org/wiki/PlayStati ... m_software). Switch's SDK is also based on clang (https://www.youtube.com/watch?v=9_7exO60EA8).

FB's GCC emitter really is a GCC emitter, not a C emitter. It doesn't compile with clang (at least not clang 7). Also I don't think FB's LLVM emitter is ready for use yet. However, it should probably be pretty easy to get -gen gcc working with clang. The problems I notice immediately are all easily solved:
-for x86 32 bit builds, fbc puts inline assembly in the .c which isn't compatible with clang. Not problem on other platforms. It'll be easy to fix fbc.
-fbc tells clang to produce asm which it then tries to compile. That doesn't work because clang produces llvm bitcode. Easy to fix: fbc already has code to compile llvm bitcode, or we could just make fbc tell clang to produce an .o instead of an .asm.
-clang hates the computed gotos fbc produces for error checking support (-e flag). Those really ought to be removed anyway if you're not using ON ERROR GOTO (I'll submit a patch when I have time). So just don't use -e.
I'm expecting there are no further problems that are serious. And I will be fixing these problems anyway, you don't need to worry about them.

Originally to target UWP (Windows Store and Xbox One) you would have had to use Visual C++, but it seems MS how provide a clang-based toolchain, and mingw (GCC) also has experimental support (https://stackoverflow.com/questions/129 ... with-mingw). I don't know whether clang or mingw would be the easier path, but probably at least one is easy.

----- Graphics -----

I don't really use fbgfx but it has the following backends: X11, X11+OpenGL, linux framebuffer, win32 DirectDraw, win32 GDI, win32 OpenGL, and some DOS ones. So it certainly can't be used on a console without porting it, that would be a full-fledged port. Only a part of it would need porting but it's going to be a substantial amount of work, and probably no one will do it for you (they can't without an SDK anyway). So either you might do it yourself, or (which requires the same expertise) you could use the console's API directly, or you could port your game to SDL2.

However SDL2 supports UWP and Switch (support added within the last year) but not PS4 (and no indication that port is being worked on).

AFAIK PS4 does not support OpenGL. Apparently there is an OpenGL ES 2 implementation... as part of the web browser? (https://blog.madnation.net/ps4-opengl-e ... -graphics/ -- this writeup is about homebrew, not the official SDK) I don't know whether it's available in the SDK to other programs or not. Considering that I can find no mention of PS4 supporting OpenGL ES, likely not.
So you seem to be stuck on PS4.
Switch supports OpenGL (https://wccftech.com/nintendo-switch-supports-vulkan/), so that's OK.

UWP doesn't support OpenGL either.
However, you can use the ANGLE library which is a wrapper that reimplements OpenGL on top of the DirectX API. It's a high quality well maintained library, used by both Firefox and Chrome.
If you were using SDL2 for graphics like me, then it could use DirectX directly instead of OpenGL.
Landeel
Posts: 777
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Re: PS4? Xbox One? Switch?

Post by Landeel »

Hey TeeEmCee,
Thank you so much for your detailed and complete answer. Just what I needed to know.

I'm using fbgfx for:
-Creating the Window/setting the screen mode;
-Loading images to RAM and applying a scaler before uploading to the GPU;
-Accurate collision checking in RAM using fb.images, put, get, line...,BF;
-Multikey, getmouse are also inside fbgfx, right? Those are easier to replace.

PS4 looks like a lost cause for now.
Switch should be easier.

So, a SDL2 backend for my game would solve a lot of my problems... It's a 2D sprite based game, so I think it's not going to be so hard.

The hardest parts are probably the collision checking and the image loader/scaler. I hope I can just work with 32 bpp images in RAM, and use the same code.

Well, I'm going to try that.
TeeEmCee
Posts: 375
Joined: Jul 22, 2006 0:54
Location: Auckland

Re: PS4? Xbox One? Switch?

Post by TeeEmCee »

fbgfx also has a null driver, which should work on all platforms. I have never used it, but I assume that you could use it do everything you need except for drawing to the screen and I/O, and use SDL2 for those. Yes multikey/getmouse/etc are part of fbgfx (though there is also a "console" implementation of multikey in the rtlib that is used for commandline FB programs).

Note that SDL2 has software implementations of loading .bmps, scaling, rotation, converting between pixel formats, etc. Actually, you can use all of these functions (they act on SDL_Surfaces) even if not using SDL2 to draw to the screen (which requires creating SDL_Textures from your SDL_Surfaces).
And if you have code to do custom image operations by reading/writing pixels directly using pointers you can easily port that code to work on SDL_Surfaces instead.
Landeel
Posts: 777
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Re: PS4? Xbox One? Switch?

Post by Landeel »

Wow, I didn't remember about the null driver.

I'm using a very specific image format (FLC from Autodesk Animator), and getting data from it to generate my collision data.

I guess I could still use fbgfx to calculate collisions and process the images. Then have a SDL2 backend just for input and rendering.

Or I could go full SDL2, and retrieve the collision data from BMPs, but I would have more to rewrite.

I will take a look at SDL's API documentation to see which route is better.

Thanks again.
Last edited by Landeel on Oct 07, 2019 19:55, edited 1 time in total.
Landeel
Posts: 777
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Re: PS4? Xbox One? Switch?

Post by Landeel »

Could get the game to work in a SDL window using:

SDL_CreateWindow
SDL_GL_CreateContext
SDL_GL_SwapWindow
SDL_GL_SetSwapInterval
SDL_GL_GetProcAddress
SDL_GL_DeleteContext

So, in case of a target platform that has OpenGL, my SDL backend could probably work already. That's crazy!

I still need to fix input and implement the SDL renderer in case OpenGL is not available.
Landeel
Posts: 777
Joined: Jan 25, 2007 10:32
Location: Brazil
Contact:

Re: PS4? Xbox One? Switch?

Post by Landeel »

I think a SDL_GL driver for fbgfx would be very straightforward to implement.
A full SDL driver wouldn't be hard either, if one can use fbgfx internals, and only use the SDL renderer to draw the output to the window.
But how to do it without making SDL a hard dependency?
Post Reply