Get\Put troubles

[stylin]

LOL

Then like 100 QB games are bad coded and don't work :roll:

Then, like, the QB documentation is wrong. Take your pick.

[na_th_an]

The QBasic documentation describes the general formula in which the PMAP value has to be taken in account. It works in excess guaranteeing (sp?) that the arrays will be big enough. The (x*y+4)/2 formula fails when x*y is odd. For example if you have a 5x5 image it would need 25 bytes + 4 = 29 bytes, but 29 / 2 = 14. If you DIM sprite%(13) you are not reserving the needed amount of memory.

The QB help is a "failsafe" solution providing a decent array size which will work for every videomode, but it's not the most efficient formula, memory-wise.

Anyway, following the formula:

Code:

4 + INT(((x2 - x1 + 1) * (bits-per-pixel-per-plane) + 7)/8) * planes * ((y2 - y1) + 1)

You get:

Code:

4 + INT (((319 - 0 + 1) * 8 + 7) / 8) * 1 * (199 - 0 + 1)

solving...

Code:

4 + INT ((320 * 8 + 7) / 8) * 200

4 + INT (2567 / 8) * 200

4 + 320 * 200

4 + 64000

64004

You know, this time we get the same results.

[Neo]

Nope. The correct number of subscripts is 32263.
Look http://forum.qbasicnews.com/viewtopic.ph...3&start=26 for more info.

Do not question me like that again. I don't like it.
In that case, you tell me what you need those 524 extra bytes for.

Oh well... I said enough... I dont feel like repeating what Nath said.

[stylin]

The QB help is a "failsafe" solution providing a decent array size which will work for every videomode, but it's not the most efficient formula, memory-wise.

I see. My apologies. I guess then it would help if the QB help would be (a little) clearer in its documentation. It's situations like these that I remember why I work in FreeBASIC now.

Do not question me like that again. I don't like it.

I didn't question you.

In that case, you tell me what you need those 524 extra bytes for.

I would if I could. Seemed rather odd to me, and apparently, QB doesn't even know. :roll:

[na_th_an]

No need to apologise. Now I realise that my "LOL" shouldn't be there. It's me who apologises.

I think that you got the big number 'cause you used 320 and 200 instead of 319 and 199. The formula considers coordinates, not measurements.

[stylin]

Yes, I just noticed that as well. I need to stop posting at 6am - or stay clear of the QB forums.

[axipher]

well 32001 works fine, but when it fills, it still flickers... but otehr then that it works

[Dr_Davenstein]

The only way to really stop the flickering, is to use double beffering. You can make it less noticable, by adding a strategic Wait &H3DA,8 though. Have you considered using a library?

[Neo]

Code:

WAIT &H3DA, 8
WAIT &H3DA, 8, 8

[axipher]

double buffering, well i fixed it, i simply put the PUT statement in rite before the x and y values are changed which un-draws the old img, then in the SUB where it draws it, then it draws it, and it doesnt have to change the background at all, so no more flickering, yay.

anyway, for future reference in case i need it, wat is this double buffering u speak of, i read a tutorial on it, but didnt quite understand, and the

Code:

WAIT &H3DA, 8
WAIT &H3DA, 8, 8

wat on earth does that do, u said its a wait period, is it like negative or sumtin, or wat, well im probably getting anoying, in like 6 days ive posted about 40 out of my 48 posts, and there all to do with one simple thing im trying to do, but everyone is so helpful, its awsome, good thing i looked on my old cpu wat programs it had before i formatted it and backed the qb4.0, then found a forum site for it, it all worked out, plus old school programming in dos owns anyway