Torque SDK Owner …

I am now an official Torque SDK Owner , I am also an official TGB Owner, as well as an Adventure Kit and Torsion owner, but this post is supposed to highlight the fact that I finally managed to find the funds to purchase the Torque SDK. Now … let’s see what I can do with full access to the documentation … oh me, oh my, oh NO!

Dungeon Walk-thru …

For those following the Dungeon Builder progress, here’s a video showcasing what it can do so far … there are still some issues with the render system … namely it rendering some things too early … and rendering some things incorrectly … but otherwise, the overall code base is almost finalized and it’s just a matter of tweaking and squishing bugs …

You can find the Dungeon Builder video by clicking the picture below:

UPDATE: Added a link to the second Demo, which show cases some corrected render glitches, and what I believe to be the ‘beta’ version of the render system

Updates to TGB Dungeon Builder

I’ve spent the past week cleaning up the Dungeon Builder code, 15 minutes here, 15 minutes there … and have taken it from “prototype code” to “alpha code” … it’s now much cleaner looking, a hell of a lot easier to work with, and makes damn near perfect sense now … and boy, let me tell you … going from prototype to alpha … WHAT A BITCH … I damn near lost it a few times … couldn’t figure out what the hell I was thinking when I wrote some of the code, only to find out … most of the code that was giving me headaches didn’t work and wasn’t rendering stuff anyhow … I must have just left it in there when I was doing the prototype “just in case” … and figured “its not putting stuff on screen, who cares …” and kept going …

But now the code has a fairly easy to follow structure … and I’ve even created an Image Map mock-up that I’m using …

To see more “pretty” pictures, continue reading …

TGB Dungeon Builder

For those of you who remember the original “3D” dungeon crawlers, such as Stonekeep, Eye of the Beholder, Lands of Lore or Bard’s Tale … this might be of interest to you.

I saw a post on the GG forums a couple days ago, and it peaked an interest … and, being me, I had to scratch the itch … so I started working on it. I’ve got some pretty decent progress so far, especially for a few hours of prototyping work … Images are attached for your viewing pleasure.

The general concept is this, using a 2D Tile-Layer (multiple layers, possibly?), the “player”can move around a “pseudo-3D” environment.  Basically, using 2D Sprites, which are custom made (I’ll tell you how a little further down …), we draw the first set of sprites and only show a portion of them, to simulate ‘being in the room’, then we draw the next set of sprites … at a reduced size, and butted up against the previous sprites on the X/Y coords … and we repeat this process until we feel we have a good ‘distance’ in front of us (for my tests, 6 rooms seems about the extent of viewable distance with -my- artwork — other artwork may allow for up-to maybe 10 rooms?).

The trick is … if we have a 512×512 seamless tiling texture, and we skew the right side of it so that the right edge is only 256 tall and perfectly centered (128-384) and then we squish the graphic’s width and divide by 4 (512/4 = 128) … we wind up with a … Perspective Tile … Nice, eh?

Now, if we take the image we just created, and duplicate it so we now have 4 copies … then rotate one, place it ontop of the first so the top-left edges are have the same coords, then flip the next one and make it so the top-right corners are touching the one we just rotated … then rotate the next and smack it down at the bottom… we have a ‘pseudo-3D’ room.

Now, if it were only this simply in code, right?

Well, it sort of is … difference is, the code should be intelligent enough to draw the right texture in the right place, and only draw a texture when it should …

Say what?

Yeah, ok … so, we build a 2D Tile-Layer, and every three horizontal squares are a ‘room’ … the left tile is the left wall and the right tile is the right wall, and the center tile represents the floor/ceiling (eh?) … so, if we use this to determine what artwork to draw, the previous example still applies, we just don’t make 4 copies of the same image anymore, we make copies of the images we want to draw …

So what about drawing rooms in front of us? Well, the same logic as mentioned above applies, but, we have to just simply scale our images … given the 512×512 to 128×512 image example i mentioned, our scale is literally 50% (hence the simplicity of the image I made for testing).  We scale everything down by 50% … and just make sure that our left-wall image (the basis of our coordinates) is in the right place … which would be the width of the wall before it, minus the width of the current wall divided by four … why? I honestly don’t remember off hand… haha …

I intend to have a much more detailed description, and hopefully some more useful screenshots in the near future….

Here’s a diagram of the general concept:

A working “prototype” layout, completely faked in Level Builder with scaling and positioning of artwork

This is actually ‘rendered’ with some code that looks at a 2D Tile-Layer to know what to draw …

And here we are after another hour of coding, with a hallway and a t-junction … all determined from a 2D tile-layer.

TGB Resource: Bitmap Fonts

Ok, so I’ve been on a role in the past 24 hours.  I just released the ‘Easy Edit’ resource, mentioned in a previous post, and have now just released the ‘Bitmap Fonts’ resource earlier this morning.

This latest resource, Bitmap Fonts, allows for the use of Bitmap Fonts in TGB.  What does this mean?  Well, remember the old days where fonts were actually just ’tiles’ in an “image map” and had to be drawn to the screen just like any other graphic?  Well, those fonts were cool, blocky and pixelated, etc, etc — this resource allows you to bring back some of the old, and even mix it with a bit of the new, by creating font images, which are just a series of tiled characters on an image in a specific order.  The resource even allows for multiple fonts to exist in the same image map.

For ‘purty’ screenshots of the resource in action, as well as an example ‘font’ image, read this entire post, or jump over to the GG .plan

TGB Resource – Easy Edit v1.0.0

I have just recently posted a .plan on the GarageGame’s website, with links to a recently released TGB Resource that I am proving to the community for free.

The resource in mention is called “Easy Edit v1.0.0″, and is a simple floater that can be toggled on/off with a shortcut or menu option, and it’s functionality is quite simple.  It contains 9 buttons, 8 buttons for each map direction and a center button.

Each button moves the level builders active camera position in the direction clicked.  The resource is intended more as an example of how to create custom resources, and to also promote the creation and distribution of custom resources.

Here’s a screenshot of the resource:

XMLObject v1.0 Beta Release

I have released the existing XMLObject code as a v1.0 Beta, and the details can be found in this GG .plan.

The current object supports the majority of the expat libraries standard callbacks, with the exception of it’s Schema/DTD callbacks, as well as the ability to parse both a full file and a string (obtained from network resources such as SOAP and XML-RPC requests).

Additional features, demos and examples of use for the XMLObject will be released in time, these examples include integrating my existing HighScores object as an XML document, as well as retrieving the HighScores object from a network resource.

For more details, and a download link, please drop by and read the GG .plan.

XMLObject Updates

Ok, I’ve finished some more of the XMLObject code, and now have the following SAX methods implemented as TorqueScript callbacks:

• onElementStart(%this, %name, %attributes)
• onElementEnd(%this, %name)
• onCharacterData(%this, %name, %data) // %name is a reference to the last element started
• onProcessingInstruction(%this, %target, %data)
• onComment(%this, %data)
• onCdataSectionStart(%this)
• onCdataSectionEnd(%this)
• onDefault(%this, %data, %len)

Not all of the callbacks have been thoroughly tested, but the following callbacks have been tested and found to be in full working order so far;

OnElementStart, onElementEnd, onCharacterData and onComment.

It looks like I’m getting nearer and nearer to having my saveXml() and loadXml() methods fully functioning, and as seen in my previous post, I’ve already got the makings of a TorqueScript-based object/level loader.

TorqueScript XML Object Loads

I've managed to get the XMLObject to a fairly useable point, so far, the following script, is useable:

This will actually create instances of the objects identified by the xml elements inside of an "objects" node, for example, the following XML document was parsed for testing;

I've not yet thoroughly tested it, but once I find a useful and reusable XML format for Objects and Levels, I'll start working on the saveXml and loadXml functions respectively, and add them as either ConsoleFunctions which take in any SimObject, or add them as addon functions to the base SimObject within the XMLObject.cc itself (little to no engine code should need to be updated for this resource to work effectively)

TorqueScript XMLObject

I have started working on an implementation of Expat (the Gnome XML Parser) library into TGB, and expect that a large portion of the code should work with TGE as well, as it's just a simple Console Object being added to the system.

So far, I've managed to create and expose the XMLObject class to TorqueScript, as well as added a 'parseDocument' method to the object, which is exposed to TorqueScript and takes in a Filename as it's only parameter. This then makes numerous calls to the startElement and endElement C++ methods (there's a static and non-static version of each, something to do with the function pointers that expat uses since its written in C). These C++ methods then call there TorqueScript equivalents, onStartElement and onEndElement, which allows a script developer to very simply use the SAX parser functionality of Expat within TorqueScript by doing the following:

I am intending to release the XMLObject code, along with any other TGB engine hacks I make that use the code, as a resource on GG's site. I'll post my progress here, and when I get a more completed version, I'll post a .plan on GG's site.

So far, all I've managed to cover is the Start and End element handlers, and the CDATA handler for the XML, my plans include to add the following:

1. SimObject.saveXml() -- save SimObjects as XML Files rather then TorqueScript
2. SimObject.loadXml() -- load SimObjects from XML Files, rather then exec()ing the TorqueScript
3. Full list of SAX Methods, as made available through Expat
4. Possibility of adding a DOM to the Code (Adding a DOM may require using yet another library, other then SAX, or a replacement to SAX that supports DOM -- but I'm going to take a look at implementing a very simple DOM using my own code, and my own XPath implementation -- just cause I wanna see how hard it'll be to do ;p)

Newer Posts »