OpenGL Color Effects

[mrToad]

You're welcome. The GL code is a little more complex, but only at first (as with almost anything new, no?).

Definitely. But I am looking forward to seeing what I can do.

On a side note, how are you storing your assets? In the aforementioned format (texture packed), or do you pack them at load time and keep them segregated in memory?

I start with a lot of PNG files that already have certain graphics grouped together, such as a single character and all his animations. I wrote my own packer that lets me draw slices on such an image and give them unique data, which helps later for animation. Then the graphics of individuals slices are kept in RAM at load time so I can do pixel tests. Several sprite sheets are combined onto a single large texture and uploaded to vRam. For example all characters needed at a particular time in the game are grouped on one texture. And all graphics for the current region of the game world are combined onto another texture. I use as few slots as possible. Yes binding is expensive; I don't bind anything except between regions of the game, or when I need to change the clothing layers of a character (pieces of clothing are pre-rendered together over a character to create different outfits), which is not often. Since I work with such small graphics I can fit all kinds of stuff on a single texture.

So with shaders I could access and manipulate pixels stored in vRam? That would be pretty incredible, to draw on a sprite during runtime. For example perhaps I could draw footprints in the sand without creating new objects for each step. Also to selectively find and replace certain pixel colors/alpha values on a sprite. Not to mention the blend modes. You're coding all 21? Sounds like a lot of work!

Well, it's a sick day for me today so I'm going to get some work done on this thing.

[paul doe]

Definitely. But I am looking forward to seeing what I can do.

It should be straightforward, if you've been using OpenGL already. Don't worry ;)

I start with a lot of PNG files that already have certain graphics grouped together, such as a single character and all his animations. I wrote my own packer that lets me draw slices on such an image and give them unique data, which helps later for animation. Then the graphics of individuals slices are kept in RAM at load time so I can do pixel tests. Several sprite sheets are combined onto a single large texture and uploaded to vRam. For example all characters needed at a particular time in the game are grouped on one texture. And all graphics for the current region of the game world are combined onto another texture. I use as few slots as possible. Yes binding is expensive; I don't bind anything except between regions of the game, or when I need to change the clothing layers of a character (pieces of clothing are pre-rendered together over a character to create different outfits), which is not often. Since I work with such small graphics I can fit all kinds of stuff on a single texture.

Great. I take it that you don't use the standard fb.image buffers, then. However, you won't find it difficult to adapt the blitter and the blending functions, as they're implemented in a rather straightforward way (I use the fb.image buffers, so it's compatible with the built-in graphic commands).
For simplicity reasons, I use 32-bit TGA files, but you can adapt it to use other formats such as PNG. The only thing really important is that the format supports alpha channel, for the blitter does proper alpha composition ie. it does not use that 'magic pink' bullcrap for doing transparency. I imagine that you're using FBPNG or FreeImage to load your images, no?

So with shaders I could access and manipulate pixels stored in vRam? That would be pretty incredible, to draw on a sprite during runtime.

With shaders you must access and manipulate pixels stored in vRam, as it's the only way to actually get something displayed on the screen =D

Not to mention the blend modes. You're coding all 21? Sounds like a lot of work!

And then some more =D
Yes, it's work, but mostly boilerplate work. When I publish it you'll see what I mean. However, with the blitter and the blenders, you can reproduce all the effects that you can do with layers in GIMP (as it uses the equivalent formulas). I also added some other useful blend modes that GIMP doesn't support natively. You're an artist, so I'm sure that you will find uses for them (and perhaps even code some!). Once I'm finished with it (I'm pretty much done already), I'll publish it in it's own thread with a link to this one, as it's related but it's not OpenGL based. And I could also provide support and answer questions without polluting this thread (which, once we get to OpenGL shaders, will have a different focus). Agree?

[mrToad]

I take it that you don't use the standard fb.image buffers, then.

I do use them, but it's like this:

Code: Select all

Type IMAGE Field = 1		'' GL Image, same as FB.Image but makes use of 12 reserved bytes.

	'' FB.IMAGE part:
	Union
		old 		As _OLD_HEADER
		Type 		As UInteger
	End Union
	bpp 			As Integer
	Width 			As UInteger
	height 			As UInteger
	pitch 			As UInteger
	
	'' Using the 12 reserved bytes for GL:
	textureID 		As UInteger			'' 4 bytes
	u_offset		As UShort			'' 2 bytes
	v_offset		As UShort			'' 2 bytes
	texture_width	As UShort			'' 2 bytes
	texture_height	As UShort			'' 2 bytes

End Type

'' My sprite header:
Type gfxmap_spr		Field = 1	'' A sprite on a sprite sheet
	As gfxmap_set Ptr set		   '' Pointer to the set it belongs to
	As ZString * 32 id			  '' Personal tag for easier reference
	As UInteger r					'' Reference number
	As GL.IMAGE Ptr p			 '' SW image header and body. Header contains ID for GL HW copy.
	As Integer ax,ay				'' x/y adjustment when drawing, for lining up animation frames.
	As Integer delay, transp
End Type

So I kind of wrapped it into my own UDT in order to give each sprite more data. I'm not sure but it seems that shouldn't get in the way, should it?

... proper alpha composition ie. it does not use that 'magic pink' bullcrap for doing transparency.

LOL I was happy to do away with that a long time ago. Would hate to go back.

I imagine that you're using FBPNG or FreeImage to load your images, no?

Yes, FBPNG.

With shaders you must access and manipulate pixels stored in vRam, as it's the only way to actually get something displayed on the screen =D

Gotcha. Awesome. :)

Once I'm finished with it (I'm pretty much done already), I'll publish it in it's own thread with a link to this one, as it's related but it's not OpenGL based. And I could also provide support and answer questions without polluting this thread (which, once we get to OpenGL shaders, will have a different focus). Agree?

Sounds good!

[paul doe]

So I kind of wrapped it into my own UDT in order to give each sprite more data. I'm not sure but it seems that shouldn't get in the way, should it?

Not at all, don't worry. I'm having a pretty good idea how you're performing the blits. So you'll be able to use it without changes =D

Yes, FBPNG.

That's cool. The only thing required is that the library loads the image to the buffer in BGRA format (the format FB uses)

Sounds good!

Very well, then. As soon as I'm finished, I'll post it. Looking forward! ;)

[MrSwiss]

@mrToad,

be aware, that your Type(s), using U/Integer are only, for FBC 32bit.
A example, below:

Code: Select all

   '' Using the 12 reserved bytes for GL:
   textureID       As UInteger         '' 4 bytes

Your comment is already wrong, with FBC 64bit (UInteger = ULongInt = 8 * UByte).
You'd better use: U/Long, 32bit fixed size (for compatibility with both compilers).

[mrToad]

That's cool. The only thing required is that the library loads the image to the buffer in BGRA format (the format FB uses)

I remember way back I was scratching my head about that. I ended up with this to fix that problem:

Code: Select all

#define _RGBA( r, g, b, a )   RGBA( (b), (g), (r), (a) )

be aware, that your Type(s), using U/Integer are only, for FBC 32bit... You'd better use: U/Long, 32bit fixed size (for compatibility with both compilers).

Thank you! Especially for these headers. I'll make the changes now.

[D.J.Peters]

if you create a OpenGL pixelbuffer / texture from FB image pixelpointer you can use the const GL_BGRA also.

Joshy

[paul doe]

Thank you! Especially for these headers. I'll make the changes now.

MrSwiss advice was spot-on. Which version are you using? 32 or 64-bit? Are you able to compile your game using 64-bit FB? I ask this because I use the 64-bit version with the gcc backend, so I have to make sure you can actually integrate my code with a minimum of fuss, should you wish to do so. I assume you're using 32-bit, no?

[mrToad]

MrSwiss advice was spot-on. Which version are you using? 32 or 64-bit? Are you able to compile your game using 64-bit FB? I ask this because I use the 64-bit version with the gcc backend, so I have to make sure you can actually integrate my code with a minimum of fuss, should you wish to do so. I assume you're using 32-bit, no?

Yes I am. Trying to compile with 64-bit I get quite a few errors, two of them are:

Code: Select all

fbpng_v3_2_q\inc\png_image.bi(195) error 4: Duplicated definition in 'Type uInt as uinteger'

error 323: Fixed-length string combined with BYREF (not supported), before ',' in 'Declare Function strIf(Boolean As Integer, rtrnTrue As ZString*16, rtrnFalse As ZString*16) As String'

Not sure how to fix these yet.

[MrSwiss]

Not sure how to fix these yet.

I haven't heard of FBPNG (it may be, a old lib. = 32bit only?).
I'd try to use the more recent FBImage (by D.J.Peters), see Libraries Section.

[mrToad]

I havn't heard of FBPNG (may be, a old lib. = 32bit only?).
I'd try to use the more recent FBImage (by D.J.Peters), see Libraries Section.

Thanks, I will.

Looks like I'm going to have to ditch FBSound as well. Any recommended alternatives?

[MrSwiss]

I'll leave all the "sound" stuff, for others, who are actually using that.
(I've never used any, except to test libs.)

[mrToad]

How important to move everything to 64-bit?

@paul doe, it will be necessary for your code it seems?

I don't mind moving over but the word "fuss" is spot-on as well. :D

[paul doe]

How important to move everything to 64-bit?

@paul doe, it will be necessary for your code it seems?

I don't mind moving over but the word "fuss" is spot-on as well. :D

Not necessary if you don't want to. The code runs equally well in 32-bit. However, for best results, you should use the GCC backend (more than twice as fast as GAS, with all optimizations in place). So, don't worry about it for now ;)

[MrSwiss]

How important to move everything to 64-bit?

Well, almost all code, that used U/Integer (especially in Types) assuming it:
to always be 32bit, is affected. Those Libs., using U/Long (instead) are not affected.