i wanted to make maps. random maps. for a future project. because i'm a nerd. i googled for "random map algorithms" and "random map generators". i got some hits but mostly for making random dungeons or mazes. i want outdoor maps. terrain maps.

googling for "random terrain algorithms" and "random terrain generators" gives much better hits. but, i don't want to make beautiful photo realistic fractal terrain. if i did i'd be done by now.

once upon a time you'd generate fractal "plasma cloud", and use the values from that as your height map. run that through a scene editor for your specific renderer or ray tracer. then you'd run your scene through your renderer and wait a couple of days. after tweaking your scene and re-rendering it, you'd eventually have your pretty pretty terrain.

computers are faster now. algorithms are better now. faster computers + better algorithms = nommier awesomeness. this brings us to noise. specifically Perlin noise. Perlin noise is a type of "coherent noise", which itself is a type of pseduo-random noise. This psudo-randomness is why Perlin noise is now heavily used in computer graphics as it produces more natural looking textures (or landscapes). Plasma clouds tend to look more artificial; more like they're computer generated.

but i don't want to make pretty landscapes. i'd rather go there. what i want are 2D tile-based maps. like a board game. or like the maps from computer games like Freeciv. more specifically, i want the data that the maps represent.

i'm working on it.

in the meantime, i need to fudge it. so back to Perlin noise. why couldn't i take a complex image generated with Perlin noise and simplify it? tilify? tiliate? make it into tiles. no reason.

first i need a coherent noise generator. easy. libnoise takes care of that. it just so happens that libnoise takes care of some basic rendering as well. third i need to process the image to get our tile map. i could use a program like The Gimp but, the goal is to do it programatically, in one step (eventually). i'll use GD instead.

using libnoise and the values from its great tutorial i:

1. generate a height map from a 2D slice of 3D Perlin noise
2. "colorize" it by applying a gradient to it
3. render it with some fancy lighting
4. and get this for a result

too fancy though. undoing "step 3" we get:

this is better, but it as to many colors. it will work for now though.

so i think i want 16x16 tiles for my example. and for the example i want to render each pixel in my source image as a 16x16 tile. i'll have to use a smaller input image. a 64x64 pixel source blown up by 16x will give a 1024x1024 final image. so, a little effort with GD and i get something i might be able to work with:

by the way, the time was:

[badtz:~/terrain] time (./ter && (bmptopnm tutorial.bmp| pnmtopng - > tutorial.png) && ./tile 2>&1 >/dev/null)
(; ./ter && (; bmptopnm tutorial.bmp | pnmtopng - > tutorial.png; ) && ./tile)  0.13s user 0.00s system 98% cpu 0.134 total
[badtz:~/terrain] 

the lines of source are (eat it python!):

[badtz:~/terrain] wc -l ter.cc tile.cc
  42 ter.cc
  40 tile.cc
  82 total
[badtz:~/terrain] wc -l ter.cc tile.cc Makefile
  42 ter.cc
  40 tile.cc
  15 Makefile
  97 total
[badtz:~/terrain] grep -v '^$' ter.cc tile.cc Makefile |wc -l
79
[badtz:~/terrain] 

it would actually be less, as a third of ter.cc and all of tile.cc are for image manipulation. i don't care about the actual images. i care about the data that the images represent.

what i do with the data is the cool part.

[12:47] | [/] | #

catch(const boost::filesystem::filesystem_error& e) {
	std::cout << e.what() << std::endl;
	std::cout << e.system_error() << std::endl;
	}

// b::f::basic_filesystem_error is derived from b::f::filesystem_error
catch(const boost::filesystem::basic_filesystem_error<Path>& e) {
	std::cout << e.what() << std::endl;
	std::cout << e.system_error() << std::endl;
	std::cout << e.path1().string() << std::endl;
	std::cout << e.path2().string() << std::endl;
	}

[11:33] | [/c++] | #

File Type	Video Codec/Profile	Containers	Claimed Extensions	Streamed Extensions	FAT32 Extensions
AVI	MPEG-4 Part 2 (Simple Profile) MPEG-4 Part 2 (Advanced Simple Profile)	AVI	.avi, .divx
H.264	Baseline, main, and high (up to level 4.1)	MPEG-4, QuickTime	.mp4, .m4v, mp4v, .mov, .avi	.mov, .avi	.mp4, .mov, .avi
MPEG-4 Part 2	MPEG-4 Part 2 (Simple Profile) MPEG-4 Part 2 (Advanced Simple Profile)	MPEG-4, QuickTime	.mp4, .m4v, mp4v, .mov, .avi
WMV	WMV7 (WMV1) WMV8 (WMV2) WMV9 (WMV3) VC-1 (WVC1 or WMVA) in simple, main, and advanced up to level 3	ASF	.wmv

# v:H.263 a:AAC c:MP4, streaming (.avi to trick the xbox)
ffmpeg -i input.file -vcodec libx264 -acodec -libfaac -f mp4 output.avi

[19:39] | [/xbox360] | #

echo -en "\033%-12345X@PJL RDYMSG DISPLAY=\"Cake\r\n\033%-12345X\r\n\"" | nc printer 9100

[16:19] | [/] | #

there. i said it. a devoted user for 20+ years, and i'm finally willing to admit that this piece of shit eats my balls.

i just installed XEmacs from source. again. why again? it's just one of those packages i like to manage myself, since no single Linux distribution can seem to do a decent job of it with their crappy package management system. that's not the point though. the point is (X)Emacs eating balls.

take this little tidbit from XEmacs's ./configure --help

  --with-menubars=TYPE    Use TYPE menubars ('yes', `no', `lucid', `motif',
                          `athena', `gtk', or `msw'). The Lucid widgets
                          emulate Motif (mostly) but are faster. *WARNING* The
                          Motif menubar is currently broken. Lucid menubars
                          are the default.

oh! thanks for letting me know that Motif menubars are broken. damn. sucks for anyone stuck using Motif. the warning's not such a big deal. the big deal is that this warning has been there since 1996. twelve fucking years! proof? it's here. i swear to the FSM that this was the case in '94 too, but i can't find anything earlier than v19.14. ytf is (let's say) 12 year old broken ass code still even in the fucking code-base? who-tf even uses Motif anymore anyway? IRIX? uh, IRIX is EOP as of December '06. Solaris? They've had GTK+ since 7? 8? HPUX? who-tf cares about HPUX? the last reference to motif on comp.emacs.xemacs was in 2005. seriously, cut that shit out like a frostbitten toe or a botfly.

GTK+? it only took about 5 fucking years to get that implemented!

Fontconfig? oh holy flying fuck at a rolling donut. here's what set me off this time. Xft support was finally released in XEmacs with 21.5.24 on December 18, 2005. Xft support was first announced as being "real soon now" in the release announcement for 21.5.17 on March 22, 2004. the first public patches i can Google are from July 29, 2003. it's now January 28, 2008, and the Xft support is still fucking broken and inconsistent! four and a half fucking years and they still they still can't get the fucking X resources straight. example:

!this sets up fonts for specific XEmacs faces
XEmacs.default.attributeFont:           mono:size=10
XEmacs.bold.attributeFont:		mono:size=10:style=Bold
XEmacs.bold-italic.attributeFont:       mono:size=10:style=Bold Oblique
XEmacs.italic.attributeFont:		mono:size=10:style=Oblique
XEmacs.modeline.attributeFont:		Bitstream Charter:size=8

!this sets up fonts for specific XEmacs widgets
XEmacs*Tabs.xftFont:			serif:size=10
XEmacs*menubar*xftFont:                 serif:size=10

oh ho! XEmacs*menubar*xftFont is fucking broken! the correct resource is XEmacs*menubar*fcFontName! where is this documented? oh, no where except the mailing list archives, which you can't search because they're at tux.org and tux.org has been broken for 15 fucking years.

so, for my benefit, here are working X resources:

!this sets up fonts for specific XEmacs faces
XEmacs.default.attributeFont:           mono:size=10
XEmacs.bold.attributeFont:		mono:size=10:style=Bold
XEmacs.bold-italic.attributeFont:       mono:size=10:style=Bold Oblique
XEmacs.italic.attributeFont:            mono:size=10:style=Oblique
XEmacs.modeline.attributeFont:          Bitstream Charter:size=8
!this sets up fonts for specific XEmacs widgets
XEmacs*Tabs.xftFont:			serif:size=10
XEmacs*menubar*fcFontName:		serif:size=8:style=Bold

(oh, XEmacs still checks the resource XEmacs*menubar*Font even though it's not supposed to do anything when Xft is enabled!)

how did i find that out? beacuse i spent over an hour dicking with various settings to get it to match the way it looked yesterday before i reinstalled my system. and yes i'm using the same X resources and the same Fontconfig settings. how do i know? because i checked them into git before i reinstalled, then checked them back out, afterwards. so either XEmacs is fucked up or git is fucked up. take your pick as to which is less frightening.

no small wonder why Eclipse has exploded. shit, they even have COBOL support.

[04:15] | [/xemacs] | #

[S+Z] ustreamer|983 (~ustreamer@dev-8260F538.dsl.ksc2mo.swbell.net) has joined
      channel #Zooomr-TV
<ustreamer|983> ddasf
<ustreamer|983> have you ever
<ustreamer|983> stumbled across a chat box
<ustreamer|983> and just wondered for
<ustreamer|983> a minute 
<ustreamer|983> if anyone was really reading, chatting, or even remotely
                likely to do either?
<ustreamer|983> i had that feeling.
<ustreamer|983> so i started typing.
<ustreamer|983> according to the list on the right side
<ustreamer|983> there are about a dozen other people with a plain view of this
                chat box.
<ustreamer|983> none are chatting.
<ustreamer|983> none are acknowledging.
<ustreamer|983> but the chat feature stays.  
<ustreamer|983> we don't know why
<ustreamer|983> but we know
<ustreamer|983> it's interactive
<ustreamer|983> and that's considered an a priori good.  always has been.
<ustreamer|983> even the Web 0.0, before we gave it volume names,
<ustreamer|983> was a project in interactivity.  
<ustreamer|983> the communicative action.  the information sharing.
<ustreamer|983> always the big deal.
<ustreamer|983> even though most real users have long been guys downloading
                and collecting porn.
<ustreamer|983> hey, those guys will also use the net to talk about porn with
                one another.
<ustreamer|983> interactivity, baby.
<ustreamer|983> anyway, it's all communication all the time and the natural
                extension of that
<ustreamer|983> thinking is to create and maintain chat boxes.
<ustreamer|983> it's like building little islands of communicative hope where
                no land was before.
<ustreamer|983> sort of like thumbing your nose at the "old net" and raising
                the 2.0+ flag.
<ustreamer|983> COMMUNINTERACTIVITY
<ustreamer|983> problem.
<ustreamer|983> a dozen people.
<ustreamer|983> a chat box.
<ustreamer|983> no one's chatting.
<ustreamer|983> maybe their downloading porn?
<ustreamer|983> if you read this, please go to the worst site on the internet:
<ustreamer|983> http://rachel-ray-info.blogspot.com and leave a comment on the
                first post you see.
<ustreamer|983> ADIOS
[S+Z] Signoff: ustreamer|983 (Client exited)

[13:59] | [/zooomr] | #

[00:00] | [/zooomr] | #

... from '99 - '02 have been added but r/o by me.

[00:34] | [/] | #

whee

[18:14] | [/] | #