How fast is POKE and PEEK?
Blitz3D Forums/Blitz3D Beginners Area/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. |
   |