More work on the uploader today, and with some experience gleaned from the last two days’ worth of fiddling about with uploads I now have a lovely asynchronous uploading panel.
You can upload multiple files at once. You can see how far each individual file has got (i.e. a progress indicator; this does require a Perl CGI script, but there’s no real way around that). If files fail, they turn red and you get a reason why (normally you’ve run out of quota). If files succeed, they turn green and then clear themselves after a few seconds (the disappearing is customisable for both fail and success).
If you don’t have CGI support on your webserver, it falls back to normal PHP uploading (which is actually slightly faster), and a little spinner animation.
Overall, it’s pretty neat, and is as close to Web 2.0 as ByteHoard uploading is probably going to get. Of course, behind the scenes it uses IFrames, but then that’s the only way really.
Of course, there is still the issue of uploading entire folders and drag-and-drop from your favourite file manager, but they are issues that can only be solved in some sort of client-side program, be it a java applet or a small executable file. At least I’ve finally got progress bars after three years.
Screenshots follow, as usual.
So, after a touch more work on ByteHoard3 (well, perhaps a bit more) I have uploads and downloads working, along with deletion. The usual screenshots are attached, but basically the uploader currently creates little progress bars below the upload form with details about each file, which turn green or red at the end depending on completion or failure.
The download works exactly as all other downloads do - click and your browser bugs you about what you should do, and optionally how evil files might be. The delete action has an inline confirmation, although I may have to redesign it as I develop on a widescreen and it doesn’t like anything slimmer at the moment.
I’m terrible with focusing on one project, since I’ll get bored after a few weeks of one, and so I need to change. Luckily, I’m overcoming this ‘probem’, but in the meantime, I have a good menagerie of projects to work on. I like to keep a few around since each is really a learning experience; ByteHoard is web programming, Aevolution is singleplayer games.
So, onto the last main project to appear on the blog. Perhaps some of my readers (yes, both of you) have heard of it; although it’s pretty unlikely.
QuSpace is the (rather bad) name this project has, and simly put, it’s an MMO engine. It’s my vain attempt at creating something more interesting and versatile than an MMORPG, something more interactive and prettier than a website, and something faster than Second Life. It’s my way of learning more about multilayer game and network programming, as well as a bit of fun (creating virtual worlds is always fun; there’s a reason Sim City is so popular).
It’s already had one attempt at life, which failed badly thanks to it being my first ever attempt at both game and network programming. I now return to it almost a year later, feeling a little more confident.
And, thankfully, I seem to have been justified. I have the whole client/server thing working really well; streaming map data, dead reckoning, and so forth. I haven’t tried anything like collision detection or physics yet, since I’d like to get the other parts (authentication, etc.) working.
I still have the wonderful synchronisation issues where, if I get two clients on different computers to connect, one lags behind the other slightly, but I’m confident I can solve this with a slightly better time synchronisation (cue reading up on NTP). However, I currently have a somewhat-decent VRML-alike, with the bonus of real time streaming, something that seems to be in vogue these days.
At least my job is made a lot eaasier thanks to both Python and Panda3D, the python-oriented 3D engine I’m using for both this and Aevolution. The entire project fits in less than 1000 lines of code at the moment, yet does all the network stuff for both ends, the rendering, and everything else. It may not be as efficient to run as C, I guess, but it’s a lot more efficient to write.
