Joomla! 3.1 on XAMPP OS X 1.8.3 PHP 5.5

Today I toyed around with Joomla 3.1. I was asked to take a look at converting an existing Joomla 1.5 site to a more recent version because it’s being hacked all the time. Soon enough I decided that manually converting the existing site to a 3.x version was too laborious to get into, so I would try to make a fresh Joomla 3.1 install and replicate the site in that.

I started out downloading the latest version of XAMPP, as that was the most recommended package for local-hosting Joomla installs. Version 1.8.3 with PHP 5.5 is the most recent at this time. It installed without a problem. Next up was downloading Joomla version 3.1 and unpacking it into the htdocs directory.

From there the Joomla installation procedure started. I pointed the browser to http://localhost/joomla_install and started filling out the required information on the PHP pages. However, every time I completed the first page of information (on admin login and the like) and pressed on to the next page, the animated blue progress bar would show forever. Refreshing the page and trying again yielded the same result every time. I switched browsers but to no avail.

After a short web-search I came up with this link:

http://forum.joomla.org/viewtopic.php?t=808997

which in turn points to the solution here:

https://github.com/joomla/joomla-cms/pull/1309/files

I seems that recent PHP versions deprecated the version of the function ‘preg_replace’ that Joomla uses during installation. Copy-pasting the two new lines into my input.php file did the trick. Too bad the Joomla installer doesn’t warn you about this kind of thing. Searching for a solution like this can be like looking for a needle in a haystack.

Oculus Rift – first experience

Yesterday we hooked up and experimented with the Oculus Rift VR goggles devkit for the first time. It was first and foremost very cool. I can now finally relate to a first-hand experience with the VR goggles and formulate some initial feedback on it.

Starting out

Installation of the hardware is a breeze. This is how you’d want a consumer to setup virtual reality. A USB and DVI plug into the computer, some power to the headset, set your graphics card to clone the image across monitors and you’re good to go. Major props.

Games

We tested a couple of applications:

Epic Citadel rollercoaster
The first demo we tried. Starting off with a painstakingly slow hoist to the highest point of the track we’re launched into a high-speed rollercoaster ride. I’ve been on a couple of real ones before, and the expectancy of experiencing G-forces combined with the immersive visuals threw me off guard almost immediately. Motion sickness was moderate at some of the tight bends but all in all very cool to race around in.

Planet 1 demo
At first glance this demo struck me as a nausea-generator, but it was actually the least discomforting demo we tried. You’re navigating around on a planet surface in some kind of hover-/spacecraft while avoiding incoming meteors. You can fly in every direction, look around you while flying the other way, do 360 loops etc. It’s great to just look around over your shoulder and see the rear side of the plane. What helped greatly here (I think) is the presence of a metal frame around the view position. When you look around you always have a frame of reference (which is similar to the rollercoaster demo; there the motion sickness is not caused by a lack of this frame of reference (the cart’s there, after all) but by the body not experiencing what you think it should, based on what you see).

Team Fortress 2
Once again the experience was very convincing. Looking down to see your virtual body holding a minigun or a bazooka is particularly nice, as is the ability to change the way the headset orientation affects the HUD and camera-behaviour. TF2 also has an in-game calibration method for setting the inter-pupillary distance. Don’t skip out on that step! It changes the image to completely fill up your own vision-boundaries and ‘pulls you in’ even more.

With this game I had the most trouble, motion sickness-wise. We played around with the different configurations camera behaviour and all that changing around, combined with the higher speed of gameplay and running in different directions than you’re looking in left me pretty sick in the end.

TF2 also makes the limited resolution of the displays apparent. Navigating the game’s menus and reading the in-game interface messages is quite hard, even with anti-aliasing up all the way and motion blur and V-sync turned off. The screen-door effect┬áis fairly noticeable as well. Hopefully that will be changed with later iterations of the hardware. I’m also quite curious to see if that would affect the degree of motion sickness I get.

Conclusion

I was most surprised about the motion sickness effects. In all my history of playing games I have never experienced it before, but that turns out to be no guarantee. The resolution of the displays is also a possible optimization.

All in all I think the Oculus Rift delivers a very good virtual reality experience. Installation is very easy, the headset is comfortable to wear and we didn’t have any technical trouble with it whatsoever. We will definitely be experimenting with using this headset for one or more serious game projects.

Talk Nerdy To Me

I’ve uploaded the sheets (they’re in Dutch, mind you) for my talk at ‘Talk Nerdy To Me’, an event about advances in web-development, hosted by NHL.

Get them here.

Even though I’m not much of a web-developer, I wanted to talk about a subject that can be both interesting and useful for a large amount of IT-professionals and students alike: rapid prototyping. Titled ‘Hyperspeed Prototyping’ the presentation focussed on a number of subjects that one can improve upon in order to make the most use of the available energy and enthusiasm when starting a new project. I wanted to point out some strategies and tools that we use at Grendel Games during 10%-time (much akin to Google’s 20% time projects) and during gamejams. How is it possible that functional, entertaining and well-polished games emerge during only 48 hours, whilst some student teams seem to have difficulty getting to that same level during 5 months of development.

The TL;DR of the talk basically boiled down to this:

  • During the initial idea-phase, don’t spend most of your time discussing pros and cons. Try to make choices quickly and channel your energy into building your choices instead. It’s much more fruitful discussing stuff you can actually play and evaluate.
  • Try to get a well-balanced team together. In smallish teams of about 5 people, there’s no room for full-time game designers or project managers. Everybody should be able to contribute assets to the final product in some way. Look for roles adjacent to a person’s skills: a concept artist might be able to make 2D sprites as well; a game designer can write dialogue, etc.
  • Pick and choose technology that matches your team’s skills, but don’t stare blindly at just what you know. Sometimes new tools can be easily mastered in an hour or two that will save you tons of time in the long run.
  • Beware the desire to build everything from scratch. This generally takes lots of time and you’ll miss out on a great many available tools, libraries and assets that can do the job just as well, if not better.
  • Last but not least, keep it simple. A great game doesn’t have to bulk in features, it requires a solid and entertaining core concept, one that you can generally realize in a short timespan. Better to deliver a working and polished product than a collection of separate features.

Vasilis van Gemert, one of the other speakers at the event, posted an article on the similarities between the topics I highlighted during my talk, and his experiences in web-development. Good to see so much overlap. I hope these views can be of use during your next gamejam or hackathon.