Author |
Topic: Reserving memory for an image (Read 535 times) |
|
michael
Senior Member
member is offline
Posts: 335
|
 |
Reserving memory for an image
« Thread started on: Jul 31st, 2016, 9:01pm » |
|
Lets say that I have a image on the screen that I wanted to capture.. and say, it is 100x100 pixels in size.
Would the bytes I would need to create be calculated like this:
(100x100)x3 =30000 bytes
This is the info I got from a uncompressed 24 bit image
If I can get the answer before my tests indicate, I should be able to recreate 2 commands:
GET and PUT..
I would create new commands that would automatically scale memory depending on the size of the image. AND eventually make a sprite creation tool that eliminates the trouble of creating masks.
The variable pointers could be created using reserved variables that activate when a new image is created.
|
| « Last Edit: Jul 31st, 2016, 9:16pm by michael » |
 Logged
|
I like making program generators and like reinventing the wheel
|
|
|
DDRM
Administrator
member is offline
Gender: 
Posts: 321
|
|
Re: Reserving memory for an image
« Reply #1 on: Aug 1st, 2016, 5:54pm » |
|
Hi Michael,
In principle, yes. I think the bitmap image for BB4W is a 24 bit per pixel bitmap - certainly that's what Richard's routine for a "huge window" uses. You could DIM a space that is width x height x 3 bytes, and store the data in that.
However, you might want to consider using 4 bytes (32 bits) per pixel: that's what TINT returns, and that would make it easier to use (32 bit) integers to manipulate the data.
If you want to be able to write it back to the screen you will need to create a DIBSection and select it into the @memhdc (have a look at the routine for HugeWindow to see how to do that, or there have been a number of examples posted here fairly recently). That would also make reading the data much faster, and is the only realistic way of handling anything like this in real time. In that case, you could consider using a 32BPP bitmap anyway - then the data transfers would be easier. That would also let you encode transparency data, which might help with your plans for sprites.
I'm assuming here that you want a "pure BBC" approach - otherwise I'd just go for the Windows blitting operations, which are blindingly fast. I'd make a DIBSection, select it into a spare device context, and then I'd copy to and from that using BitBLT, or similar.
Bear in mind you could also use the RECTANGLE TO method to copy it to a bit of offscreen bitmap, as we did with the colour picker....
Can I suggest NOT using GET and PUT for your routines? GET already exists in BB4W, so it would be confusing, and PUT exists in various other BASICs (as a memory handling command). GetPic and PutPic would be fine...
Best wishes,
D
|
|
Logged
|
|
|
|
michael
Senior Member
member is offline
Posts: 335
|
|
Re: Reserving memory for an image
« Reply #2 on: Aug 2nd, 2016, 2:30pm » |
|
So you are saying I can copy the image off screen with RECTANGLE TO and then move it and many other images back and forth to make my game?
That would eliminate the need for *REFRESH and the need to clear the screen.
The memory allocation was necessary also for using the sprite library which I am looking to use.
I found the post you are talking about.. thanks.
|
| « Last Edit: Aug 5th, 2016, 2:35pm by michael » |
Logged
|
I like making program generators and like reinventing the wheel
|
|
|
|
