Time limit above 999, random characters in timer

[1033Forest]

Tried this time limit for myself. 26xx shows a broken SSD and 25xx shows some random colored...dont know what that is

[James]

It sounds like you've got a working copy of MSCC now, but I've still finished the following write-up to document some of the pecularities of the behaviour anyways. (By the way, CCDesign will let you put time limits up to 65,535.)

I've uploaded the game's internal digit graphic file (200.bmp) to my site as a reference: (click) As a reminder to those who perhaps aren't as familiar with MSCC, the game normally uses the green digits; the yellow digits are only used when the game is switched into black and white mode in the options menu (or when there are 15 seconds or less on the clock). The digits are numbered 0-23, starting from the bottom.

As I mentioned earlier, the clock will display differently depending on whether the time is between 1000-2399, 2400-3499, 3500-32767, or 32768-65535. (In fact, the level number display and the chips required display will operate under these rules too, but those are far less relevant.)

From 1000-2399 the timer is still somewhat normal and regular, since the game can still use that digit graphic file without problems. The game will display the ones' digit and the tens' digit normally, then it will naively assume the number can be displayed in three digits and it will attempt to find the appropriate "hundreds' digit" to display. As an example, the game will interpret 1300 as having a "hundreds' digit" of 13, and so it will look for the graphic representing "13" to display in the hundreds' place on the clock. Since digit #13 in the graphics file is the yellow 1, the game will display 1300 as [yellow 1][0][0]. After one second the clock will tick down to 1299 ([yellow 0][9][9]]) and it will tick all the way down to 0 as you would expect.

Note 1: Normally, the tens' digit will always display its proper 0-9 regardless of what is going on with the hundreds' digit. However, there is one exception. When a time is between 1000-1009 - corresponding to a hundreds' digit of 10, which is an unlit green 7-segment "blank" display - the tens' digit will also turn into an unlit green 7-segment display. (e.g. 1005 is displayed as [blank][blank][5] instead of [blank][0][5] as you would expect.) This does not occur with the unlit yellow 7-segment display (from 2100-2109) nor does it occur at any other multiple of 1000. The blank tens' digit seems to only occur between 1000-1009.

Note 2: it looks like the game handles turning the colour off by simply adding 12 to every digit internally, since that's the distance between a green digit and its corresponding yellow digit on the digit graphics file. (So when you select SPECIAL in CC1 and turn the colour off, the 999 time limit turns yellow because the game is actually now thinking [21][21][21], and the 21st digit in the digit graphics file is the yellow 9.) A consequence of this design choice is that the colour time display and the black and white time display will actually become "desynchronized" once the game can no longer use the digit graphics file, since the +12 to the "hundreds' digit" no longer means anything after that point. (This occurs at time limits of 1200+, which correspond to the game attempting to display 2400+ in black and white.)

From 2400-3499 the timer starts to freak out a bit. 23 is the last digit in the graphics file, and beyond that the game starts inventing new graphics every 100 seconds in an attempt to display *something* in the hundreds' digit spot, and...well, I don't even know what the game is doing at this point. It looks like the game is still trying to read the graphics digit file, but it has no idea how; sometimes it will display garbled and unintelligible mash-ups of multiple digits, and sometimes it will display a random section of the digit graphic that is usually horizontally off-centre and without any vertical alignment to a specific digit. However, this behaviour is still consistent (with a few exceptions); if you become familiar with the new "digits", you can still read the clock and know exactly how much time is left.

Note 3a: The "25 digit" isn't even a digit at all, it's just a chameleon that takes on the appearance of whatever was last displayed as the hundreds' digit. (If you beat a level with 300 seconds left on the clock and the next level has a 25xx time limit, that time will display as 3xx until it ticks down to 24xx. If you play the level for a while and restart with 2100 seconds left, the time will now display as [21 digit]xx until it ticks down to 24xx, and so on.) This behaviour reminds me a lot of the <combination>/overlay buffer tile in the game itself, which acts like a wall but appears like whatever transparent tile combination the game last had to draw. (Play EvanD1.dat level 125 or pi-rejects.dat level 2 in MSCC to see how that works in practice if you haven't seen it.) Since the <combination> tile isn't meant to be an actual "tile" for placement in levels but is actually used internally by the game to draw things correctly, it's possible that the "25 digit" serves a similar purpose. However, it's also possible that I'm reading *way* too much into it and that the "25 digit" is simply nothing at all and so the game just doesn't even update the visual displays. (Or maybe it does exist in an abstract sense, but it's undrawable? I don't know.)

Note 3b: If you open CHIPS.exe to a level with a 25xx time limit - so there is no "previous hundreds' digit" - the "25 digit" will simply display as the green empty 7-segment display, which seems to suggest that this is its initial state. However, if you drag another window - or an in-game dialog box like Best Times, Go To..., Level Complete, etc. - over top of a "25 digit", the obscured portion of the "25 digit" will be pitch-black when you move the window away. This effect will stay on the screen until the next non-25xx time limit is displayed. (It's worth nothing that you actually do need to drag it across to create the effect. For example, if the Go To... menu pops up over top of the time display, the effect will not occur. However, if you drag that window away and then drag it right back over top of the display, the effect will now occur. You can also trigger this effect by beating a level immediately before one with a 25xx time limit, and making sure the score window is over top of the time display as you hit the "Onwards!" button.)

Note 3c: It appears that the level number, time limit, and chip counter displays all handle 25 digits independently of each other. (e.g. If you're playing level 1250 with time limit --- and a chips remaining of 350, and switch to level 2500 with time limit 2500 and chips remaining 2500, the displays will read 1200/-00/300. "25 digits" don't transfer across displays.) Notes 3b and 3c seem to strongly support the idea that the game doesn't update the displays at all rather than the "25 digit" being some sort of <combination>-type thing. (Though that idea was much cooler.)

Note 4: 30xx and 34xx appear to be highly volatile; they are different every time you open the game. They can even change during the course of a level (!) if you turn the colour off and on again. (You're far more likely to see a change if you swap the sound effects off and on again as well as the colour. I have no idea why any of this stuff happens.)

From 3500-32767 the game stops coming up with new "graphics" every 100 seconds and instead just repeats the same hundreds' digit for this entire range. (It looks just like the one for 31xx, just horizontally shifted by a tiny bit.) The timer is still functional in this range, but you have no way of knowing exactly what the time is anymore while playing beyond "somewhere above 3500".

From 32768-65535 the hundreds' digit is the same as the previous range but the tens' and ones' digits turn yellow (even if the colour is on) and the game no longer ticks down the timer; it's stuck at its original value forever and the level is effectively untimed. (Ditto for the chip counter. Level numbers above 32767 appear unplayable in MSCC in any form - though I need to do a little bit more research on this - but presumably they would also display in the same manner.) Despite the timer being completely broken, you will still get the correct amount of time bonus points when you solve the level. (However, time bonus points roll over at 32768 to -32767, and so the "correct amount" may not be what you think it is.)

Coming soon: a video featuring all of these things as well as bonus material which I discovered during the course of investigating this stuff (three Chips stacked on top of each other; a timed level which is solvable at any time you wish, but on which it is impossible to achieve any level or time bonus points at all; experimentation with how MSCC hates levels numbered 10000+.)

[M11k4]

Wow James you really did do a lot of work on this! ...only to find out stuff EVERYONE already knows, right?

Thanks for the interesting and useless info
Can't wait to see the video.

[1033Forest]

Even with this, I plan to include very few levels with 1000+ time limits in my set, there will be a hint on how much time there actually is in these levels.

I also wonder if Tile World can handle 32767+ time limits, since it's a 32 bit application. Maybe even over 65535.

[H2O]

2¹⁶ = 65536

2³² = 4294967296

[Eric119]

From 32768-65535 the hundreds' digit is the same as the previous range but the tens' and ones' digits turn yellow (even if the colour is on) and the game no longer ticks down the timer; it's stuck at its original value forever and the level is effectively untimed. (Ditto for the chip counter. Level numbers above 32767 appear unplayable in MSCC in any form - though I need to do a little bit more research on this - but presumably they would also display in the same manner.) Despite the timer being completely broken, you will still get the correct amount of time bonus points when you solve the level. (However, time bonus points roll over at 32768 to -32767, and so the "correct amount" may not be what you think it is.)
display and the chips required display will operate under these rules too, but those are far less relevant.)

The conclusion from this of course is that MSCC is using signed 16-bit quantities. So there is no range 32768-65535, and you can't set a time limit greater than 32767. Rather, you are setting a negative time limit.

[James]

The conclusion from this of course is that MSCC is using signed 16-bit quantities. So there is no range 32768-65535, and you can't set a time limit greater than 32767. Rather, you are setting a negative time limit.

It doesn't always, though. Time bonus is the only signed 16-bit integer on the score screen; level bonus, level score, and overall score are all 32-bit and allow up to 2.1b before rolling over to -2.1b.

There are several things that lead me to believe the time limit is not stored as a signed 16-bit integer:

* when you set a time limit or chip counter of 32768+, the last two digits still display properly (e.g. 32775 displays as [garbled][7][5])

* I was a bit ambiguous above; it is the time bonus points that overflow, which starts as early as time=3277. (since 32770 > 32767) It is not unique to time limits above 32768, and in fact there is no discontinuity between the time bonus points at time=32767 (-10) and time=32768 (0).

* when you reset (4,32) or (5,32) - which store the initial time limit of the level - the new data on the bottom layer of (4,0) and (5,0) is consistent with an unsigned 16-bit integer going up to 65535 rather than a signed one that wraps to -32768. (At time=32767, (4,0) will contain 255 and (5,0) will contain 127. At time=32768, (4,0) will contain 0 and (5,0) will contain 128.)

[The Architect]

I also wonder if Tile World can handle 32767+ time limits, since it's a 32 bit application. Maybe even over 65535.

Theoretically it could, but there is no way to encode a 32-bit time limit in a CCL file.

[random 8]

Signed and unsigned integers have the same bit representations; the difference is how the bits are interpreted (see https://en.wikipedia.org/wiki/Two's_complement).

I think the variable that stores the time limit is designated as a signed integer since time limits past 32767 are frozen, but the code that handles the timer display is looking at the bits directly to determine the last two digits.

[James]

2 (Two; /ˈtuː/ (About this sound listen)) is a number, numeral, and glyph. It is the natural number following 1 and preceding 3.

(Your Wikipedia link is broken )

Yeah, that sounds about right. That would also explain the (4,32) and (5,32) results.