Image Map Image Map
Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: Turbo Pascal - what are the differences between v1 - v2 - v3

  1. #11
    Join Date
    May 2003
    Location
    Back of Burke (Guday!), Australia
    Posts
    2,919

    Default

    In my Pascal version of Ghost Guzzler, I have this to testing the Keypresses with the numbers following it representing the Keys used ( 'X' and 'M'):

    Code:
     if keypressed then begin
      read(kbd,getkey);
      if getkey IN [#120, #88, #109, #77] then begin
       case getkey of
        #120, #88 : checkresult(myvalue,ghostvalue);
        #109, #77 : begin
                     myvalue:=myvalue+1;
                     if myvalue=10 then myvalue:=0
                    end;
       end;
      end;
     end;

  2. #12

    Default

    I've got the same problem in turbo pascal 3 for PC's. If I test if a key is ready with keypressed and then read the key, but then have an outer loop running where it is writing to the screen, keys will be lost. Basically it seems that if the write() executes, the key buffer is somehow cleared. Surely others have run into this issue.

  3. #13
    Join Date
    May 2003
    Location
    Back of Burke (Guday!), Australia
    Posts
    2,919

    Default

    Quote Originally Posted by alank2 View Post
    I've got the same problem in turbo pascal 3 for PC's. If I test if a key is ready with keypressed and then read the key, but then have an outer loop running where it is writing to the screen, keys will be lost. Basically it seems that if the write() executes, the key buffer is somehow cleared. Surely others have run into this issue.
    I'm not sure, the routine I posted above tests to determine if a key has been pressed, if it's not pressed, everything else continues. I'm unsure though in this situation it maybe a case of having a Procedure to handle Keypresses and checking it as various intervals in the main loop of the program.

  4. #14

    Default

    It is a weird situation, the write or writeln command seems to clear out the key buffer.

    This one does not interfere so much because the write occurs and then there is a delay in which to type the key:

    Code:
    while (true) do
      begin
        if (Keypressed) then
          begin
            Read(Kbd,ch);
          end;
        write(ch);
        for i:=1 to 10000 do ;
      end;
    This one loses tons of keys because the delay is swapped with the write. If a key is typed during the delay, the write will clear it.

    Code:
    while (true) do
      begin
        if (Keypressed) then
          begin
            Read(Kbd,ch);
          end;
        for i:=1 to 10000 do ;
        write(ch);
      end;

  5. #15
    Join Date
    May 2003
    Location
    Back of Burke (Guday!), Australia
    Posts
    2,919

    Default

    Quote Originally Posted by alank2 View Post
    It is a weird situation, the write or writeln command seems to clear out the key buffer.

    This one does not interfere so much because the write occurs and then there is a delay in which to type the key:

    Code:
    while (true) do
      begin
        if (Keypressed) then
          begin
            Read(Kbd,ch);
          end;
        write(ch);
        for i:=1 to 10000 do ;
      end;
    I changed the WHILE loop to a REPEAT...UNTIL using the 'ch' variable to check if x was pressed and exit, the delay in this example will delay, but on my computer no keys are cleared, so the last key I pressed will cause ch to hold that character (you can see this in my attached screenshot). At the beginning I have cleared the ch variable, but Turbo Pascal 3 doesn't like ch:=''; ch:=chr(0); has to be used instead to clear the keyboard buffer.

    This one loses tons of keys because the delay is swapped with the write. If a key is typed during the delay, the write will clear it.

    Code:
    while (true) do
      begin
        if (Keypressed) then
          begin
            Read(Kbd,ch);
          end;
        for i:=1 to 10000 do ;
        write(ch);
      end;
    I think the problem here is the loop gets caught up doing it's thing, so what happens when you press a key, it occurs during the loop cycle, which doesn't register and forcing the user to hold down the key. Once I did that, ch held the character presssed, but not printing as frequently because of the loop being between the Keypress routine and the Writing process. When I coverted Ghost Guzzler game and wanted to slow the game a little bit, I placed a delay(100); before the actual keypress routine, so maybe that would help when testing keypresses.

    My short example looks like this, followby an attached screenshot, to produce a very responcive output.

    Code:
    program testkey1;
    
    var ch : char;
         l : integer;
    begin
      ch:=chr(0);
      repeat
        if keypressed then
        begin
          read(kbd,ch)
        end;
        write(ch);
      until ch='x'
    end.
    Attached Images Attached Images

  6. #16

    Default

    I think the until ch='x' component probably adds enough delay to give a typed key an opportunity to not be eaten by the write command. The real question is - why does the write command have anything to do with reading at all. I'm going to try a version when I have a moment just using the bios instead of write to see if it is any better.

  7. #17

    Default

    Ok, so the deal is that if you do a write or writeln, it clears the keyboard buffer. Maybe this is by design in that they think you would print things and then clear the buffer before waiting for a key. I go around this by just using a bios function to output to the screen and this works as expected - no characters are lost. I saw the same behavior on the PC platform.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •