logo

Search

February 1, 2012

Extend a <div> element to the bottom of the page with Javascript

Filed under: Miskellaneous — trentg @ 4:18 pm

This is the situation: You have some kind of footer markup on your page and you want it (probably the background of it, actually) to extend to the bottom of your browser window. Your site is dynamic so it usually does so automatically, but on short pages, it stops abruptly and looks odd. This post proposes a solution.

There are only a few things you need to know:

• Height of the page in pixels (not browser window visible area,
	but the entire scrolling length).
• Position of the top of the <div> you wish to extend.

You need to know how to use Javascript to obtain these values, and how to use it to set the height of the <div> element you want to extend. This is pretty basic Javascript stuff. First let’s look at a function you’ll put in your page <head>.

function extend_bottom()
{
	var e = document.getElementById('element_to_extend')
	var tmp = e
	var o = e.offsetTop
	while (tmp.parentNode.tagName != "BODY") {
		if (tmp.parentNode.tagName == "DIV") {
			o = o + tmp.parentNode.offsetTop
		}
		tmp = tmp.parentNode
	}
	var h = window.innerHeight - o
	e.style.height = "" + h + "px"
}

That is almost entirely all you need. We gave the element to extend the ID ‘element_to_extend’ (ie, <div … id=”element_to_extend” …>… The code grabs a reference to the element, traverses up the node hierarchy to each parent element that has “DIV” as a tagName, and adds the element.offsetTop of each to a variable, o. The height of the element needed is now easily calculated by ‘window.innerHeight – o’. The last line in the function sets the height value in the elements style which ultimately is what does the job.

There is just one more thing you need to do: call this function. The way I’ve done it is to use the <body> ‘onload’ callback. Your <body> tag should look like this:

<body onload="extend_bottom()">

That’s all there is to it. To see it in action, go to this (non-existant) page and notice that the translucent footer extends to the bottom of the page. It should go to exactly the bottom of the page, unless your browser window is very short, so there should be no scrollbar on the right hand side of the page.

Note: updated slightly after original post with a better way to find pixel top of element to extend. Instead of going up parents while the parent is a <div>, we go all the way up to the <body> tag, adding only offsetTop of <div> elements.


January 18, 2012

Very simple perl/cgi based newsletter/feeds application: simplefeeds

Filed under: Miskellaneous — trentg @ 11:17 pm

Since I needed some way to notify our users of updates to our games, and I didn’t want to spend a lot of time evaluating all of the thousands of mailing list/newsletter software available, I rolled my own. And since I see no reason not to, I’m going to share it here. It is about as bare bones as it gets.

The included README.txt will tell you what you need to edit to get it running. The requirements are: Perl, MySQL, a few common Perl modules, a web server with cgi-bin support enabled, cron, and permission to make the required changes to the system/server.

To see it in action and decide if you like it, go here. The README.txt really should say it all, so here is the source code. You may freely choose your own license.

simplefeeds-1.0


December 26, 2011

Steering behaviours to simulate bees or other flying insects

Filed under: Uncategorized — trentg @ 8:56 pm

I have a need for a swarm of bees moving about in a game that can be given some general directions. Directions like ‘move towards this point while remaining in some sort of cohesive ‘pack”. Some of you may already be familiar with ‘steering behaviours’ (they’re nothing new and used extensively in games), and they make this task, which may sound difficult, very easy.

First I’ll try to do my best to define steering behaviours. They are stateless, very specific bits of code that tell an entity (a ‘boid’ when discussing steering behaviours) what it should do. There can be more than one steering behaviour operating on a boid at once, which builds up what looks like sophisticated behaviour from these simple pieces of program code.

There are books and internet articles abound on the subject, so I will just briefly describe the patterns I used to create my bee swarm. The first two are opposites and are the bread and butter of the behaviour. They are usually referred to as ‘cohesion’ and ‘separate’. Cohesion tells the boid to move toward the average position of boids in its vicinity. Separate tells it to avoid colliding into other boids and not to get too close. Finally, to keep the group from dispersing, I used a pattern that I’m not sure has a name. Basically it tells the boid that if it is too far from the average position of all of the other boids, to move toward that average position. Without this I had stray ‘bees’ flying out from the swarm and never returning.

The most difficult part of implementing steering behaviours is summation of behaviours. I’ve read about several different methods, and not everyone agrees on which is best. The most straight forward method is to simply add up all of the forces… you see, steering behaviours do nothing but adjust acceleration of a boid and orient the boid (change its direction). In my case though, I did not really need a direction since bees are visible only as small ‘pixels’ on the screen. When I summed my forces, I made sure to weight them by quantity of forces. If there were 20 cohesion forces and 10 separation, the cohesion forces would be greater. To make things simple, I stored both cohesion and separation forces as position values giving an average position. Then I subtracted the separation forces from the cohesion forces.

Well, source code, a video, and pre-compiled demonstration are worth a thousand words, so I’ve prepared all three. I highly recommend reading up about steering behaviours if you’re a game developer, from a more scholarly source than I. But let’s cut to the chase. Here are the files.

Swarm source code and demo

Swarm video


December 10, 2011

iPad with keyboard case in your lap

Filed under: Uncategorized — trentg @ 4:01 pm

You’ve probably seen the advertisements for iPad cases that come with a keyboard. You might even have one. They look like a mini laptop, and feel like it too. Well, the one I purchased had one flaw: it’s a soft case, so the only thing holding the screen up is a picture frame-like flap that pops out of the back. What’s the problem? When I use my iPad it’s usually on the couch, so that flap doesn’t work (unless you can balance the iPad+keyboard in your lap while the flap sits on one leg — but it’s not easy.)

I decided to make a little project out of this and build a stand I could use in my lap on the couch while still having access to the full keyboard. Here are the steps I took along with some pictures of the final result.

  • Measured and bought some wood. I bought two pieces of maple, 1/2 inch thick, from a cabinetry place in town. I had them cut two pieces about the size of the iPad and keyboard respectively. It turned out due to the size of the hinges (see below) that the bigger bottom piece was about an inch too short, so the keyboard hangs out over the front a bit. No big deal.
  • Obtained some adjustable tension torque hinges. I bought mine on eBay.
  • Bought some nuts and bolts. Screws, I fear, would not hold due to the high amount of tension needed on the hinges to keep the iPad in place while still allowing you to adjust the angle. I bought 8 1″ bolts, 1/4″ diameter, with 8 of those rounded off nuts (see pictures.) They turned out to be almost the perfect size. I may use some loc-tite to permanently affix them at some point.
  • Measure where to drill your holes. I simply marked off some lines with a pencil, put the hinges up to the lines, and used a sharpie to make dots in the holes.
  • Drill the holes. I first used a smaller (5/32″) bit just to start so I’d not slip with the bigger bit. I used a 1/4″ bit to drill the final holes since that’s the size of bolts I bought and also the size of the holes in my hinges.
  • Put the hinges in place and fasten them on with the nuts and bolts. I had to drill out one hole some that was a bit off.
  • Adjust the tension on the hinges. Mine have a phillips head “screw” to do this. You need fairly high tension to hold the iPad up.

That’s it. The results are below. This article was typed using my iPad 2 and this stand.


November 14, 2011

Xbox Live Indie Games peer review process

Filed under: Uncategorized — trentg @ 7:41 pm

I thought that since I now have some experience building, testing, fixing, and having a game approved on XBLIG (Xbox Live Indie Games), I would share my opinions on the platform and processes involved. First, the platform is excellent. You have a very powerful console to develop for, using top notch tools (being somewhat of a Unix geek who uses vim a lot of the time, I’m willing to admit that VS Express is a good development tool), and a very (VERY) easy to use API. But that’s not really the main thing I wanted to talk about in this post.

I’m going to be brief because I don’t have a whole lot to say on this matter, even though I feel strongly about it. The peer review process for Xbox Indie games makes developing for Xbox Indie a risk, and a hassle.

Let me explain both parts. The risk comes from the fact that you can make a perfectly conforming, non-buggy, heck, even FUN game and still have your game denied distribution on Microsoft’s Indie channel. There are two camps on this issue. One believes that approving all games will make the average quality of Indie games drop, and the other believes that all games, so long as they function properly, should be approved. All I have to say about this is that the former camp might have a point, but if you look at the games currently on Xbox Indie, surely, they are not right. Games get approved based on how many people they offend, how vulgar they are, how many memes they use, and whatever else is cool on the internet these days. It’s not about quality. The people who do peer reviews (not all of them, and this is just in my own personal observation) see a funny game title and give it a review. They see a game with potentially more depth but less “lol factor”, and don’t bother. That’s how it seems to me anyway.

The second part, the hassle, comes from the design of the whole system and approval process. One thing I found really perplexing was, if you find a bug in your game while it’s in review, you not only lose all “passing” reviews, but you have to wait a whole week before submitting again, even if it’s a one _character_ fix. Now about losing passing reviews. It’s true that games should be re-reviewed after changes are made, but the fact is, once somehow has reviewed a game, they’re very unlikely to review it again after fixes have been made. They’ve been there and done that. So that lowers your chances of getting enough reviews to be approved. And one final thing before I end this collection of personal opinions, from my experience there is a culture of “you scratch my back, I’ll scratch yours” going on on Indie. Review a few games and you’ll probably see authors of those games reviewing yours too. And in my honest opinion, that could be turned into a real positive for the whole system, if people were honest. Commit to reviewing 10 games, and you’re guaranteed to get 10 reviews yourself. I don’t know how this would work in practice but it sounds pretty good in pixels doesn’t it?

TL;DR: The Xbox Indie peer review process is a pain in the neck for developers. I would much prefer an Apple App Store type review process for Indie.


August 29, 2011

SVN diff on renamed files

Filed under: Uncategorized — trentg @ 12:28 pm

By default an `svn diff -r xx` after svn mv’ing a file will give you a complete listing of both the old and new file. Very difficult to find differences with a complete listing. To get a better diff, you can use:

svn diff --old=https://server.com/svn/path/to/oldfile.ext@REV \
         --new=https://server.com/svn/path/to/newfile.ext

This will give you what you’re probably looking for.


July 24, 2011

Boot a USB drive on a Mac with GRUB

Filed under: Miskellaneous — trentg @ 7:43 pm

Let me start by saying that this solution is by no means perfect, and will only work in certain situations. Let me explain.

In order to do this you need either a) a working optical drive and a Linux live CD with GRUB on it, or b) an existing install of Linux on your Mac which uses GRUB. In my case, my CD drive is not working correctly but I do have Ubuntu installed (a WUBI install) so I can run GRUB from that.

Given those restrictions, the solution is very simple. First thing to do is get to the GRUB screen. For me that means booting Bootcamp, then selecting Ubuntu from the Windows boot menu. Now the hardest part, which is really fairly simple but may require a couple tries if you don’t know your device name/ids.

Press c at the GRUB screen to get a prompt. Now enter the commands:

set root='(hd1,1)'
chainloader +1
boot

Replace hd1,1 with the drive number (the first 1, they are 0 based so here 1 is the second drive) and the partition number (these seem to be 1 based, so here 1 is the first partition). After typing ‘boot’ and hitting enter, GRUB then boots from the drive. That simple.


June 29, 2011

Flaws in “ancient” code uncovered

Filed under: Nooskewl — trentg @ 4:56 pm

Monster RPG 2 has undergone some serious changes over the years. It started out with Allegro 4 and 4.9 backends. Allegro 4.9 (now known as 5.0) has gone from nothing to a complete and stable gaming API, while flip flopping through many revisions, some of which brought major changes and ripped out and replaced major sections of code at times. Monster RPG 2 had to undergo all sorts of changes to keep up with the ever changing 4.9 API.

Since then, the Allegro 4.x code has mostly been removed, and is entirely unused. The bulk of Monster RPG 2 still uses the thin layer that enabled the game to use either the 4.x or 5.x backends.

Monster RPG 2′s code itself has also be rehauled over and over to add new features, optimize slow bits, remove unwanted parts, and fix bugs. All in all the code has actually improved since the early days. However, there are still parts that leave me scratching my head.

Right now I’m working on another update to Monster RPG 2. It will be 1.9 on iOS and 1.2 everywhere else. One of my main goals with this update was to address the creeping problem of slow interface on older iOS gadgets. One big issue was the pause screen (of all things), where on iPod Touch 1st and 2nd generation, reaction to user touch input lagged and was very frustrating to use.

Now I get to the point of this post: to point on how “brushing code under the rug” can bite you in the long run. Here’s a snippet of pseudo-code from the menus:

createPrimaryInterface();
while (in menu) {
    update();
    if (user pressed items button) {
         tguiTranslate(currentInterface, 1000, 1000);
         addNewInterface();
    }
    if (item interface cancelled) {
          deleteItemInterface();
          tguiTranslate(currentInterface, -1000, -1000);
     }
}

The gist of it is, for several sub-screens of the main menu, I was moving the current interface off-screen, then adding the new interface elements and letting the GUI run. What this meant is, even though off screen, the old interface was still being drawn and updated while the new one was in focus! I replaced the translate(1000, 1000) calls with tguiPush() (which pushes the active widgets onto a stack) and the translate(-1000, -1000) with tguiPop() (bringing back the last set of pushed widgets). Slowness problem solved. Now two interfaces weren’t being drawn and updated at the same time! (the stack in TGUI is for inactive widgets, the elements are never used, only complete sets of widgets are pushed or popped from it).

Moral of the story: While everyone can agree that premature optimization is a bad thing, brushing major optimizations under the rug early on is just as bad. Now I’m going to enjoy the glory of Monster RPG 2 on my 1st generation iPod Touch, and look for more laugh-out-loud code that has creeped in over the past 3-4 years.


June 22, 2011

Battled2 0.1 source code released

Filed under: Allegro,Games,Nooskewl — trentg @ 11:12 pm

I wanted to get some feedback from team members on this level editor before releasing the source, but everyone is busy, so, as promised, I’ve uploaded it and linked to it on our free software page. I’m really happy with how my GUI library, TGUI (available on the same page and required, along with the atlas library, to compile battled2), held up in a semi-major application. Enjoy.


June 3, 2011

TGUI2 released with initial widget library

Filed under: Allegro,Games,Nooskewl — trentg @ 6:26 pm

TGUI has long been a GUI without widgets. It was your job to make your own so they look and feel right in your game. However, I recently created a bunch of widgets for the library for use in a level editor, and I plan to continue to both support and extend these widgets.

One problem with the widgets right now is a lack of discipline with naming conventions. Some things are named TGUI_Some_Widget, while some are TGUI_SomeWidget. Likewise, some member functions are named in camelCase and some with_underscores. I plan to clean this all up (Using TGUI_SomeWidget and camelCase method names), but for now I’m releasing beta 1 of TGUI2 as is.

There is a small example in the distribution that shows how to create your own widgets, which I still think is necessary for games. There is no documentation and everything is provided as-is, but it’s quite a nice little library to work with. Just to show you some of the things you can do with it, I’m uploading a demo (Windows binary for now, until it’s out of beta) of the level editor I mentioned earlier. It’s not a typical square tile based top down level editor. This one is for making side scrolling type levels with parallaxing backgrounds and tiles of any size. It’s quite spiffy.

To use all of this you need to have Allegro 5.1. The level editor uses our texture atlas library which was recently released and can be obtained from the Nooskewl Open Source page. Check back soon for the source code to “battled2″. For now, here is what I promised.

tgui2-20110603
battled2-1.0b1

Next Page »