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.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.