planet romero

Floor casting is simple if you think it like this: to go from 3D space to 2D space (screen) you use some function. To do floor casting all you have to do is reverse this function and go from 2D space (screen) to 3D space. So for each floor pixel you have some X_2d, Y_2d coordinates and you need X_3d, Y_3d and Z_3d. Assuming your world uses the Z-goes-up coordinate system (like in wolf, doom, quake, etc), you alreaedy know Z_3d: its the height of the floor. So you need only to find X_3d and Y_3d. Since to calculate X_2d using the function above you use X_3d and Z_3d, to do the reverse you just solve the formula for X_3d (you know X_2d and Z_3d and you need X_3d). The same for Y_3d.

Once you know X_3d and Y_3d, just used them as your texture coordinates. You’ll need to wrap them of course (ie if you use 32×32 textures and the X_3d is 48, you’ll need to make it 16 – just use something like X_texture=X_3d&0x1F). This way you’ll get some floor casting. The same is true for ceiling, just use another Z_3d.

Now doing all these calculations for each pixel is obviously slow. You can speed it up by calculating the first and last pixel in a column and doing perspective correct interpolation between them. Or use some sort of masking: mark which pixels are visible floor/ceiling texture and calculate them below. Depending on the platform it might be faster this way.

Personally for Rombo i just calculated the pixels. Although i had a lot of precalculated lookup tables for these which included the floor/ceiling height (which is why i haven’t added bobbing in the engine).

Finally caved in and quitted the AI university course this week. I didn’t want to, but the course itself wasn’t exactly clear in it’s requirements. In a nutshell, it jumped straight into advanced algebra, Calculus, proofs, biology…hell, you need a PhD in Voodoo Magic just to keep up! Also, it uses Netlogo for programming, but there was little effort to properly teach the language, and so we are thrown into the deep end once again.

I feel a bit shit for giving up on a subject that I consider my mission in life, but with its high difficulty & work load, and the fact I have another course on the go and a day job as well(!), I really had no choice. So, I’ve swapped it for a Social Sciences course(don’t ask!) that begins in May, and so I can focus my efforts entirely until then on the remaining course I have on the go at the moment…

…nothing is EVER simple. Is it? #_#

Anyway, this means only one thing: I now have more free time available to me! FINALLY! So with a little effort each and every night, I should have something soon, but as a certain programmer is fond of saying – “When its done!”…

For a proper game and Java, you’re better using LWJGL anyway .

The Lightweight Java Game Library (LWJGL) is a solution aimed directly at professional and amateur Java programmers alike to enable commercial quality games to be written in Java. LWJGL provides developers access to high performance crossplatform libraries such as OpenGL (Open Graphics Library) and OpenAL (Open Audio Library) allowing for state of the art 3D games and 3D sound. Additionally LWJGL provides access to controllers such as Gamepads, Steering wheel and Joysticks. All in a simple and straight forward API.

LWJGL isn’t a game engine. It just provides access to technologies outside of Java, such as OpenGL (up to versions 3.3 and 4.0 – that is GL for DX10 and DX11-class hardware), OpenAL (hardware accelerated 3D audio) and various input devices. It is a much lower level library than Swing/AWT and you get fine control over what is done.

Having said all that, you can use KeyAdapter to handle multiple key press events. However instead of relying only on keyPressed/keyReleased events, you use them to update a local array of booleans with the current key state.

Here is an example program which shows how to do it (its very simple, the “meat” of the method is about 15-20 lines of code, the rest is support stuff to make the example program run). It is a NetBeans 6.9 project, so you can run it directly from NetBeans.

Here is a screenshot of the program:

As you can see, i’ve pressed six keys simultaneously. The program updates the info about 66 times per second (every 15 milliseconds) using the “current key state”. Read the comments in there to get an idea about the method and how to use it.

Still mucking around in Java but have decided to focus on writing a small midlet game for my Nokia 2700. I really want to make a version of Phantasy Star 1 for it as the resolution of the phone(on it’s side) is a match for the Sega Master System, and there is enough control to emulate such a game. I’ve got a copy of Martin J. Wells’ “J2ME Game Programming” which covers MIDP 2.0, so I’ve got enough resources to be cracking on with that. I think this a more realistic goal for my current skill level with Java, without getting too ambitious.

In other news: I decided to see how rusty my C++ skills were…not as much as I had thought! Downloaded VC++ Express 2010, and began to update an old Dx9 Space Invaders clone I had written using VC++.NET 2003. Overcame the usual problems of switching to an updated IDE(“Engineers! They just LOVE to change things!”, but the real headache came when the program worked fine in debug mode, but would randomly not show some of my sprites in the release build. Its a nasty bug that I’m stumped over, but some evidence points to a possibility of mixing DX9 with Vista…although, I’m not really convinced thats the real cause. So, I decided to take my libraries into a fresh project and put the newer Direct2D interface to the test. Unfortunately VC++ Express is playing silly buggers with “This header file doesn’t exist even though its included in the project view to the left of the screen and you are editing it through this IDE right now, opened from via the project itself…”.

Joy-oh-joy, eh chums? ^_^ Anyway, I don’t want to take on another “from-scratch” game dev project what with the Java RPG as well, so I’ve set myself the goal of merely updating my last game COA(Constellation of Athena) to run on more modern versions of Windows. The bugs, missed opportunities and sluggish frame-rate on newer machines has frustrated me for years, so I think it’s high time to give my beloved game a complete make-over!(oo-er!) I certainly hope to be sharing it with you all by the new year…

Well, the Direct2D puzzle is now solved: Its not a DirectX component but a Windows one instead! So yes, Direct2D can definitely compile and run on Vista. Will have to do some more work on that…

As for updating the Space Invaders game on Express 2010 – nothing doing! I asked over on the gamedev site and the only suggestion given was that if its a problem with a release build then its highly likely an uninitialised variable somewhere in the code. But I’ve double-checked the variables in my code and can’t find a sausage that ain’t been initialised. Oh well, back to the drawing board I guess…

Still, on the bright side this has been giving me a much needed refresher crash course in C++. Also makes me appreciate Java a bit more with having both the header and source in a single file. Header file errors are a fucking nightmare at the worst of times! Oh, speaking of which…

…I’m going to spend a little time tomorrow hunting down some decent LWJGL tutorials. Looks quite a nice little api…