APE Coding, How does the Framebuffer Work???

Hi

Im writing AVS Presets since im 11years and after beeing into trigonometry and advanced mathematics and learning c++, i Want to start writing APEs.

But i simply cant figure out how the framebuffer works.
Somewhere on these forums i read this:

the *int framebuffer pointer points to the first pixel of the framebuffer, in which colour information is stored in 00RGB format (whatever this means)

From the BOX Tutorial
Example:

int C_THISCLASS::render(char visdata[2][2][576], int isBeat, int *framebuffer, int *fbout, int w, int h)

If i understood the usage of pointers u would acces the ADRESS of *int framebuffer via
ADRESSFB=framebuffer
And the Data (i think its colour information) via int COLPIXEL=*framebuffer

is this right?

so what does this:

framebuffer+=(((halfh/2)*w)+ (halfw/2));

I think this is pointer arithmetics, but it simply makes no sense to me, i cant understand it.

for(int j=0;j<halfh;j++) { for(int i=0;i<halfw;i++) { framebuffer[i]=color; } framebuffer+=w; }

What i guess happens here is that the pixels in the fb are processed and there colour is changed.

Plz help me understanding

It would help me too if someone could tell me if its possible to debug my APE with VS2002 with the DLL Debugger, simply cant get it to work.

thx Chaos_2k

anyone???
im desperate 😢

quite frankly, if you are struggling with the concept of a framebuffer you really shouldnt be trying to code an APE.

I would normally post something more helpful but if your understanding is that limited I'm not sure where to start. Try reading some c++ tutorials (pointers and arrays in particular), then try looking up some basic graphics programming theory (framebuffers and pixel formats in particular)

P.S. I personally have not got debugging of avs to work in VS.NET (bear in mind that it is a vc6 project and you do lose some stuff in the conversion) but apparently it is possible.

mh, yeah after some redaing about Bitmaps i got the point.
I simply didnt konw where to start. Its nowhere stated that the framebuffer is organized like a bitmap.
I havent had any experiences with framebuffers though ive already written little OpenGL aps.
You shouldnt forget im just 15 and still learning *g*

Im not that much skilled in c++ but i've already written some little games and stuff for parsing texts (wouldnt have to be in c++ nescesarely but i just wanted to try).

After i spend some days relaxing and doing sth. else, i tried to find out myself how it works. But whats not documented:
A Bitmap according to Microsofts Specs is starting with the first pixel on the bottom left.
The AVS framebuffer starts with the top left Pixel. Also AVS can only use resolutions that are quadruples of 4 because it cant fill up 4 bytes with zeros so the ampount of bytes per line are divisible by four.
Or has this a different reason? (i.e 32Bit what used by default will always give you a quadruple of 4, so why couldnt you use different resolutions?)

some questions to the c++ code: and YES ive tried to find out myself and this is what i came up with, i just want to know if its correct. I know some questions are realy basic and i think i understood pointers & references. This is no hep forum for c++, but i think its quiet easy for you to answer as my questions arent that difficult.

Ill give some code to explain.

//f recieves the pointer int pointer framebuffer which
//stores the Adress of the first (top/left) pixel
void f (*int framebuffer)
{
std.cout<<framebuffer<<endl; //this would print the adress
std.cout<<*framebuffer<<endl; //this would print the data stored @ the adress

framebuffer= framebuffer + w //this changes the adress by one "line"

This would require the framebuffer to be stored in one sequence in memory, otherwise the result of this operation would be undefined and dangerous.

Next question. if the width of my avs window is 322, is w given to the render function 332, or something else? Because if you want to advance to the next pixel, you would have to go 32Bits ahead.
On a 32Bit system every Adress in the memory stores 32Bit of Data, so simply going on to the next adress means that there is the next pixel in the framebuffer, right?

*framebuffer=color; //this changes the color of the current pixel

right?

for(int j=0;j<halfh;j++) {
for(int i=0;i<halfw;i++) {
framebuffer[i]=color; } framebuffer+=w; }

The framebuffer[i]=color operation has nothing to do woth an array, right? Because the framebuffer is no array, its a sequence of 32bit Pixels stored in sequence in mem.

so whats the []operator???
The STL knows the bitset:😳perator[] but i dont think its waht this operator does.

Could one of you be so kind and correct me?

Sorry for my bad english and my inconvenience

Originally posted by Chaos_2k
mh, yeah after some redaing about Bitmaps i got the point.
I simply didnt konw where to start. Its nowhere stated that the framebuffer is organized like a bitmap.

A framebuffer isn't like a bitmap, a bitmap is like a framebuffer. Although the comparison is valid.

Originally posted by Chaos_2k
A Bitmap according to Microsofts Specs is starting with the first pixel on the bottom left.
The AVS framebuffer starts with the top left Pixel. Also AVS can only use resolutions that are quadruples of 4 because it cant fill up 4 bytes with zeros so the ampount of bytes per line are divisible by four.Or has this a different reason? (i.e 32Bit what used by default will always give you a quadruple of 4, so why couldnt you use different resolutions?)

Okay you are probably taking the bitmap comparison too far now. Bitmaps do indeed start from the bottom left, AVS from the top left, this is arbitrary and unimportant. Windows bitmaps are dword (double word, i.e 32bit, sometimes call quad byte) aligned per row, meaning if a row of pixels at whatever pixel format ends at a number of bytes indivisible by four, zeros will be added to make it up to a byte value which is. The reason for this is speed related, working with 32bits at a time is a lot quicker than other sizes due to the architecture of (average) computers (for example all of the main registers in your cpu are 32bit unless you have a 64bit system). AVS does not have quad byte alignment because the pixel format is already 32bit (as opposed to windows bitmaps which can have 1,4,8,24 bit iirc) so there is no need. (I am not sure what you meant by "resolutions that are quadruples of 4", only 16 is a quadruple of 4 and I'm pretty sure avs supports resolutions above that 😛 )
___

I'm not going to quote the rest of your post because again I'm not sure where to start. You need to look up and experiment with arrays and pointers. Your basic knowledge gap is that an array IS a continuous block of memory, and there are two ways of accessing data in an array

The pointer way...

//declare an integer pointer

int *piIntPointer;

//point piIntPointer to the first item of the array

piIntPointer = piBigArrayOfInts; 

//point piIntPointer to the next item of the array

++piIntPointer;

//set it to some value

*piIntPointer = 1;

The array index way...

//access the array index we want directly and set its value

piBigArrayOfInts[1] = 1;

Neither is better, they are just different, but you should understand how each works since other people may use either in their code (the AVS source is pretty pointer heavy).

Again, try to learn at least some c++ before diving into a relatively difficult task like an avs ape. You can ask more questions if you like but try to keep the short and to the point, I'm not going to keep typing huge replies 😁

Thx for your answer, helped me a lot. 😁

You expressed exactly what i thought about Bitmaps, but you know my bad english *g*
Quadruple was meant as something dividable by 4 or something multiplied with 4. 😁

I didnt know about the pointer way to acces arrays.
Im not that unskilled in writing c++ apps but im lacking experience in programming as you already noticed *g*

I've also tried to understand the avs Source, and i have to say im very impressed about the eel concept with VMs and stuff like that.
Its a very good lesson to read and try to understand the Sourc.

My deepest respect to those guys who wrote AVS *g*

Thx Pak-9

reading and understanding the AVS source is quite a good learning experience as you say, however it is not that easy since the code is pretty messy.

The best way to learn coding is to actually do it, the more practice you have the better you will get.

Originally posted by Chaos_2k

My deepest respect to those guys who wrote AVS *g*

Mostly one guy incidentally. All of the impressive bits anyway...

Curse my computer for not working whilst such an awesome thread existed in the forums. 🙁

I was a bit curious why you didn't dive in 😛

Originally posted by PAK-9
P.S. I personally have not got debugging of avs to work in VS.NET (bear in mind that it is a vc6 project and you do lose some stuff in the conversion) but apparently it is possible.

I can debug my APEs (and AVS source code) in VS.NET (2003 and 2005) without problem. Just compile a debug version of your APE into your plugins/avs folder then set winamp.exe as executable name for debug. Put some breakpoint, click run into visual studio, Winamp will launch, then run avs from winamp and instanciate your new ape from it. Your breakpoints should work 🙂

Hope this helps.

Useful, thanks 👍