AI

[computerkid14]

mabye somthing to do with the if guyy is > AIy = AIy -1

[Mitthrawnuruodo]

Yep that will do it.

[computerkid14]

hmm so how can i fix this
it seem like if the npc is above the player it should move down 1
but in order to move without leaveing a trail of blue behind i have to cls and put the ai square again, right?

[computerkid14]

anyone?

[Anonymous]

its things like this why people are using fb and not qb. you CAN cls after every put, but thats flickery as hell...

to do what you wanna do is called using 'pages', i think its called buffering but im not sure =P

let say all the memory that the screen data requires can be put into an array "screen%()"

now, in order to print all that image data to the screen, all you would have to do is copy the data to the memory location of the screen (this is what put does)

but thats where qb laks behind. you could make an array to hold 2 screens, but... memory is very limited in qb. to make even one integer array to hold the screen data would take 32002 integer indexs in the array... btw the formula for that is:

(width% * height%) \ 2 + 2
i.e.
(320 * 200) \ 2 + 2

to this would total 64004 bytes... (every integer array index is 2 bytes) if you think about it thats 1/10th of your conventional memory right there, for ONE screen worth of memory. to have even 2 pages costs almost 128kb of memory... which is why people got fixes like EMS, etc... anyways im getting off topic

the main point is to do what you wanna do, you need 2 pages.

1) you set one page as the "working" page, and one page as the
"visible" page.

then you

2) "print" everything to the working page
3) then you copy the working page into the visible page
4) then clear the working page

...and repeat at step 2 until youre... done basically.

this allows the user to basically see a finished snapshot of whatever tiles youve built together, then you can erase the (invisible) working page and start it all over, the user never seeing any of the 'messiness' if you will.

anywho people used to use libraries and all kinds of hacks to fix it so screen 13 could have the extra memory to hold invisible pages. well, now with fb, its already built in the syntax! alls youd have to do is

SCREEN 13, , 2 (qb screen 13, with 2 pages)

and heres how youd do the steps from before:

1) SCREENSET 0, 1 (sets working page to 0, visible to 1)

2) put tiles to invisible working page (this is automatically taken care of, as fb assumes the page you write to is 0.)

3) SCREENCOPY (easy? :P)

4) CLS (good old cls only clears off the working page)


id suggest looking into it.

friggin long post... <.<

[TheDarkJay]

I suggest you just erase the area that CHANGES, (i think it is called BLT BLT or something like that),

example

Code:

SCREEN 13

DIM bground(1000)

x = 50
y = 50

LINE (0, 0)-(300, 200), 3, BF 'this will not cover the whole screen
GET (x, y)-(x + 10, y + 10), bground
LINE (x, y)-(x + 10, y + 10), 15, BF

DO
key$ = INKEY$

IF key$ = "a" THEN
oldx = x
oldy = y
x = x - 10
LINE (oldx, oldy)-(oldx + 10, oldy + 10), 0, BF
PUT (oldx, oldy), bground
GET (x, y)-(x + 10, y + 10), bground
LINE (x, y)-(x + 10, y + 10), 15, BF
END IF

IF key$ = "d" THEN
oldx = x
oldy = y
x = x + 10
LINE (oldx, oldy)-(oldx + 10, oldy + 10), 0, BF
PUT (oldx, oldy), bground
GET (x, y)-(x + 10, y + 10), bground
LINE (x, y)-(x + 10, y + 10), 15, BF
END IF

IF key$ = "w" THEN
oldx = x
oldy = y
y = y - 10
LINE (oldx, oldy)-(oldx + 10, oldy + 10), 0, BF
PUT (oldx, oldy), bground
GET (x, y)-(x + 10, y + 10), bground
LINE (x, y)-(x + 10, y + 10), 15, BF
END IF

IF key$ = "s" THEN
oldx = x
oldy = y
y = y + 10
LINE (oldx, oldy)-(oldx + 10, oldy + 10), 0, BF
PUT (oldx, oldy), bground
GET (x, y)-(x + 10, y + 10), bground
LINE (x, y)-(x + 10, y + 10), 15, BF
END IF


LOOP UNTIL key$ = CHR$(27) 'loop until [esc] is presses

i prefer to use CASE but i used IF in this example because it is more commonly used for moving

Another way to remove flashing is

WAIT &H3DA, 8

[Mitthrawnuruodo]

BLT: Bacon Lettuce + Tomato! :lol:

Ya What I do is draw stuff to the screen, store those coordinates, change the original coordinates, check them, WAIT &3DHA, 8 (also use WAIT &3DHA, 8, 8 after that if you want it slower), erase the images by using the coorinated you stored, loop.


That minimizes flicker to non-existant.
You draw then you wait + do all your calcs for the next draw making those calculations helpful to minimizing flicker, then you erase and draw right after that erase. :wink:

[TheBigBasicQ]

mitth: make that:
1. Draw
2. Do calc
3. Wait
4. Clear
6. repeat from 1

[TheDarkJay]

BLT: Bacon Lettuce + Tomato! :lol:

Ya What I do is draw stuff to the screen, store those coordinates, change the original coordinates, check them, WAIT &3DHA, 8 (also use WAIT &3DHA, 8, 8 after that if you want it slower), erase the images by using the coorinated you stored, loop.


That minimizes flicker to non-existant.
You draw then you wait + do all your calcs for the next draw making those calculations helpful to minimizing flicker, then you erase and draw right after that erase. :wink:

I was told to use WAIT &H3DA, 8 to remove flickering, what is the difference?

[Mitthrawnuruodo]

Ummm, I use WAIT &H3DA, 8. I also use WAIT &H3DA, 8, 8 to make the delay var longer (with the first one).

I use my routine to add the calcs TO the delays so the slowness of complex calculations accually is benificial.

And BBQ, if I did it your way it would not work. You have to store the draw variables into another variable to then erase at that stored variable later while you change the first one.

Your way:
Say I have an image at (3,4)
1. Draw image at (3,4)
2. change + check image to (5,6)
3. wait
4. erase image at (5,6)
5. loop

You don't want to do that above ^.
My way:

1. Draw image at (3,4)
2. Store image coordiantes to another variable which are (3,4)
3. Change + check image to (5,6)
4. WAIT
5. Erase image at old coordinates that you stored [(3,4)]
6. Loop

:wink: