Detect buffer end ?

[DaveInDev]

Probably a stupid question and I'll be shot down for this but :
while iterating a buffer in a loop with buffer_read, how do you detect the end of the buffer ?
Because buffer_read crashes if you try to read after the end...
Do I have to use buffer_get_size and count my steps, or is there a shorter way ?

 

[TheouAegis]

Speedwise, I'm not sure which is faster: counting down a variable like you said, or using buffer_tell==buffer_size-1. But yeah, that's what you do out of the box. Alternatively, you set the very last byte(s) in the buffer to be a value that you would never use in that buffer, and when you read it, check if the value is illegal and tell your code to stop trying to read the buffer any further. but that is typically a method you use for delineating data within the buffer itself, not the end of the buffer.

If your buffer is going to be a variable size, then just compare the tell with the size. If your buffer is going to be a set specific size, then really it's on you if you try to read past the end of the buffer.

 

[chamaeleon]

Just throwing out there that for a binary data it makes sense including structure/header information that tells you what the content is (unless it's a buffer containing just N primitive types that are of fixed size, perhaps). Of course, if you're not the creator of the buffer content, you may not have any choice in the matter. I'd feel more comfortable using that kind of information rather than buffer size, which in theory could be larger than the actual amount of data.

 

[DaveInDev]

Infact I load a WAV file in bulk with buffer_load, and would like to quickly iterate thru this buffer. Of course, I can have the size of the buffer and count, but as buffer_read seems to perfectly detect the end of the buffer (and crash !!! ) I thought I missed a function like buffer_end() or EOB()...

 

[chamaeleon]

Maybe something like

var length = buffer_length(buf);
while (buffer_tell(buf) < length) {
...
}

 

[TheouAegis]

Are you just reading every byte sequentially? You don't need buffer_tell() for that. If you are reading the whole thing in one step, just repeat(buffer_get_size(buffer)). If it will be sequential over multiple steps, just save buffer_fet_size() to a variable and then decrease it every step, should be a tad faster.

 

[DaveInDev]

I finally found this buffer_load_partial function that is even faster, but the I keep the repeat(buffer_get_size(buffer)) for other needs. I always forget this repeat(N) stuff in GMS. Coming from C++, it does not come to my mind easily.

 

[Nidoking]

repeat(N) is exactly the same as for (var i=0; i<N; i++) and not using i in the loop.

 

[DaveInDev]

repeat(N) is exactly the same as for (var i=0; i<N; i++) and not using i in the loop.

oh yes, I'm sure of that too, but it's shorter to write.

 

[TheouAegis]

repeat(N) is exactly the same as for (var i=0; i<N; i++) and not using i in the loop.

Functionally, it's different enough, while is closer to for than repeat.

The break condition in repeat must evaluate to a real. This also means the breakpoint is saved to an internal variable rather than being re-evaluated on each loop. As such, repeat is the fastest of the 3, at the cost of flexibility.

The breakpoint in while is just a bool and as such must be checked every loop, so it's frequently used in loops that have unknown or variable conditions. Furthermore, the breakpoint doesn't actually need to be met, so it could be unrelated to the main block.

while 1
    if clamp(++x,0,room_width) != x
        break;

The breakpoint in for is the same as while. The breakpoint in for is intended to work with the variable declaration, but they are unrelated. The statement at the end is also unrelated to the variable declaration and the breakpoint.

for(x=x; y=ystart; image_xscale=sign(x-room_width/2);) {
    x+=hspd;
    if clamp(x,0,room_width) != x
        y += 16*sign(hspd);
    else
    if place_meeting(x,y,oWall) break;
}

 

[Nidoking]

Functionally, it's different enough, while is closer to for than repeat.

I'm just speaking in logical terms here. The premise was "I'm a C++ programmer, so I don't think about loops that are hardcoded to run N times," and my response was "This is a loop in C++ that does exactly that, and we just have a cleaner way to write it in GML."