Sprites and GRAPHIC COPY and the manual

[Barry Marks]

I'm playing around with a little program to learn how to do sprites with masks in PB using DDT. I found messages in here about that and read them and used them and got this working just fine. But I'm not really sure why it's working. The help on the mix mode parameters in GRAPHIC COPY don't quite tell me what they do.

For example the description of %mix_MaskSrc IS

Pixel is a combination of the colors common to both the source and the pixel.

What the heck does that mean?

How are the colors combined? Is each 8 bit color value added or OR'd or what? Or is this not something done with each individucal color value? Can anyone please explain this or point me to something that explains what's going on?

Thanks,
Barry

[Chris Holbrook]

...or point me to something that explains what's going on?

you could try it using solid colors and examine the color of a pixel in the result using GRAPHIC GET PIXEL. My guess is that it is OR'd.

[Barry Marks]

I guess I'll do something like that. And maybe look at the resulting color values. I had hoped to get a kind of overall explanation of how this works in PB but maybe everyone else is confused, too

My only experience with sprites was on my HP 200lx with it's 640x200 2 color CGA screen, where I wrote some sprite code in assembly, just for something to play with. That's far simpler than this. Every pixel is a 1 or a 0 and I was manipulating them myself and nothing was hidden.

Programming is a lot harder stuff these days.

Barry

[Chris Holbrook]

Given the interest in games and animation, I'm surprised that it is not made easier by PB. Do people usually do this with a third-party library perchance?

[Brice Manuel]

Do people usually do this with a third-party library perchance?

Yes or they write their own.

[Barry Marks]

I have to agree that this is a weakness in PB. I have a couple of other Basics that I tried out before I got PB and they both have far more facilities for games and graphics. I decided to stay with PB because I like the language better and also because of this forum and also because of the debugger. PB is a nice, carefully thought out package and I like it.

Most of the stuff I do is graphical and a lot of it involves games but they're all very simple so my thought was that since my graphic needs were small and I like the language better I'd use PB. I think I made a good choice but I really do wish it had things like the ability to do simple sprites and to load GIFs and JPGs.

Most of the Basics I tried even have built-in support for DiretX and in some cases even Direct3D. I don't really want those personally but I'm surprised they aren't here. I wonder if they were left out because it makes it seem more professional. Or maybe they just didn't seem important enough. When I made a living programming some of the languages I used supported graphics in one form or another but I never had any occasion to use those features.

Anyway, Chris Boss's sprite library looks promising but it requires a DLL and I like doing self contained programs. I may give in on that point when it's available.

All of this stuff I'm doing is mostly for the fun of doing it so it doesn't really matter that much.

Barry

[Brice Manuel]

but it requires a DLL and I like doing self contained programs.

How about a static lib?

[Jeff Blakeney]

I don't see things not being included in the language as a weakness. If I couldn't use DLLs or COM objects to expand the capabilities of the language, that would be a weakness.

There are lots of tools available that you can use in your PowerBASIC programs simply by adding an include statement and sometimes distributing a DLL with your program. Things like DirectX and Direct3D, you do not need to distribute the DLLs as they are basically part of the operating system. Having these sorts of things built into the language can slow you down from advancements when a new version comes out (ie. DirectX 9 support is in the language but when you install DirectX 10) you have to wait for an update to your programming language to use the new features. Also, the language support will probably be limited so if you want to do advanced stuff, you have to go to direct calls to the tool anyway.

This doesn't even touch on the fact that you might not like the way the language implements these sorts of things and you'd probably end up writing your own wrappers for things anyway.

DDT is an example of something that I feel shouldn't be part of PBWin. It is supposed to make Windows programming easier but it is limited in what it can do and if it doesn't do what you need it to, you have to switch to using the API directly. Also, if DDT were not part of PBWin and was instead a separate library, it could be used by PBCC as well as any other language. However, if it wasn't part of PBWin then there would be very little difference between PBWin and PBCC to justify separate products. I've never really understood the need for separate products but that's getting away from the point of this message.

[Chris Holbrook]

DDT is an example of something that I feel shouldn't be part of PBWin. It is supposed to make Windows programming easier but it is limited in what it can do and if it doesn't do what you need it to, you have to switch to using the API directly.

If you want to develop fast, and understand DDT's limitations and can work within them then it is an excellent tool.

Horses for courses.

[james klutho]

Barry

I posted some code in the source code forum a few days ago that you might find of interest. Using internal PB grapic statements and a couple of API calls you generate sprites which are colorkeyed and alphablended.

http://www.powerbasic.com/support/pbforums/showthread.php?t=41911

The CopyBitmapEx function may be a starting point for what you are trying to accomplish.

Jim

[Barry Marks]

How about a static lib?

I thought PB didn't support static libraries? However, that would be a good answer for me if it did.

Still, I'll eventually figure this stuff out and once I do I probably won't need a library for it anyway. I won't be doing anything very demanding.

Barry

[Barry Marks]

There are lots of tools available that you can use in your PowerBASIC programs simply by adding an include statement and sometimes distributing a DLL with your program. Things like DirectX and Direct3D, you do not need to distribute the DLLs as they are basically part of the operating system. Having these sorts of things built into the language can slow you down from advancements when a new version comes out (ie. DirectX 9 support is in the language but when you install DirectX 10) you have to wait for an update to your programming language to use the new features. Also, the language support will probably be limited so if you want to do advanced stuff, you have to go to direct calls to the tool anyway.

DDT is an example of something that I feel shouldn't be part of PBWin. It is supposed to make Windows programming easier but it is limited in what it can do and if it doesn't do what you need it to, you have to switch to using the API directly. Also, if DDT were not part of PBWin and was instead a separate library, it could be used by PBCC as well as any other language. However, if it wasn't part of PBWin then there would be very little difference between PBWin and PBCC to justify separate products. I've never really understood the need for separate products but that's getting away from the point of this message.

That's all true for someone that writes leading edge stuff or that has to make a living from it and be able to do whatever the current task demands. It's obvious there are a number of professional programmers in this forum.

I'm a badly out-of-date former programmer and I just want to do some simple stuff to pass the time. I don't need the leading edge or even want it. I spent decades doing low level programming and I'm retired. Now I want to play.

I don't think I'm the only one in this forum who thinks this way. Look how many people do use DDT and Firefly and EZGUI, etc.

Of course the answer is that PB is doing well the way it is and doesn't have to add things like graphics support. I'm not complaining. I looked over a few compilers and picked PB. The choice was mine. But I am wishing.

Barry

[Barry Marks]

Barry

I posted some code in the source code forum a few days ago that you might find of interest. Using internal PB grapic statements and a couple of API calls you generate sprites which are colorkeyed and alphablended.

http://www.powerbasic.com/support/pbforums/showthread.php?t=41911

The CopyBitmapEx function may be a starting point for what you are trying to accomplish.

Thanks. I do already have transparent sprites displaying but not moving yet. The way you're doing it looks better and also covers some of the next steps for me. I'll play with it.

Barry

[Michael Mattias]

>promising but it requires a DLL

???

All your programs require DLLs just to run.

Besides, this is not like "Brand M"... if you need a DLL you just install it (=copy) in the same folder with the EXE and it works. (COM servers excepted). (and I think you can even make COM servers work the same way if you want to).

"Using procedures in a [non-Windows O/S] DLL" is one of the "Top Ten Things All Programmers Should Know How to Do."

MCM

[Barry Marks]

I realize that having a DLL isn't a real problem. It's just that I'm doing this for fun and it's nice to be able to have a single file for a program. They are small programs, after all. If I have to use a DLL I will but I'll avoid it if I can.

Of course I realize that much of Windows is contained in DLL's but those are always there on every machine. I don't have to worry about them.

Barry

[Barry Marks]

Barry

I posted some code in the source code forum a few days ago that you might find of interest. Using internal PB grapic statements and a couple of API calls you generate sprites which are colorkeyed and alphablended.

http://www.powerbasic.com/support/pbforums/showthread.php?t=41911

The CopyBitmapEx function may be a starting point for what you are trying to accomplish.

Jim

I just did a little playing with this and the CopyBitmapEX function works nicely. I don't need the alphablending for what I'm doing now, or I don't think I do, but I think I'll use your function anyway, if that's okay, since it simplifies things for me.

Even better, the sample program around that function has the movement done in a way that's easy to understand and that was the next thing I planned to figure out how to do.

Thanks for posting this and thanks for calling my attention to it. It helped a lot.

Barry

[james klutho]

Barry

I just posted a little update to the sample CopyBitmapEx program. It has a few balls flying around and a scrolling marque at the bottom. You can turn off and on the alphablending and watch the program suck up the CPUs.

Jim

[Barry Marks]

I saw that and yes, it does eat cycles.

Thanks,
Barry

[Brice Manuel]

I just posted a little update to the sample CopyBitmapEx program. It has a few balls flying around and a scrolling marque at the bottom. You can turn off and on the alphablending and watch the program suck up the CPUs.

James, I gave your code a little test. I get a rock-solid 60 FPS with alphablending on and off. That is with 50% CPU use.

[Gösta H. Lovgren-2]

Barry

I just posted a little update to the sample CopyBitmapEx program. It has a few balls flying around and a scrolling marque at the bottom. You can turn off and on the alphablending and watch the program suck up the CPUs.

Jim

VERY neat demo, Jim.

Using 'PBWIN 9.02 - WinApi 05/2008 - XP Pro Dell XPS (1.77gz?), I noticed a couple interesting things:

1). After a few seconds runinng, the fps is in the mostly upper 30's, some 40's (aphab off/on about the same). Moving the mouse around the dialog cause the fps to go to upper 40's/50's while the mouse is moving.

2) Clicking on file (dropping the submenu) boosts the fps to 64 while the submenu is showing. Clicking on the dialog (closing the submenu) drops the fps back down.

Interesting. Kinda fun really.

TaskMgr shows 0% usage in either case.

Just ran again and fps was about 10 higher (64 tops). Curious. Doesn't seem to be consistent across runs. Sometimes faster/slower. No code changes. Just exit and (re)run. Curious
===========================
"Beauty is eternity gazing
at itself in a mirror."
Kahil Gibran
===========================