PDA

View Full Version : joystick code



DarkDragon
12-22-2016, 05:53 AM
What is this block supposed to do in zc_sys.cpp:



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.

Gleeok
12-22-2016, 07:25 AM
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?

ZoriaRPG
12-22-2016, 11:09 AM
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 (?).

Saffith
12-22-2016, 11:35 AM
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.

ZoriaRPG
12-22-2016, 12:48 PM
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.

Gleeok
12-22-2016, 10:16 PM
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:



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;


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.