00:00:07 <jix> but i want spiral adressing in it
00:00:59 <jix> to the line FEDCB
00:01:33 <Keymaker> 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:02:08 <jix> Keymaker: you adress one pixel and it takes the info from 4 pixels next to that pixel
00:02:21 <jix> and the one pixel is adressed using SpiralAdressing(tm)^^
00:02:51 <Keymaker> perhaps better than instruction stack
00:03:05 <kipple> nice if all data is stored in the image
00:03:33 <Keymaker> as well, i think that the next pixels should be taken from the direction the data pointer is moving
00:04:09 <kipple> and the datapointer could have a flag which says "move in a spiral"
00:04:37 <Keymaker> if you really want to use the data pointer, then.. :)
00:04:53 <Keymaker> perhaps it's best to have data pointer AND instruction pointer
00:05:12 <kipple> oh, I meant instruction pointer
00:05:43 <kipple> how about the IP being a function (which can be redefined)
00:05:55 <kipple> then it could move in many different ways
00:05:59 <jix> kipple: another language... imho
00:06:20 <Keymaker> but about the instruction pointer..
00:07:07 <kipple> since the data is stored in the same pixel as the instruction I don't think you need a data pointer
00:07:24 <kipple> so, just IP and selfmod
00:07:54 <jix> no ip moves linear
00:07:58 <jix> but adressing is spiral
00:08:12 <pgimeno> like, indirect addressing?
00:08:15 <jix> like add_a_to_cell_at_adress_b 1 2
00:08:31 <jix> which fits perfectly into rgb
00:08:41 <jix> adressing is spiral and relative to ip
00:09:44 <Keymaker> do you mean by that reading the values near the ip that are needed for example copying piece of canvas?
00:10:12 <jix> and you can do nothing if you can only access the current cell
00:10:18 <kipple> if the IP is at 0 then the addresses for other pixels is:
00:10:32 <jix> i did it CCW but CW is ok too
00:12:55 <kipple> gonna be difficult to program ...
00:13:59 <kipple> not sure if it's right for this lang (though I like the idea)
00:14:48 <Keymaker> it's naturally possible that we make separate languages, as i've mentioned
00:15:12 <Keymaker> the more non-textual langs the better ;)
00:18:48 <calamari> cool, started on my spec then too :)
00:19:04 <calamari> I would appreciate help with SDL, though.. any guides for that?
00:19:33 <Keymaker> i'll have a bit hard time coding things up
00:20:00 <Keymaker> i can't do almost nothing at all in it
00:20:11 <Keymaker> i can try to send you some small codes tomorrow
00:20:37 <Keymaker> although i don't have single pixel drawing stuff..
00:21:15 <Keymaker> 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 <calamari> that's okay. I might as well try to figure it out :)
00:21:50 <Keymaker> anyways, good luck with your language gentlemen
00:22:10 <Keymaker> kipple: do you want to cooperative work with me or design own?
00:22:23 <Keymaker> i think we were on same thought patterns, so..
00:23:43 <kipple> I'm not going to make my own , no
00:24:27 <kipple> can help with yours if you want
00:24:44 <Keymaker> i'll e-mail to your e-mail address,
00:25:29 <kipple> yes, but my router won't cooperate
00:25:42 <Keymaker> well, then can you tell here what the address is?
00:25:49 <Keymaker> or open that new window and tell
00:26:27 <Keymaker> it'll be interesting to see what kind of languages people make up
00:26:33 <kipple> anyway, maybe we should make a page under Works in Progress in the wiki
00:27:14 <kipple> lets just pick a temporary one
00:27:41 <int-e> and the final could be TT - Temporary Two.
00:28:31 <kipple> what happens if two people edit the same article at the same time?
00:30:19 <kipple> http://esoteric.voxelperfect.net/wiki/Codename:_RGB
00:31:07 <kipple> so, what do we have so far?
00:31:34 <Keymaker> where the program will be placed on left top corner
00:31:44 <Keymaker> (i accidentally said 'right' sometime ago)
00:32:27 <Keymaker> the other canvas is filled with zeroes or something
00:33:08 <Keymaker> often used as 'transparent colour'
00:33:28 <Keymaker> anyways; then we have instruction pointer
00:34:06 <Keymaker> i'd be fine with the four directions
00:34:37 <Keymaker> then, we have each pixel that have rgb value, where r is some instruction
00:34:49 <Keymaker> each of them naturally being 8-bit
00:35:54 <Keymaker> 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:13 <kipple> that's the easiest way
00:36:15 <Keymaker> then, if there's only two arguments, should the instruction take them from g and b?
00:36:35 <kipple> I would say that can be different in each instruction
00:37:28 <Keymaker> probably should save to g and b
00:37:55 <jix> fill unused space with random data
00:37:59 <Keymaker> eof thing could be useful, i think
00:38:04 <jix> that makes nondeterministic programs possible
00:38:08 <jix> like number guessing game
00:38:19 <Keymaker> jix: that was one of my ideas many lines ago :)
00:38:39 <Keymaker> but i was talking about the empty canvas
00:38:45 <kipple> why not have a separate random function? we have 256 instructions possible
00:39:18 <Keymaker> anyways; what do you think about that eof kipple?
00:39:47 <Keymaker> that something like setting g to 1 in case of eof or something
00:40:06 <Keymaker> yeah, something like that would be useful
00:40:26 <Keymaker> by the way, what should happen if the ip moves to top edge or left edge?
00:40:39 <kipple> it could be infinite in all directions
00:41:45 <Keymaker> like 5000x5000 canvas with 3 values for every pixel..
00:41:55 <GregorR> You waaanto to use RXML for input :)
00:42:04 <kipple> the canvas should be allocated dynamically as needed
00:42:17 <Keymaker> well, yeah, but i can't program that :)
00:42:36 <kipple> just resize the image when needed. is that difficult?
00:43:20 <kipple> anyway, lets not go into implementation details at this point :)
00:43:31 <GregorR> Such as using RXML as input :)
00:43:46 <GregorR> http://www.codu.org/rxml.php
00:44:02 <GregorR> Raster imaging in XML. Mind-bogglingly stupid is what it is 8-D
00:44:03 <Keymaker> i was already guessing it was some gregorr's stuff..
00:44:10 <int-e> Keymaker: what's 100 MB among friends?
00:45:01 * int-e pukes somewhere behind the scenes.
00:45:21 <Keymaker> as a sidenote; the hats gallery still needs updating!
00:46:16 <kipple> lets make some instructions!
00:46:30 <kipple> we need a put value to pixel (x,y)
00:47:08 <Keymaker> or only that it changes b automatically?
00:47:20 <int-e> 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 <kipple> a problem is that x and y can larger than 8bits
00:48:54 <Keymaker> never thought about that before..
00:49:25 <kipple> so x and y should perhaps be relative to current IP position
00:50:36 <int-e> <?xml version="1.0"?> <rxml version="1.0"> <image maxval="255" width="477" height="493"> <layer x="1" y="1" width="477" height="493" z-index="1"> <pixel x="1" y="1"> <red value="5"/> <green value="1"/> <blue value="2"/> <alpha value="255"/> </pixel> [...] properly indented of course. This is great stuff.
00:51:06 <kipple> 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 <GregorR> Could int-e be raising some sort of sarcastic defiance against RXML? :P
00:51:12 <int-e> note that this format is easily extensible to include alpha and octarine channels.
00:51:27 <kipple> the coords taken from the next pixel
00:51:33 <int-e> no. RXML is a great example why XML should *not* be blindly used.
00:51:52 <GregorR> NO!!!! XML IS ALWAYS BETTER!!!!! BUZZWORD = GOOD!!!!
00:52:06 <int-e> See, that's what I'm defiant against.
00:52:34 <Keymaker> should the values go backwards if value is bigger than 128 or something?
00:52:42 <GregorR> Keymaker: You know, you would have an extra data byte if you used alpha.
00:52:45 <kipple> yes. the bytes could be signed
00:53:17 <GregorR> 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:50 <int-e> 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:54:18 <GregorR> kipple: XML will fuck your brain enough without Brainfuck support ;)
00:54:33 <kipple> double negative is positive!
00:54:37 <int-e> Oh. I see something coming
00:54:58 <int-e> <LOOP> <PLUS/> <PLUS/> <LEFT/> </LOOP>
00:55:32 <int-e> too concise, I'll admit, but it's a start.
00:55:33 <GregorR> <operation encoding="UTF-8">+</operation>
00:56:26 <calamari> err it'd be <!-- > --> wouldn't it
00:57:01 <Keymaker> 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 <kipple> back to RGB: how about put taking coords from the two next pixels. the first pixel would be negative, and the second positive
00:58:38 <Keymaker> 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:59:11 <Keymaker> the g being 0 or 1 determining the direction (backwards or forwards)
00:59:26 <kipple> yes. it could handle the next pixels as 24bit signed integers
00:59:57 <kipple> no, that would perhaps make it too hard to program...
01:00:15 <Keymaker> perhaps the 8-bit values is fine
01:00:27 <Keymaker> i doubt anyone makes something very large program anyways,
01:00:32 <Keymaker> and if does, they can use patterns
01:00:59 <kipple> hmm. an address stack is tempting
01:01:15 <jix> Keymaker: did a trigger program
01:01:44 <jix> http://rafb.net/paste/results/1jN0f072.html
01:01:54 <jix> it's simple but it works
01:02:34 <jix> trigger is cool
01:02:50 <jix> and 99bob in trigger is insane-cool
01:02:55 <jix> voted *****
01:03:09 <Keymaker> i have a new version of it on my page
01:05:16 <int-e> xaxxaaxb bbxbbxc ccxccxd
01:05:16 <int-e> aatbbuccv111fddev222eddfuccv333fddev444eddftbbu555fddeu666e
01:05:55 <jix> the rand seed is bad
01:06:12 <jix> i get the same number for every >4 calls
01:06:15 <int-e> I know. I used the standard technique to use time()
01:06:24 <int-e> which only changes once per second
01:06:52 <jix> ruby uses microseconds^pid
01:07:00 <Keymaker> anyways; kipple; where were we?
01:07:08 <kipple> thinking about addressing
01:07:20 <int-e> yes, using gettimeofday would be better but I was lazy
01:07:32 <kipple> maybe we need a datapointer...
01:07:34 <jix> ruby's prng is very good.. passes all ent test
01:07:50 <jix> it's a mtSOMENUMBER
01:08:07 <int-e> mersenne twister. hmm.
01:08:39 <jix> i just read the comment 'equidistributed in 300 dimensions' and stopped reading the source *g*
01:08:45 <kipple> I don't think the idea to read from the next pixels according to the IP is a good idea.
01:09:04 <jix> it's already hard to imagine 4d.. i don't want to imagine 300d
01:09:13 <Keymaker> yes, it isn't very nice looking in the source either
01:09:27 <int-e> "(It is proved that the period is 2^19937-1, and 623-dimensional equidistribution property is assured.)"
01:10:03 <Keymaker> kipple: then, do you suggest a stack?
01:10:13 <Keymaker> it'd be probably best, since it's non-visible etc
01:10:25 <kipple> would be convenient, but unelegant
01:10:41 <Keymaker> yeah.. but what would be the elegant choice?
01:10:57 <kipple> haven't thought of it yet :)
01:11:25 <kipple> the elegant choice wouild be to use only g and b
01:11:43 <kipple> g is value, b is address
01:11:52 <kipple> a bit limited though ;)
01:12:10 <Keymaker> almost trigger limited, if b being some memory address
01:12:39 <kipple> but the address is really 3d
01:12:50 <kipple> since there are 3 components of each pixels
01:13:21 <kipple> that could be solved with three put instructions putR, putG and putB
01:13:54 <Keymaker> but what about the coordinates -- or the value?
01:14:03 <Keymaker> all can't be fit in two places
01:14:27 <kipple> 4 bits for x and 4 for y :(
01:14:51 <Keymaker> not to mention copy and paste...
01:15:07 <Keymaker> maybe we'll need to make up our own image format
01:15:31 <kipple> like where each color component is a 64 bit int?
01:15:33 <Keymaker> where each pixel has r and g and b values and ten other values :)
01:15:50 <int-e> I'm sure RXML is up to the task
01:16:07 <Keymaker> but that 64 bit int thing could work
01:16:28 <kipple> let's stick to standard rgb or we cant convert to a normal image file
01:17:50 <GregorR> 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 <GregorR> (Where "packet" = "pixel")
01:18:11 <kipple> how about having a Data Offset which is applied to the IP when reading values?
01:18:59 <kipple> no, that's just a data pointer in disguise...
01:20:35 <kipple> how about the values being read from a direction perpendicular to the IP?
01:21:18 <kipple> 90 degrees (unless I'm mixing things up)
01:22:27 <Keymaker> that would prevent the ip execution the "argument pixels"..
01:22:32 <kipple> so if the IP is moving left, the data is read downwards
01:24:01 <Keymaker> designing this kind of language is a lot more difficult than i expected it to b
01:24:31 <kipple> I think this is maybe the best way if we're to avoid DPs and stacks
01:24:46 <Keymaker> anyways, i'm getting rather tired, it's 3:30 am already..
01:24:57 <Keymaker> maybe better continue another time?
01:25:36 -!- Keymaker has left (?).
01:28:55 <jix> input in trigger doesn't work
01:30:14 <jix> ah it does work
01:31:18 -!- CXI has quit (Connection timed out).
01:35:53 <jix> a new trigger programm called numcat
01:35:54 <jix> http://rafb.net/paste/results/3OHwfi96.html
01:36:05 <jix> it's like cat but only supports 0123456789 and \n
01:39:17 -!- kipple has quit ("See you later").
01:42:52 -!- jix has quit ("Bitte waehlen Sie eine Beerdigungnachricht").
01:55:25 -!- calamari_ has joined.
01:56:24 -!- calamari has quit (Read error: 110 (Connection timed out)).
02:19:41 -!- calamari_ has quit ("Leaving").
02:44:37 -!- calamari has joined.
02:45:21 <calamari> yay, hacked scrobbler to remove all the limits about why it won't add a song :)
03:53:48 -!- int-e has quit ("Bye!").
04:15:12 <calamari> done with summer classes.. that means I can work on my game a lot more now!
04:55:29 -!- calamari_ has joined.
05:14:05 -!- calamari has quit (Read error: 110 (Connection timed out)).
06:23:04 -!- prf has quit ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )").
06:49:56 -!- fizzie has quit (brown.freenode.net irc.freenode.net).
06:50:18 -!- fizzie has joined.
07:18:25 -!- kipple has joined.
07:21:39 -!- pgimeno has quit (brown.freenode.net irc.freenode.net).
07:21:46 -!- pgimeno has joined.
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
08:23:45 -!- puzzlet has quit (Remote closed the connection).
08:23:45 -!- kipple has quit (Read error: 104 (Connection reset by peer)).
08:31:56 -!- puzzlet has joined.
11:02:33 -!- calamari_ has quit (Read error: 110 (Connection timed out)).
11:20:09 -!- jix has joined.
13:22:12 -!- Keymaker has joined.
14:26:33 <Keymaker> bbl, hopefully kipple'll be around.
14:26:37 -!- Keymaker has left (?).
14:27:27 <{^Raven^}> I gotta explain to someone unfamiliar to BF that it is *impossible* to save and load files
14:29:21 <{^Raven^}> I guess that what happens when you make brainfuck programs for the general public to use
15:50:36 -!- CXI has joined.
16:11:37 -!- int-e has joined.
16:46:22 <int-e> GregorR: Using DOM for the RXML to PNM converter turned out to be a great choice - converting that 35 MB image to PNM used 350 MB of RAM ;)
17:22:05 <GregorR> int-e: YEEEEEEEEEEEEEEEEEEEEE HAW!!!!
18:30:16 -!- kipple has joined.
18:35:34 -!- Keymaker has joined.
18:36:45 <Keymaker> kipple: the esowiki article seems nice
18:37:25 <kipple> now that is an idea. an esolang based on RPGs :D
18:37:57 <kipple> anyway, I just jotted down what we've discussed so far. probably missed a bunch
18:53:20 <kipple> uploaded? what do you mean?
18:54:31 <Keymaker> i meant that have you uploaded the things you jotted down
18:54:38 <Keymaker> or did you jot them down on real paper?
18:54:44 <kipple> umm. in the esowiki :)
18:54:56 <kipple> I said I porbably missed a bunch :)
18:55:16 <kipple> feel free to add to it
18:55:52 <Keymaker> yeah, it looks like it has probably all or most of the stuff
18:55:57 <kipple> anyway, regarding instructions and arguments
18:56:36 <kipple> what if g determines direction for reading the arguments, and b says how many arguments to be used?
18:57:16 <kipple> for instance: ADD RIGHT 5 will add the values of the 5 pixels to the right of the IP
18:57:41 <kipple> but where to put the return value if it's larger than 255?
18:58:54 <Keymaker> what if the case is that copy area thing where there's many arguments?
18:59:21 <Keymaker> i think your idea could work the way g determines the direction where the values are read from
18:59:27 <kipple> with this method there are up to 255 args
19:00:12 <Keymaker> oops, seems i forgot to continue:
19:01:05 <Keymaker> if there's the command copy_area(x1,y1,width,height,x2,y2)
19:01:18 <Keymaker> then, where the instruction takes the arguments?
19:01:35 <kipple> from the direction specified by g
19:01:41 <kipple> (I don't understand the problem)
19:02:25 <Keymaker> should the b affect to every instruction
19:02:39 <Keymaker> or do instruction take the amount of argument pixels they need
19:02:50 <kipple> some instructions will have a constant number of arguments, so then it is not needed
19:03:15 <kipple> so we don't really need it
19:03:35 <kipple> but it is nice because we can have functions with a variable number of args
19:03:46 <kipple> but perhaps we can find better use for b
19:04:20 <Keymaker> by the way, as well, when there are those argument pixels..
19:04:37 <Keymaker> should the instruction take data from their r and g and b
19:04:50 <kipple> I'd say that should depend on the instruction
19:05:01 <kipple> copy_are should take all
19:05:19 <kipple> but there must be a way to manipulate them individually
19:05:30 <kipple> that is something b could be used for
19:06:06 <kipple> b determines whether values are taken from r,g,b or all
19:07:22 <kipple> what about instructions that return values? should we restrict return values to 8 or 16 bits?
19:07:32 <Keymaker> ah, i was just going to mention that
19:07:43 <kipple> or should we overwrite the entire pixel at IP?
19:07:59 <Keymaker> that could depend on instruction
19:08:28 <kipple> that's probably the best way to do it
19:08:37 <Keymaker> 16 bit values could be divided into two cells, g and b, if wanted
19:08:46 <Keymaker> but does anyone use that big number these days ;)
19:10:14 <kipple> the instruction could also just overwrite the arguments
19:10:50 <Keymaker> but i think it's best to make that instruction-dependable
19:10:51 <kipple> but then again, has to be different for each instruction
19:11:16 <Keymaker> if wanting to make bigger values,
19:11:36 <Keymaker> naturally it could be that each r, g and b are for example 32 bit values
19:11:45 <Keymaker> that in the beginning just get values from 0 to 255
19:12:13 <kipple> but it wouldn't work in a visual interpreter
19:13:11 <Keymaker> anyways, i'm really excited about the visual interpreter.. that will be really nice
19:13:16 <kipple> bah. 8 bits is more than anyone's ever gonna need, right?
19:13:39 <Keymaker> maybe we should just keep all 8 bits
19:14:18 <kipple> you should be able to address larger blocks than 8 bits though
19:14:39 <Keymaker> just add two arguments for one value
19:15:24 <Keymaker> nobody will ever need to copy bigger than maxium 16-bit value width areas
19:15:43 <kipple> that's a pretty big image, yes
19:16:24 <Keymaker> what resolution would be good?
19:17:20 <kipple> do you need specific res? why not a windowed app?
19:17:47 <Keymaker> what if the ip moves out of the window?
19:18:45 <Keymaker> i'm not sure if can get this thing programmed, though.. i'm not that good with any real langs, not to mention that i should do something with graphics or gui
19:19:27 <kipple> the largest image I've worked with is 29952 x 11520, so 16 bits should be enough :)
19:19:40 <kipple> well, lets make a spec first, and think about implementation later
19:20:10 <kipple> I don't have time to work on an interpreter at this time
19:20:15 <Keymaker> and let's someone else, say GregorR write the interpreter :)
19:20:26 -!- int-e has set topic: Uhm, where are these archives again?.
19:20:55 <Keymaker> http://tunes.org/~nef/logs/esoteric/
19:21:11 -!- int-e has set topic: archives of previous discussions can be found at http://tunes.org/~nef/logs/esoteric/.
19:21:25 <int-e> thanks. I like to have that link in the topic.
19:21:38 <kipple> this one is better formatted: http://meme.b9.com/~13835c5e839f38a85e97aeef~/cdates.html?channel=esoteric
19:21:59 <Keymaker> i personally prefer the link i posted :)
19:22:45 <kipple> less ugly link: http://meme.b9.com/cdates.html?channel=esoteric
19:23:44 <Keymaker> i think the program should read the input from a file
19:24:05 <kipple> we don't really need file output, but ok
19:24:24 <kipple> should they be images?
19:25:13 <Keymaker> but then making it read for example normal text files would be quite difficult
19:25:35 <GregorR> Apparently my powerful interpreters have gained notoriety :P
19:26:04 <int-e> the meme link is updated more quickly, I like that
19:26:18 -!- int-e has set topic: archives of previous discussions can be found at http://tunes.org/~nef/logs/esoteric/ and also at http://meme.b9.com/cdates.html?channel=esoteric.
19:26:19 <kipple> don't let Gregor do it. then it will only ouput RXML!
19:26:33 <GregorR> MUAHAHAHAHAHAHAHAHAHAHAHAHAHA
19:27:16 <int-e> Sorting mailbox...Segmentation fault
19:27:19 <GregorR> How about jpeg, so the program doesn't actually do what you programmed it to :P
19:28:12 <kipple> cat would then be a whatever to jpg converter :)
19:29:01 <kipple> anyway, if we go with normal file IO it should be pretty straight forward I think
19:29:07 -!- CXI has quit (Read error: 60 (Operation timed out)).
19:29:46 <GregorR> Since there doesn't seem to be any suggestion of a nop there :P
19:30:11 <kipple> read/write could take arguments specifying the area to fill/read from
19:30:25 <kipple> anything that is not an instruction should be NOP
19:31:16 <kipple> anyway, did we agree on the canvas size?
19:31:23 <kipple> infinite in all directions?
19:31:35 <kipple> (negative coordinates)
19:32:07 <Keymaker> but naturally we can change that if you want to
19:32:18 <kipple> so, the source is placed at (0,0) but can move into negatives during exec
19:33:01 <kipple> then we need negative numbers in arguments :)
19:33:26 <Keymaker> well, what about using the 16 bit values
19:33:33 <kipple> well, we can do without, but it would be nice
19:33:49 <Keymaker> i was just thinking something and didn't realize to continue:
19:34:10 <Keymaker> i mean if we're using 16 bit values, that are taken from two arguments (like g and b)
19:34:34 <Keymaker> we could do the usual trick if the value is bigger than 16000 something
19:35:08 <kipple> we could just treat it as a signed integer. no need to do tricks
19:35:26 <int-e> 16383. and you mean the same thing
19:35:29 <Keymaker> that's what i was trying to say :D
19:35:39 <GregorR> I would suggest some sort of bignumish support for having numeric values in the gb-rgb-rgb-... stream.
19:36:02 <GregorR> So that you can truly support infinite area.
19:36:05 <int-e> hmm. actually should be 32767, byt that's ok (or did you use another bit for something else?)
19:36:45 <kipple> int-e: you are correct
19:37:44 <Keymaker> btw, i need go for a while.. i'll be back soon..
19:38:38 <kipple> I'll probably be gone then
19:59:46 <kipple> updated the wiki article
19:59:55 <kipple> with some suggestions for G
20:03:02 <Keymaker> perhaps we could have instructions for getting the next byte and outputting only one byte?
20:04:09 <Keymaker> good, because i want to make the traditional digital root calculator :)
20:04:09 <kipple> how about: if G is 0 then take argument from b?
20:04:37 <Keymaker> what about the directions then?
20:04:59 <kipple> if G > 0 take B number of arguments in the direction specified by G
20:05:28 <Keymaker> should've thought about that before asking :)
20:05:43 <kipple> that could apply to most instructions
20:06:59 <kipple> so, should we have diagonal directions for the args? or just right angles?
20:07:17 <Keymaker> i think diagonal would be better
20:07:32 <kipple> yeah, why not. we're wasting enough bits already :)
20:08:32 <Keymaker> or wait.. i meant by diagonal to read the arguments from the direction g tells..
20:09:40 <kipple> um. that's what I meant. Or maybe I am misunderstanding you...
20:09:53 <Keymaker> sorry, i didn't quite understand :)
20:10:09 <Keymaker> anyways, that's what i think is the best.. to check the direction from g
20:10:28 <kipple> but how many directions are there? 4 or 8?
20:10:58 <kipple> though it will probably not be used
20:11:27 <int-e> how about the 8 knight jumps :P
20:12:27 <Keymaker> at least we have many instructions to use..
20:12:50 <Keymaker> so, having 8 instead of 4 wouldn't hurt
20:14:13 <Keymaker> should we have stuff that something is ==, > or <?
20:16:41 <Keymaker> i mean that return 0 if two values aren't same and 1 if they're equal and so on..
20:17:34 <kipple> or one instruction for each
20:18:03 <Keymaker> yeah, one instruction for each is good
20:18:10 <kipple> and the result could affect the IP, not return a value
20:18:35 <kipple> all control flow should be via the IP
20:19:36 <kipple> it could compare just g and b, but we should probably be able to compare larger values as well
20:19:50 <Keymaker> (since we have plenty of instructions, perhaps we should have ==, !=, <, >, <=, >=?)
20:20:59 <Keymaker> naturally it could be that those instructions just take more arguments
20:21:53 <kipple> how about: if G>0 then take arguments as normal. if G== then compare b to 0
20:22:19 <kipple> if G=0 then compare b to 0
20:22:36 <Keymaker> hmm, you mean in this specific instruction?
20:23:31 <kipple> well, in general G=0 means use only B as arg.
20:24:13 <Keymaker> by the way, what directions to use for the ip in those cases?
20:24:53 <Keymaker> that if true, them let ip continue, otherwise turn the direction..
20:25:04 <kipple> i don't think reverse is good
20:25:25 <kipple> how about: combining ==,> and <
20:25:42 <kipple> if equal, continue forward. if greater go right, if less go left
20:27:12 <kipple> that instruction could handle all manipulation of the IP
20:27:29 <kipple> anyway, now I gotta go.
20:54:10 -!- calamari has joined.
21:05:50 <calamari> I think I'm going to abandon my 2-d language for now. I want to work on other projects :) What ever you guys come up with will be great anyways.
21:06:24 <Keymaker> ok.. and thanks, i hope it's going to be great
21:07:06 <Keymaker> good luck with the other projects
21:07:22 <calamari> One thing I was planning to do differently was to use the lower 2 bits of each RGB, to give 6 bits to work with. This way it's harder to see the program, but it's still faintly there
21:08:12 <calamari> 2 bits would determine the next cell: straight, turn left, turn right, choose: a<b left, a>b right, a==b straight
21:08:26 <calamari> and two registers a & b obviously :)
21:09:03 <Keymaker> kipple has made some very clever ideas for movement
21:09:24 <calamari> that left 4 bits for an instruction.. so 16 instructions. I figured that multiple 4 bit chunks would be used for data
21:09:56 <calamari> kinda like in asm ,where after an opcode is given, the next few bytes given are data rather than opcodes
21:10:27 <calamari> I was reading some of the logs and you both ahve come up with some great ideas
21:10:47 <Keymaker> it's very fun to do cooperative language
21:13:32 <calamari> I have a Java 2D graphing program I wrote that should be able to be redone for whatever you need, in case you decide not to go with SDL
21:14:42 <Keymaker> writing the interpreter for this language will be quite hard i assume..
21:15:00 <calamari> are you going to be doing jix's spiral idea?
21:15:55 <Keymaker> it's nice idea but we want to make the language as simple as possible
21:16:02 <Keymaker> and since there is no data pointer,
21:16:25 <Keymaker> making the instruction pointer behave that would be difficult for the programmer :)
21:18:15 <calamari> one thing I began to realize with mine is that if I limited the data pointer to the cell I was in, that would make it impossible to have an artibrary effect on a single memory location
21:18:40 <calamari> so some kind of offset system or my box bushing or whatever might be needed
23:31:22 -!- calamari_ has joined.
23:48:26 -!- calamari has quit (Read error: 110 (Connection timed out)).
23:49:49 -!- Keymaker has left (?).