Archive for the 'FreeBSD' Category

18
Apr
15

Xsokoban on NetBSD

Having been busy and stressed out lately I haven’t had much time for tinkering or gaming. This is where smaller games that you can play as a quick distraction can help, as they are easy to squeeze in between other jobs, and todays game is one such game.

Xsokoban is obviously a clone of the old classic game sokoban. The original was made for the PC-8801 way back in 1982 by Thinking Rabbit. It has since been implemented and ported to pretty much every system, Xsokoban is one such port for Unix systems running X windows.

There isn’t anything really remarkable about this particular port. The quality of the graphics is quite reasonable, and it works well on pretty much any system I’ve tried it on including my older machines such as the Sparcstation 20. I’ve even played it over SSH via my comparatively slow ADSL2 connection, and it worked really quite well.

Interestingly the game has been studied in the field of computer science, it turns out it’s quite a difficult problem computationally, being PSPACE-complete. Lots of different researchers have worked on different algorithms for solving and producing optimal solutions. The complexity certainly makes me feel better about getting temporarily stuck on level 6!

As far as enjoyment goes, it’s really enjoyable for the puzzle solver in me, even when I’m stuck. It doesn’t take a huge commitment to play for a short while, and is quite challenging! This particular port isn’t any better or worse than any other, so don’t go out of your way, but NetBSD and FreeBSD users will find it easy to get running.

This slideshow requires JavaScript.

14
Nov
13

Some words on X windows

I’ve recently been reading about and watching a few videos about the replacement for X called Wayland. Now I know very little about Wayland itself, but I’ve been a user of X since about 1999 when I first went to university, so I can’t help it, I feel moved to write about my current and old experiences. X is actually really quite an old protocol and was designed with different goals in mind than those modern desktop environments have today. The history is written all over the internet so I won’t repeat it, but it is evident that X was originally meant for the X-terminal connected to a mainframe case that was so very common at the point of its inception.

One of the questions asked was “what does X do well?”

Lincity via SSH

Lincity via SSH

The core of the X protocol is based around drawing primitives such as lines and circles but also includes pixmaps (bitmaps for those who don’t speak X). Here is an example screen shot of a program, lincity, that was one of the first games I wrote about here on my blog. In this case I’m running it through an SSH tunnel over an ADSL line with a maximum upload rate (to the X server) of about 75Kb/s. Because of the way X works lincity is not only able to draw to my remote display, but is able to animate the play area at a reasonable rate. This situation is something which VNC and RDP just can’t do over my connection. The remote machine running lincity is my old Sparcstation 20 with 2x 50Mhz supersparc processors, running a pkgsrc build at the same time.

Working remotely

Working remotely

Here is another screenshot of me monitoring my old Sparc, again doing a pkgsrc build (they take a long time with only 50Mhz you know). I’m able to get real time performance graphs and interactive terminals, all using about 5-7Kb/s data through a SSH tunnel, and much less when the remote windows are not visible on the screen. This kind of use if very common for me, not just to old machines, but also modern ones that are around my workplace, X and SSH makes it easy to start a program from any machine. This is very handy for testing and I can run software from home or work as I need.

XDMCP Chooser

XDMCP Chooser

My machines at home are running NetBSD, FreeBSD and Gentoo currently and whilst some of them are capable, none currently have a head attached. So I frequently use XDMCP and a X server on my windows machine to access them, and it works basically flawlessly. I realise this is a less common situation now, but with thin clients becoming all the rage in different forms, it seems this feature of X could be exploited more.

FVWM on my Sparc

FVWM on my Sparc

I love that there is so much variety in window managers and that there are light ones that make even my oldest machine quite usable with recent operating systems. Pictured here is my nostalgic favourite FVWM, which incidentally is still being maintained and developed. Windowmaker, openbox, fluxbox, etc, all deserve to exist and have a dedicated user base. They are interesting and useful, but mostly truly light-weight, making using older hardware viable. People like myself who collect and use old hardware find this useful to keep life in their old pride-and-joys.

No matter how it is implemented under the hood, for users the network feature of X is seamless and very easy to use, in no small part due to the hard work of the X11 developers, many of whom are working on Wayland. So what motivated the big change?

One of the major factors is X is becoming too large and difficult a project to develop and manage. A contributing factor to this is the explosion in extensions to it that made it kind of bloated. It seems they were sort of added willy-nilly (mostly during the Xfree86 days) to meet the demands of people developing the more eye-candy based style desktop environments we see now. Fortunately the X developers have been cutting much of the debris out of the extensions and have made the X server modular. Now if only the X server was actually installed/packaged in separate modules for each extension and the core it might make having a slimmer server easier, but as far as I know that’s not possible.

Personally I’ve not had much trouble with X. I mostly had problems with getting proprietary drivers to work for my GPU back in the Xfree86 days, but I’ve not had that problem in ages. I have only really seen the flickering that has been talked about over high latency network connections, never over any LAN I’ve ever used. I understand that it probably does have huge design flaws, and that a newer system and design is needed to meet the needs of new desktop environments. I just feel somehow, that when it’s gone I’ll miss X.

04
Feb
13

WindowMaker on FreeBSD

The basic WindowMaker interface plus a few applications.

WindowMaker on FreeBSD

This weekend I decided it was time to upgrade the software on the two functional Sun Sparc systems I have. I have FreeBSD on the newer of the two machines, and had been trying various window managers to use. The older Sparc has FVWM (recently upgraded to the latest version) on it so whilst it is really my favourite for reasons of nostalgia, I felt I’d like something different. I had tried XFce, but many features of it were broken on the FreeBSD/Sparc64 platform. So I installed a few other window managers to see what they were like.

I had never installed WindowMaker before but had certainly heard of it. I remember looking through many package lists to see many of the dock apps, and wondering about the window manager itself. WindowMaker has a similar style to the old NeXT workstations operating system called NeXTStep the system that would eventually become mac OSX.

The first thing I noticed when I fired it up was how minimalist it appeared to be. I found the root menu relatively quickly and managed to work out most of how it works within a few hours. I was quite impressed with how fast the interface responded when I clicked on items, although FVWM is a slight bit faster but not by much. There is a very nifty configuration program built-in that controls pretty much everything you could want to change. This makes it very newb friendly, I was able to set up my desktop the way I wanted it very quickly.

It isn’t the most pretty of window managers however, and there is no pager built-in. Workspaces are managed by the clip icon, usually at the top left of the screen. When using it via X on the local network it was quite fast, but over a VPN or SSH connection it became quite sluggish when FVWM maintains reasonable speed. I’ve heard that it can get slow if you have a large number of dock apps running.

Overall I quite like WindowMaker, whilst it isn’t a replacement for FVWM for me, it will be a nifty interface for my newer sparc machine. I like that I can configure most things with the user interface, and the large number of dock apps available for it. It isn’t so useful when I’m connecting into my machine externally however as the speed drops of significantly. It’s available on all the different distributions and the various BSD systems.

26
Nov
12

Freeciv on FreeBSD

Main Menu

Main Menu

Quite some time ago I worked at a radio telescope for 3 months as part of my work experience for my engineering degree. During that time I had an incredibly old machine as my work station, it was an original Pentium running at 77 Mhz. Because it was so old and because of the job I was doing I installed Linux on it. I used my favourite old school window manager (FVWM) and had it set up pretty sweet.

One of my duties for a short period of time was looking after the telescope after hours. This was called being the duty astronomer and was something everyone did at sometime during the year. Basically you were on call for if something happened to the equipment that the remote astronomer couldn’t handle. Most of the people using the telescope were often some distance away and did observations remotely thanks to the power of the net.

The main view

The main view

So I was spending many hours at my workstation after work hours, not working, and watching the telescope and waiting for something to happen. This is when I installed freeciv and started playing. Surprisingly even on that hideously old machine the game played quite well and was quite enjoyable.

The city screen

The city screen

Recently I compiled and installed it on my sun fire R280 machine which is running FreeBSD. The machine is headless so I was accessing the machine via XDMCP in order to play. There are too many graphics to play the game via a VPN connection, but it works very well over a LAN connection, mine is 100Mbps so it would be significantly better on gigabit.

City production

City production

I was playing on the standard GTK based client, but there are other clients with support for the Xaw, Xaw3d and SDL toolkits so you can get it to work on systems without GTK installed. Most of the clients look pretty much the same with the exception of the SDL client which imitates the interface of the newer civilization games.

Research tree

Research tree

The graphics for units and the terrain are consistent across all the clients so you won’t be confused trying to identify units or terrain. There are several tile-sets to choose from as well so you can customise the way the game looks. Unfortunately the newer versions of freeciv don’t have as many tile-sets available as the older ones. Some times I have found some of the text is difficult to read because it is so small.

Other civilisations

Other civilisations

If your platform supports sound there are some sound effects for events such as combat. On the sun machine I didn’t have sound, however I do have it working on my macbook running the SDL client for freeciv. The sound is reasonably good, but not essential to game play. There isn’t any music in the game, but this leaves you room to play some of your own.

The SDL client

The SDL client

The game play is of course very much like civilization. The default rules most resemble the rules of civilization II with some differences. There are different rule sets that you can use, for instance there is a rule set for the first civilization game. There are unfortunately many subtle differences in game play that may annoy some players. The main draw card here is that multiplayer games are supported. This is reflected in the way diplomacy works differently to the commercial games.

Personally I actually prefer the original civ II game play, graphics and sound, but freeciv has some merit of its own. There are some features that are nice such as extremely large maps, and many more players in one game. The rules are subtly different which can change some of the strategies for play, but for the most part the same strategies will work. It still is fun to play for me, but it really will be a matter of personal preference as to whether you enjoy it or not.

This slideshow requires JavaScript.

02
Oct
12

XBlast on NetBSD

XBlast was created by Oliver Vogel and Garth Denley between 1993 and 2006. It is a multi-player game that is based on the Bomberman games which were popular on many old home consoles as early as 1983. I had never previously played a Bomberman game before so I have very little frame of reference for comparison to the older original games,  many of which I’ve read about have a similar multi-player facility. I built XBlast on my old Sparc hardware as I have done for many of the old X based Unix game. It built with out any problems and seems to run quite well even via XDMCP over the network. I haven’t tried building it on other platforms but I suspect that it would work on most Unix like systems.

The graphics for the game are colourful, and look fairly nice. Like I said they seem to work over the network with very little to no performance issues at all. The user interface has many options and I found it a little confusing to use, in particular when trying to use the network play options on what they call central. The game has an option for sound, but that did not work for me on the Sun platform so I can’t really comment on the quality of it.

There is no single player option really for this game, you can play multi-player games over a LAN, the internet, or on the local machine by sharing a keyboard or using multiple controllers. I wasn’t really able to get multi-player working, either because there is no-one on-line or because I couldn’t work out how to get the internet play working properly. I was able to play against an AI on the local machine and found the game was a little confusing to play at first. The controls for movement seemed to worked fine, but when I tried dropping bombs I’d find that it was a bit slow to do so, or wouldn’t do it at all for some unexplained reason. The game basically involves running around trying to get power-ups whilst avoiding bombs and laying your own to get your opponent. There was little of any kind of puzzle element and after a period of time the level space would start shrinking until some one gets killed or caught in the new wall sections appearing. There are many different levels/arenas for you to play in each with it’s own rules for game play. Some are quite large whilst others are relatively small. They change your strategy in where you try to place your bombs, and how you go about avoiding bombs placed by other players.

I think the software itself and the graphics are crafted quite well, but the game does get old fairly quickly. I think that it would definitely benefit from having a single player campaign with puzzle elements much like the original Bomberman games. I found myself getting bored fairly quickly, and I didn’t really enjoy the experience. This may be different for you if you liked the multi-player elements of the Bomberman games, or if you were a fan of them. Otherwise I’d suggest you’d probably be better off finding another way to entertain yourself.

23
Sep
12

Xboing on NetBSD

Xboing is a breakout style game for the X windows systems, it was written by Justin C. Kibell in the years 1993 – 1997. It is written using the basic X toolkit libraries so will run on pretty much any Unix system with a half decent compiler set. The game models itself after an arcade machine, and even goes as far as having an attract mode (or demo) to show the basics of the game.

The graphics are very colourful and pleasing, and I’m happy to report it works very well even on very old hardware, or via an XDMCP session over the local network. I found it worked quite well on my old sparcstation. The animations and movement of the paddle and ball are fast and this helps the controls be responsive.

Sound didn’t work very well for me, it froze the game on the sparc, which could be caused by any number of issues. The game doesn’t suffer for not having sound, so if you have similar issues, I’d just turn the sound off.

Gameplay is very similar to all the other break out classics around with some differences. For instance, the power ups do not drop out of bricks when they are broken. Instead they themselves are bricks that when you break them give you the power up contained therein. You get a limited supply of bullets in the game to help you clear areas faster. This is very handy when there are only a handful of bricks left that are quite hard to hit with the ball. That being said, because you have a limited supply, you aren’t tempted to go shooting down every brick in a level as it will affect how much ammunition you carry over to the next level. Interestingly you can accidentally shoot your ball and end your game if you aren’t careful. I’ve also noticed you can squeeze the bullets up between columns of blocks to hit something at the top of the screen. This was useful when the “eyeball dude” went past, I had a chance to shoot him for points.

The default setting for the game is quite fast, so you will probably want to slow it down. Don’t slow it down too much however as this impacts your ability to score and get bonus score for completing a level quickly. Control is via the mouse, and is very responsive and quick. The only problem I had was when I accidentally moved my mouse out of focus and the paddle stopped moving. This may not be a problem for you depending on your window manager, I could always configure mine to improve the situation!

I found that the game was quite fun, and offered something different to the other breakout games out there that mostly follow after the classic Arkanoid. The challenge is high enough depending on the speed you set, and you shouldn’t find yourself bogged down trying to get that last one or two bricks for very long. So if you are a fan of breakout games, have a Unix system, and want to play a good breakout game, I’d recommend giving Xboing a try.

18
Sep
12

Xpilot on Mac OS

Xpilot is a game very much like Thrust on the C64, but with many more complicated features and game-play. The game is one of the pioneering games in internet gaming, it was one of the first to include in game chat and different game modes such as capture the flag. It was written for unix workstations, and the first public release was made back in 1992 by Bjørn Stabell and Ken Schouten. Xpilot runs on most unix systems including Linux, FreeBSD, NetBSD, Mac OS, ans Sun OS that I know of, in theory if the X libraries are installed Xpilot should run on it. You can build it under cygwin for windows, but I believe that there is a proper windows port you can use.

I built the game on my macbook which runs Mac OSX Lion. It was fairly straight forward to build, but I needed to install the imake utility from macports to make my life easier. I also had to modify some source code very slightly for it to work on my computer, so I would suggest using the version of it in Fink. I have previously built and ran the game on NetBSD, Linux and FreeBSD without any issues.

The games system requirements for getting it to work are fairly low, but it’s a good idea to not run it on very old hardware. Anything younger than about 10 years old should be fine. It can demand a lot of the X server, and can require a lot of your network if your X server isn’t local to where the game is running. I tried running the game on my old sparcstation to see how well it would work, it seemed fine, but the server used all of one CPU and the client a good part of the other. I was running the X server on my desktop machine which was taking some of the load off, so it would be unlikely that the old machine could have coped very well with the full load of the game unless I upgrade it.

Because of the systems the game was meant to run on originally, there is no audio as many X terminals never had sound and there wasn’t a uniform way to access audio hardware when it was first written.

The game play seems very complicated at first, there are tons of controls, options and bonus pickups to learn about. The initial keyboard controls are a bit unintuitive, so it is a very good idea for you to change them before hand. This can be a little difficult because you need to modify your configuration file to do it. Once you have changed to controls to something that suites you better, it is a much easier and better game to play. I found I was woefully outgunned against a bunch of robots, and I am still pretty much a newbie at piloting. My scores often go negative. Very negative. I have occasionally done better but that was weirdly enough when testing on the sparcstation.

If you’re looking for more information about how to play or configure the game there are numerous newbie guides of which I found this one to be quite good. The game is very addictive and quite fun (more so against humans than robots!) and many people still play it today. There are also a couple of newer ports that are partly compatible with the original called xpilot-ng and xpilot5. I’ve also noted there is a java client available on source forge and an app for the iPhone available. I tried xpilot-ng quite a while ago and think it’s pretty alright, but I haven’t tried the others for comparison.




Blogs I Follow

Enter your email address to follow this blog and receive notifications of new posts by email.


Mister G Kids

A daily comic about real stuff little kids say in school. By Matt Gajdoš

Random Battles: my life long level grind

completing every RPG, ever.

Gough's Tech Zone

Reversing the mindless enslavement of humans by technology.

Retrocosm's Vintage Computing, Tech & Scale RC Blog

Random mutterings on retro computing, old technology, some new, plus radio controlled scale modelling.

ancientelectronics

retro computing and gaming plus a little more

Retrocomputing with 90's SPARC

21st-Century computing, the hard way

lazygamereviews

MS-DOS game reviews, retro ramblings and more...