2015 Holiday Demo Contest

[Iwantgames:)]

I'll look at it some more after work. I also saved tursi's compressed program and matts original to my PC so I can figure out how that works.

[+jedimatt42]

Hey games... I think you should VCHARs instead of HCHARs... You can eliminate a bunch of the repeated HCHARs because your graphic there has several vertical repeats of the FFFFFFFFFFFFFFFF character. VCHAR works just like HCHAR, but in THIS particular case, you can get some space economy out of using VCHAR instead of HCHAR.

 

Right now, if you changed HCHAR to VCHAR in 4, it would run precisely the same way. If you use VCHAR, you can get some repeats and save a bunch of data.

 

Just my $.02

 

If you are talking about Iwantgames:) 's Texas, then I agree, there are about 7 vertical streaks of '!' characters that could be drawn first, and then filled in around with all the detailed graphics. If you Alt-4 break the program, it becomes apparent when XB still shows the layout, but reverts the character set for programming. Also, 2 of those chunks could be filled in as 1 by letting the '&' and the '.' write over it later.

 

That very well may be more efficient than grouping by repeating character codes, because after you do those '!', the only character that repeats is the '#'

 

-M@

[Opry99er]

Yes... that is what I was referring to.

 

I believe it will be more than possible to drop it below the limit once repeating VCHARs and looped-DATA-read character definitions are implemented.

[Iwantgames:)]

I'm sure I can get it under 10. Looked at it again and moved some bits around and got it to 13 but I gotta get at least a couple hours of sleep before work so I'll look into compressing it further after work

[Opry99er]

Here's a new layout for the "Contributions" panel of the J Card... Since we're obviously going to use both sides of the tape, here's what I've got so far.

 

 

 

 

 

Thoughts??

Edited November 16, 2015 by Opry99er

[sometimes99er]

Santa's Boat Ride is there twice.

[Opry99er]

Ahh yes... I had moved it to Side A to fill the space and neglected to remove it from Side B.

 

Good eye.

[sometimes99er]

[Tursi]

I imagine this gets messy if any values of R are greater than 127, but both our cases don't have that issue.

Nope, that problem won't rear its head here because we don't actually have 8-bit values, we're just treating floats like them. So up to 256 is just fine. And you aren't restricted to bytes, either, you can use any multiplier that makes sense for your data.

[+Schmitzi]

When looking at the picture in Photobucket, do not try to right click and download the picture. You will get the problem you've identified, Schmitzi. Instead, click on the Gear Icon and then click the Download selection from the dropdown. Note that the only two permissions you have to give the site to view the pictures (using No Script in Firefox) are photobucket.com and pbsrc.com.

.

.

Yes, THIS works fine 4 me now (next pic from today came via photobuckle again)

Exactly as you mentioned: NOT rightklicking/saving the pic itself BUT using the dropdown-panel for downoad

 

thanks

[Opry99er]

If this pic doesnt get you in the Christmas spirit, nothing will...

[Opry99er]

Nice I have 0 programming skills so can't make anything but this is a cool holiday themed TI screensaver

 

Well? What the hell happened, man...

[Iwantgames:)]

Well? What the hell happened, man...

I learning man this contest gave me the push I needed to start learning some programming

[+jedimatt42]

So does anyone know what the actual line length limits are in XB?

 

There is the input buffer limit, that can then be exceeded by editing a line.

 

Then, it seems some lines hit there limit shorter than others, like it is encoding tokens into a byte code.

 

With 4 character numbers in a data statement, the line length limit seems to be about 115 characters. And with the little numbers it seems to be about 117 characters. This is commuter train math based on inaccurate inputs. So this seems to be mostly bound to line length. But it is raising my curiosity because the data lines are so much shorter than the code lines.

 

Has anyone dug out the details before?

 

-M@

[unhuman]

I think the limit has to do with the length of the line and the number of tokens on the line. So, you can sometimes shove in a command where text won't fit, etc... There used to be a shortcut for generating the tokens, which I used to use... Maybe it was like holding down FN-P to generate "PRINT" for example.

[Iwantgames:)]

So far I got it to 12 lines. Now to see how Tursi's compression works

 

Not too sure I understand this one

Edited November 17, 2015 by Iwantgames:)

[Tursi]

Yes, the main limit is the token limit. Typing the tokens directly isn't likely to get you longer lines. I don't know what the limit IS, mind, but you can keep it in mind if you're hitting limits. Every keyword and every piece of punctuation is a token, numbers are a token plus 8 bytes, variables cost a token plus a byte per character... there are certainly people here who know XB a LOT better than me, though. I just experimented by changing the lines and seeing how much XB would take.

 

Iwantgames: we're just packing the data by multiplying and dividing. It might be easier to explain using tens instead of 256's.

 

Imagine that your data is all less than ten, let's say you have the values 1,2,3,4,5,6. XB's token limit means that you run out of space in the line before you run out of numbers (not in this example, of course, but this is WHY we do the compression)... so it would be nice if the numbers were packed a bit.

 

Furthermore, let's assume for sake of argument that they are always read with "READ X,Y", that is, two at a time.

 

The maximum value of a number in XB is quite large... really big numbers run into accuracy issues, but we can easily go into the tens of thousands without problem.

 

Since we read two at a time, it would be very convenient to pack two numbers into one to get around that token limit -- that would allow twice as many numbers in a line. But how do we do it?

 

In this case, we notice that all the numbers are less than 10. So we can pack one digit into each position of a two-digit number. To do that, we multiply the first number by 10, and then add the second.

 

1*10+2 = 12, 3*10+4=34, 5*10+6=56 -- so our new data line becomes: 12,34,56

 

So how do we get the individual digits back? We just divide and subtract.

 

12/10 = 1.2. We don't want that decimal part, and INT will drop the decimal for us. So the first digit becomes INT(12/10), which is 1.

To get the second digit, we just need the remainder. XB doesn't provide a way to get the remainder nicely, but if we multiply the first digit back up and subtract, that will give it to us: 12 - (1*10) = 12 - 10 = 2.

 

So now we turn that into code - instead of "READ X,Y", we can say "READ N:=INT(N/10)::Y=N-X*10" - which is the encoding of the above sequence. This does take a fair number of tokens, but when you have enough data to compress it makes it worth while.

 

Now, the nice thing is you are not restricted to powers of 10, or byte values (like I arbitrarily used 256), you can use whatever number is big enough to hold your highest value. So instead of 10, you can use 256, or 128, or 32, or 90, whatever you like, as long as you both multiply and divide by that same value, and as long as it's bigger than the largest number in your set.

 

HTH!

[Tursi]

(Re-reading my message, one clarification -- it's still a byte limit, but tokens mean that the number of bytes a line uses is not the same as the number of characters you can see. Keywords are only one token, while things like variables may cost an extra tokenized byte you can't see).

[Iwantgames:)]

Ok I get it now. I'll see what I can do with my code after work

[unhuman]

I'd probably prefer my submission renamed for the official release. Perhaps just call it, "On Christmas." I'll rename it in my submission as well.

Edited November 17, 2015 by unhuman

[Opry99er]

Sounds good Howie.

[RXB]

Well this don't fit 10 lines but I made it anyways

 

1 CALL CLEAR::CALL SCREEN(2)::CALL CHAR(33,"FFFFFFFFFFFFFFFF",34,"000000000080C0E0",35,"FEFEFEFEFEFEFEFE",36,"C0E0F0F8FCFEFFFF")
2 CALL CHAR(37,"F8800000000080F8",38,"1F0100000000011F",48,"00007CFEFEFEFEFE",49,"003C7EFFFF7E3C00",50,"FEFEFEFEFEFEFEFE")
3 CALL CHAR(39,"0303030303030301",40,"80C0E0E0E0E0E0E0",41,"FF7F3F0703030101",51,"FEFEFE7C00000000",42,"E0E0E0E0E0E0E0E0")
4 CALL CHAR(43,"FF7F3E1C00000000",44,"FFFF7F3F1F0F0703",45,"000000000080C0FF",46,"FFFF7F3F1F1F3FFF",47,"E0E0E0E0C0800000")
5 CALL CHAR(56,"FF7F7F3F3F1F1F0F",57,"FFFEFCF8F0E0C080",58,"0F07070707030301",59,"FF7F7F3F3F1F1F0F",60,"FFFFFFFEFEFCFCFC")
6 CALL CHAR(61,"0F07070303010000",62,"F8F8FCFCFEFF7F00",100,"000028107C102800")
7 CALL HCHAR(5,14,33,2)::CALL HCHAR(6,14,33,2)::CALL HCHAR(6,16,34,1)::CALL HCHAR(7,14,33,2)::CALL HCHAR(7,16,35,1)
8 CALL HCHAR(7,17,48,1)::CALL HCHAR(7,18,33,2)::CALL HCHAR(7,20,36,1)::CALL HCHAR(6,17,49,1)::CALL HCHAR(8,14,33,2)
9 CALL HCHAR(8,16,37,1)::CALL HCHAR(8,18,38,1)::CALL HCHAR(8,17,50,1)::CALL HCHAR(8,19,33,2)::CALL HCHAR(9,12,39,1)
10 CALL HCHAR(9,13,33,3)::CALL HCHAR(9,16,35,1)::CALL HCHAR(9,17,50,1)::CALL HCHAR(9,18,33,3)::CALL HCHAR(9,21,40,1)
11 CALL HCHAR(10,13,41,1)::CALL HCHAR(10,14,33,2)::CALL HCHAR(10,16,35,1)::CALL HCHAR(10,17,51,1)::CALL HCHAR(10,18,33,3)
12 CALL HCHAR(10,21,42,1)::CALL HCHAR(11,14,43,1)::CALL HCHAR(11,15,44,1)::CALL HCHAR(11,16,33,1)::CALL HCHAR(11,17,45,1)
13 CALL HCHAR(11,18,46,1)::CALL HCHAR(11,19,33,2)::CALL HCHAR(11,21,47,1)::CALL HCHAR(12,16,56,1)::CALL HCHAR(12,17,33,3)
14 CALL HCHAR(12,20,57,1)::CALL HCHAR(13,16,58,1)::CALL HCHAR(13,17,33,2)::CALL HCHAR(13,19,57,1)::CALL HCHAR(14,17,59,1)
15 CALL HCHAR(14,18,60,1)::CALL HCHAR(15,17,61,1)::CALL HCHAR(15,18,62,1)::CALL COLOR(1,7,1,2,7,1,3,13,1,4,7,1,5,5,1)
16 CALL COLOR(6,5,1,7,5,1,8,5,1,10,16,1)::DISPLAY AT(18,30):"  HAPPY HOLIDAYS TO ALL MY"
17 DISPLAY AT(20,30):"      FELLOW TI USERS"
18 CALL SAY("HOW HOW HOW")::RANDOMIZE::FOR I=3 TO 28::SC=INT(RND*256)+1::VSPD=INT(RND*2)+5
19 CALL SPRITE(#I,100,16,1,SC,VSPD,0)::FOR DEL=1 TO 50::NEXT DEL::NEXT I
20 GOTO 20

RXB VERSION:

1 CALL CLEAR::CALL SCREEN(2)::CALL CHAR(33,"FFFFFFFFFFFFFFFF",34,"000000000080C0E0",35,"FEFEFEFEFEFEFEFE",36,"C0E0F0F8FCFEFFFF")
2 CALL CHAR(37,"F8800000000080F8",38,"1F0100000000011F",48,"00007CFEFEFEFEFE",49,"003C7EFFFF7E3C00",50,"FEFEFEFEFEFEFEFE")
3 CALL CHAR(39,"0303030303030301",40,"80C0E0E0E0E0E0E0",41,"FF7F3F0703030101",51,"FEFEFE7C00000000",42,"E0E0E0E0E0E0E0E0")
4 CALL CHAR(43,"FF7F3E1C00000000",44,"FFFF7F3F1F0F0703",45,"000000000080C0FF",46,"FFFF7F3F1F1F3FFF",47,"E0E0E0E0C0800000")
5 CALL CHAR(56,"FF7F7F3F3F1F1F0F",57,"FFFEFCF8F0E0C080",58,"0F07070707030301",59,"FF7F7F3F3F1F1F0F",60,"FFFFFFFEFEFCFCFC")
6 CALL CHAR(61,"0F07070303010000",62,"F8F8FCFCFEFF7F00",100,"000028107C102800")
7 CALL HCHAR(5,14,33,2,6,14,33,2,6,16,34,1,7,14,33,2,7,16,35,1)
8 CALL HCHAR(7,17,48,1,7,18,33,2,7,20,36,1,6,17,49,1,8,14,33,2)
9 CALL HCHAR(8,16,37,1,8,18,38,1,8,17,50,1,8,19,33,2,9,12,39,1)
10 CALL HCHAR(9,13,33,3,9,16,35,1,9,17,50,1,9,18,33,3,9,21,40,1)
11 CALL HCHAR(10,13,41,1,10,14,33,2,10,16,35,1,10,17,51,1,10,18,33,3)
12 CALL HCHAR(10,21,42,1,11,14,43,1,11,15,44,1,11,16,33,1,11,17,45,1)
13 CALL HCHAR(11,18,46,1,11,19,33,2,11,21,47,1,12,16,56,1,12,17,33,3)
14 CALL HCHAR(12,20,57,1,13,16,58,1,13,17,33,2,13,19,57,1,14,17,59,1)
15 CALL HCHAR(14,18,60,1,15,17,61,1,15,18,62,1):: CALL COLOR(1,7,1,2,7,1,3,13,1,4,7,1,5,5,1)
16 CALL COLOR(6,5,1,7,5,1,8,5,1,10,16,1):: CALL HPUT(18,32,"  HAPPY HOLIDAYS TO ALL MY",20,32,"      FELLOW TI USERS")
17 !
18 CALL SAY("HOW HOW HOW")::RANDOMIZE::FOR I=3 TO 28::SC=INT(RND*256)+1::VSPD=INT(RND*2)+5
19 CALL SPRITE(#I,100,16,1,SC,VSPD,0)::FOR DL=1 TO 50::NEXT DL::NEXT I
20 GOTO 20

[Iwantgames:)]

Ok still trying to figure this out. How do I make it read 3 numbers to make HCHAR(R,C,V)?

[+jedimatt42]

Ok still trying to figure this out. How do I make it read 3 numbers to make HCHAR(R,C,V)?

 

You could just encode the R,C together and read a second value for the character code V.

 

If R=24, C=32 & V = 65, you could use 33 as the shifting factor ( the largest value of either R or C + 1 ), and get (24*33)+32=824.. and then a second value of V... So

DATA 824,65

 

which you would read back as:

READ N,V::R=INT(N/33)::C=N-(R*33), then CALL HCHAR(R,C,V)

 

you could also double pack if the numbers all fit....

 

If R=24, C=32 & V=65, pack R & C as above, to get 824, then use another shifting factor that is again your largest value of V + 1 (I'll use 101 since I thought I saw 100 in the code somewhere)

So, R&C encoded is 824, shifted ( 824 * 101 ) = 83224, then add V. where if V is 65, the 3 values encoded together are:

DATA 83289

 

That's one less character in the code ( the comma for the two is gone ) I'm not sure if that extra effort will make a difference or not depends on how much you save, you'll have to trade it for extra decoding:

READ N::L=INT(N/101)::V=N-(L*101)::R=INT(L/33)::C=L-(R*33)

 

For data values like this,

With packing results like DATA 83289, you can get a DATA statement with 19*3=57 items in it. Or 19 sets of CALL HCHAR triplets per line.

With packing results like DATA 824,65 you can get a DATA statement with 14*(2+1)=42 items in it. Or 14 sets of CALL HCHAR triplets per line.

 

I've typed in lines like DATA 84000,84000,84000,84000.... and get 19 values in before line to long. and DATA 840,65,840,65... to compare the other.

 

I'm really supposed to be making a presentation for work... Why is reasoning this out so much fun?

 

One more thought. You can make things even smaller if you examine the data set instead of generalizing. like for R & C we know they are rows and column coordinates, so you can use 33 as a factor, since the max column value is 32. But... you can kick it into crazy if you encode a position in a range with a base offset... For instance, if your actual max( R, C ) is 25, and your actual min( R, C ) is 12, you could consider all the coordinates in a range from 1 to 13. so you could use a factor of 14, but have to add the base (in my example the 12) in during decoding. I'm probably off by one somewhere here, I'll have to try it out... Anyway, if you make your numbers smaller, you can get more on a DATA line too. This might work particularly well for the ascii codes, so a much smaller factor can be used when shifting the encoded R&C value over.

[Iwantgames:)]

Hmm ok thanks I'll have to try again tomorrow evening as its almost 1am :/