00:00:26 -!- calamari_ has joined.
00:12:54 -!- harkeyahh has joined.
00:18:49 <harkeyahh> U r always on my case abotu something ChanServ
00:19:10 <harkeyahh> if you wanna serve me get me something to drink and then get down on your knees...
00:19:33 -!- calamari has quit (Read error: 110 (Connection timed out)).
00:25:12 <desafinado> harkeyahh: did you package arrive safely to Mumbai?
00:25:38 <harkeyahh> oh, yes it did i meant to change the topic
00:26:36 -!- harkeyahh has set topic: Another brainfuck site (http://www.bf-hacks.org/) is open! ~ http://chriscoyne.com/cfdg/ ~ Esolang wiki: http://esolangs.org/wiki/ Thank you for your prayers my children. The package arrived safely into the arms of a 10,000 pound elephant..
00:37:18 <desafinado> there has been confusion regarding turing-completeness of smallfuck
00:38:23 <desafinado> I made up my mind. Available memory is limited. Smallfuck is not turing-complete.
00:57:38 <cpressey> desafinado: on that topic, you might be interested in this: http://catseye.webhop.net/projects/sf2tab/src/sf2tab.c
00:57:46 <cpressey> it compiles smallfuck programs into lookup tables
01:06:16 -!- heatsink has joined.
02:40:02 -!- tokigun has quit ("Chatzilla 0.9.68.5 [Firefox 1.0.3/20050414]").
02:58:10 -!- malaprop has quit ("bounce").
03:14:42 -!- desafinado has changed nick to lament.
04:24:16 <graue> I added pages to the esowiki on Archway and Qdeql
04:43:11 -!- calamari_ has quit (Read error: 110 (Connection timed out)).
05:02:18 -!- heatsink has quit ("Leaving").
05:39:15 -!- harkeyahh has quit ("Chatzilla 0.9.68.5 [Firefox 1.0.4/20050511]").
07:59:59 -!- clog has quit (ended).
08:00:00 -!- clog has joined.
08:14:59 -!- pgimeno has joined.
08:31:08 -!- graue has quit (Read error: 110 (Connection timed out)).
11:36:33 -!- tokigun has joined.
11:38:37 <tokigun> i've submitted three beer song program to 99-bottles-of-beer.net; one of them is already uploaded.
11:38:38 <tokigun> http://www.99-bottles-of-beer.net/language-whirl-761.html
13:18:13 -!- malaprop has joined.
13:28:18 -!- jix has joined.
15:50:39 -!- jix has quit ("Banned from network").
17:46:48 -!- calamari_ has joined.
18:42:46 -!- graue has joined.
18:55:22 -!- comet_11 has joined.
18:55:37 -!- CXI has quit (Read error: 104 (Connection reset by peer)).
18:55:56 -!- comet_11 has changed nick to CXI.
19:08:33 -!- calamari_ has quit ("bbl").
20:23:36 -!- graue has quit (Remote closed the connection).
20:36:28 -!- calamari has joined.
20:49:10 -!- graue has joined.
21:54:03 -!- jix has joined.
21:59:01 -!- jix has quit ("Banned from network").
22:16:21 <calamari> better now that I've taken my math test :)
22:17:55 <calamari> I'm considering writing an adventure game.. need to see if my idea is feasible though. Of course an extra 8k of data storage helps a lot :)
22:18:22 <{^Raven^}> just 2.8k is suficcient for a large game
22:18:55 <calamari> depends on how much time you spend compressing things
22:19:26 <calamari> nothing in the rules says not to use the data file, so why not? hehe
22:19:35 <{^Raven^}> I enjoy squeezing every last byte out of code. optimisation is fun
22:20:13 <calamari> oh, don't get me wrong.. it's just that if I limit myself to 2.8, it's not going to be the same game as 2+8k
22:20:38 <calamari> still only 2k of code.. the 8k is for data
22:22:17 <calamari> I need to write a quick assembler, though, so that I can use a compressed source format.. 2929 bytes of standard asm source code won't get me much
22:23:06 <{^Raven^}> last year assembler games were accepted without source code
22:23:13 <calamari> I think that source rule is silly, though.. it's the binary that matters.. actually a lot of the rules are silly, it's all for the fun of it, I suppose
22:23:32 <calamari> oic.. that makes things considerably easier
22:25:04 <calamari> with 2k of code, I could probably write a semi-generic engine
22:25:22 <{^Raven^}> once that fits your game perfectly
22:25:56 <{^Raven^}> if you want to follow the rules as posted then a zip of your engine + your data file has to be under 2.7Kb and that's pretty impossible
22:26:20 <{^Raven^}> the organiser has not thought about the rules, think of them as general guidelines
22:26:36 <{^Raven^}> and there should be an OR clause between rules one and two
22:27:01 <calamari> it was funny how he called it RAM, that makes no sense in the context
22:27:13 <{^Raven^}> the source code limit is for games written in BASIC or interpreted languages
22:27:42 <{^Raven^}> the executable code limit is for compiled/assembled games
22:29:23 <{^Raven^}> yeah, it implies that a UPXd EXE (!) when decompressed must be within the 2.79Kb [sic] limit
22:29:34 <calamari> I should e-mail him to see what the actual rules are
22:30:33 <{^Raven^}> people have tried this year and last year to clarify them but to no avail. Good Luck!
22:31:01 <calamari> raven: I think it'd be pretty hard for him to verify how much ram is being used
22:31:48 <calamari> pretty much impossible without disasseming the source, on game systems such as the atari 5200
22:32:39 <{^Raven^}> yeah. I'm still strying to get the whole concept of a 1024-2048 byte game competition that allows entries up to almost 3K in size
22:35:06 <lament> what the fuck is "data"
22:35:11 <lament> maybe my "data" is Python code
22:35:26 <graue> define "executed", eh
22:35:44 <graue> an interpreter doesn't execute anything, it just looks at "data" and decides what to do
22:36:58 <lament> of course for an interactive fiction game
22:37:08 <lament> you probably need much more "real data" than code
22:37:29 <lament> it might be possible to fit Scott Adams' engnine in 2k
22:37:41 <lament> and any scott adams' game fits easily (zipped) in 8k data
22:37:47 <{^Raven^}> easily, you could do it in much less
22:38:00 <lament> (which is exactly what i was planning to do for the competition :))
22:38:38 <{^Raven^}> Previously I used my own custom data compression code rather than relying on any external libraries
22:40:06 <{^Raven^}> For this I would prefer to do the same to keep the 'game' as self contained as possible (not saying that I won't though)
22:41:32 <calamari> wisdom from the dunric file: http://groups-beta.google.com/group/rec.games.video.classic/browse_thread/thread/5110daaa04a82c2c/0267f0dcc89cbaf5?q=rec.games.video.classic+dunric&rnum=8&hl=en#0267f0dcc89cbaf5
22:45:14 <{^Raven^}> Here is a "clarification" of the rules (at the bottom) http://groups-beta.google.com/group/rec.arts.int-fiction/browse_frm/thread/68e352749cb768ff/cc85e00f30ff941d?q=dunric&rnum=6&hl=en#cc85e00f30ff941d
22:45:49 <{^Raven^}> if accepted as true it allows for some major abuse of the rules
22:46:21 <lament> he says you can use "TADS, Adrift, etc"
22:46:24 <lament> which also means inform
22:47:01 <{^Raven^}> for instance you could write a *huge* generic game engine without any size limitations (the interpreter)
22:47:27 <{^Raven^}> the code (game logic) would have to fit in 2.83Kb which would allow for a huge amount of logic
22:47:44 <{^Raven^}> and all data (strings etc) would go in the 8Kb data file
22:48:21 <{^Raven^}> IMHO that's what dunrics clarification allows and that goes against what I feel to be the spirit of the competition
22:48:55 <lament> TADS, Adrift, Inform ARE "huge, generic game engines"
22:49:00 <lament> and what's better, you don't have to write them yourself.
22:50:18 <{^Raven^}> but it means that you could really submit anything, you can compress the logic (code) to fit within 2.83Kb and not suffer from the EXE/UPX clause in rule one
22:51:35 <lament> basically the rules of the competition are kinda dumb :)
22:51:47 <lament> he should have restricted them waay more
22:52:11 <{^Raven^}> this needs to be sorted out, the rules need to be revised
22:54:08 <{^Raven^}> My entry from last year was fully self contained at 2,803 bytes of BBC BASIC, it even ran on a BBC
22:57:07 <{^Raven^}> He states that the absolute maximum source size is 2.83Kb and later adds 'give or take a few hundred bytes' and gives a new limit of 2.86Kb
22:57:41 <{^Raven^}> no-one, to my knowledge has ever understood what dunric's rules mean
22:59:12 <calamari> including him, I'd imagine.. where would 2.83k come from? not exactly a common file size :)
23:00:54 <{^Raven^}> ~2.831Kb = 2899 bytes. Since when are there only 1000 bytes in a kilobyte? Any programmer (aside form dunric!) should know this.
23:01:43 <{^Raven^}> and 2.83Kb is waaaay outside the 1Kb to 2Kb remit of the contest
23:01:54 <calamari> it doesn't matter tho, in the end :)
23:02:43 <{^Raven^}> not really, but knowing the original reason why the competition started makes it seem silly
23:04:38 <calamari> hmm, if I don't have an external data file, I'd better think harder about compression. Maybe perl? :)
23:05:54 <{^Raven^}> #defining common operations as macros would allow a good degree of compression.
23:06:15 <calamari> I'm think more along the lines of text compression
23:07:06 -!- CXI has changed nick to test.
23:07:10 -!- test has changed nick to CXI.
23:07:20 <{^Raven^}> hmmm, the main problem is the trade off between the space gained by compression and the code size required for decompression
23:08:11 <{^Raven^}> finding an optimal or beneficial balance is difficult but possible if you limit yourself to only 2.83Kb for the entire game
23:16:47 <calamari> it is possible to decompress in very little code, depending on the compression used. For example, dictionary compression
23:35:00 -!- KarlMarx has joined.
23:41:20 <calamari> I've e-mailed him.. hopefully I'll get a response since we used to hang out online all the time
23:45:33 <calamari> I asked for clarifications, and also offered alternate rules that made sense to us
23:46:02 <{^Raven^}> hmmm...i am doing the same (but not sent yet)
23:46:25 <calamari> let me paste the rules I suggested to see if you agree
23:46:50 <calamari> 1) The size of the unzipped game file may be no larger than 2048 bytes in
23:46:51 <calamari> size, whether source or binary in nature. The internal details or methods
23:46:51 <calamari> used in the binary or source file are unimportant (feel free to use UPX
23:46:51 <calamari> compression, platform tricks, etc), so long as the game file itself is no
23:46:53 <calamari> 2) External game engines or language interpreters may be used to run the
23:46:55 <calamari> game, so long as it can be verified that the engine or language employed was
23:46:57 <calamari> written prior to the contest starting date.
23:49:50 <calamari> he relied already, basically ignoring the rule suggestions
23:50:10 <{^Raven^}> I would have suggested that the original 2899 byte limit be allowed for this year only
23:50:53 <graue> why was the limit set at 2899 bytes?
23:51:34 <calamari> maybe a certain auto-adventure generator saves files of that size?
23:52:15 <{^Raven^}> It may not be 'entirely' true, but it fits the events surrounding the announcement of the original competition last year
23:52:47 <{^Raven^}> Each year in the interactive-fiction community there is a competition called IF-Comp
23:53:27 <{^Raven^}> Dunric submitted his game B-Venture to the 2004 IF-Comp
23:53:57 <{^Raven^}> his entry was disqualified because it broke the 'entries must not have been previously released' rule
23:54:30 <calamari> that sux.. so he probably made his own contest in spite?
23:54:30 <{^Raven^}> he discussed this fervently (to understate reality) with the organisers and community at large
23:54:49 <{^Raven^}> and yes, in spite he made his own competition
23:55:06 <graue> you know what I think would be really neat
23:55:09 <{^Raven^}> in his competition there were no rules to disallow previously released games
23:55:12 <graue> a modular music studio, using Brainfuck programs
23:55:31 <graue> effects would be programs that read samples on stdin and produce samples on stdout
23:55:49 <{^Raven^}> And B-Venture was 2,700(ish) bytes long, so he set a max code limit which was a little larger
23:56:14 <{^Raven^}> This was part of the reason why the first competition was ignored by the IF community
23:56:46 <lament> the other part of the reason is probably because the vast majority of the IF community couldn't care less about "old-school" crappy games which fit in a few K
23:56:59 <calamari> you could even get fancy and have wave in, wave out bookends
23:57:12 <graue> I am not familiar with the use of the term 'bookend' in this context
23:58:24 <calamari> the idea is that you'd give a regaular wav file, it'd be decoded and sent to the next filter, which would only be dealing with a raw file, then after the last filter you'd feed the raw into the last program and it'd becomes a playable wav again
23:58:28 <{^Raven^}> lament: it's not that miniature masterpieces in general are crap, coding small elegant programs with a apurpose is a lost art. The quality of the works of certain authors (not mentioning names here) does leave a lot to be desired
23:58:47 <lament> {^Raven^}: it's an art the IF community isn't terribly interested in.
23:59:03 <lament> they have their own art to worry about
23:59:25 <graue> calamari, I guess so, but I was thinking the environment executing the programs would do that sort of coding
23:59:27 <calamari> lament: maybe not, but it is interesting, nonetheless