About this blog
Musings on stuff. Mostly programming.
Entries in this blog
Although it's not games-related, I made an updated version of the BBC radio player for easier access.
This might be against the BBC's rules, but I'm not going to take it down until they ask me to :)
I'm planning to enter the Shmup-dev horizontal scroller with boss competition.
I've already been working on my entry for a couple of weeks - it's looking pretty good so far (but then, so are other peoples').
Here's a screenie for your viewing pleasure:
My web site, which I update very infrequently, has been updated.
I've added a couple of new games to the PC games page, and put my web games on the web games page.
This is an offshoot of vectrex.org.uk, which is now (mostly) defunct, but still works.
BLATANT WEB SITE PIMPAGE
Well, we're coming to the end of another fun game programming year for me.
So far this year I've completed
"Peril" - my TINS05 entry,
"Sidescroller" - an entry for a small 48 hour competition
"Jack" - an entry in LD48 #7 - in the showcase
and I'm working on my final game of the year, my Allegro Xmashack entry, which is looking pretty nice.
The theme? Well, they all use hardware opengl and aren't (quite) 3d games. I'm getting to the point where I can actually achieve useful stuff quickly with opengl. It's good.
Spammers are bad for the people they spam, right?
But they've also broken into a server I run. At least, not really "broken in", rather used a rather lame vulnerability in a common open source (rather low quality) web app which we happen to run, to send spam.
This means that our server has been sending spam. Hurrah.
And they've used a robot which uses random proxies, so we can't localise them.
It's an app I don't have the time or inclination to fix, therefore, the contact form will be off limits for ever more, henceforth. My clients will get annoyed and complain.
Result = spammers are evil, and must die.
Well, it's not really ready to try out, but here is a work in progress:
A web forum
Still in a pretty early testing / prototype stage. Most useful features aren't implemented, but it does the very most basic stuff.
Things that you might notice:
There is no post formatting
The "Back" button on your browser does not do what you expect
There is no paging facility, so if there are too many posts, the page becomes overly long.
You can post anonymously as well as registering and posting as a known user. Please don't use real / important passwords or emails - they will certainly be deleted anyway.
At the moment there's no real denial-of-service or flood protection - so please don't try to hack it or anything.
So I've been trying out these so-called "AJAX" (I hate the name) web applications.
Basically the idea is that you make a web application which uses a richer client layer and the server does a lot less than conventional apps.
- Much better user responsiveness
- Much lower bandwidth usage (for some apps anyway)
- Forces you to adopt a "3 tiered" approach
- Many different conflicting techniques at the moment (and likely to be for the forseeable future)
- Conventional web technologies don't "fit"
- Possible incompatibility with some web browsers, software firewalls / corporate AV systems etc
So I've been making a simple web forum, using
- HTML - a static HTML page
- PHP - I'm using PHP5.1.0 RC4 (not too out of date then)
I've almost got it to the working state. It's certainly showing some promise. Responsiveness is very good.
As far as I'm aware, nobody else has yet made a "AJAX-based" web forum application (please let me know if you know of someone who has). That's discounting google groups, of course.
This technique could certainly be applied to turn-based web games, or possibly even slowish realtime ones.
A demo will be forthcoming as soon as it's usable.
A simple enough concept. n players each have a bat on the side of a regular polygon with n sides (Except where there are less than 4 players, where it could get tricky)
The aim is to make a very simple network-playable realtime game, which tries out lots of techniques.
I've never really made a multiplayer network game before* - although I've done plenty of multiplayer games and network applications, so it should be easy enough.
Should be cool.
* In about 1992 I made a RTS game ("War on Zog") which played in DOS (text-mode) over a null modem cable. Does that count? It wasn't really very good. You could only move one unit at a time, and could cast various "spells" which did things like creating holes in walls. The world was huge and the main challenge was finding the other player's base.
Got the GUI basically going.
OpenGL context created with GLFW
GUI made with libufo
All working pretty well too - text entry, a few buttons etc.
I've been playing with this library, libufo.
It's a GUI that uses opengl. This is ideal for a game which uses opengl for its main graphics rendering, and also wants a nice gui to slap on top - dialogue boxes, popup menus etc. It has lots of nice features.
Unfortunately, it isn't working as well as I'd hoped. I've got the samples working fine, but I tried just one little thing and it's now crashing, never mind.
They're using some clever C++ garbage collector which I don't understand. Maybe that is the source of the failures.
Documentation is largely only in the form of class documentation, which is typically like:
"setFont - this sets the font"
Or something equally useless. Reminds me a lot of the MSDN library :)
Anyway, I hope to find out what the problem is soon.
Then, I can create a compelling GUI for this game, which will definitely need one.
Ideas are strange things. Some days I have none, other days I have hundreds.
Most of them are lousy, a few are amazing. And I have very little skill at differentiating them.
My previous idea for 4E4 (A Pirates / robots / zombies RTS game), had several problems
- It was going to be very difficult to make
- Similarity to other potential entries
- Not easy enough to balance / make it enjoyable and amusing.
Today (well, maybe yesterday or the day before), I had another idea. This one is much better, much more original, and made me laugh just thinking about it (which is not necessarily a good sign).
*if* I can pull it off (and this is a big "If"), then it will be hugely entertaining. And seems fairly achievable at the moment. But then perhaps I'm barking mad (hint: yes).
Looks like I'm probably going to have a crack at the 4E4 compo.
I've designed some aspects of my entry in my head, and discussed it a little. Here are some points
- It will probably be a RTS
- It will try not to be excessively complicated
- Zombies, robots and pirates will probably all be capable of being on the same side, unlike others' entries which view them as different races
- I'm currently looking at about 10 different unit types.
- The game will probably contain about 10 short missions with maybe 2 optional and 1 secret one.
Well, I was doing a bit of real paying work. Then I was doing a bit of work on the afore mentioned "XUL Mysql client" app.
But recently I've been working on a new commercial (non-game) project, which may end up being quite lucrative (I hope).
Anyway, I'm back on win32 C coding with MingW.
So far my observations have been:
- Using COM in C with MingW is awkward
- In the win32 shell, redirecting stdout to a file, causes the file to be "unix2dos'd" - and there's NOTHING you can do about it (read: not binary safe, whatsoever)
- What works in an exe from the command line, does not work in CGI necessarily, and it's difficult to figure out why.
I'm calling a COM API. It's working fine, I can run my program from the command-line, and the right thing happens.
I do the same thing in a cgi program (the same exe), and it doesn't work. The error code is not helpful.
- A permissions problem (Not as far as I can tell using ntfilemon to check file accesses)
- Some env variable set wrong (nonexistent temp dir)? seems ok so far
- It just decided it doesn't feel like it
I shall have to investigate later. Perhaps the user ID that the web server (currently IIS, but hopefully Apache ultimately, when I get around to installing it (I hate IIS)) is running under, doesn't have rights to something that the API requires.
I decided to stop buggering about with XUL, and try to make a real app with it. It's basically, a simple MySQL client, like PHPMyAdmin, but less sucky (A really simple target to start with, as PhpMyAdmin sucks IMMENSELY).
I thought that it should be able to be more usable and more responsive, if not more fully featured.
Anyway, progress is basically pretty good, in two half-mornings (well, doing a bit of real work at the same time), I've got the basic outline of the app working.
Currently it does
- Connect to server, prompting for server name, username / passowrd
- Lists databases and tables
- Queries individual tables - presenting the contents in a big listbox
- Page through the table, 10 rows at a time
All works pretty straightforward. There are some minor issues to overcome, but I think the principle is proved.
Last week I managed to completely fry the motherboard of my old AMD K6-2 system. This in itself was quite annoying, but not critical as it's not my main box (I may be behind the times hardware-wise - but not THAT far :) )
Anyway, I'm trying to rebuild a working box today using my ancient Pentium motherboard.
I swapped the mobo's out, and the bios (to my surprise) actually boots. Well, that's one hurdle.
Haven't actually had it get as far as booting an OS (other than DOS, which doesn't count) yet. Win2k is installed on the HD, but won't boot because of some hardware change issue (blue screen stop 7B).
This motherboard is very old, and doesn't even have a bios which can boot off an IDE cdrom (annoying).
So first I'll install win98 to check if it's all working properly, then maybe something else. Possibly Windows 2000 or WinNT (maybe not enough RAM in there at the moment though).
The problem with NT and 2000, is they require me to make lots of floppies to install from (just the floppydisc installation part, I still need the CD)
Anyway, it looks like I might have managed to salvage the machine from being total scrap :)
So first I'll try to install
One of those sort of random days today.
After much thinking for the last few days about ways to do opengl motion blur, I tried to implement it today.
My first thought was to use glCopyPixels to copy from the front to the back buffer, and use a blender.
Unfortunately, glCopyPixels copies pixels at a glacial speed (from 100FPS to 0.1 FPS or something). Therefore that approach was quickly abandoned.
Funny, loads of people had said "don't use glCopyPixels, it's too slow". I didn't believe them. They actually turned out to be right!
Anyway, got it working, a different combination of creating textures from the front buffer and drawing them blended. Uses lots of texture memory, but the effect is fast and cool looking.
Speaking to people on IRC, I realised there was no web page containing my games, so I made one here.
Finally I almost missed Dr. Who this evening - cool episode, with things exploding and everything. And quite a comedy.