Question about Windowed Screens and donationware concept

[DrCharbonneau]

In EBasic the only drawback I found was that I could only have one screen per each program. In that I could only have a single spritebuffer, front buffer and back buffer to use for the entire program. To get around this, I plan to try chaining several programs together or simply workspace windows that are effectively their own program with a workspace relayed to the main program.

The question is, "In IWBasic, is the ability to use more buffer screens available?" By that I mean can we have one windowed program and screen that has say spritebuffer1, spritebuffer2,...3...4... and so on?

I noticed IWB is currently a "donationware" product. By this, is it meant that if I find it useful that I pay what I feel it is worth?

Dr. C

[LarryMc]

I noticed IWB is currently a "donationware" product. By this, is it meant that if I find it useful that I pay what I feel it is worth?

It means that for a donation you get the current, fully functional, version. The amount of the donation is basically determined by you.

In a perfect world, a person who makes a small donation to download it, after enjoying its value, would return and make a much larger donation to support the continued development of the product.

Unfortunately, we are too often reminded that we do not live in a perfect world.

When IWBasic 2.0 is released the distribution will return to a retail model.

LarryMc

[DrCharbonneau]

In a perfect world we wouldn't be draining the planet's lubricating fluid and replacing it with salt water to feed our need for speed and greed.

Somewhere in the NTDfuture, I'll do what I can. I may be a doctor of physics, but grants are few and financial drains are many.

In a perfect IWB compiler we will have unlimited screen buffers... (LOL) On the serious side, that's what my question is about. Will (or does) IWB have more screen buffers per program? With or without, I'm pretty happy with EBasic, so you can eventually expect some endowment from me.

Dr. C

[LarryMc]

The question is, "In IWBasic, is the ability to use more buffer screens available?" By that I mean can we have one windowed program and screen that has say spritebuffer1, spritebuffer2,...3...4... and so on?

I didn't respond to the first of your two questions in my initial response because I'm not into 2d/3d programming at all so I have little knowledge in that area.

However, since no one else has responded I'll take a shot at it after reviewing the help file.

I could not find anything that told me I could have more than one spritebuffer per screen.
And the same applies to front/backbuffers.

It appears that a spritebuffer's intended use is to load a sprite into it so that the sprite can be modified.
Then you can save the contents of the spritebuffer to the original sprite or to a newly created sprite.
There's even an example in the help file that shows how to do that.

It further appears that you can have as many sprites as you want.  So, to me, there is no need for multiple spritebuffers anyway.
You can shuffle as many sprites as you need to modify in/out of the single spritebuffer on an individual basis.

As to the idea of having multiple windows with each having its own attached screen.  I don't find anything in the buffer commands that tells me which parent window is being used.  So, I would have to say no to that being workable.

OK, that was my shot at it.  I know there are people here who know a ton about 2d/3d programming who can easily confirm what I've said  or blow me plumb out of the water .

LarryMc

[ZeroDog]

You can only have one spritebuffer to move sprites to, but you can write directly to the sprite memory itself.   This sample code is from the Users Gude, LOCKSPRITE function: 

Code Select Expand

DEF pBuffer as POINTER
sprite1 = LOADSPRITE(GETSTARTPATH+"bug.bmp",0,0,3)
LOCKSPRITE sprite1
pitch = GETSPRITEPITCH sprite1
pBuffer = GETSPRITEPOINTER sprite1
'Change the first pixel of the sprite to red
#<UINT>pBuffer = RGBToScreen(RGB(255,0,0))
'Change the first pixel on the next line to green
pBuffer += pitch
#<UINT>pBuffer = RGBToScreen(RGB(0,255,0))
UNLOCKSPRITE sprite1


[DrCharbonneau]

Hi fellows,

I already have such a write function in the program, ZD. What Larry mentioned, and you as well, have me thinking about it all. I'm busy with some other projects right now, so I won't get a chance to work on this for a bit. I will do so before long though.

I've already successfully chained some programs together. So that option is possible. It's very possible to use one program as a matrix tracking system that remains in the background and calls each formula program as it is needed. The one drawback will be memory overhead. If the programs are tiny enough, it shouldn't be a major problem, but if each one takes a megabyte, it could add up in a hurry.

For another program, the spritebuffer can likely be used as you guys are suggesting. I'm thinking of creating a hundred different sprite variable names that I can overwrite as often as I like with different jpgs to create a custom "brush" so-to-speak. Then I can scale, rotate and do what I want with the images.

Like I said. It'll be a bit before I can get back to writing code, but not THAT long...

Dr. C.