How fast is POKE and PEEK?

Hi all,

1. How fast is POKE and PEEK?
2. Are they just used for replacing variable assignment?

Thanks in advance.
Sammy
:)

Peek and Poke are the Basic languages equivalent of the machine code command MOVE. Basicly it's used to move a value to a certain RAM adress. In Blitz we can only use a pseudo variant of Peek and Poke, that's Bank operations: PeekInt, PokeInt, PeekFloat, PokeFloat etc. In a Bank you can access a value by an "offset" that's in fact an adress relative to the bank. The Offset we use is not a real RAM adress.

Sometimes it's useful to access data by adress and not by name. Banks also offer some nice features eg. ReadBytes, to quickly read a bulk of data from a file.


It's pretty fast, but not much faster than eg. array access.

The one nice advantage a Bank has over an array, is that if you are doing a "map" (as in a world map for an RPG), you can load the whole map in one swoop, versus one-byte-at-a-time with using For-Next loops and an array.

Ditto, you can save the contents of a bank in one operation, rather than a For-Next loop one byte at a time.

If you are using a map, for instance, for a 256x256 tiled world, that's 64K For-Next loop reads/writes with the harddrive, versus using one operation with Readbytes/Writebytes.

Also if you are tight for storage space then you can store data at a single byte level (or even less if you want - rather than having an array where each element is 4 bytes (int / float)).

Also they are useful for when you would like to have an array within a type that can be resized by using a bank to do it instead.

They provide a lot of flexibility over how you can store your game data.

The situation of, when you are tight for storage space, is fast becoming a relic of earlier computing days, when processors were 8-bit and 64K was all the RAM space you had (i.e. the Commodore 64), and a hard drive (if you could get one) was a mere 5 MB. Nowadays, with hard drives in the hundreds of gigabytes (even beginning to approach terabytes), and PCs regularly being able to have gigabytes of RAM, "tight for storage space" is sorta becoming a non-issue, as in the dialogue: "That program needs 290 MB? So what? (Shrugs indifferently)."

Ahhh, Technology!

Just because storage is cheap, squandering resources is not something that should be at all tolerated or encouraged. There may come a time when RAM is prohibitively expensive and we will be thankful for every last byte.

People still using a 64MiB 350MHz system will be thankful today for your non-lazy programming practices.

Vinylpusher:
Good point. Just today, at work, I tried running (in my spare time) a copy of my 3d program I'm developing, and the little test for 3d capability that I put in at the very start of the program, triggered:

caps= GfxDriverCaps3D() ; 110 means it supports cube face mapping
If caps<110 Then RuntimeError "Sorry, but you need a 3D cube-mapping capable video card to play this game."

The machines at work are over 1 Ghz in processor speed with 256 MB RAM (30 GB HD), and all, but obviously their video capabilities are not up to the task. Just because high-end machines can do what I've described, does not mean everyone has such equipment, of course, and your example of a 64MB 350MHz machine is appropriate. <Sigh>

I agree, squandering resources is just plain lazy.

Peek and Poke are not as fast as operations with variables. There are, as above, many advantages.