smedleyisageek

So awhile ago I had the idea of grabbing all the items from a vast swathe of rss feeds that I would regularly add to my google homepage if I actually had enough space for them all, and selecting a random set of items from all of those feeds to display. This evening I had a bit of time and decided to actually do it, since I reasoned it would be a fairly simple task. I had a quick google and found this, but that is a lot of stuff for what really only needs to be a small php script at best. After all, you’re only grabbing a bunch of current feeds, combining all their items, shuffling that item array and selecting the first n elements! So anyway, it was very simple after installing the pear XML_RSS package. I don’t do that much php and didn’t have much time, so forgive the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48

 
<?php echo "<?xml version='1.0'?>"; ?>
 
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
         xmlns="http://my.netscape.com/rdf/simple/0.9/">
 
<channel>
 <title>Tavis' Random RSS Items</title>
 <link>http://smedleyisageek.net</link>
 <description>Ten random feed items from my favorite sources.</description>
</channel>
 
<?php
 
require_once("XML/RSS.php");
 
$items = array();
$feeds = array(
    "http://rss.slashdot.org/Slashdot/slashdot",
    "http://newsrss.bbc.co.uk/rss/newsonline_uk_edition/front_page/rss.xml",
    "http://feeds.digg.com/digg/container/technology/popular.rss");
 
foreach($feeds as $feed){
 
	$rss =& new XML_RSS($feed); //assign by reference, not required in php5 +
	$rss->parse();
 
	foreach ($rss->getItems() as $item) {
          $items[] = $item;
	}
 
}
 
shuffle($items);
 
for($i = 0; $i < 9; $i++){
?>
 
<item>
 
<?php
	echo "<title>".$items[$i]['title']."</title>\n".
	     "<link>".$items[$i]['link']."</link>\n";
?>
 
</item>
 
<?php } ?>

It is unlikely to be useful to anyone, but as a very brief toy project it certainly suffices for my needs.

So I sat down the other day with the idea of creating a simple photologging (or photoblogging, whatever floats your boat you horrible pedant) system. This would comprise a mobile component, written using JavaME, and a server component that would be written in php; JavaME because it’s vaguely quick and easy and I’m pretty sure it’s the only development platform supported by my phone and php because it’s quick and easy and I’m pretty sure it’s the only development platform supported by my webhost. Well, that last bit isn’t strictly true. But shut up.

Initially the project went well, in about an hour and a half (possibly two hours, I can’t recall too specifically; my apologies) I had the basic system working fine sending raw binary data to my php script, which would just dump it to the filesystem with a timestamp. This works ok for the moment because the image is only ever either sent after being taken or discarded if there is no internet connection (although this behaviour may change later if I can be bothered). Then I tried to upload it to my webhost, at which point the horrible hours of pain and suffering started. I was getting a 411 Content Length required error from the server. Without including too many details, this is essentially because JavaME requires HTTP1.1 compliant servers and automatically chunks data over a certain size. My hosting provider’s server, though saying it was HTTP1.1 compliant, was obviously lying.

After many hours of googling, I had to conclude that it was either a problem with the hosting provider’s apache or php installation, and I still have no idea what the specific issue is - their Apache sends data using chunked transfer encoding, which is confusing. Their support just took my word that it was probably apache and said they couldn’t do anything about it, which was obviously fucking awesome customer support right there. My eventual solution was to create a temporary php script on my home server, which then sends the files on to my shared hosting server. It’s a crap solution. I had tried a great deal of other solutions, including direct socket communication with the server - this worked on the emulator, but sadly threw a SecurityException on my phone - apparently, making direct socket communications to certain ports (including 80) on a remote server is not allowed without a signed midlet. I don’t want to pay for a certificate, and I can’t use a self signed one with my mobile. I hate midlet signing. With a passion. This dude can explain why!

Also, I’m hungover. But at least my program does what it’s supposed to, albeit via an unsustainable hack. Once I’ve polished it up a bit I’ll post the source. The photolog is on the main menu or you can click here!

This is a very old post from a very old version of this site. I don’t have the whole posting, so I’ve guessed the last bits:

Stupid though the title may be, this very useful functionality is something present in bbwin (and therefore maybe the original blackbox? Not sure). So I had a hack around in the fluxbox source and implemented the behaviour myself:

1. Create two method prototypes in Window.hh (in the fluxbox source): void nextSpace() and void prevSpace()

2. Implement the methods in Window.cc:

void FluxboxWindow::nextSpace() {
screen().sendToWorkspace(m_workspace_number+1,this,true);
}

void FluxboxWindow::prevSpace() {
screen().sendToWorkspace(m_workspace_number-1,this,true);
}

3. Add event handlers for the mousewheel up and down (so that the above methods are called when the wheel is used on the window title bar) in setupWindow():

That’s where the original post ends So I’ve guessed the following after looking at the fluxbox 1.0 stable source code for Window.cc:

frame().setOnClickTitlebar(nextSpace, 5 - reverse);   // next space on wheel up
frame().setOnClickTitlebar(prevSpace, 4 + reverse); // previous space on wheel down

Looking at the source code, and looking at my hack, I would probably recommend going about it another way; however I can’t remember when exactly I did this or why I chose to do it that way… there also may be further lines to this, although I don’t think so!

I’ve tried to keep the original post title intact as it is vaguely amusing. I also built a debian package and used this code for quite some time some years ago, I should probably look into doing it in a better way as I recall it being quite useful at the time.

Anyway, hope this old Fluxbox hack will be useful to someone someday!

It is on the menu bar!

It is also here!

It will have links and things that I would like to keep track of or share but that I don’t really want to clog up this blog with. Y’all have fun now!

While out in Hoxton last night, we wandered under a bridge and found a band called United Vibrations performing. I got a crappy cameraphone photo:

They were amazing, we hung out for a good 20 minutes as a crowd gathered under the bridge. It was surreal but fun, if we’d had beer we would’ve stayed all night I think Steve and I bought their album, and this is their myspace page. Well worth a listen!

I’ve finished the first game I started since playing with javascript for games (and html tables for rendering!). It’s a simple gravity game, not particularly challenging, but does obtain level structures from bitmaps parsed within javascript! W00! It’s fun to play I think, although is really just a tech demo of sorts:

Gravity Game

I’ll probably leave it as a work in progress and add more levels to it. It currently loads levels via synchronous xmlhttp requests though, which I acknowledge to be a bit of a bad idea, but I was hungover today and didn’t want to mess around restructuring the game to handle asynchronous loading. It did make me think about writing an event driven game engine though, I implemented one in python once based on sjbrown’s guide to writing games, which has apparently been recently updated, hooray! It would be fun, indeed

The other day I felt I needed to add support for loading actual images that could be used as sprites or collision maps. I had a play around and found that the easiest way would be to have an XMLHttpRequest calling a simple python script I knocked up that would load an image and return the pixel data in the preferred format. However, as far as I’m aware my hosting provider doesn’t support python, and I got interested in the potential for simply requesting a bitmap file from the server and parsing it in Javascript. So, after a bit of reading (and struggling to parse the bitmap file I was using to test with, which turned out to be the wrong type of bitmap) I eventually managed to get something up and running.

The only issue really was getting the binary data into Javascript; I stumbled across this which sorted that out nicely. Having said that, it’ll probably only work in Firefox. But then, I’m pretty sure the game and graphics libraries I’ve got here will only work in Firefox for the moment anyway

Bitmap Demo

The above link should show you a bitmap image, rendered to an html table. The Bitmap class is now part of the quirkybadger library.

Are combinations of adjectives and animal names that amused me. So I’m stealing them! Why, you may ask. Well for starters they amuse me, but secondarily I needed to name the two projects I’ve been fiddling with in the last couple of days. The first I mentioned yesterday, it’s a 2d renderer in javascript that uses an HTML table as its display. It shall henceforth be named QuirkyBadger. The second is a game framework, again for javascript; currently it provides simple stuff like input handling and a framework for managing the main update and render loop. It is known as the mighty IntentionalPanda. There’s lots more that can be added, this is just what I’ve managed to get to so far.

It’s really interesting stuff actually, there’s a vast amount of optimization that I’m sure can be done with the rendering engine - I’ve already managed to get from 2 fps to lots (ish) by direct rendering to the HTML table and by disabling screen clearing. Initially, every render cycle I was:

• Setting the background of all the cells in the table to black
• Going through the level’s ‘model’ matrix (containing the tile values, please see the example source for more detail) and writing the pixel values of each image comprising the level to the table
• Going through the player’s image and writing its pixel values to the table

Now, it should be noted that I’ve no real graphics experience at all and started doing this myself a couple of days ago, without knowing any traditional techniques for 2d rendering other than the vague notion that pixel values have to end up on a physical display comprised of pixels somehow So, the first optimization I tried was to use a ‘buffer’ matrix, the size of the ‘display’ (table, ha) and then write all pixel data to that before writing that entire matrix to the display. That was pretty fucking stupid wasn’t it! Ha! Since the bottleneck appears to be how many ‘writes’ you do to ‘pixels’ in the ‘display’ every render cycle, it turned out to be a bad idea since you are then modifying the maximum possible number of pixels every single render cycle.

So, optimization number two - go back to direct rendering (if a call to graphics.drawImage occurs, we immediately modify the pixels in the display). Stop clearing the display every render. Stop rendering the ‘level’ (essentially, the background) every render. Only update the pixel values of moving objects. This appears to work very well, but the thing to solve now is how to update portions of the background that moving objects overwrite, back to their previous pixel value. Then we should have something reasonable to work with. I mean, rendering the level every update cycle will work, but you only get about 18 fps on my box, so I think I need to go and look at existing software renderers and see how they do it. I’m also pretty sure I’ll need to learn about matrices properly and matrix arithmetic specifically, particularly when I add functionality to rotate images, etc.

Anyway, I hope someone will find these projects interesting, and I’m hoping to have a working demo of the two in action at some point before the end of the day.

A tiny update just to mention that I’ve been playing around with rendering methods in javascript and have decided on a technique that I like. It’s detailed here. It’s rough around the edges, needs a lot of work and is perhaps a strange approach; I’ve explained more about the why on the project page though.

I’ve also had some friends join in a little game with so few rules that you may not even consider it a game: adjective animals. Contributions are more than welcome in the comments on that page! The rules are also there, but the clue is really in the name

I had a bit of a thought today regarding javacript games. I think I may have played a javascript game once, in fact, I have - robotfindskitten is exactly that. However, I’ve never really thought about how one would go about doing it until today, and so I had a go:

Javascript Dungeon Game

I suppose it’s funny really, I’ve never considered the potential for making games with javascript. After all, it’s a pretty flexible language, supports object orientation, provides the ability to manipulate a view by way of DOM elements and css as well as supporting event driven programming (which I’ve played with before in the context of game creation and found interesting and useful). So above is a first bash, pretty simple game. After I’ve added the logic for going to the next level (and have created some more levels!) I’ll be rewriting it mostly using proper object orientation, and fixing some of the bugs. I would also like to explore using a similar concept for a platformer (probably using a table again, as I like the simplicity it provides for the rendering). Hope you enjoy!

As a brief note, I am aware that there are potentially ‘better’ ways to create a graphics rendering engine in javascript, using css and divs or using the canvas tag; the method used here is just something that seemed relatively intuitive to me at the time. And it’s ok, I think it’s potentially a viable method - cell widths and heights could be reduced to create higher ‘resolution’ but I’ve had a few nice ideas for more arty games just using large blocks of color that could still be fun. Far more importantly, I think it allows prototyping experiments with gameplay without concentrating on graphical sexyness.