About this blog
Even more clever description, but really it's just slightly wordier.
Entries in this blog
Refactored a bit of the PSP demo code. Menus, the board, etc.
Eat some more bandwidth with this video of an effect applied to the entire game board.
I got a little reprieve from parenting duties this weekend, so here's the latest build of the PSP demo. I'm using Visual Studio to code and build for testing on Win32, then compiling against the PSPSDK and uploading to the real hardware. So far no major problems have come up, although it would be easier to have display lists working for using the standard bitmap font routines on the PSP.
Here's a video of an attempt to break the logic.
Currently it uses some Othello/Reversi logic to swap cube colors, and that mode of play is pretty much complete except for an exit/win condition. Hopefully I'll get more time to work on this and add some new features.
My new job affords me a couple of interesting perks. One of which happens to be a decent library of games along with their respective console hardware. After talking to my cube neighbor, the local PSP aficionado, I became interested in the PSP homebrew scene. So I checked out the company PSP, (which luckily is a 1.5 firmware rev) and got to tinkering. With the dev tools set up and a fresh compile of the PSPGL lib, writing 3D code for the PSP is a snap.
I have an idea for a turn based game, and if time allows I'll develop it further, but for now I'm content to have gotten something running on hardware that's a tad more exotic than a PC/Mac.
So I took a chance and upgraded my Ubuntu installation from 5.10 to 6.6. And by upgraded ladies and gents, I mean a clean install, as there truly is no other way to install an OS. Maybe it's just that I'm fractionally more familiar with it, and conscious of the fact that I'm going to HAVE to open a shell to issue a half dozen commands, but this install was by far the quickest from blank partition to working development environment.
The default setup provides a good base, and the subsequent updates were painless. I still dislike searching through innumerable packages with Synaptic, but and once the basic dev tools (gcc, g++, headers, etc) were installed the only imperative that remained was the video drivers. Been there done that, wrote it down. Nvidia driver install was not an issue, but that's not to say it can't be greatly improved upon.
After the miserable failure of MinGW Dev Studio to do anything whatsoever on 5.10 without crashing, I had downloaded and installed Borland's C++ IDE. Atrocious interface aside, it worked. But before I went that route again, I wanted to give Code::Blocks a try. Last time an install would have required compiling it from source, which is not something I was (or am) willing to sacrifice any of my time for. Let's face it, life is too short and my family is too important for me to waste time compiling something which amounts to a trivial pursuit.
I looked... lo and behold, there was a recent nightly build in a Debian package. What happened next was beyond my wildest dreams. I downloaded it, the Debian package installer opened, Code::Blocks landed on the hard drive and was added to the development tools menu. I opened the IDE up, converted a simple Visual Studio solution and the thing just worked. Amazing.
Suffice to say I'm impressed, as it basically Just Works(TM). This environment is very livable if not slightly more compelling than it has been in the past. Mind you, I still think Linux has a 'slapped together' feel about it, but for now I'll say that if I HAD to work with it, I would consider it far less painful (maybe even enjoyable) than it has ever been.
My friend Laz got new glasses.
And a badass hat!
Did he say bad asshat?
As mentioned by my good friend Laz, we had a visit from the stork this week.
Have you ever gone into a massive collection of folders and files to organize them, only to find something you'd forgotten about? That happened today when I ran across scans I had made of a card box sometime in 1998.
I had scanned them to learn texturing/material application in 3DS Max, but somehow they got shuffled off into nested folder oblivion. So I cleaned them up and threw them together and voila..
They never made it into 3DS Max, but that's only because I became acquainted with Maya in the meantime.
So this weekend, after a bit of hacking, I've got an x86 machine running Max OSX. It's truly a weird thing to behold, having both a shiny aluminum G5 chassis and a semi-plain Dell Dimension case sitting next to each other running the same operating system.
Previous builds of my game framework using Universal Binaries on the G5 presented no problem, but for some reason or another they just weren't happy on the P4. After shuffling the project across, the x86 builds were up and running in a native configuration.
At any rate, defintely worth a day of effort to see something that almost nobody thought would ever come to pass.. a Mac OS on PC hardware.
Recently my friend Nick (Laz on the forums here) happened on a run of bad luck. I an act of spite against his dear friend Murphy (and his Law) I bought for Nick one Sapphire Radeon 9600 of the AGP variety. Now it seems Nick's fortunes are becoming a bit more upbeat and no longer needs this bit of friendly charity.
So here's the deal. I fully intend to give this video card away. It's nothing major but here are the specs:
Now I'd like your opinions on how to give this away within the GameDev community. My first thought is to just let it go to some random respondant, but given the unique position of having alreay made an investment, I thought of something else. How about a raffle? Not for the sake of recouping costs, but to perpetuate this kind of giveaway. I'm not really interested in running a contest, as there are a few of those already. A raffle could have a much shorter run, and depending on the amount of entries could allow for a fast turn around for the next one. Your thoughts??
GDNet subscription unpaid?! What's going on here?! Seems something happened around the way at PayPal, and they discontinued my subscription. Thanks alot PayPals!
Had a rough patch over the last few weeks. A childhood friend of mine passed away, and the means by which this happened I'll leave at unnatural causes.
But work goes on in the 'Game Project Referred To In The Journal Of Schmedly'. The designs I have in mind are largely based around recreating certain classic arcade games, which lend themselves easily to a tile based structure, but how to handle that in 3D? How about a 3D tile engine? Given the fact the game designs incorporate forced perspectives, it seems natural to do it this way. It also makes culling extremely simple. Anyway, a shot of the world editor affectionaly known as Schmedit.
Currently limited to loading/saving and basic editing. The editor mostly needs work in the editing controls (note the hacky buttons) but I also need to figure out a more robust way to handle the tile connectivity. At this point it only supports branching nodes and will simply overlap when nodes are connected in a loop.
Not much for words today, but completed a rewrite of the original Maya exporter. All the important data except for animations are extracted from the DAG. The mesh and joints are exported together, all that remains is finishing the Quaternion class so I can implement animations. Neat.
This week is starting off rough.. feeling rather sickly today. Hope I don't give it to the rest of the family. At any rate, journal readers love pictures I've been told, so here's the latest, exporting joint heirarchies for animated skinned meshes.
Still very much in the works, but code reuse is at an all time high here. I had written a simple .rtg model viewer ages ago, so the basic framework was used for the new viewer.
Here's a shot of the original skeleton in Maya, and loaded much the same way into a very slim version of the engine.
More as this progresses...
Cue Oingo Boingo's Weird Science!
Although there's a problem with the system timing calls, which I'm trying to figure out... everything else compiled and ran perfectly. Actually there was one namespace collision that X refused to give up on, so I renamed my object, which ended up being more accurate.
As suggested by stormrunner (and somebody else a long time ago) I used MinGW Studio and it handled everything great. I had to add newlines to the end of each file to remove all warnings but it was worth it to see a clean build. Only thing wrong with MinGW Studio is that it doesn't allow for nested folders inside the file pane. It will access the files in nested folders without issue, but it just doesn't give you the option to create a folder structue inside the IDE. Eh, it looks a little messy, but maybe a fix will come along at some point.
Oh well, I get to marvel at a little coolness now.. because to me it's great when something 'just works.'
EDIT: Timing calls fixed, but still not reporting the initial interval as I'd expect. Truly weird science!
You recant your previous declaration, turn around and 'try one more thing.' You get a small step closer.
So the Linux endeavour continues.
I *can* build the game with Anjuta running on Ubuntu, but... I *can't* build the game. You see, somehwere along the line, somebody chose to make it hard to include and build source from multiple folders. Within the confines of this Linux IDE that is. So you see this is why I *can't* build my game. I refuse to reorganize all the source files into one directory and rewrite all the include statements. And why should I? Visual Studio and XCode have no problem dealing with this structure.
This all sounds like more bitching and moaning of course, but what it boils down to is that intuition alone (given previous exposure to other IDE's) should be enough to make this build happen. But it's not. My refusal to touch a makefile certainly limits the available options to compile in Linux, but that's really not my point. If Linux is ever going to cater to a wider audience (like certain religious pundits predict) it's going to have to have 'stuff that just works.'
It seems fair to say that each time I want to attempt developing with Linux, I have forgotten all the pain it caused the previous time. Once again I got the urge, and once again I'm left jaw agape, completely befuddled and wondering why I'd put myself through *THAT* again.
Sure, it feels good having my project running like a charm on both Win32 and OSX, so naturally I thought, "Well I'll give Linux a try again. People say Ubuntu is soooooo good these days. Hmmm, okay that settles it."
While I admit the basic install for the OS was pretty painless, the fact is that nothing for development was installed by default. Only the common desktop apps were to be found. So I gave in, yet again, and started the tedious task of tracking down all the crap I'd need.
Much later, after all the googling and apt-get'ing I should have had everything. Bear in mind that I rather dislike using the commnand line. Some people love it, but I swear somebody once told me this is the twenty first century, and in my opinion, I should have a GUI to do everything. Typing poorly named commands and even worse package titles is just so 70's style. But I digress.
The bright spot in using all that junk was Eclipse. It took three steps to have it running...
1) Download archive
2) Unpack archive
3) Double click eclipse icon
It doesn't get any better than that in terms of expected results.
Okay, let the real pain begin. Next comes endless lib searches and all sorts of nasty linker errors from the eclipse C/C++ perspective. Sigh, I'm thinking to myself, "I could solve these problems with little to no effort in Win32 or OSX." But an hour later, even after I tracked down all the function containing libs, I sit here with a nebulous *** [App] Error 1. That kills it folks... Screw Linux. Again.
Last time it was Mandrake and KDevelop that refused to work correctly. The time before that it was ummm... Mandrake and Anjuta. The time before that it was RedHat and something-or-other. I don't even *like* Linux in the first place for crying outloud!
For a few shining moments two days ago, I thought it would be cool to have my game running on Linux. Now, once again, I remember why I chose NOT to continue that effort many times before. Sheesh, if I was going to throw away two days worth of my free time on something that produced nothing, I'd have plopped myself down in front of the TV.
Alright, I feel like I've accomplished enough to merit writing in my journal. I'd also like to get some feedback on some design thoughts I have.
Working on a little dungeon crawling project with a forced perspective (psuedo isometric). What I'm attempting to do is use a series of meshes to represent the world, connected by portals. When a world mesh is present in the scene, it's subdivided by a quadtree. Each quad node holds an index array for rendering that chunk of the world.
My first thought is to provide a 2d collision proxy which represents the collidable floor of the dungeon. The other alternative is to use the world geometry. The 2d proxy would probably be faster since it would contian less triangles.
I've got a Maya exporter to handle all my pre-processing needs, so I can generate the 2d geometry at export time. With that in mind I could also define a world file structure to arrange all the world mesh/portal data beforehand.
One thing I'm still a little fuzzy on is how to handle the actual collisions themselves. Not the testing mind you, but how to relate the current triangle of collision to it's neighbors. I guess you'd say I need a little advice on how best to handle the grouping and testing of the world geometry.
Again, feedback is very much welcome and in fact, encouraged :)
Schmedly - out