LazyImageLayout and WordPress 2.0

For instructions on use, see the original post.

WordPress 2.1.x Issues

LZIL is compatible with 2.1.x, as far as I can tell! There's also a new version, version 0.45, that adds a few new features:

• Thickbox support: If you're using Cody Lindley's ThickBox CSS image gallery with jQuery, then you can use the new thickbox: selector instead of popimg:. Use thickbox:gallery to use the gallery features (gallery can be whatever you want).

• Captioning: The Javascript popup code now adds some very simple captioning to pop-up windows. If you don't like it, you can modify the plugin code and turn the $lzi_caption to false.

• Improved CSS: I've made some updates to the CSS to show rollover states. Also, when there is no popimg: or other URL, a border is no longer shown. This gets rid of the false javascript cursor for non-clickable images.

• Internal Bug Fixes: There was a bug in calculating the width of the image, which meant that the $lzi_full+width variable was set 10 pixels too small. It now matches. This is mostly useful for people using fixed-width site designs.

» download LazyImageLayout 0.45

WordPress 2.0.x Issues

• April 14, 2006: Asperientje has released a version of LZIL that adds a few more features I never got around to implementing: centering images, borderless images, and so forth. Check it out!!! It's an unofficial branch. UPDATE: If you are using this version of the plugin, you should contact Asperientje regarding issues with it, not me. I have not personally reviewed the code in his plugin.

• Mar 02, 2006: The new version of LZIL adds the ability to delete cache files. Hooray! It's also a little more informative on the Option page. Download 0.40. Please exercise caution when testing the cache delete functionality. I am also reviewing security of the plugin; if any PHP gurus want to give me some tips, I'm all ears!

  And yes, this one does now detect the wp-content path without using the fileupload_realpath database setting.

• Feb 28, 2006: I'm working on a new version of LZIL that will detect the upload path in a different way. This has a new options page that doesn't yet do anything, but will allow you to clear the cache and set other parameters without editing the plugin code.

• The new WYSIWYG editor in WordPress 2.0 may cause formatting alignment issues with the current version of LZIL (0.36). The workaround is to edit your post in HTML mode.

• The reported path problem was just a CSS bug in someone's template. LZIL version 0.36 is still fine. I'm still not sure if WordPress 2.0 still has the fileupload_realpath setting in the wp-options table. Will have to install a new db and blog to know for sure. Last updated Jan 3, 2006.

• QUESTION: Has 'wp-options' database table dropped fileupload_realpath and fileupload_url? There is currently no way to set these values in WordPress 2.0. Haven't yet found definitive list of option changes. LZIL is dependent on these options to correctly find the image relative to the wp-content directory. Need feedback from testers.

If there are any problems, leave a comment and I'll do my best to address them as quickly as possible. I'm planning on bringing LZIL up to spec with an admin panel plus several user-submitted enhancements, in January of 2006 when I can get a moment. LZIL may not be necessary with the new thumbnail features of WP 2.0, but I'll take a look at what it does. Integration would be better!

Debugging Help

To make it easier for me to diagnose your problem, please make sure you do the following:

1. Provide a URL to a page on your WordPress blog that is exhibiting the problem, and identify the area where it is occuring. Sometimes it's not obvious to me!

2. Tell me what browser you're seeing the problem in.

3. Tell me what version of WordPress are you using.

4. Send me the !@ line that you're using to show the thumbnail.

5. Tell me if you've modified the CSS for images, anchors, or javascript related to displaying images (you don't need to add any CSS of javascript for LZIL to work; it inserts it automatically).

Feel free to post a comment here, or email me if you are including sensitive server information.

DirectX Programming Prep

Some working notes and links for getting into DirectX this weekend. I'm looking primarily for an architectural overview of how everything fits together.

• Microsoft's official "Getting Started" docs...as a starting point, not very useful. Like a lot of programming guides, it's not a "big picture" document beyond a cursory mapping; it's like a bad tourist map that leaves out the critical contextual details that make navigating easier. For example, a tourist map of Boston should note one-way streets, and point out which roads are the main drags for getting from place to place. Like a lot of bad online documentation, it tries to start out with a basic description, only to get lost in a hyperlinked mess of information. Because of this, the information just doesn't flow...it's like talking to someone who constantly digresses from his digressions, losing sight of the main point. So while hyperlinking keeps the number of sections down, making them easier to keep technically accurate and consistent, it makes for terrible reading. I guess I want "The DirectX Story" to be like Lord of the Rings; instead, I get The Silmarillion

• One nice thing about DirectX is that each interface can be learned independently of the ones that came before it. Usually, APIs tend to build up over time, until they collapse under the weight of accumulated bad ideas. With DirectX 9.0c, I just need to learn version 9c of the API. There's no need to also know version 8, 7, 6, 5, etc. That simplifies things considerably, as version 9 of the API is hopefully is more refined compared to earlier versions.

• I browsed through the DirectX Reference Section to get an idea of how many interfaces, methods, and objects there area. Maybe 50-100 total...that's not bad. Of course, I don't yet have a clear sense of what the creation order is and which ones are "critical path", but I can probably now find a basic tutorial and start from there. Time to make a reference guide!

• Hm, should I actually just skip Direct3D and go with Simple DirectMedia Layer? That would give me a clean API to work from, and cross-platform capability to begin with. That is, if I want to do games right away. I actually want to get a little more immersed in the Microsoft Application side of things, just to become familiar with it, so I think I'll stick with Direct3D for now.

• While looking for information on .X file exporters for Blender, I came across Toymaker, which looks like a cool, no-nonsense resource for game makers. What I particularly like is that it makes recommendations and has a "voice" in the form of Keith Ditchburn.

• This FAQ provided me with a pretty good sense of what the state DirectX is in and answered some basic questions about loading 3D files to boot.

Crixa on the Mac

Here's something I never expected to see anytime soon...Crixa running on my Macintosh!

Jeremy had actually ported the low level graphics and sound classes to SDL, which means we have cross-platformness. This is the first time I've actually seen it run on my Powerbook.

Our 1.0 goal is to just release what we had back in 1997...there are still some keyboard and sound issues, along with some (we think) memory-related instability that must be quashed.

Jeremy, you rock!

Later, I tried to get the source to compile on my own PowerBook, discovering the joys of incompatible link options. I just got it working tonight, having figured out that the bundled sound mixing library had been compiled assuming...well, actually who cares. This is a huge milestone for the project.

Installing SDL on the Mac

Jeremy has been busy getting Crixa to work on the Mac. He checked in his source to our repository, with the caveats that they seem to have broken the MSVC side of things. So I'm going to try installing this on the Mac and compile using Xcode and SDL. My boring installation notes follow:

1. Installed subversion on the Mac, the command-line version (The GUI version, svnX, doesn't support user names yet)
2. Did svn checkout svn://repository/url/path to grab the latest sources
3. Opened the Xcode Project Builder, tried to build
4. Fixed the absolute paths in the source/ and include/ trees...they're now relative
5. Need SDL libraries, so download tar.gz SDL from http://libsdl.org and install from terminal
   ./configure; make; sudo make install
6. Need SDL mixer, so download tar.gz source and install from terminal ./configure; make; sudo make install
7. Need SDL net, so download tar.gz source and install from terminal ./configure; make; sudo make install

I note for the last two, I seem to be missing the "framework" for Xcode. A Google search says that it's actually the ZIP package that still has it...I looked, and didn't see it. Then I realized that "PBProjects" meant "Project Builder Projects" for Xcode...duh.

There's two things: targets and build styles. I think I chose an incompatible build style for the target of "SDL_mixer Framework", so looking to see how to change it...hm.

I probably need to do a bit of reading about Xcode... shelving this until later.

Simple DirectMedia Layer

Jeremy has taken the initiative on the Resurrect Crixa drive by mostly porting the current codebase to Simple DirectMedia Layer. This is cool because this will eventually allow Crixa to run on non-Windows platforms such as MacOS and Linux.

Inspired by Jeremy's progress, I got my Visual Studio .NET environment up. After muddling through the project settings, I eventually got the old DirectX based codebase to run and compile. There's a lot of stuff that is starting to come back, so I can see that I have my work cut out for me. I then downloaded and installed SDL into the Visual Studio environment. You download the ZIP package, compile the libraries and DLLs, and then you're done. There are several articles that describe how to set it up in a particular environment (in my case, Visual C++ 7).

So far the most irking thing has been, again, not knowing what all the damn project compiler / linker options are when setting up a blank Win32 app. I have some knowledge here about what needs to be linked where, but how to do it in the GUI for VS.NET is maddening. There is quite a bit of interdepency between various compiler switches, debugging support, and code generation options.

I haven't actually spent much time looking at C++ or game graphics libraries, but I was impressed at the lack of fiddly Windows things one normally would have to do (WinMain, for example). In the past, I would have studied all the ins and outs of this and got nothing done. In today's era of tools built on tools, I've given up and have decided that I don't really have to worry about this now. Eventually, though, it would be nice to have a decent architectural understanding of the Win32 programming environment, since I can think of a number of interesting utilities that I'd like to write.

Anyway, seeing Crixa run again is pretty damn cool, and I had to write about it :-)

Getting my Feet Wet Again

Jeremy IMs me out of the blue, announcing that he's made progress on porting Crixa to SDL on the PC. Wow! Much more exciting than anything I had going on. So I had to get into it myself. It's been a good eight years since I looked at the source code, a hundred-fold collection of C++ files that I still have yet to fully grasp...

The first order of business was to find the source code and get it to compile. I have Microsoft Visual Studio 2003, and it was able to convert the Visual C 4.0 project files to the new format. Then it was a matter of figuring out how to get the damn thing to run, which required some fiddling to get it back into a semi-windowed mode. The original code base doesn't have niceties like running in a window or being able to convert the graphics on-the-fly to match the current display mode...that'll have to be fixed. Then setting the working directory to the folder with all the level files seemed to do the trick, and I was again running Crixa on my desktop. It holds up surprisingly well. There are also some crash bugs happening I don't remembe that are memory related...not sure if it's me, or if they've always been there and didn't show up until today. Crixa is written in object oriented C++, which means that the memory allocation is done manually. This is highly error prone, so it's completely possible that there are some doozies in there. The other major Crixa instability is probably the floating point math used in the physics simulation; there are cases that quantities become too small to operate on.

As I scanned through the hundreds of files that made up this project, I am somewhat in awe of its complexity. Rebuilding my own library from scratch entails quite a lot of work and testing to get even the most basic things working. I've got my work cut out for me.

Five of Ten

I've queued up 5 game programming projects for this year so far:

• The ActiveEdge Winteractive, which I'm finalizing code for right now
• The resurrection of Crixa
• A Flash conversion of a game programmed by my cousin Ben Loh, originally created in RealBasic
• A collaboration with the "cool" Brad Fitzpatrick, Illustrator / Cartoonist. Not that other guy.
• There are also some tools on Ingeeni's Website that look interesting, so I want to see what's up with them. Looks like an interesting 2.5D sprite technology for Flash.

I'm also evaluating some cross platform third party game engines for C# development...more on that later. So many tools. So little time.

Let the Games Begin!

Last year I started to transition away from graphic design to programming, writing a couple ActionScript 2.0 based Flash apps. To maintain momentum, my pledge for 2005 is to make 10 games. They might be crappy, short, or ugly, but each game will provide an opportunity to learn something about game theory versus implementation. I've got game theory in spades...implementation (that is, code) is where the rubber meets the road.

• So far, I have finished one game for ActiveEdge, which should be showing up soon. It's got all the basics of a simple game: event loops, triggers, sprite sequences, level logic, and simple physics. While the game works pretty well, the object hierarchy is pretty fragile and needs to be re-abstracted. I'll be writing about this when the game goes live, and will incorporate those lessons into whatever the next game happens to be.

• A second goal that I have is to concentrate on larger programming issues rather than re-invent the wheel. Therefore, I plan on looking at the available programming libraries to save some time. There's plenty to do already without having to write your own game engine from scratch.

• A third goal is to work with other programmers and artists with a collaborative learning spirit. The important thing is to maintain the momentum... Collaboration will be KEY!

• A fourth goal is to make a better logo. I chose colors from the Apple II Plus color graphics generator, but that's about all I did.

I plan on writing about this journey throughout the year...stay tuned!