31 color blending modes (WIP OpenGL version)

Game development specific discussions.
paul doe
Posts: 176
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: 31 color blending modes

Postby paul doe » Dec 05, 2017 16:18

mrToad wrote:Yes I get the feeling that is true. It seems to go in harmony with the whole idea of game-making in general (and other things in life), for me at least... Go to the lowest level if you want the most control and the best results. I know there are lines to be drawn, where effort and time needed is too much to be worth it, and that differs for everyone, but I may just be able to do this thing, perhaps as your inspiration and help affords. :)

That's the spirit! As I promised, here's a (totally rushed) OpenGL version of the blitter:

https://github.com/glasyalabolas/fb-shaders-demo

You need OpenGL 4.0+ to run the code. As you can see, it's pretty much the same, only a :lot: faster ;)

mrToad wrote:I'm taking a look at the link already. Was EasyGL2D7 a typo? I don't have any 7 :D Definitely looking forward to this as well. Don't mind making changes. I don't think it will effect the current scripts or other engine code I have, that's the only thing I was concerned about. Even if so, the changes might only be here and there.

Nop, that's how The Man himself calls it. It is actually the 0.7 version, but it has that '7' attached to it =D

Now, the code is ugly and rushed, I know. I didn't have much time to code these days, so I put together a demo to show you how you can use shaders to do the heavy lifting. We can do it much better, but see if you like it and can grasp some of the concepts involved. I commented the code a little to help you find you way through the terminology, but feel free to ask anything you wish. While I refactor it to be able to implement the other blending modes, play around and see if you can understand what's going on (use your implementation of EasyGL2D to see the differences, that should help a lot). Also, post your results here, it will be interesting to compare this to the pure FB blending ;)

Look also on this site, to see the amazing power of shaders: https://www.shadertoy.com/. As a nostalgic note, Joshy (D.J. Peters), had posted about those in the forum, and even coded an offline version of it. Man, I'll surely miss him :'(

See you soon.
mrToad
Posts: 342
Joined: Jun 07, 2005 23:03
Location: USA

Re: 31 color blending modes (WIP OpenGL version)

Postby mrToad » Dec 07, 2017 18:52

Wow, thank you. Impressive speed to say the least! - somewhere around 39K BPS. :O I'm doing back-flips.

Only compiled with 64-bit GCC. Wouldn't compile 32-bit GCC:
Cannot export DETERMINANT@36: symbol not found
Cannot export DISTANCE@24: symbol not found
Cannot export _Z11VECTORANGLE5VEC2H@12: symbol not found
Cannot export _Z11VECTORANGLE5VEC2HS_@24: symbol not found

I was reading up here: https://thebookofshaders.com/01/
Which was nice up to a point where it gets into pattern and color math, which is fascinating but not what I need right now. But it's already helping with the whole understanding of a GPU, uniforms, and verts. From what I learned in a short time it seems a shader is a program that operates on every pixel. Still have a lot to learn. I also don't know what the shader files contain exactly, or why they are needed to be separate files, or how to make them. :D

One question (although I have many) is why 6 verts? They are all for UVs? I would think only 4 would be needed. What are they holding?

Code: Select all

   '' compute corners
   dim as vec2h p1 = vec2h( x - hw, y - hh )
   dim as vec2h p2 = vec2h( x - hw, y + hh )
   dim as vec2h p3 = vec2h( x + hw, y + hh )
   dim as vec2h p4 = vec2h( x + hw, y - hh )
      
   '' update the vertices data
   vertexData( 0 ) = p1
   vertexData( 1 ) = p2
   vertexData( 2 ) = p3
   
   vertexData( 3 ) = p1
   vertexData( 4 ) = p3
   vertexData( 5 ) = p4

^ I don't understand using 6 verts for 4 UV points. Plus why 123, 134? (Bare with me and my questions!)

And it appears (understandably for a demo purpose) you are using a separate texture unit for each image. Besides that, this code already comes close to what I am doing with the oldschool pipeline. Add the ability to read from packed sprites, a little vertical/horizontal stretching, bolt in those blends you worked up, basic shapes and lines, and I'd be all set, lol. But it is my desire to understand it as fully as possible. I'm not sure why you call it "horrible and rushed", but being a noob in this area I guess I wouldn't know!

Considering what's been accomplished there's not too much code. The speed is insane. It's modern. The possibilities are now wide-open.
This is great stuff.
paul doe
Posts: 176
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: 31 color blending modes (WIP OpenGL version)

Postby paul doe » Dec 07, 2017 20:09

mrToad wrote:Wow, thank you. Impressive speed to say the least! - somewhere around 39K BPS. :O I'm doing back-flips.

Only compiled with 64-bit GCC. Wouldn't compile 32-bit GCC:
Cannot export DETERMINANT@36: symbol not found
Cannot export DISTANCE@24: symbol not found
Cannot export _Z11VECTORANGLE5VEC2H@12: symbol not found
Cannot export _Z11VECTORANGLE5VEC2HS_@24: symbol not found

You're welcome =D
That's really weird. Of course, I hadn't tested it with 32-bit GCC, so it's good to know (my math routines seem to be the culprit).
mrToad wrote:I was reading up here: https://thebookofshaders.com/01/
Which was nice up to a point where it gets into pattern and color math, which is fascinating but not what I need right now. But it's already helping with the whole understanding of a GPU, uniforms, and verts. From what I learned in a short time it seems a shader is a program that operates on every pixel. Still have a lot to learn. I also don't know what the shader files contain exactly, or why they are needed to be separate files, or how to make them. :D

Yes, that's a fragment shader. A vertex shader operates (you guessed it) at the vertex level. Want to know what a shader contains? Open the files (.vert and .frag in my demo) in notepad ;)

mrToad wrote:One question (although I have many) is why 6 verts? They are all for UVs? I would think only 4 would be needed. What are they holding?

Code: Select all

   '' compute corners
   dim as vec2h p1 = vec2h( x - hw, y - hh )
   dim as vec2h p2 = vec2h( x - hw, y + hh )
   dim as vec2h p3 = vec2h( x + hw, y + hh )
   dim as vec2h p4 = vec2h( x + hw, y - hh )
      
   '' update the vertices data
   vertexData( 0 ) = p1
   vertexData( 1 ) = p2
   vertexData( 2 ) = p3
   
   vertexData( 3 ) = p1
   vertexData( 4 ) = p3
   vertexData( 5 ) = p4

^ I don't understand using 6 verts for 4 UV points. Plus why 123, 134? (Bare with me and my questions!)

There's 6 vertices because there are 2 triangles, not one quad. They are drawn like a quad. Modern OpenGL doesn't have anything in the way of GL_QUAD like before, you have to do everything with triangles. What you're quoting here are actually the vertices of the triangles (defined around the center point of a quad) that get updated every time you blit. The UVs don't change, they don't need to (for now).
mrToad wrote:And it appears (understandably for a demo purpose) you are using a separate texture unit for each image. Besides that, this code already comes close to what I am doing with the oldschool pipeline. Add the ability to read from packed sprites, a little vertical/horizontal stretching, bolt in those blends you worked up, basic shapes and lines, and I'd be all set, lol. But it is my desire to understand it as fully as possible. I'm not sure why you call it "horrible and rushed", but being a noob in this area I guess I wouldn't know!

This requires a far more involved explanation. I'm a bit busy now, but tonight I can spare some time to explain what I'm doing, and why. Suffice it to say, that when using fragment shaders you can't read the pixel, only write it. That's the reason for the 2 textures. I'll update the demo later to show you additive blending, and I'll explain all this in detail. Meanwhile, take a look at the shaders, I also commented them for you ;)
And the code IS horrible =D I refactored it a little (it's not the final version just yet), so it's easier and clearer now. You'll see.
mrToad wrote:Considering what's been accomplished there's not too much code. The speed is insane. It's modern. The possibilities are now wide-open.
This is great stuff.

There's not too much code yet XD Anyway, as you can see, it's mostly boringplate code, that stem from the need to deal with your data.
Thanks, pal. This will get a lot better, as we are only starting =D
mrToad
Posts: 342
Joined: Jun 07, 2005 23:03
Location: USA

Re: 31 color blending modes (WIP OpenGL version)

Postby mrToad » Dec 08, 2017 4:09

paul doe wrote:Yes, that's a fragment shader. A vertex shader operates (you guessed it) at the vertex level. Want to know what a shader contains? Open the files (.vert and .frag in my demo) in notepad ;)

Oh, that helps. Thanks.

paul doe wrote:There's 6 vertices because there are 2 triangles, not one quad. They are drawn like a quad. Modern OpenGL doesn't have anything in the way of GL_QUAD like before, you have to do everything with triangles. What you're quoting here are actually the vertices of the triangles (defined around the center point of a quad) that get updated every time you blit.

Gotcha, thank you!

One little concern popped up to me, that this is GL 4.0+ only. I realized of course the demo won't run on my older laptop with GL 2.1. Kind of made me sad, actually. My target audience may include folks who only have older computers; friends in Thailand who don't have the money to upgrade their stuff. I would really like to be able to share my game with them. Heck, maybe in the end this is all for only the people I know. And look at my game. It doesn't seem like it should require more than 2.0. I know 2.0 is terribly old now, my laptop is 6.1, but I keep thinking of those buds of mine 9000 miles away.

So, what makes your demo 4.0+ only? And is it fairly silly to bother coding for 2.0 these days? It's almost like I have to pick between cutting off older systems or writing something that dies with them. Is that true?
paul doe
Posts: 176
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: 31 color blending modes (WIP OpenGL version)

Postby paul doe » Dec 08, 2017 4:31

Well, I just uploaded a version with some corrections. It's far from finished, but for now it will gain me some time ;) I implemented the 'bmAddition' blend mode and scaling in both X and Y directions.

As I promised, I'll give some more detailed answers now:
mrToad wrote:I was reading up here: https://thebookofshaders.com/01/
Which was nice up to a point where it gets into pattern and color math, which is fascinating but not what I need right now. But it's already helping with the whole understanding of a GPU, uniforms, and verts. From what I learned in a short time it seems a shader is a program that operates on every pixel. Still have a lot to learn. I also don't know what the shader files contain exactly, or why they are needed to be separate files, or how to make them. :D

Yeah, The Book of Shaders is a great resource. Have it handy, you may need it in the future ;)

The shader files contain code. If you open them, you'll see that it looks a lot like C, so if you are proficient with it, you'll be coding your own shaders in no time. They don't necessarily need to be separate files, you could embed them in a string inside your program, for the card expects them to be simply plain text. Look at the file 'glshader.bi' to see the implementation, and how this is done.
mrToad wrote:And it appears (understandably for a demo purpose) you are using a separate texture unit for each image. Besides that, this code already comes close to what I am doing with the oldschool pipeline. Add the ability to read from packed sprites, a little vertical/horizontal stretching, bolt in those blends you worked up, basic shapes and lines, and I'd be all set, lol. But it is my desire to understand it as fully as possible. I'm not sure why you call it "horrible and rushed", but being a noob in this area I guess I wouldn't know!

In all honesty, the implementation kind of 'cheats'. Look at the main loop, the following lines:

Code: Select all

   '' blit the background
   glBlit(   screenWidth / 2, screenHeight / 2, texture( 0 ), , alphaShader.ID )
   
   t = timer()
      
   '' blit the sprite
   glBlit(   mx, my, texture( 1 ), texture( 0 ), addShader.ID, 1.0, ang, abs( sin( radians( scale ) ) ) )
   'glBlit(   screenWidth / 2, screenHeight / 2, texture( 1 ), texture( 0 ), addShader.ID, 1.0 )
   
   t = timer() - t

There's some interesting things happening here. Put the background blitting inside the timer() calls and see what happens. What!? The demo is actually slower!
What is happening here? What it happens is that the second blitting (the one that's measured) is operating with all the data already in the card, since the first call uploaded it. See why I told you that modern cards are tailored for bulk rendering? You can even store all the needed vertices into one vertex array, and draw them all at once with a single call. Neat, no?

You can also see something interesting if you comment the blitting of the background. If you do, you'll see that the sprite actually blits a part of the 'background' with it. This happens because we're sampling the texture that contains the background, not the frame buffer itself (the texture of the background is not altered by the blitting process). To really perform the blits the way they're supposed to work, we'll have to render all our stuff to a texture, bind this texture to a Framebuffer Object (FBO) and then render the Framebuffer Object itself. This is explained in the comments in the code (both in the shaders and on the client).

The reason for having to jump through all these hoops lies in massive parallelization of the GPUs. Nowadays, they have thousands of cores, and each one of them is capable of processing a pixel asynchronously with the others. So, to be able to get away with all this, the buffer to which one renders needs to be immutable. If this doesn't make sense to you, don't worry for now. Just explaining why I'm doing things the way I do here =D

Another interesting thing: you seem way too concerned with binding textures. Don't. Back when the GPUs were crap, this was really expensive, but this is not the case anymore. Perhaps you didn't noticed, but the blitter is actually binding and unbinding the texture each call (the call that draws the sprite even binds two textures!), and I coded this intentionally to show you that it's really of no concern nowadays. Nonetheless, the less binding the better, but the way you structure your data and upload it to the card is far, far more important than doing a simple texture bind.

There's more than one way to skin this particular cat, and some are better than others. Generally speaking, the more efficient the method, the less flexible it is. Remember, GPUs are tailored to crunch 3D (and they are darn good at it), and while 2D isn't certainly alien, it does pose some interesting challenges to overcome.
paul doe
Posts: 176
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: 31 color blending modes (WIP OpenGL version)

Postby paul doe » Dec 08, 2017 4:45

mrToad wrote:One little concern popped up to me, that this is GL 4.0+ only. I realized of course the demo won't run on my older laptop with GL 2.1. Kind of made me sad, actually. My target audience may include folks who only have older computers; friends in Thailand who don't have the money to upgrade their stuff. I would really like to be able to share my game with them. Heck, maybe in the end this is all for only the people I know. And look at my game. It doesn't seem like it should require more than 2.0. I know 2.0 is terribly old now, my laptop is 6.1, but I keep thinking of those buds of mine 9000 miles away.

So, what makes your demo 4.0+ only? And is it fairly silly to bother coding for 2.0 these days? It's almost like I have to pick between cutting off older systems or writing something that dies with them. Is that true?

The functions that I use, and the way the shaders are written. It is fairly silly? That's for you to decide. Told you, I show you how it's done, you decide if you implement it or not. For the record, everything below OpenGL less than 3.3 is deprecated. That doesn't mean you can't use it, but some newer GPUs won't even bother to run it.

Yes, it's sad, but that's the way it is, sorry. I think that 4.0 is a fairly common denominator these days (heck, even this craptop comes with 4.0 already)

Another thing you may want to consider: some things simply can't be done in 2.0. I'll have to check, but I'm pretty sure that doing custom color blending is one of those things (which means that you're stuck with the blending modes that glBlendFunc provides).
Last edited by paul doe on Dec 09, 2017 0:01, edited 1 time in total.
mrToad
Posts: 342
Joined: Jun 07, 2005 23:03
Location: USA

Re: 31 color blending modes (WIP OpenGL version)

Postby mrToad » Dec 08, 2017 5:29

paul doe wrote:That's for you to decide. Told you, I show you how it's done, you decide if you implement it or not. For the record, everything below OpenGL less than 3.3 is deprecated. That doesn't mean you can't use it, but some newer GPUs won't even bother to run it.

Yes, it's sad, but that's the way it is, sorry. I think that 4.0 is a fairly common denominator these days (heck, even this craptop comes with 4.0 already)

Another thing you may want to consider: some things simply can't be done in 2.0. I'll have to check, but I'm pretty sure that doing custom color blending is some of those things (which means that you're stuck with the blending modes that glBlendFunc provides).

I appreciate that straight-forward summary. It is as I suspected. See, this makes me wonder why I am using GL. It's powerful because it's built to push the limits, but this also limits what computers it can run on. My game isn't trying to push any limits, even in the 2D world I suppose. It's certainly not trying to crunch 3D! :) You solved the need for some special effects with your FB blitter. I ran that on my older system and get ~250 BPS. Why do I need GL? There are ways to rotate and scale without it. I should try drawing a complex scene of my game with your awesome FB blitter.

I'm starting to wonder - as long as the CPU can handle the graphical needs, wouldn't this simplify compatibility? Also, wouldn't it simplify coding?

OpenGL is amazing and I don't regret anything I've learned so far. In fact I can't believe how much you helped me process all of this stuff which I normally would never have been inspired to look into. (Where did you get all this knowledge? :D) I want to continue learning. I just want to make the most practical choices for this project.
paul doe
Posts: 176
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: 31 color blending modes (WIP OpenGL version)

Postby paul doe » Dec 08, 2017 11:07

mrToad wrote:I appreciate that straight-forward summary. It is as I suspected. See, this makes me wonder why I am using GL. It's powerful because it's built to push the limits, but this also limits what computers it can run on. My game isn't trying to push any limits, even in the 2D world I suppose. It's certainly not trying to crunch 3D! :) You solved the need for some special effects with your FB blitter. I ran that on my older system and get ~250 BPS. Why do I need GL? There are ways to rotate and scale without it. I should try drawing a complex scene of my game with your awesome FB blitter.

That's for you to decide. Remember that if you're using the EasyGL2D version that's compatible with FB buffers, you can use the best of both worlds. The only thing that remains is to decide how you will lay out the rendering to take advantage of each technique. You can use OpenGL for the bulk rendering, and the blending blitter to apply some special effects here and there.
mrToad wrote:I'm starting to wonder - as long as the CPU can handle the graphical needs, wouldn't this simplify compatibility? Also, wouldn't it simplify coding?

Probably. You'll have to benchmark and test this to be sure. As I told you, the game changer here is how you lay out the rendering. You mentioned that you're using different layers before, which I'm going to assume are used to perform some sort of parallaxing, such as the sky, no? Then, find a way to integrate this with the effects you need. Modern OpenGL is uber powerful, but it's no walk in the park, as you probably realized by now, so just use what you already have. If not, then you may never finish your project ;)
mrToad wrote:OpenGL is amazing and I don't regret anything I've learned so far. In fact I can't believe how much you helped me process all of this stuff which I normally would never have been inspired to look into. (Where did you get all this knowledge? :D) I want to continue learning. I just want to make the most practical choices for this project.

Knowledge is free for the taking, especially in the web =D
I have more than 20 years of experience, in a variety of programming languages that you wouldn't believe haha. I wholeheartedly agree that you need to make the most practical choices. All I did was presenting you some alternatives, even if you don't end using them. The learning is what's really important, as you point out. That, and having a lot of fun =D
mrToad
Posts: 342
Joined: Jun 07, 2005 23:03
Location: USA

Re: 31 color blending modes (WIP OpenGL version)

Postby mrToad » Dec 08, 2017 15:19

paul doe wrote:That's for you to decide. Remember that if you're using the EasyGL2D version that's compatible with FB buffers, you can use the best of both worlds. The only thing that remains is to decide how you will lay out the rendering to take advantage of each technique. You can use OpenGL for the bulk rendering, and the blending blitter to apply some special effects here and there. [...]
You mentioned that you're using different layers before, which I'm going to assume are used to perform some sort of parallaxing, such as the sky, no? Then, find a way to integrate this with the effects you need.

Right, but taking a look at that link you shared did open my eyes about FFP. I recall you said although FFP is deprecated, it still works fine. That article agrees: "OpenGL 3.2, back in 2009, finally removed all notion of fixed-function vertex and fragment processing (however, it remains available for legacy use via a compatibility profile)." I obviously must have that profile on my system. But I wonder how long this compatibility will remain. It's true, it doesn't make a lot of sense to code this way. But since it's already done, I guess I could always modify the rendering later if support is completely dropped.

paul doe wrote:Modern OpenGL is uber powerful, but it's no walk in the park, as you probably realized by now, so just use what you already have. If not, then you may never finish your project ;)

Yes, time required is the second issue I'm having besides wanting to support older hardware. My game has an old-school feel and it kind of doesn't feel right for it to have high requirements, although in fact they aren't very high.

paul doe wrote:All I did was presenting you some alternatives, even if you don't end using them. The learning is what's really important, as you point out. That, and having a lot of fun =D

Yea, I appreciate it, and pardon me for just saying whatever is on my mind, it's been helpful to talk.

And then there is seeing what the CPU alone can do to resolve both of these issues.

I'll give it some thought.
paul doe
Posts: 176
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: 31 color blending modes (WIP OpenGL version)

Postby paul doe » Dec 08, 2017 21:01

mrToad wrote:Right, but taking a look at that link you shared did open my eyes about FFP. I recall you said although FFP is deprecated, it still works fine. That article agrees: "OpenGL 3.2, back in 2009, finally removed all notion of fixed-function vertex and fragment processing (however, it remains available for legacy use via a compatibility profile)." I obviously must have that profile on my system. But I wonder how long this compatibility will remain. It's true, it doesn't make a lot of sense to code this way. But since it's already done, I guess I could always modify the rendering later if support is completely dropped.

I'd say you'd stop worrying so much about the issue. You see, the version that comes with all major OSses is OpenGL 1.1 (or 1.2, I can't quite remember now). All the additional functionality is implemented via extensions. You can access them from FB with the screenGLProc function (look at my implementation and the FB documentation to see how this is done), but it isn't necessary, as long as you don't use those extensions. So for desktop apps, you'll be just fine. However, a different story is OpenGL ES (for mobile devices) and WebGL (for web apps), these don't have the 'compatibility profile', but I doubt that you'll want to deploy your game on mobile or web. See the Wikipedia entry (https://en.wikipedia.org/wiki/OpenGL) for a little historical notes on OpenGL.
mrToad wrote:Yes, time required is the second issue I'm having besides wanting to support older hardware. My game has an old-school feel and it kind of doesn't feel right for it to have high requirements, although in fact they aren't very high.

Then continue doing what you're doing. There's nothing wrong with it, I can perfectly run the examples that EasyGL2D already provides. It's only that what you wanted to do (custom color blending) simply requires some functionality that's not in the compatibility profile.
mrToad wrote:Yea, I appreciate it, and pardon me for just saying whatever is on my mind, it's been helpful to talk.

And then there is seeing what the CPU alone can do to resolve both of these issues.

I'll give it some thought.

No prob ;)
I'll continue developing this, as it's very useful also for me. Perhaps I'll finally end that SVG rendering library I've shelved for so long =D
mrToad
Posts: 342
Joined: Jun 07, 2005 23:03
Location: USA

Re: 31 color blending modes (WIP OpenGL version)

Postby mrToad » Dec 09, 2017 1:02

paul doe wrote:I'd say you'd stop worrying so much about the issue. You see, the version that comes with all major OSses is OpenGL 1.1 (or 1.2, I can't quite remember now). All the additional functionality is implemented via extensions. You can access them from FB via the screenGLProc function (look at my implementation and the FB documentation to see how this is done), but it isn't necessary, as long as you don't use those extensions.

^_^

paul doe wrote:So for desktop apps, you'll be just fine. However, a different story is OpenGL ES (for mobile devices) and WebGL (for web apps), these don't have the 'compatibility profile', but I doubt that you'll want to deploy your game on mobile or web.

I never was that interested in doing that, but now mobile is so crazy popular, I was a bit curious about what it would involve. Still, not that important for this project.

paul doe wrote:Then continue doing what you're doing. There's nothing wrong with it

Sometimes it's hard to tell (for me anyway) what is an acceptable choice and what is a ridiculous thing to commit to. It's good to hear this from someone as experienced as yourself.

At this time I might shy back from using GL shaders. Mainly just to stay focused and reserve time and energy. For six months in Thailand I was teaching myself [3D modelling]. At the time I could barely communicate in Thai so a lot of my time I was in a little room, over 100° F, delving in. I taught myself how to model, texture, rig, and animate characters and scenery. The whole point being I often venture into other worlds of learning in order to figure out what I really want to do. It was fun and I still use the skills I learned for my current job, but it just didn't quite hit home and it was very involved. In the end I ditched the whole thing in favor of the simple and delightful world of pixels, a place I can still do good art, story, and gameplay, while keeping everything modest and reasonable, being the only one on the team. So here I was again considering my options but I must stay true to the most practical route to actually achieve this goal.

paul doe wrote:No prob ;)
I'll continue developing this, as it's very useful also for me. Perhaps I'll finally end that SVG rendering library I've shelved for so long =D

So do you have a game project of some kind? Or what are you mainly working on?

EDIT:
I said my OpenGL was 6.1 because of this... But now I feel a bit silly because in fact my version is 4.4. I don't know why Catalyst says that.
paul doe
Posts: 176
Joined: Jul 25, 2017 17:22
Location: Argentina

Re: 31 color blending modes (WIP OpenGL version)

Postby paul doe » Dec 09, 2017 21:38

mrToad wrote:Sometimes it's hard to tell (for me anyway) what is an acceptable choice and what is a ridiculous thing to commit to. It's good to hear this from someone as experienced as yourself.

It's hard to tell for anybody. Ringo Bonavena, an argentinian boxer, once said that "experience is like a comb, that is given to you when you're bald" =D
mrToad wrote:At this time I might shy back from using GL shaders. Mainly just to stay focused and reserve time and energy. For six months in Thailand I was teaching myself [3D modelling]. At the time I could barely communicate in Thai so a lot of my time I was in a little room, over 100° F, delving in. I taught myself how to model, texture, rig, and animate characters and scenery. The whole point being I often venture into other worlds of learning in order to figure out what I really want to do. It was fun and I still use the skills I learned for my current job, but it just didn't quite hit home and it was very involved. In the end I ditched the whole thing in favor of the simple and delightful world of pixels, a place I can still do good art, story, and gameplay, while keeping everything modest and reasonable, being the only one on the team. So here I was again considering my options but I must stay true to the most practical route to actually achieve this goal.

Checked it out, it's really great. Does the second image look familiar to me? =D You're really a force to be reckoned with (an artist, and also a coder!). I'd say that doing what you did is really necessary from time to time. Mostly, to expand your mind and learn some new ways of thinking. Learning other languages (computer or natural) is one of the best ways for me to do it (I learned english all by myself, much like coding). My artistic skills suck (to say it politely) but I'm constantly trying to improve =D
Working on your project has to be fun, otherwise you don't give it all you can. Just use what you're comfortable with, and that which you enjoy the most. You'll never regret it.
mrToad wrote:So do you have a game project of some kind? Or what are you mainly working on?

I code mostly boring financial stuff (I plan to become a fully independent trader by next year), but coding games is something that I love since I was a toddler (coded my first program at 7). It's unbelievable just how many skills you need to learn to pull off even a simple game, no?

I currently have two main Freebasic projects shelved (among some games, I need to have fun too =D): a 3D GUI/UX (something like this, which I'll eventually use to give my trading terminal a sleek look hahaha), and a 2D vector rendering library (like Cairo) to be able to perform 2D vector rendering of things like the SVG file format and be able to use it directly in FB. This one is almost finished, I only need to fully implement the parsing of the XML subset that SVG represents. However, I absolutely hate parsing text, which is why, after coding a few compilers for different languages (I even implemented something that can be called '3D Logo', inspired by the now defunct Elica Logo, which is awesome for doing procedural 3D code), I settled for my own dialect of Forth as my main scripting language. Now, that's simplicity and power, indeed =D
Remember we're talking FB-only here, no external libraries or third parties involved (which is precisely the point, having all that in 'native' FB)
mrToad wrote:I said my OpenGL was 6.1 because of this... But now I feel a bit silly because in fact my version is 4.4. I don't know why Catalyst says that.

Don't be ;D
That's the version of that particular driver, not the OpenGL implementation (the latest version is 4.6). Remember that OpenGL is a specification, it's up to the vendor to provide an implementation that agrees to some version of it.
mrToad
Posts: 342
Joined: Jun 07, 2005 23:03
Location: USA

Re: 31 color blending modes (WIP OpenGL version)

Postby mrToad » Dec 10, 2017 15:58

paul doe wrote:Ringo Bonavena, an argentinian boxer, once said that "experience is like a comb, that is given to you when you're bald" =D
Ha! I like that quote.

paul doe wrote:Checked it out, it's really great. Does the second image look familiar to me? =D You're really a force to be reckoned with (an artist, and also a coder!)
Thank you kindly. :) It's all just fun and learning, like you say. The familiar one might be the dock picture? I did have a reference for that one, hehe. The second one, the cave one, I can't remember if I had a reference! It's been a long time.

paul doe wrote:(I learned english all by myself, much like coding).
Well, your English is 100%. Yes it is good for your brain and broadens your perspective.

paul doe wrote:My artistic skills suck (to say it politely) but I'm constantly trying to improve =D
LOL. Art is a big world, I'm not good at most of it either. (If only we had all the time we need to develop more talent.)

paul doe wrote:but coding games is something that I love since I was a toddler (coded my first program at 7). It's unbelievable just how many skills you need to learn to pull off even a simple game, no?
Wow. Very young. And yes I never realized how much it takes to do a game. It's borderline insane, except it's so fun. ;D

paul doe wrote:a 3D GUI/UX (something like this, which I'll eventually use to give my trading terminal a sleek look hahaha)
Sleek is the right word. Looks awesome.

paul doe wrote:and a 2D vector rendering library (like Cairo) to be able to perform 2D vector rendering of things like the SVG file format and be able to use it directly in FB.
This sounds really cool. Would like to see more about it.

paul doe wrote:Remember we're talking FB-only here, no external libraries or third parties involved (which is precisely the point, having all that in 'native' FB)
Well if you have any posts or site where I can see updates, link me over. Got to run for now.

Been nice chatting. :) I'm sorry I steered this thread way off to left field! Haha.

Return to “Game Dev”

Who is online

Users browsing this forum: No registered users and 1 guest