Raycasting woes

What I'm working on now is a raycasting engine, like was used back in the days of Wolfenstein 3D. It's not a complicated technique, really, but it's a little fussy, and I just couldn't get my last attempt to quite work right.

My original attempt was based partly on trying to convert A first-person engine in 265 lines from javascript to haxe, with this actionscript-based raycaster as a second opinion. I never quite got the math to work right, and it was running painfully slowly anyway. I might have been able to work it out if I'd been more diligent about putting debugging tools into my code, but I instead went the simpler route of ripping everything out and starting over!


This time, I'm using a technique from Lode's Computer Graphics Tutorial. Instead of doing a bunch of trigonometry for every column to be rendered like the previous technique I was trying to use, this technique uses vectors, basically just calculating once per frame instead of once per pixel-column. It turned out to get a much better framerate even without doing any optimizations, and as an added bonus:

It actually works!

Next up is to draw the ceiling and the floor, instead of just using solid colors.

 I've tossed the code up on bitbucket, if you want to poke around at it.

So what happened?

Gosh, it's been a while, huh? Well, if you're hoping that I'm rising phoenix-like from the ashes to complete Project Jumper... well, I'm not. Sorry! But it's not all bad news.

So what actually happened is that, around the time I was looking into updating all my code to the new (at the time) version of flixel, my laptop exploded. Like, loud noise and smoke and a bit of fire exploded. It took a while before I even got a working machine that I COULD program on, and by then there were just other things taking up my time and I didn't have the motivation to jump right back in.

Fast forward a bit more, and you see the slow death of Flash, and Flixel getting ported over to Haxe instead. I did, at one point, consider jumping back in and porting Jumper over to Haxe myself but, uh... Someone beat me to it. (That was pretty hilarious to discover when looking for haxeflixel tutorials!)

At this point, I don't think there's a lot of value to me personally in revisiting Jumper. It's not like I ever had a vision of a complete game in mind, I just wanted to learn. And I learned a lot! And judging from some of the responses I've gotten, people have also learned from reading, and that means a lot to me. But picking up where I left off isn't what I want to learn right now; it's been so long that I'm almost starting from scratch anyway, so I'm going to try new things.

I've got a new, unnamed project I'm working on now. Again, not a complete game, I just want to learn some techniques. This time, I'm looking into Haxe, partly because I might come back to Haxeflixel some day, and partly just because I really like the FlashDevelop IDE (they even made a haxe specific version!)

I'm not sure if I'll keep nearly as detailed a diary of my work as I did for Jumper, but I'm sure I can't keep myself from sharing at least a little. In the meanwhile, a peek at what I'm doing:

It's, uh, a work in progress. (I know where the problem is and I think I know how to fix it, I just think this looks amusing.)

*blows dust off of blog*

Not entirely dead yet.

Gearing up to 2.5

The Flixel team (i.e. Adam Saltman) is hard at work on the next version of Flixel. If you've been watching the twitter feed, you can see that it's a pretty big upgrade. I'm digging the multiple cameras, myself. Anyway, I don't know yet how difficult it would be to migrate a project in progress from the current flixel to 2.5. My tentative plan is to do another update or two for Jumper (Yes, I'm still working on it, just not able to devote a lot of time to it these days) under the current library, and then take a swing at the conversion process.

BFXR

If you recall, I used DrPetter's program sfxr to make the sound effects for Project Jumper. Well, the lovely thing about open source code is that people keep poking away at it, and now increpare has created a new, feature overloaded version that he's calling bfxr. I've been getting pretty good sounds out of the thing by just mashing buttons at random. Just imagine what someone that actually knows what all those sliders mean could do!

Not all effort results in progress

I got it in my head today to make a useful variation of FlxSprite. Basically, I just want to add some simple masking, a function that will let you mask of portions of the sprite as transparent.

The actual pixels of a sprite are stored in a BitmapData object called _pixels. So my bright idea was to store all the masking info into another BitmapData object called _alphamask, and combine the mask with original image to get the masked out image. A little research, and it looks like BitmapData.copyChannel() should let me transfer the alpha channel data from _alphamask to _pixels without touching anything else on the image.

Organization

One of the things that doesn't leap out at you right away as a new game developer is just how many files start building up, and how important it is to keep them organized. The project I'm working on right now (yeah, the one that's keeping me from Project Jumper. Sorry!) started out in my head as a pretty simple Arkanoid style game. Surely that won't involve too many files, right? I'll just use the standard src/com/developer/name file structure, and that should be fine.

Hah. Maybe I'm just too addicted to making new classes for every little bit of functionality, and maybe I could cram all my graphics into spritesheets, but still, my folders are becoming a cluttered mess. The OCD part of me that makes me rename/reorganize all my music to a very strict scheme is going insane that I haven't sorted my files into categories and subcategories.

Well, while this project is too far along to make a reorganization worthwhile, I think it's actually a good lesson. The aggravation I'm starting to suffer at the end of this small game will teach me to avoid the same aggravation on a larger scale when I start working on more ambitious things. This is just another of those times when mistakes are actually more beneficial than success.