Modern GL 2D game lib needed

[mrToad]

Currently I am using the fixed-function pipeline of GL for a 2D game, similar to Rel's Easy GL2D lib. FFP provides enough for me. But does it make sense for a commercial-destined project? That's the main reason I am concerned. I'm not sure how long FFP will be supported, even solely on Windows desktop/laptop GPUs, because I don't know a lot about it. Perhaps it will be supported for a very long time, I don't know. It's been long-deprecated. What do you think?

On the other hand, to be safe and up to date, if someone was able to create a simple modern 2D GL lib to replace the classics such as Easy GL2D, that would be awesome. Just to be able set up a screen mode, and blit loaded sprites/images with alpha support, scale x/y, rotate, flip.

paul doe has already coded some useful blends that could be implemented. I'm currently talking with him about it in another thread, but I wanted to open it up to everyone.

A primary goal would be to keep it "easy" to use, much as Rel's version was, if that is possible.
Do you think the community would be excited to have this?

Perhaps if it is a difficult task, some contributions could be made toward its development.

[angros47]

OpenGL in windows is often emulated by DirectX (that's why only the older, fixed function based version is implemented). Fixed function features have been removed in GLES 2.0, and are planned to be removed in the last versions of OpenGL, as well. Also, some people claim Vulkan to be the successor of OpenGL, although it seems to have been less successful than expected (by looking at the examples, it seems to be too verbose to be of any practical use)

In the past I have made OpenB2D (a 2d library, adaptation of the basic4GL one) for FreeBasic, but I dropped it for lack of general interest. OpenB3D, on the other hand, is already able to be compiled without FFP (to be able to use WebGL, if needed)

I also remind you that the last version of FreeBasic supports natively blitting of the graphic page in OpenGl (no blitting of sprites, sorry)

[mrToad]

Thanks for your reply.

planned to be removed in the last versions of OpenGL

So, any programs that use it for rendering will soon no longer run on the latest GPUs? I'm just trying to decide whether or not to stick with FFP rendering, because it's been very convenient for a 2D game project, and I personally can't work out how to do the same things with modern GL. That's why I thought a simple new lib would be so useful. I don't want to stick with rendering that will break/no longer run as people upgrade their computers in a few years.

I may be able to just use FBGfx but scaling is taking a lot of FPS (I need to scale the final render of 300x144 pixels to a larger resolution so you can even see it!) Joshy's PutResize is the fastest scaler I've found, and it may work, but if you have a better idea, please let me know.

One other thing I would miss if leaving GL behind, besides sheer speed, is being able to scale down a sprite without losing pixels (the GL screen is already scaling pixels up).

I also remind you that the last version of FreeBasic supports natively blitting of the graphic page in OpenGl (no blitting of sprites, sorry)

This would be mainly for speed? In other words this could replace any FBGfx method of rendering to screen (Flip, ScreenCopy) and rather blit the screen buffer with GL? I will check it out. It would be nice if scaling could be done during that blit as well.

The real goal is to find any reasonable solution for my rendering.

[angros47]

Thanks for your reply.

planned to be removed in the last versions of OpenGL

So, any programs that use it for rendering will soon no longer run on the latest GPUs?

I have no way to know it, although there are so many programs still using the FFP that I doubt they will want to break retro-compatibility.
Likely, on new systems there will be several versions of OpenGL, old programs will use OpenGL 1.0, new programs will use newer versions. On embedded systems, on the other hand, there might be no legacy software to run, so they would support only the newer method (they already do that: on phones, for example, you have only GLES, and GLES 2.0 has no FFP)

I'm just trying to decide whether or not to stick with FFP rendering, because it's been very convenient for a 2D game project, and I personally can't work out how to do the same things with modern GL.

As long as your target is a PC, you don't have to worry too much. If you plan, in the future, to port your work to tablets, smartphones, smart tv, or gaming consoles, you will have more issues.

I may be able to just use FBGfx but scaling is taking a lot of FPS (I need to scale the final render of 300x144 pixels to a larger resolution so you can even see it!) Joshy's PutResize is the fastest scaler I've found, and it may work, but if you have a better idea, please let me know.

That's EXACTLY what the latest FBGfx does: have a look at the ScreenControl command (in particular the SET_GL_2D_MODE and SET_GL_SCALE options). You will do your final render at 300x144, and the GPU will take care of upscaling it, with no extra load on the processor, and no waste of FPS.

Joshy's PutResize is an efficient piece of code, but it does the resizing on the CPU, subtracting time that could have been used to perform other task, and causing the slow down. If you use the CPU to render the picture, and the GPU to upscale it, it would save a lot of time.

[mrToad]

Thank you angros47! That's exactly what I was wondering / hoping to confirm about the FFP. It is good to hear from one or two others that retro-compatibility would likely be important. paul doe also mentioned this over a year ago, but I believe in an old proverb "in the multitude of counselors there is accomplishment." The main issue is portability away from the PC, and it is worth considering, in light of how popular other devices are for games now.

That's great news about FBGfx. I've been away doing (besides work and family life) art, animation, and music for the project, so I've been ignorant of FB's updates. I am excited to check that out. :)

So a question comes to mind now. If FBGfx can handle my rendering, is it more likely to be portable to things like tablets or gaming consoles? Or basically, that rendering is in the same boat as using the GL FFP, and will also run into issues for porting?

Please excuse my ignorance regarding these things.
Thanks again for your thoughts.

[angros47]

So a question comes to mind now. If FBGfx can handle my rendering, is it more likely to be portable to things like tablets or gaming consoles? Or basically, that rendering is in the same boat as using the GL FFP, and will also run into issues for porting?

That rendering uses the GL FFP, so it can work even on older versions of OpenGL. Since all it does is drawing a textured quad (and it makes the quad as a triangle strip, drawing it with glDrawArrays, and not with glBegin...glEnd), converting it to GLES would not be difficult (one would just need to change the glVertexPointer to a glVertexAttrib call, and create a very simple shader to handle a textured mesh. It would become even simpler than the FFP version). I did a similar change on OpenB3D when I made the WebGL version, so I know

[mrToad]

Thank you, I understand now. A small change or two for the final draw is much better than rewriting a full FFP rendering setup later. I can only imagine the disappointment too, after the rewrite, that it still looks different!

Another question if you don't mind? On this topic of porting to other devices, such as a game console. Currently FB can build for win/lin/dos and Xbox? This is an area I know nothing about, but you say "If you plan, in the future, to port your work to tablets, smartphones, smart tv, or gaming consoles..." I didn't think this was possible for FB. Is this based on FB's potential development, or if rewriting the engine in another language?

[angros47]

Currently FreeBasic can build for windows 32 and 64, for linux 32 and 64, and for dos (only 32, because there is no official 64 bit dos extender). Forget the xbox port... it is an old port, not updated in years, for an old version of xbox not in production any more.

There are unofficial ports of FreeBasic for Raspberry Pi and for Macintosh, as far as I know. Also, some years ago there was a fork (now abandoned) for Emscripten (it allowed to compile as a subset of Javascript and run the compiled program inside a web page).

At the moment, there are no versions of Freebasic able to compile for Android or iPhone, as far as I know. It is possible that, in the future, a version of FreeBasic for those platforms would be developed (since it would emit C, and not Java code, for Android it would need to compile using the NDK, that is less used, so developing for Android would still be a bit tricky)

If FreeBasic will be ported to mobile devices, surely porting your work to them would be worth (it wouldn't require big effort, and it would increase the user base). Otherwise, rewriting the engine in another language might take much more time (I can't estimate how much, since I have no idea of how complex your engine is, and how much it relies on FB-specific features), and you must decide if it's worth.

[mrToad]

Edit: revised, because I often write nonsense and later fix it. :)

Thanks for the info, I appreciate the thorough coverage of Freebasic's current abilities. I didn't think XBox was supported anymore. Anyway, I think XBox is rather dying (from what I've heard) as a gaming console, especially compared to the Switch and Playstation.

There's too much to keep up with in the game-dev world :)

I suppose this is why Unity is popular right now, as it is apparently able to (much of the time) compile for most target platforms. But I can't imagine myself rewriting the engine in C#, or even C++, basically like starting all over. I am not very experienced with those languages, and I may miss some of the features of FB. I do have about 20 years experience coding QB/FB (along with some web and other languages), and I could probably adapt to those languages, but I wish to 1) reserve time and energy, 2) finish what I started rather than starting over, 3) support FB!

Probably I should just focus on Windows PC for this project, I'm just one Toad after all. :)

Anyhow, now I am trying to use ScreenControl for GL and scaling:

Code: Select all

ScreenControl(SET_GL_2D_MODE, OGL_2D_MANUAL_SYNC)
ScreenControl(SET_GL_SCALE, 4)
ScreenRes(1024,768,32)

Then I PUT one FB.Image to the screen in a loop. However, when I Flip, the screen draws the image as normal, without scaling. What am I doing wrong?

If I should create a new thread, let me know :)

[angros47]

Looks like you forgot to set the OpenGL mode in ScreenRes, using the GFX_OPENGL flag.

Code: Select all

ScreenRes(1024,768,32, , GFX_OPENGL)

Although the window itself will be scaled, and made 4x bigger (4096*3072), so you might want to use

Code: Select all

ScreenRes(256,192,32, , GFX_OPENGL)

instead

[mrToad]

Ah, I see. Thank you :) When I read the help file I saw that when using the GFX_OPENGL flag "FreeBASIC graphic functions can't be used," so I thought it was related to something else.

It works well, but it is blurry, because of the method of scaling. Is there some way to do a nearest neighbor scale?

[angros47]

Try adding

Code: Select all

glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_NEAREST)
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_NEAREST)

after ScreenRes, tell me if it works (you need to include the OpenGL header, of course)

[mrToad]

Yes, that works perfectly :)

In fact right after that, I looked at EasyGL2D lib and found the same code. Rel also put some other stuff in there, like

Code: Select all

glTexEnvf( GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE )

but I would need to research more why it was important. It doesn't seem necessary right now anyway.

Anyway, thank you! This is a brilliant addition to FBGfx.

[badidea]

Could be very useful for quickly upscaling old games. Test code:

Code: Select all

#define NO_BLUR 0 'change to 1

#include "fbgfx.bi"
using fb

screencontrol(SET_GL_2D_MODE, OGL_2D_MANUAL_SYNC)
screencontrol(SET_GL_SCALE, 3)
screenres 320, 200, 32, , GFX_OPENGL

#if (NO_BLUR = 1)
	#include "GL/gl.bi"
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST)
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST)
#endif

dim as integer w, h, d
dim as string driverName
screeninfo w, h, d, , , , driverName
print driverName & " @ " & str(w) & "x" + str(h) & "x" + str(d)
circle(320\2, 200\2), 90, rgb(200,200,0)
flip

sleep

[Gunslinger]

Could be very useful for quickly upscaling old games. Test code:

Code: Select all

#define NO_BLUR 0 'change to 1

#include "fbgfx.bi"
using fb

screencontrol(SET_GL_2D_MODE, OGL_2D_MANUAL_SYNC)
screencontrol(SET_GL_SCALE, 3)
screenres 320, 200, 32, , GFX_OPENGL

#if (NO_BLUR = 1)
	#include "GL/gl.bi"
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST)
	glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST)
#endif

dim as integer w, h, d
dim as string driverName
screeninfo w, h, d, , , , driverName
print driverName & " @ " & str(w) & "x" + str(h) & "x" + str(d)
circle(320\2, 200\2), 90, rgb(200,200,0)
flip

sleep

This code looks interesting for using 2d en 3d at some time.
To bad it hangs at screen flip command on windows 10 pc 64 bit.
And i had to update free-basic to 1.07.1