User Tag List

Results 1 to 6 of 6

Thread: joystick code

  1. #1
    Administrator DarkDragon's Avatar
    Join Date
    Oct 2001
    Posts
    6,228
    Mentioned
    70 Post(s)
    Tagged
    0 Thread(s)
    vBActivity - Stats
    Points
    11,025
    Level
    31
    vBActivity - Bars
    Lv. Percent
    8.16%

    joystick code

    What is this block supposed to do in zc_sys.cpp:

    Code:
    bool b[joy[joystick_index].num_buttons+1];
        
    for(int i=1; i<=joy[joystick_index].num_buttons; i++)
        b[i]=joybtn(i);
    First, this is not legal C++ since the array size is not a constant expression.

    Second, it seems like the block is dead code anyway since b is never read anywhere later in the function.

  2. #2
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    What I want to know is how the compiler can figure out what to do with that when it's not allowed to optimize it away. -_` ...Does it still compile if you add the volatile keyword?

    As far as the code goes, I have no idea. Just rip it off like a smelly band-aid. :) Actually, I hate all the joystick code in ZC. If porting ever goes somewhere I volunteer to rewrite it.


    [edit]
    Ah wait a minute - variable length arrays in c++! Cool. Saffith: What compiler are you using?
    Last edited by Gleeok; 12-22-2016 at 09:24 AM.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

  3. #3
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Gleeok View Post
    What I want to know is how the compiler can figure out what to do with that when it's not allowed to optimize it away. -_` ...Does it still compile if you add the volatile keyword?

    As far as the code goes, I have no idea. Just rip it off like a smelly band-aid. :) Actually, I hate all the joystick code in ZC. If porting ever goes somewhere I volunteer to rewrite it.


    [edit]
    Ah wait a minute - variable length arrays in c++! Cool. Saffith: What compiler are you using?
    He's using gcc via MSYS/MinGW. Same as me, now.
    @DarkDragon There's plenty of unused rubbish floating in there. I believe that variable-length arrays are legal in some C++ standards. They are defined in C99, for instance, and IIRC some extensions supported them for a while (?).

  4. #4
    Is this the end?
    ZC Developer
    Saffith's Avatar
    Join Date
    Jan 2001
    Age
    41
    Posts
    3,389
    Mentioned
    178 Post(s)
    Tagged
    6 Thread(s)
    vBActivity - Stats
    Points
    6,430
    Level
    24
    vBActivity - Bars
    Lv. Percent
    69.57%
    Could've sworn VLAs were allowed by the standard, but, yeah, seems to be compiler-specific. Maybe better not to do that, then. I've only tried it on GCC on Linux.
    There are two or three arrays like that. They used to be fixed-size, but they were too small, and I found lots of buttons not responding. I didn't really look at what the code was doing beyond the array size.

  5. #5
    The Timelord
    QDB Manager
    ZC Developer

    Join Date
    Oct 2006
    Location
    Prydon Academy
    Posts
    1,396
    Mentioned
    112 Post(s)
    Tagged
    1 Thread(s)
    vBActivity - Stats
    Points
    4,760
    Level
    21
    vBActivity - Bars
    Lv. Percent
    68.7%
    Quote Originally Posted by Saffith View Post
    Could've sworn VLAs were allowed by the standard, but, yeah, seems to be compiler-specific. Maybe better not to do that, then. I've only tried it on GCC on Linux.
    There are two or three arrays like that. They used to be fixed-size, but they were too small, and I found lots of buttons not responding. I didn't really look at what the code was doing beyond the array size.
    Well, does VC2015+ not support it? All recent builds of gcc should. How about code::blocks?

    It's probably goin to be supported more readily in coming years, so maybe adding some compiler definitions could work, too, but IDK. It depends how important it is.

    I read up on this three years back, as it was something that I wanted to be able to do. (In fact, I'd love to add variable-sized arrays to the scripting language, as it's very useful, IMO.)
    @Gleeok : I would be willing to help, if I can. I wanted to add some other joystick code to 2.54 anyway. I think our present input support leaves much room for improvement, new back end, or otherwise.

  6. #6
    The Time-Loop Continues ZC Developer
    Gleeok's Avatar
    Join Date
    Apr 2007
    Posts
    4,815
    Mentioned
    259 Post(s)
    Tagged
    10 Thread(s)
    vBActivity - Stats
    Points
    12,933
    Level
    33
    vBActivity - Bars
    Lv. Percent
    23.44%
    VLA's in general were considered to be a bad idea in C99, and the itty-bitty-shitty-commitee for c++ only seems to care about non core language things, templates, stl crap; they would never put in something as type-unsafe as VLAs.

    I took about 20 minutes today to try and improve upon VLAs and alloca(), and came up with this:

    Code:
    void Proc() {
      LOCAL_STACK(4000); // No way to emit this without compiler support.
    
      Foo* foo = stackalloc Foo();
      Bar* bar = stackalloc Bar[64];
      u8* buffer = (u8*)stackalloca(MEGABYTES(8)); // Perfectly safe! Fall back to backing allocator.
    
      //cleanup if any
    }
    The coolest thing is actually stuff like this though;
    Code:
    StackArray<char*> ScanDirectory(const char* path)
    {
      StackArray<char*> filenames;
      //get all the files in the directory without allocating memory
    
      return filenames; //no local sp, does not reset from scope.  // no deep copy
    }
    Which (to me at least) is better and safer than VLAs and alloca(). Of course I'd have to benchmark this in actual code, but I suspect it's only 4 asm instructions overhead over the fixed "char buf[2048]" approach.
    Last edited by Gleeok; 12-22-2016 at 10:34 PM.
    This post contains the official Gleeok seal of approval. Look for these and other posts in an area near you.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
About us
Armageddon Games is a game development group founded in 1997. We are extremely passionate about our work and our inspirations are mostly drawn from games of the 8-bit and 16-bit era.
Social