31 color blending modes (WIP OpenGL version)

[paul doe]

paul doe - I have returned. *bows to you*
...

Nice to see you again, Mike ;) *bows back*

...
;D How are you?

It's a shame on me to be gone so long from this forum. I've returned to find good things, though.

Have you been working on anything fun or still doing the "boring financial stuff"? Did you meet your goal of becoming an independent trader? (I'm guessing that's like a freelance coder?)
...

Still doing boring stuff for a living, but working on different projects of my own. And yes, it's pretty much similar to any freelance activity =D

...
I re-read our conversations recently and reviewed all the code you wrote, taking my time with it. Although I'm no true GL programmer, I understand it a lot better due to your good commenting. Did you ever make further progress with the blitter?
...

Indeed I did. I've implemented a 'proper' blitter using FBOs and shaders, with all the blending modes we've discussed here (and others). Works like a charm. It's part of another, bigger GL framework but I can easily pluck it out if you want it to use as-is. Don't expect it to be as straightforward as this version is, though. You see, GPUs are really fast if you do process in bulks. Otherwise they become remarkably slow. This basically means that: *1* Your data needs to be carefully arranged in memory for them to upload/download it faster and *2*, you'll likely need to refactor a lot of your code to use it.

...
Although I've been working on other parts of the game, I recently attempted to change rendering to just software, incorporating your FB blending blitter, and Joshy's PutResize code for scaling the final render to user resolution. It's actually quite fast on my 10-year-old laptop! (I haven't tried it on any genuine 'craptops' yet.) The issue is now that I cannot scale down any graphics, or I will lose pixels. It doesn't look terrible in all cases but sometimes it's pretty rough. Also the GUI and fonts currently require being scaled to fit more text and save room on the screen.
...

That happens because, when you scale down, you invariably have to interpolate the pixels, leading to information loss (that's why the scaled image looks bad). There's no way around it: scaling a bitmap involves either loss of information (scaling down) or adding information that isn't there in the first place (scaling up). Generally speaking, nearest-neighbor interpolation leads to poor results when scaling down, so you need bilinear (at the very least). Also, if the pixels need to be rotated, you'll need to use sub-pixel accuracy to do it, otherwise you'll end up with 'gaps' between the pixels (due to rounding). All this, as you can imagine, consume a lot of resources and is, thus, quite slow in software. Factor in the blending modes and you'll find that, while you can certainly blit a few pixels with a reasonable framerate, real-time would be almost impossible.

If you're doing the kind of scaling you show in the image, then you may want to do trilinear interpolation (along three axes; the third axis being, of course, the available images to interpolate from).

...
So here I am wondering if I could beg, bargain, or threaten you to finish up that GL blitter? ;) ...

There's really no need. I'll upload a better version once I refactor it to deal only with 2D blitting ;)

...
You left off with a nice Add shader, and basics of scaling/rotation/opacity. I could use merely a Flip option and an Overlay shader, both of which I might be able to code myself. The real problem is how you didn't render via Framebuffer Objects, but did a sort of "hackish" render. It's still beyond me how to do it properly. If you haven't the time, no worries. I'm just checking out my options for final rendering.
...

Framebuffer Objects (FBOs) are pretty straightforward to use, actually (check the OpenGL docs). Another option is Render Buffer Objects (RBOs) and/or Pixel Buffer Objects (PBOs) but not all cards support them (if I recall correctly, being able to run it on an abacus was part of the requirements XD)

...
In any case, hope all is well. I've got more things to talk about but probably for another thread. :)

Yes, all is as it needs to be =D

Well, I was wondering how were you faring (been playing FF Mystic Quest for SNES a lot lately =D) so I guess that pretty much answers it. So, as soon as I have a little time, I'll upload an update for the blitter.

PS: if anyone else has tried something in this respect, please, share your thoughts and insights with us! Yeah I'm looking at you angros47 and Joshi ;)

[mrToad]

Nice to see you again, Mike ;)

Hey, you're either getting me back for forgetting your name one time (called you John in another thread), or you forgot I never gave you my first name! Toad will do fine though. :)

Indeed I did. I've implemented a 'proper' blitter using FBOs and shaders, with all the blending modes we've discussed here (and others). Works like a charm.

Wow, I should have guessed!

It's part of another, bigger GL framework but I can easily pluck it out if you want it to use as-is. Don't expect it to be as straightforward as this version is, though. You see, GPUs are really fast if you do process in bulks. Otherwise they become remarkably slow. This basically means that: *1* Your data needs to be carefully arranged in memory for them to upload/download it faster and *2*, you'll likely need to refactor a lot of your code to use it.

I would give it my best, build a branch to my project and attempt to replace the rendering with it. You do have me curious on the careful arrangement of the graphics data.

I'll upload a better version once I refactor it to deal only with 2D blitting ;)

I'd be truly grateful. I think many in the community would benefit from such a resource as well - you have the knowledge and skill to build FB's longed-for modern 2D GL game lib: the upgrade from the classics like Easy GL2D. Even one simple to use, powerful blitting function with stretch/scale, rotate, flip, and even the possibility of blend modes? In my opinion that would be a powerful asset to the community and greatly appreciated by anyone making games with FB.

Thanks for your reply!

[paul doe]

Hey, you're either getting me back for forgetting your name one time (called you John in another thread), or you forgot I never gave you my first name! Toad will do fine though. :)

Bwahaha I mixed your name with that of another member, sorry =D

...
I would give it my best, build a branch to my project and attempt to replace the rendering with it. You do have me curious on the careful arrangement of the graphics data.
...

Well, start with this resource then:

https://en.wikipedia.org/wiki/AoS_and_SoA

Depending on which one you choose, you have to set up buffers and a lot of stuff differently. My implementation uses the SoA pattern (which is especially suitable if you have an Entity-Component-System in place).

I'd be truly grateful. I think many in the community would benefit from such a resource as well - you have the knowledge and skill to build FB's longed-for modern 2D GL game lib: the upgrade from the classics like Easy GL2D. Even one simple to use, powerful blitting function with stretch/scale, rotate, flip, and even the possibility of blend modes? In my opinion that would be a powerful asset to the community and greatly appreciated by anyone making games with FB.

Thanks for your reply!

You're welcome. There are already some other implementations too (and in fact, angros47 already patched fbgfx2 to use shaders starting from fb 1.06; check the Wiki), so you may want to have a look at those too (perhaps they're easier to use/grasp?) Mine is full of OOP abstractions (which is not the preferred coding style for most folks here) since I find it pretty comfortable and convenient (not to mention flexible).

However, I must ask: will it be worth all the trouble? I mean, how many sprites on screen we're talking about? Hundreds? Thousands? If not, then you can do perfectly fine with what you have now. Looking at the picture you posted reminded me a lot to Sam & Max Hit the Road (the first and ONLY one, not the crappy 3D versions). Indeed, you can see that the scaling algo they use is pretty similar to what you have (you can see the effect more clearly in places like The World's Biggest Ball of Rope, for example). Another option would be to simply use pre-scaled graphics and interpolate them just as you interpolate the animation (at fixed intervals).

By the way: I coded a SVG renderer for another, unrelated project (which may also come in handy). I left it in a (mostly) finished state, but I'll update it and post it too whenever I have a little time. Then, you could simply store your graphics data as a pre-compiled series of drawing commands, and blast them on screen or on a buffer on request, with perfect scaling; or pre-render the graphics to the selected/current resolution (for resolution-independent graphics). Implement caching for it, though, should provide an interesting exercise for the reader (or user) >=D

Speaking of resolution: the resolution of your game is super low (maybe 320x200?), so I would suggest that you don't pay so much attention to the quality of the scaling (there are not enough pixels anyway!)

Thanks for putting up against my (usual) text walls XD

[mrToad]

Hey, I put up a good wall of text myself sometimes. No worries, I appreciate your thoughts and feedback very much.

[Edited 10/01 because I've now received help/answers in other threads.]

However, I must ask: will it be worth all the trouble? I mean, how many sprites on screen we're talking about? Hundreds? Thousands? If not, then you can do perfectly fine with what you have now.

angros47 recently pointed out to me, I think it may be related to what you mentioned, what the updated FBGfx can do - use GL to scale and render the screen. So in fact FBGfx may be a good option (as opposed to the GL FFP I am using). Before, the FPS was hurting with the scaler I was using.

Looking at the picture you posted reminded me a lot to Sam & Max Hit the Road [...] Indeed, you can see that the scaling algo they use is pretty similar to what you have.

Sam & Max was among my favorite games growing up. I loved adventure games, they are at least half of the inspiration for my project. (Yes the 3D versions looked so crappy/plastic that I didn't even play. 3D games were fairly new but only a few impressed me.)

I don't think I can go that retro with scaling (although with FBGfx I currently haven't found another choice), for one particular reason. Most scaling in my game is very subtle, used for the slight distance perspective of characters in a scene. (The little cave animation I linked earlier was just an extreme perspective test.) With GL scaling you barely notice the change (the pixels don't appear to shrink much), but it provides a nice depth perspective, avoiding oddly large characters/creatures when they take a few steps back into the scene. When attempting a subtle software scale, I'm just jacking up my character pixels. Still searching for a solution.

I created a thread about desiring a modern GL lib to replace the classics like Easy GL2D.

I was under the impression that you were pretty close to completing a game-ready GL blitter in that last code you shared, but I see it might be much more involved than that. In that thread I mentioned that I'd even be willing to donate something for the time needed to create such a lib, and I think the community would benefit too.

I appreciate the offer with the SVG renderer. I'd surely peek at it, but I've never worked with SVG, and it may also be an unnecessary and difficult implementation.

My friend thinks I'm a bit crazy to use FB for a commercial game, with all the game-dev langauges, engines and tools they have out now, where so much (like rendering) is already prepared for you. But I love FB and it seems suitable for a commercial game.

Now there's my text wall :)

Thanks for reading, and all your thoughts and help up to this day.

[mrToad]

Did some extensive editing on my rambling in the last post. I apologize if you bothered to read the original version. :)

[BasicCoder2]

But I love FB and it seems suitable for a commercial game, especially if I can get past this hurtle.

After all those years together I love FreeBasic too. Nice to see there are still supporters still using it in their projects.

[mrToad]

After all those years together I love FreeBasic too. Nice to see there are still supporters still using it in their projects.

Thanks for your reply. It's a great language, very capable. I could certainly move to another language, but (despite it is the language of my heart and youth) FB is quite powerful, intuitive, and does everything I personally need. I'm certainly thankful for all the libs, code, and tutorials that are already provided, as well as a helpful, friendly community. The only thing I desire is for a more active community, which would increase production and updates of important libs, and increase helpers on hand to assist others. I've come to realize that for game-dev there are so many expedited approaches these days, but at least speaking for myself, there's great satisfaction in building your own engine, and being under the hood. I've even built my own modest GUI. I just can't be under every hood, such as modern GL rendering, or a sound lib (thus I am really grateful for fbSound.)

Long live FB. :)

[paul doe]

Update: as of 7/21/2020, this code is no longer available.