Announcement

Collapse
No announcement yet.

INKEY$ and graphics

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mel Bishop
    replied
    >>>...something is running in the background...<<<

    Bring up Task Manager (Ctl-Alt-Del) and see if one or more processes is chewing up your CPU percentage.

    Leave a comment:


  • G Grant
    replied
    Hmm, well, that helps. Thank you VERY much for testing and getting back to me.

    I'm on an Intel Pentium 3.0 Ghz, WinXP Pro, 2 gig of RAM, ATI X1950 Pro AGP 512 meg.

    So it looks like maybe something is running in the background on my machine that might be causing this issue.
    Or maybe a windows setting?

    Running on my taskbar are Daemon tools, Virtual Drive Pro, ATI tray tools with video temp monitor, ICQ, and monitor calibration wizard. I will try shutting them all down and see what happens.

    Can anyone else test and verify that it responds instantly?


    Welp, I stopped all those processes, and it made no difference, so it wasn't that. SOMETHING has to be different on my machine from Mel's that's making it work differently.
    Last edited by G Grant; 30 Jan 2008, 11:01 PM.

    Leave a comment:


  • Mel Bishop
    replied
    What kind of machine are you using this on? I tested your code on a Dell 2.4 Ghz machine and, even after leaving it run for 5 minutes, the program aborts, Johnny on the spot, when I press a key.

    Leave a comment:


  • G Grant
    replied
    There's really not a lot to optimize in my test code (unless I'm overlooking something about the way programs under windows work).
    Here is some test code to show the problem. All it does is draw a rotating line in a loop. Throughout the loop, INKEY$ is checked to see if a key has been pressed, and if so, end the program.
    Even with this simple code, the longer you wait to press a key, the longer it takes for INKEY$ to respond. INSTAT gives the same result.
    What is it about INKEY$, graphics, and PBCC that I'm not understanding?



    Code:
    FUNCTION PBMAIN () AS LONG
        radian# = .017453293
        radius# = 500
        xcenter# = 500
        ycenter# = 500
    
        CONSOLE SET SCREEN 1, 19
        CONSOLE SET LOC -1000, -1000
     
        GRAPHIC WINDOW "", 50, 50, 1000, 1000 TO MyWindow???
        GRAPHIC ATTACH MyWindow???, 0, REDRAW
        GRAPHIC COLOR RGB(0, 0, 255), RGB(0, 255, 0)
    
     
        linecolor& = RGB(255, 0, 0)
        DO
            FOR angle# = 0 TO 359 STEP .05
                GRAPHIC CLEAR
                
                x# = xcenter# + radius# * SIN(angle# * radian#)
                y# = ycenter# - radius# * COS(angle# * radian#)
                GRAPHIC LINE (xcenter#, ycenter#) - (x#, y#), linecolor&
                GRAPHIC REDRAW
                CONSOLE SET FOCUS
                IF INKEY$ <> "" THEN END
            NEXT
        LOOP
        GRAPHIC WINDOW END
    END FUNCTION

    Leave a comment:


  • Michael Mattias
    replied
    If your program is "doing something" after INKEY$ returns null ("it can't stop and wait...") and the performance is sluggish, your problem is NOT with your choice of INKEY$. You have something in your code which is taking too long to get back to that INKEY$ statement to check again.

    In this case, I'd say your design is , well, um, let's call it "non-optimal." You normally would not want to be drawing the screen a pixel at a time, because that WILL take forever.

    But....you can try testing INSTAT instead of using INKEY$. INSTAT just checks if there is a keystroke you can pick up without the need to actually return a null string into your variable.

    Also: if you are new to Windows programming, I will guarantee there is something you're not understanding about [multi]-threaded programs.. assuming we are in fact talking about the same thing.. that is, a program in which you are using the THREAD CREATE statement.




    MCM

    Leave a comment:


  • G Grant
    replied
    Well, it has to be on the fly, it can't stop and wait if no key has been pressed.

    I'm new to windows programming, so there's probably something that I'm not understanding about threaded programming.

    Leave a comment:


  • Guy Dombrowski
    replied
    Sluggish

    You should try WAITKEY$ instead

    Leave a comment:


  • G Grant
    started a topic INKEY$ and graphics

    INKEY$ and graphics

    I'm getting sluggish response from the keyboard with INKEY$ when using graphics commands.

    Even if all I do is simply plot random pixels, and nothing else, and check INKEY$ after each pixel to exit the program if a key is pressed, the response is very sluggish. The program will go through several more iterations of pixel plotting after pressing a key before exiting. And the longer I let the program run, the more sluggish the response. I'm making sure to use CONSOLE SET FOCUS before each INKEY$, in case the console loses focus due to a mouse click, but that makes no difference in responsiveness. And the REDRAW option doesn't seem to help here either. Not that it is needed for individual pixels, but with other, more complicated graphics, it speeds up the graphics drawing itself, but not the responsiveness of INKEY$.

    Does anyone have any suggestions on how to work around this? Is there a better way to get immediate keyboard response on the fly while working with graphics?

    Thanks very much.
Working...
X