00:00:01 that'd be very neat 00:00:07 but i want spiral adressing in it 00:00:11 :9 00:00:16 %) 00:00:26 spiral addressing? 00:00:53 scroll up 00:00:59 to the line FEDCB 00:01:33 let's see.. perhaps there should be some instruction stack, or where else the program would take the coordinates of x1,y1,width1,height1 copy that, paste to x2,y2..? 00:01:56 hmm 00:02:08 Keymaker: you adress one pixel and it takes the info from 4 pixels next to that pixel 00:02:21 and the one pixel is adressed using SpiralAdressing(tm)^^ 00:02:22 yes, that's one way 00:02:28 :) 00:02:51 perhaps better than instruction stack 00:03:05 nice if all data is stored in the image 00:03:09 yes 00:03:15 jix is right on this one 00:03:33 as well, i think that the next pixels should be taken from the direction the data pointer is moving 00:03:48 yes. 00:03:57 :) 00:04:09 and the datapointer could have a flag which says "move in a spiral" 00:04:37 if you really want to use the data pointer, then.. :) 00:04:53 perhaps it's best to have data pointer AND instruction pointer 00:05:12 oh, I meant instruction pointer 00:05:18 ah 00:05:18 do we need both? 00:05:23 i don't think so 00:05:43 how about the IP being a function (which can be redefined) 00:05:55 then it could move in many different ways 00:05:59 kipple: another language... imho 00:06:04 yeah 00:06:09 just an idea 00:06:11 ok 00:06:20 but about the instruction pointer.. 00:06:29 do we need the data pointer 00:06:35 or just IP and self-modifying 00:06:37 no 00:07:07 since the data is stored in the same pixel as the instruction I don't think you need a data pointer 00:07:13 yes 00:07:17 me neither 00:07:24 so, just IP and selfmod 00:07:30 agree. 00:07:38 but then, the spiral movement 00:07:47 should the ip move spirally? 00:07:54 no ip moves linear 00:07:58 ok 00:07:58 but adressing is spiral 00:08:04 but.. 00:08:12 like, indirect addressing? 00:08:15 like add_a_to_cell_at_adress_b 1 2 00:08:30 oic 00:08:31 which fits perfectly into rgb 00:08:41 adressing is spiral and relative to ip 00:09:05 what that 'adressing' means 00:09:07 ? 00:09:44 do you mean by that reading the values near the ip that are needed for example copying piece of canvas? 00:09:59 yes 00:10:02 ok 00:10:12 and you can do nothing if you can only access the current cell 00:10:18 if the IP is at 0 then the addresses for other pixels is: 00:10:19 6789 00:10:20 501A 00:10:20 432B 00:10:20 FECD 00:10:24 am I right? 00:10:27 yes 00:10:32 i did it CCW but CW is ok too 00:12:55 gonna be difficult to program ... 00:13:30 hmm 00:13:59 not sure if it's right for this lang (though I like the idea) 00:14:08 yeah 00:14:48 it's naturally possible that we make separate languages, as i've mentioned 00:15:12 the more non-textual langs the better ;) 00:18:48 cool, started on my spec then too :) 00:18:56 ok 00:19:04 I would appreciate help with SDL, though.. any guides for that? 00:19:07 i'll keep my version simple 00:19:16 calamari: sorry, nope 00:19:33 i'll have a bit hard time coding things up 00:19:45 how did you learn it? 00:19:52 me? 00:19:53 long hours of man pages ? 00:20:00 i can't do almost nothing at all in it 00:20:03 yeah 00:20:06 oic 00:20:11 i can try to send you some small codes tomorrow 00:20:15 if i have anything left 00:20:23 like simple drawing things 00:20:37 although i don't have single pixel drawing stuff.. 00:21:15 haven't really found good manuals, i've got info from here and there around the web, and haven't program almost anything, just tests, nothing game-like or something 00:21:18 that's okay. I might as well try to figure it out :) 00:21:24 ok 00:21:50 anyways, good luck with your language gentlemen 00:22:10 kipple: do you want to cooperative work with me or design own? 00:22:23 i think we were on same thought patterns, so.. 00:23:43 I'm not going to make my own , no 00:24:27 can help with yours if you want 00:24:34 sure! 00:24:44 i'll e-mail to your e-mail address, 00:24:49 the one that is on your page 00:25:05 my page is down :) 00:25:16 is slartibartfast alive? 00:25:29 yes, but my router won't cooperate 00:25:33 ok.. 00:25:42 well, then can you tell here what the address is? 00:25:49 or open that new window and tell 00:25:51 rune@krokodille.com 00:25:53 ok 00:26:27 it'll be interesting to see what kind of languages people make up 00:26:33 anyway, maybe we should make a page under Works in Progress in the wiki 00:26:51 sure 00:26:53 but.. 00:26:56 what name?! 00:27:14 lets just pick a temporary one 00:27:25 ok.. Temporary One 00:27:41 and the final could be TT - Temporary Two. 00:27:42 ;) 00:27:43 "Codename: RGB" 00:27:47 or Three. 00:27:51 :) 00:27:53 lol 00:27:57 codename: rgb 00:28:01 that's fine! 00:28:23 do you make the article? 00:28:31 what happens if two people edit the same article at the same time? 00:28:33 ok 00:30:19 http://esoteric.voxelperfect.net/wiki/Codename:_RGB 00:30:34 ok :) 00:31:07 so, what do we have so far? 00:31:20 let's see: 00:31:24 infinite canvas 00:31:34 where the program will be placed on left top corner 00:31:44 (i accidentally said 'right' sometime ago) 00:32:27 the other canvas is filled with zeroes or something 00:32:34 zero is fine 00:32:38 ok 00:32:42 not important 00:32:47 yeah 00:32:51 how about pink? 00:32:58 not bad 00:32:59 ;) 00:33:08 often used as 'transparent colour' 00:33:28 anyways; then we have instruction pointer 00:33:47 that moves linerally 00:33:56 to befunge-like directions 00:34:06 i'd be fine with the four directions 00:34:12 yes 00:34:16 ok 00:34:37 then, we have each pixel that have rgb value, where r is some instruction 00:34:43 and g and b data 00:34:49 each of them naturally being 8-bit 00:35:54 what do you think: if there's some instruction (like that copy-paste) that needs more arguments than two, it should take them from the next pixels, from the direction the ip is moving 00:36:08 yes 00:36:13 that's the easiest way 00:36:15 then, if there's only two arguments, should the instruction take them from g and b? 00:36:35 I would say that can be different in each instruction 00:36:43 yeah 00:36:50 what about returning values? 00:37:01 do we need that? 00:37:04 hmmm 00:37:10 i meant like input 00:37:13 from a file 00:37:20 hmm 00:37:28 probably should save to g and b 00:37:34 and if eof, make g 1 00:37:36 or something 00:37:40 while it usually is 0 00:37:55 fill unused space with random data 00:37:59 eof thing could be useful, i think 00:38:04 that makes nondeterministic programs possible 00:38:08 like number guessing game 00:38:19 jix: that was one of my ideas many lines ago :) 00:38:24 oh 00:38:39 but i was talking about the empty canvas 00:38:44 not sure if you mean the same 00:38:45 why not have a separate random function? we have 256 instructions possible 00:38:49 yes 00:38:55 that should be there too 00:38:58 probably 00:39:02 most probably! 00:39:04 yeah 00:39:18 anyways; what do you think about that eof kipple? 00:39:32 which one? 00:39:47 that something like setting g to 1 in case of eof or something 00:39:55 sounds good 00:40:06 yeah, something like that would be useful 00:40:26 by the way, what should happen if the ip moves to top edge or left edge? 00:40:32 program crash? 00:40:39 it could be infinite in all directions 00:40:45 mmh 00:40:47 yes 00:41:21 aargh 00:41:27 this stuff really eats memory 00:41:45 like 5000x5000 canvas with 3 values for every pixel.. 00:41:47 * Keymaker dies 00:41:55 You waaanto to use RXML for input :) 00:42:00 waaant to even 00:42:04 the canvas should be allocated dynamically as needed 00:42:17 well, yeah, but i can't program that :) 00:42:36 just resize the image when needed. is that difficult? 00:42:57 hmm not sure 00:43:20 anyway, lets not go into implementation details at this point :) 00:43:28 yeah 00:43:31 Such as using RXML as input :) 00:43:36 :P 00:43:39 what's RXML? 00:43:46 http://www.codu.org/rxml.php 00:44:02 Raster imaging in XML. Mind-bogglingly stupid is what it is 8-D 00:44:03 i was already guessing it was some gregorr's stuff.. 00:44:10 Keymaker: what's 100 MB among friends? 00:44:11 ah, yes that one 00:44:24 :) 00:44:41 oh! 00:44:47 XML! I like. 00:45:01 * int-e pukes somewhere behind the scenes. 00:45:06 Heheheh 00:45:21 as a sidenote; the hats gallery still needs updating! 00:45:33 I know, I know XD 00:45:50 Gregor = lazy :P 00:45:56 :) 00:46:16 lets make some instructions! 00:46:21 mm ok 00:46:30 we need a put value to pixel (x,y) 00:46:36 yeah 00:46:41 as well, 00:46:53 should it be (x,y,r g or b) 00:47:08 or only that it changes b automatically? 00:47:13 or r or g 00:47:20 yay, the converter uses DOM ... read the whole document, then convert it, then write it. 00:47:24 * int-e is sooooooo happy. 00:48:17 a problem is that x and y can larger than 8bits 00:48:30 hmm 00:48:32 can _be_ larger... 00:48:36 yah 00:48:54 never thought about that before.. 00:49:25 so x and y should perhaps be relative to current IP position 00:49:31 yes 00:49:35 that's one good way 00:49:55 yeah, i think that's the best 00:50:36 [...] properly indented of course. This is great stuff. 00:51:06 how about this: the g is the value to be put, and b determines if the value goes to the r,g or b component 00:51:09 Could int-e be raising some sort of sarcastic defiance against RXML? :P 00:51:12 note that this format is easily extensible to include alpha and octarine channels. 00:51:27 the coords taken from the next pixel 00:51:31 yeah 00:51:33 no. RXML is a great example why XML should *not* be blindly used. 00:51:52 NO!!!! XML IS ALWAYS BETTER!!!!! BUZZWORD = GOOD!!!! 00:51:59 hmm, by the way 00:52:06 See, that's what I'm defiant against. 00:52:08 :) 00:52:18 what about negative values? 00:52:31 yes. that's a problem 00:52:34 should the values go backwards if value is bigger than 128 or something? 00:52:42 Keymaker: You know, you would have an extra data byte if you used alpha. 00:52:45 yes. the bytes could be signed 00:52:52 yes, we know 00:53:17 int-e: At OSCON, somebody presented (as part of their larger presentation) a convertor to write perl as XML, and an environment to run it. 00:53:48 we need XMLBrainfuck! 00:53:50 GregorR: You see I'm old-fashioned. If data is transfered in a verbose format like XML, compressed with gzip, I raise the question why they added that redundancy in the first place and didn't use a custom binary format. 00:53:53 hehe 00:54:07 int-e: Oh so true. 00:54:18 kipple: XML will fuck your brain enough without Brainfuck support ;) 00:54:33 double negative is positive! 00:54:37 Oh. I see something coming 00:54:44 :D 00:54:58 00:55:32 too concise, I'll admit, but it's a start. 00:55:33 + 00:55:44 :D 00:56:11 hmm, is --> valid? 00:56:26 err it'd be wouldn't it 00:57:01 kipple: we need to invent some logical way the next cells are checked; i mean that it's strange if sometimes the values are taken from the pixel where the instruction is, sometimes from the four next pixels etc.. 00:57:01 back to RGB: how about put taking coords from the two next pixels. the first pixel would be negative, and the second positive 00:57:32 hmm 00:58:38 or another way could be that it checks if pixel1's g is 0, then b's value will be positive direction, else if it's 1 or something, then b's direction will be negative 00:58:47 pixel1 being the x coordinate 00:58:52 and the same for pixel2 00:59:11 the g being 0 or 1 determining the direction (backwards or forwards) 00:59:19 and b being the value 00:59:26 yes. it could handle the next pixels as 24bit signed integers 00:59:57 no, that would perhaps make it too hard to program... 01:00:15 perhaps the 8-bit values is fine 01:00:27 i doubt anyone makes something very large program anyways, 01:00:32 and if does, they can use patterns 01:00:59 hmm. an address stack is tempting 01:01:15 Keymaker: did a trigger program 01:01:20 cool! 01:01:24 lemme see! :) 01:01:44 http://rafb.net/paste/results/1jN0f072.html 01:01:54 it's simple but it works 01:02:02 let me try :) 01:02:34 trigger is cool 01:02:41 thanks 01:02:50 and 99bob in trigger is insane-cool 01:02:54 :) 01:02:55 voted ***** 01:03:00 thanks 01:03:09 i have a new version of it on my page 01:04:32 jix: nice :) 01:05:14 jix: 01:05:16 xaxxaaxb bbxbbxc ccxccxd 01:05:16 aatbbuccv111fddev222eddfuccv333fddev444eddftbbu555fddeu666e 01:05:33 the die program 01:05:37 (that i call dice) 01:05:55 the rand seed is bad 01:06:12 i get the same number for every >4 calls 01:06:15 I know. I used the standard technique to use time() 01:06:24 which only changes once per second 01:06:32 hmpf 01:06:52 ruby uses microseconds^pid 01:07:00 anyways; kipple; where were we? 01:07:07 hmm. pid 01:07:08 thinking about addressing 01:07:11 ah 01:07:20 yes, using gettimeofday would be better but I was lazy 01:07:32 maybe we need a datapointer... 01:07:34 ruby's prng is very good.. passes all ent test 01:07:41 mmh 01:07:48 i'm not sure 01:07:50 it's a mtSOMENUMBER 01:08:07 mersenne twister. hmm. 01:08:35 kipple: must think about it 01:08:39 i just read the comment 'equidistributed in 300 dimensions' and stopped reading the source *g* 01:08:45 I don't think the idea to read from the next pixels according to the IP is a good idea. 01:08:46 personally i'd like only ip 01:08:56 :) 01:09:04 it's already hard to imagine 4d.. i don't want to imagine 300d 01:09:13 yes, it isn't very nice looking in the source either 01:09:20 a bit clumsy 01:09:27 "(It is proved that the period is 2^19937-1, and 623-dimensional equidistribution property is assured.)" 01:09:37 fun 01:10:03 kipple: then, do you suggest a stack? 01:10:13 it'd be probably best, since it's non-visible etc 01:10:16 hmm. not really 01:10:22 hmm ok 01:10:25 would be convenient, but unelegant 01:10:41 yeah.. but what would be the elegant choice? 01:10:57 haven't thought of it yet :) 01:11:01 :) 01:11:25 the elegant choice wouild be to use only g and b 01:11:28 :) 01:11:30 yeah 01:11:35 true 01:11:43 g is value, b is address 01:11:52 a bit limited though ;) 01:11:57 :) 01:12:10 almost trigger limited, if b being some memory address 01:12:39 but the address is really 3d 01:12:50 since there are 3 components of each pixels 01:13:00 yeah 01:13:21 that could be solved with three put instructions putR, putG and putB 01:13:30 yeah 01:13:54 but what about the coordinates -- or the value? 01:14:02 the value is from g 01:14:03 all can't be fit in two places 01:14:09 and coordinates? 01:14:13 that's the problem 01:14:15 b? 01:14:27 4 bits for x and 4 for y :( 01:14:33 yeah 01:14:40 :\ 01:14:51 not to mention copy and paste... 01:15:07 maybe we'll need to make up our own image format 01:15:31 like where each color component is a 64 bit int? 01:15:33 where each pixel has r and g and b values and ten other values :) 01:15:50 I'm sure RXML is up to the task 01:15:56 just joking :) 01:16:07 but that 64 bit int thing could work 01:16:28 let's stick to standard rgb or we cant convert to a normal image file 01:16:40 yeah 01:17:50 I think the proper course of action would be to RISCianly divide functions that can't be done in one "packet" into several *shrugs* 01:18:07 (Where "packet" = "pixel") 01:18:11 how about having a Data Offset which is applied to the IP when reading values? 01:18:40 hmm 01:18:59 no, that's just a data pointer in disguise... 01:19:06 :) 01:20:35 how about the values being read from a direction perpendicular to the IP? 01:20:51 what's perpendicular? 01:21:18 90 degrees (unless I'm mixing things up) 01:21:30 ah 01:22:06 kipple, that 01:22:10 is correct 01:22:27 that would prevent the ip execution the "argument pixels".. 01:22:32 so if the IP is moving left, the data is read downwards 01:22:37 or something 01:22:42 yeah 01:24:01 designing this kind of language is a lot more difficult than i expected it to b 01:24:06 *be 01:24:31 I think this is maybe the best way if we're to avoid DPs and stacks 01:24:40 yeah 01:24:46 anyways, i'm getting rather tired, it's 3:30 am already.. 01:24:57 maybe better continue another time? 01:24:59 only 2:30 here :) 01:25:03 :) 01:25:09 yeah, let's do that 01:25:13 ok 01:25:17 good nite everyone 01:25:28 i'm outta here for a while 01:25:29 night 01:25:34 bye 01:25:36 -!- Keymaker has left (?). 01:28:55 input in trigger doesn't work 01:30:14