ZC 2.5 RC 2.5 (Windows)
#166
Posted 22 February 2012 - 11:24 PM
#167
Posted 22 February 2012 - 11:39 PM
#168
Posted 24 February 2012 - 12:17 AM
This has been an issue for the longest time (2.11?), but one thing I've noticed is that the "cool entrance/exit wipes" are using a Super Mario All-Stars wipe that was probably meant to be a test of this:
http://img487.images...nsitions8uf.gif
That's an old GIF by Dark Nation that I saved for some bizarre reason (I lost the TI-83 mockup, which makes me sad). The first circle wipe in the GIF is the effect that has been with ZC up until 2.11. Is there any chance that the circle opening can be restored and maybe the other wipes (if they still exist/ever existed) could be some sort of setting?
Edited by Nick, 24 February 2012 - 12:31 AM.
#169
Posted 24 February 2012 - 02:44 PM
I added in separate rules for all four. Enable more than one rule, and it'll pick a wipe at random each time.
#170
Posted 24 February 2012 - 04:43 PM
Both fail miserably. The app crashes and burns, actually. Some log or another babbles about a failure in setting the resolution.
#171
Posted 24 February 2012 - 04:59 PM
#172
Posted 26 February 2012 - 02:13 PM
#173
Posted 26 February 2012 - 02:35 PM
If you don't declare a size, it'll use the smallest size possible for the given initializer. I suppose it's probably possible to initialize it with more than 214747 elements, but you still couldn't access the higher indices.
#174
Posted 26 February 2012 - 02:44 PM
They're implemented as vectors, so the limiting factor is the largest number the compiler can handle, which is 214747.
If you don't declare a size, it'll use the smallest size possible for the given initializer. I suppose it's probably possible to initialize it with more than 214747 elements, but you still couldn't access the higher indices.
Is there any way to have a globally accessible array without it being saved when the player saves the game? I've been declaring arrays locally and passing them as arguments to functions to avoid the issue but sometimes it'd be nice to have access to a global without increasing the save file size and read/write time. Of course, if there is no way to do this don't delay RC 3 to add it - I can live with the way it is now. [ I want RC 3 to be released in case you couldn't tell ]
#175
Posted 26 February 2012 - 02:45 PM
#176
Posted 26 February 2012 - 02:52 PM
If you don't declare a size, it'll use the smallest size possible for the given initializer. I suppose it's probably possible to initialize it with more than 214747 elements, but you still couldn't access the higher indices.
That doesn't appear to be the case, at least with strings.
I initialized strings like the example above assuming that the length of the array would be the length of the string, but using the string copy function in string.zh, it lagged horrendously. When I manually set the size of the array to a number... say... 15, it didn't lag. The only explanation for this would be that it used a size much greater than necessary.
#177
Posted 26 February 2012 - 03:03 PM
#178
Posted 26 February 2012 - 03:12 PM
Basically, to describe my setup, I'm creating a menu with around 8 items. However, due to various reasons, what I needed to do was have a global array for a string. A function would go in, clear out the global string, then copy one of the strings to the global string for printing. This would happen 8 times per frame.
Again, the more I think about it, maybe the printing is what's causing the problem.
#179
Posted 26 February 2012 - 03:17 PM
Oh, sorry, missed this before.
It looks that way, but it's not. The constant named MAX_ZCARRAY_SIZE is really used for the number of arrays.
Actually, I'm looking at it now, and it looks like global and local arrays are stored separately, so I think it's really 4096 of each.
#180
Posted 26 February 2012 - 03:35 PM
The same thing would be true there, though... I tried a few things, and, as far as I can see, the size is set correctly. Is it possible you had an array somewhere that was too small, and the null terminator got cut off? That would certainly cause some issues.
Ah. Yeah. I went back and did a test. Apparently what I must have been doing was copying string A with no manually set size to string B with a manually set size that was too small (it was 1 under, actually). When this happens, apparently ZScript still functions, but it lags terribly for whatever reason.
Sorry for the confusion. I wasn't paying attention to the size of the string.
Edit: Also, you're correct. I have hit issues where if the source string is exactly the same size as the array, it locks up ZC completely. Say int x[2] = "hi" for example. I'm gussing x[] = "hi" actually saves 3 characters. 'h', 'i', and a null character.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users