Been a while
So it's been a while since I wrote anything here. I wrote a whole series of articles about a scripting language I probably won't use for anything over on gamedev.net. See it over there http://www.gamedev.net/blog/342-jemgine/.
I don't know what's going to happen to Gnomes. I released a 'build demo' of it, but nobody liked it or cared. I had been working on a single player AI demo, but it's buggy as all fuck. And my idea for fully peer-to-peer multiplayer is dead in the water, despite all the time I invested trying to get it to work. I'm seriously considering scrapping the entire thing and starting over in flash. At the very least, I might toss the scripting language and replace it with C#. That hurts, a little, because I wrote the scripting language, but it's about time I actually got stuff done instead of debugging an entire separate language that lacks all the features I want.
Anyway, if you read this blog because you're interested in my 2d game engine, 'Jemgine', then I'm sorry to tell you I haven't touched that thing in months. I pretty much consider it abandoned now.
So this isn't a post where I just whine about my own inability to finish anything, I'm thinking about writing up a method of laying out guis I've used several times. But not right now.
The LD website is down!
Right in the middle of screenshot saturday!
Well, first, the game!
Second, Dinner!
So that was easy.
package
{
import net.flashpunk.* ;
import net.flashpunk.graphics.*;
import net.flashpunk.masks.Grid;
public class OgmoTileMap extends Entity
{
[Embed(source = "assets/gfx/tiles.png")]
private const TILE_SET:Class;
public var tilemap:Tilemap;
public var grid:Grid;
public function OgmoTileMap(map:XML)
{
type = "world";
graphic = tilemap = new Tilemap(TILE_SET, map.width,
map.height, 32, 32);
for each (var tile:XML in map.layer0[0].tile)
{
tilemap.setTile(tile.@x / 32, tile.@y / 32,
tilemap.getIndex(tile.@tx / 32, tile.@ty / 32));
}
for each (var rect:XML in map.layer0[0].rect)
{
tilemap.setRect(rect.@x / 32, rect.@y / 32, rect.@w / 32, rect.@h / 32,
tilemap.getIndex(rect.@tx / 32, rect.@ty / 32));
}
mask = grid = new Grid(map.width, map.height, 16, 16);
for each (var xtile:XML in map.collision[0].tile)
{
grid.setTile(xtile.@x / 16, xtile.@y / 16, true);
}
for each (var xrect:XML in map.collision[0].rect)
{
grid.setRect(xrect.@x / 16, xrect.@y / 16, xrect.@w / 16, xrect.@h / 16, true);
}
}
}
}
See? It assumes all sorts of things about the map format, but, that's fine. No need to write a generic ogmo importer.
Preparing for LudumDare
That's right! I want to actually compete in this one. It's going to be hard, as I have to work on Saturday (Don't I always?) and I never think to ask for it off in time to actually get it off. And it's going to be even harder because I'll be doing my entry in Flash! Actionscript! With flashpunk! And the Ogmo editor! And none of these are things I know! So I need to prepare.
The first step is to install FlashDevelop. That couldn't possibly be easier. The installer downloads everything I need, and it just works. This is how all software should be.
Next, Flashpunk. So, Flashpunk is just a library of actionscript files. There's no installing, just copy it to your project directory and go. And, I also learn how FlashDevelop projects work.
Then I follow the Flashpunk tutorials. I don't actually do any of them - there's no time for that!, but I do read them. And I learn a lot about Actionscript. It looks a lot like any other imperative language.
So now I need to create a map in Ogmo, and, load and display that map in Flashpunk. How hard could that be?
Compiling entities to a single vertex buffer
This is something I've wanted to do in Jemgine for a long time. Currently (Well, until last night) to draw an entity (And, I mean every entity) meant iterating over all of an entity's attached elements, discovering if they were renderable, and then drawing them. Drawing each attached element usually involved at least a texture switch, and a draw call - sometimes more than one! Drawing a lot of entities was not an option. As it stands, it never became a problem for me. It still worked plenty fast enough. But I didn't like it, and I imagined having a static background entity made of thousands of sprites, something quite impossible with the existing method. I already knew a better way, it's just a matter of actually doing it. And, actually, it's not that hard at all. Keep in mind that this is optional, as it breaks many things. Any given entity can be compiled to a single vertex buffer, or drawn using the brute force method.
Here's how it's done in basic steps:
At build time,
-Gather all the textures used by the entity. One thing I did not account for in this stage (or any others) is elements whose' texture changes. Texture-switching effects will have to be achieved using the old brute-force rendering method. I also didn't account for Lines and Splines having a default texture, or round ends. These textures won't be included.
-Combine all of those textures into a single atlas texture. There's a problem here, if the texture created exceeds the maximum size the hardware can support. It also potentially wastes, via duplicating textures, video memory. Not much to do about it. I could build a whole-map texture atlas, but imported maps would still have their own atlas, with their own potentially duplicated textures; and the whole-map atlas would be much more likely to be too big. To pack the textures, I use a simple BSP subdivision scheme. There are better algorithms. I especially like the one from this paper http://clb.demon.fi/files/RectangleBinPack.pdf which subdivides the free space left from each placement into two overlapping rectangles. I might implement something like this in the future.
-Now I go through every element and get from it a vertex list in the form of a triangle strip. I use a strip because most of the elements were already rendered using one, so the data was there ready to go. The vertex indexes are implicit in the triangle strip as well. Each element also has a color and a bone id. To the engine, these properties apply to the whole element. For the final shader, they have to be duplicated across every vertex that makes up that element. I use the texture atlas to re-map texture coordinates.
-Now, this list of verticies and indexes, and the texture atlas, are serialized to disk. The texture atlas has not been rendered yet, it's just a set of filenames and rectangles so far. I do this partly because I don't know how to get XNA's content pipeline to store generated textures and vertex buffers (I know it can) and partly because the texture atlas is much smaller stored this way.
At load time,
-Deserialize everything.
-Load the individual textures in the atlas and use a render target and spritebatch to compose them into a single texture.
-Create the vertex buffer and index buffer.
Each instance of an entity will share the atlas texture and the vertex buffers, assuming they have been instanced properly. Though, I should check on that. I might not be creating the objects at all for imported maps!
At render time,
-Collect bone transforms. An entity can still have multiple skeletons, but it must have no more than 32 bones total. This is a mostly arbitrary constant. To continue running on shader model 2.0, and thus in the reach profile, I can't have more than 256 shader constants. Each bone transform represents, I think, 4 constants.
-Set the world matrix to the entity's transform.
-Draw the entity in a single draw call!
Gnome Colony
This isn't the first ever screenshot of this. But it's the first screenshot of the 3d version.
Fake HDR
DrPetter pointed out a real simple way to fake HDR for deferred rendering. The problem is that when multiple lights shine on a surface, they can't over brighten - you need HDR for that. Well, this is a pretty simple method of faking it. Draw each light onto the light buffer at 1/4th intensity, then when drawing geometry, multiply the light buffer by 4. The result is that now multiple lights shining on the same pixels can brighten them much more.
Somewhat unrelated, the FPS counter in my screen shots means nothing. Fraps makes it dip right when I take the screenshot.
Tweaking lighting
I changed it so the middle ground casts shadows, but doesn't receive them. So now you can actually see things.
Please try Inform7.
You will not regret it. It is an incredible declarative programming language. I'd love to see a more general-purpose version of this sort of paradigm. It doesn't have function calls, so to say... well, it's hard to explain. You attach actions to other actions. Since it exists only in a player-driven environment, this works quite well for it. Instead of calling a function, the functions states when it should be called. It's really quite amazing.
In Jemgine news, I've got a rudimentary immediate mode gui going. I use this to select an item, and then that items appears, attached to the mouse. The next step is to actually spawn that item into the world. It should be fairly simple. Once it 'works', I can worry about making it not look like crap.
