CHR$(0)
CHR$(0)
(OP)
WHAT IS THE CHR$(0) JUST A "" ?
WHAT IS NULL ?
AND THERE ARE SOME ASCII CODES THAT ARE JUST ""
HOW CAN I READ THEM FROM A FILE AND WRITE THEM TO A FILE?
(I AM MAKING A PROG. USES CHR$(0-255))
WHAT IS NULL ?
AND THERE ARE SOME ASCII CODES THAT ARE JUST ""
HOW CAN I READ THEM FROM A FILE AND WRITE THEM TO A FILE?
(I AM MAKING A PROG. USES CHR$(0-255))
RE: CHR$(0)
Null is empty or nothing or not stored or switched, depending on what circumstance your are describing.
The characters that print as nothing are undisplayable characters under the system you are using. But you can sometimes load the ansi.sys driver and change the setup of your system to display better.
Writing is by print#1,chr$(123).
First major implementation of ASCII was with the teletype system where the null character was a tape feed with no holes.
Ed Fair
Any advice I give is my best judgement based on my interpretation of the facts you supply. Help increase my knowledge by providing some feedback, good or bad, on any advice I have given.
RE: CHR$(0)
1000000-11111111 the seventh bit will be always set to 1....
But i will use just 7 bits instead of 8.
1 xxxxxxxx
RE: CHR$(0)
CLS
FOR A = 0 TO 255 STEP 1
PRINT CHR$(A);" ";A
SLEEP 1
NEXT A
That will show you all of the cool characters to use in misc. programs.
Doug
RE: CHR$(0)
- Martin
RE: CHR$(0)
chr$(0) + chr$(72)
chr$(0) + chr$(75)
chr$(0) + chr$(80)
chr$(0) + chr$(77)
i don't know much about extended keys though. all i know is that they return the 0 plus their value.
so say you made a program like this
do
do
i$ = inkey$
loop until len(i$)
print i$
loop
if you pressed a normal key, say a, it would return this:
a
say you pressed an arrow key. it would return something like this:
M
notice it returned a space and the letter m. that's something like right. i never could get the values and the keys straight...
RE: CHR$(0)
I don't have the axact codes with me right now by I believe that the arrow keys are: 72 - down, 74 - left, 76 - right, and 80 - up.
I'll double check and follow up.
RE: CHR$(0)
my code was to ;
In screen 7 we have 320*200 with 16 colors means ;
320*200*4 bits, right ?
And mapping it ;
dim map(320,200)
It spends too much memory but ;
An ascii code is 8 bits long
so it can carry 2 pixel colors 4 - 4
for example;
pixels with colors 12,8
=1100,1000
=&hc8
=200
chr$(200)
get it now ?
320/2=160
dim map$(200,2)
for t=1 to 200
map$(t,1)=space$(160)
map$(t,2)=space$(160)
next
320*200*4/8=32000 ascii codes
so we used just a dim with (200,2) instead of (320,200)
when we save it as a file we can see the real difference..
but like what i said i'm gonna use 7 bits and the the 7nth bit will be set to 1 always......
1000 0000
or ;
a variable can be trough 0 to 65536 means 16 bits;
16 bit=4 pixels
so dim map(200,80)
the converter routinne is so simple..........
if u want me send it i will absoulitely send it;
but i need some help with inp and out
meet u on a different thread
RE: CHR$(0)
Going back to your original question.
chr$(0) is not the same as "".
"" does not contain anything. There isn't any space in "".
chr$(0) contains zeros like so 00000000
chr$(1) would contain a one 00000001
Pappy
You learn something new everyday.
RE: CHR$(0)
That was very helpful. I have only used the CHR$(0) to use arrows keys as well. but I didn't use CHR$(77) and such. I just put the capital letter in quotes.
CHR$(0) + "M"
~PlystirE~
RE: CHR$(0)
that will cause unwanted results. like clearing the screen with chr$(12).
RE: CHR$(0)
why not use screen 13? much better. same size screen, but 256 colours, aka 8 bit. so 8 bits = 1 byte, 1 byte = 1 pixel, 1 integer = 2 bytes (very convient) so 1 integer = 2 pixels.
so therefore if you were double buffering the whole screen, 320*200, 64000 pixels in area. but it's too big. so we're going to have to store two pixels in one integer, so it will be cut in half, 32000. if you want it in get/put format, you'll need two extra integers, one for the width in bits (so width * 8) and the height in pixels. so it seems like you need 32002, but you only need 32001, since counting in qbasic starts at 0. (0,1,2,3...) the very first variable will be 320*8, or 2560. the second will contain the height of the screen, 200 pixels. so therefore...
dim buffer(32001)
buffer(0) = 320*8
buffer(1) = 200
or...
get(0,0)-(319,199), buffer
so now you're set. however, now you need to be able to draw pixels on the buffer. with plasma357's setvideoseg, you could use qb's primary routines (pset, line, etc. etc. ) but if you don't want to use them, then you'll have to use poke. once again this only works in screen 13.
first of all, you have to set the default segment to the buffer, as poke "pokes" information to whereever the def seg is pointing too. however, if you use
def seg = buffer(0)
then it will set the default segment to 2560. in order to find the address the buffer is at, you must use varseg. it returns the segment of whatever variable you put in it.
def seg = varseg(buffer(0))
but now how do we put a pixel on the buffer? well, first you need to know the x and the y. now, poke works like this:
poke offset, byte
this creates problems. how do we get the x and y variables in there? well, you should be able to tell that this is one dimensional. since the screen is 320 pixels wide, then we should have enough information to find the offset, or x and y coordinates on the buffer.
poke 320& * y + x + varptr(buffer(2), colour
now, we times the y with 320 because since we're working with one dimension, timesing the y with 320 will bring the offset to the right row. adding x will move it forward to the right column. you must add varptr(buffer(2) to skip over the two variables holding the size of the buffer. for example, say x is 32 an y is 1. first you times the y with 320. this will move the the coordinates to the right row. then you add x, which moves teh coordinates to teh right column. oh, the reason why it's 320& instead of just 320 is because the buffer will overflow if you don't.
sub putpixel (x, y, colour, buffer()
def seg = varseg(buffer(0))
offset& = 320& * y + x + varptr(buffer(2))
poke offset&, colour
end sub
maybe later i'll explain it better.
RE: CHR$(0)
But then you used floating points variables in your example.
buffer() should be buffer%()
Also, I'm not sure if your POKEing system is fool-proof; I am pretty sure that your offset& can not be greater than 65535, but the RAM sould be sequencial, so you could figure out the offset& the way you did above, but add this code
IF offset& > 65535 THEN DEF SEG = VARSEG(buffer%(0))+1
a = offset& MOD 65535
POKE a, colour
You might be a redneck if... you think a megabyte is a good day of fishing.
RE: CHR$(0)
i also assume that people use defint a-z at the beginning of their programs. As you very well know, that means all nondefined variables are integers. but you're right, i'll take note of that. thanks.
btw qbasicking, you may very well be right. i just wrote that off the top of my head. As i recall, 16 offsets will equal a segment. knowing that, you can set the segment to this:
def seg = varseg(buffer%(0) + int(offset& / 16)
poke offset& mod 16
this will fix any overflowing bug. i don't use this often, because exeing the program will fix this bug, and it works slower than what i had before.
a very good resource would be zippy's buffering tut. it's how i learned buffering. and relgfx is a VERY good read. very well organized, shows you what pure qb can truly do.
RE: CHR$(0)
a *.bmp file huh
i thought that using integers would be better for using ram..and dims..but a *.bmp file already works like that.
what a silly.......