Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
Paniolo
Oct 9, 2007

Heads will roll.
Is there a lightweight C# media library which works with both .NET and Mono? The only thing I've found is the TaoFramework and that takes way too much of a kitchen sink approach - a 33MB runtime installer for a game which will probably be under 1MB is a little excessive, especially when I only want to use about 2% of what's included.

Adbot
ADBOT LOVES YOU

Paniolo
Oct 9, 2007

Heads will roll.

Pfhreak posted:

I just spent a couple hours banging out a quick diamond-square generator to build heightmaps, and I'm pleasantly surprised at how well it works. I've gone ahead and written a quick box filter to smooth out the heightmap, which is a nice touch.

I've taken care of filtering out areas of all white/all black by preventing values greater than 1 or less than 0 for the height. I'd like to eventually use these terrains for a game like Tropico. Only, everything I'm reading online about XNA suggests that just building vertex/index buffers out of these heightmaps is an inefficient use of resources. (Obviously, rendering every heightmap every frame is going to chew up resources.)

My thought was to break up each heightmap into smaller patches, and produce smaller LoDs for each one, then determine which LoD to render by the distance to the camera. Is this a decent way to do this for a hobby type game? Is there a better approach? I want to have an arbitrary world size some time down the line, so I'm trying to plan for managing loading and unloading groups of these patches from the hard drive so I can roll around all over Mars or something.

That algo's known as "geomipmapping" and is probably the most common technique for terrain in modern game engines. Wiki has an article on it.

Another option is clipmapping (paper here).

Most other terrain algos you'll find when googling (like ROAM) aren't used anymore because they aren't GPU-friendly. Both geomipmapping and clipmapping can use static geometry buffers and sample the heightmap texture directly in the vertex shader.

Keep in mind when doing terrain that an inefficient LOD algo can actually lower your framerate on modern GPUs so you may want to benchmark against a naive implementation.

Paniolo
Oct 9, 2007

Heads will roll.
Haven't used it myself, but Recast is a navmesh generation library that looks interesting.

Paniolo
Oct 9, 2007

Heads will roll.
For a 2D topdown game with irregular geometry I would use a quadtree instead of a grid. The world's still divided up into squares, but only to the extent that's needed to accurately represent the collision geometry. So you can get pixel accuracy where needed without needing to store a pixel-level grid for the entire world. It's also easy to dynamically add and remove geometry.

There's no reason to use a navmesh for a 2D game. The only reason for using one is to allow layered geometry in levels (rooms on top of other rooms, bridges, etc.) and it is significantly more complex, which is one reason most early 3D games simply didn't allow layered geometry.

Paniolo
Oct 9, 2007

Heads will roll.

demota posted:

Anyone out there with web development skills interested in working on a game? It's for the Apps for Healthy Kids contest, part of Michelle Obama's "Let's Move!" campaign to end childhood obesity. I'm on a team, and we're looking to build a web game similar to Kingdom of Loathing. We've got pretty much every role we need, but our programmers are asking for more help. We're all volunteers and doing this online, but we're getting a lot done. Development is going at a pretty fast pace, specific tasks are being handed out, and we're establishing and meeting milestones. Here's a sample of the work that's been done.

A little off topic, but isn't it a bit ironic to create a web-based MMORPG for a campaign to get kids to spend less time on the Internet and more time outside?

Paniolo
Oct 9, 2007

Heads will roll.

Stavros posted:

Everything works fine until the last line; adding that gives me a memory access violation error. Any ideas what I'm doing wrong?

I'm not familiar with the library you're using, but it's probably one of two things: either one of the FreeImage_ functions is returning a null pointer (you aren't checking return values! Bad!) or glTexImage2D is trying to read past the end of the data you're providing it which typically means you're specifying the wrong format.

Paniolo
Oct 9, 2007

Heads will roll.

Valtis posted:

I have been bored lately and I decided to start coding roguelike game with C++, and at the moment I'm struggling with the inventory system. I thought that it would be easiest to have one base class for the items that has all the generic attributes such as weight and item name, and then have derived classes with item spesific attributes and methods. Items would be stored into vector as pointers to base class (vector<BaseClass *> items) so that I can have single container for all items. This however causes me some headache when I actually have to do something with the items, as the base class won't have all the methods etc. so I cannot use virtual methods. Currently I have to cast the pointer back to whatever derived item class I need to use which is rather undesirable for the following reason:

For example, when I want to show item attributes in the inventory, I need to cast all the weapon items back to weapons so I can get damage etc. values from the class, all the armor items back to armors to get defence values and so on for each item type, which makes the item list code huge stack of if - else if - commands:
code:
if (itemPointer->itemType == weapon)
	(Weapon *)(itemPointer)->Foo();
else if (itemPointer->itemType == armor)
	(Armor *)(itemPointer)->Bar(); 
...
So, is there any better way to create inventory as this approach has proven to be pretty terrible to me.

Seems like you're misunderstanding how to use polymorphism here. If you have some sort of operation which needs to know the subtype of a class but only has a pointer to the base class, 90% of the time the operation is being performed in the wrong place. The sort of thing you're doing there is a really strong code smell.

For example, you could do something like this for a fairly versatile system:

code:
class ToolTip {
public:
   virtual std::string GetString() = 0;
};

class WeaponToolTip {
public:
   WeaponToolTip(const Weapon* item);
   std::string GetString();
};

class ArmorToolTip {
public:
   ArmorToolTip(const Armor* item);
   std::string GetString();
};

class ItemBase {
public:
   virtual const ToolTip& GetToolTip() = 0;
};

class ItemWeapon {
public:
   ItemWeapon()
   : mToolTip(this)
   {
   }

   const ToolTip& GetToolTip() 
   {
      return mToolTip;
   }

private:
   WeaponToolTip mToolTip;
};

class ItemArmor {
public:
   ItemArmor()
   : mToolTip(this)
   {
   }

   const ToolTip& GetToolTip()
   {
      return mToolTip;
   }

private:
   ArmorToolTip mToolTip;
};

Paniolo
Oct 9, 2007

Heads will roll.

Orzo posted:

I don't know how I would do it. That's part of the reason I asked.

If you didn't know you'd do it, it seems strange to make a statement like "game programmers are bad at OO."

When it comes to game programming, performance tends to trump elegance, and that's especially true when it comes to OOP, and especially true in the age of multicore processors. The most natural organization of data from the programmers perspective is rarely the optimal organization for concurrent algorithms.

That being said if you're browsing gamedev.net's forums you're most likely looking at posts made by people who are as or even more inexperienced than yourself (regardless of your level of experience) so it's not really a great resource unless you know exactly who is talking.

Anyway, to contribute: I've been working on an experimental multithreaded game engine for a little while. The way I organize game data is to have several different modules which are all completely independent. They don't share any data but instead synchronize via message passing using lockless queues.

So, for example, there's an Entity class and a EntityManager which tracks the logical entity and its gameplay-related statistics. For rendering the equivalent is Actor and SceneManager, for collision/physics it's Body and PhysicsManager, etc. Unique IDs are used to identify objects in messages.

Each of the sub-engines (the Manager classes) works by first processing all pending messages to update its objects to the most recent state. For example the physics engine will receive any message from the game engine about position changes for bodies which are not physics-driven. Then it'll run its own simulation, and post messages to the game engine for any collisions or position changes for physics-driven bodies (using the entity ID codes to signify which entity it's talking about.)

Loose coupling is a huge advantage and means each system can be completely replaced without any effect on the others so long as the interface remains the same. No data sharing, which resulting in some additional memory usage, means that multicore processors can be exploited much more efficiently. Personally I find tight coupling of the various components (rendering, physics, logic) to be a huge code smell.

Paniolo
Oct 9, 2007

Heads will roll.

haveblue posted:

This is a horrible, horrible naming convention (unless you just pulled it out of your rear end for this example).

No that's actually what Source is like. What can you do, some people like the smell of skunks. Though the lack of a toolchain from this century is a bigger problem with Source than the naming conventions (of which it has at least half a dozen in use, since there's code in there dating back to the original Quake.)

Paniolo
Oct 9, 2007

Heads will roll.

Zero The Hero posted:

I've been trying to learn SDL for a while now, using the [url="https://"http://www.lazyfoo.net/SDL_tutorials/"]Lazy Foo Tutorials[/url] if you're familiar with them, but it's been slow going. I was checking out XNA recently and it looks a lot... cleaner. And easier. Is there any good reason NOT to use XNA and keep trying SDL?

Do you want to make something that runs on Windows and Xbox only and use C#? Then use XNA. If you want to make something that runs on other platforms, or use a language other than C#, then use SDL. The only real use for SDL nowadays is as a cross-platform wrapper for initializing OpenGL (and simple input handling.) The tutorials you linked might teach you some relevant concepts but in terms of practical game programming skills they're over a decade out of date.

Paniolo
Oct 9, 2007

Heads will roll.

Zero The Hero posted:

Do you have any better tutorials? So far the tutorials have been great. They don't teach everything, but what they do teach they teach well, and quickly. As for language, I'll write in whatever language I need to. I had planned to write cross-platform for SDL, but if I end up using XNA, I don't mind being restricted to Windows. I've written in C/C++/Python/Java/C# and a bunch of other things. But I feel like C# is going to take over a lot of things because of its simplicity, so if XNA doesn't have any downsides except being stuck on Windows, I might just switch to it.

It's not that those tutorials are bad, it's that they're obsolete. Any graphics work (yes even 2D stuff) nowadays should be done using DirectX (which XNA is a wrapper for) or OpenGL; as I mentioned, SDL is great as a cross-platform initializer for OpenGL, but that's about it.

I'd say you should go with XNA, there's a lot of good documentation available for it, and it uses modern graphics programming techniques. There's so much out of date stuff floating around for SDL and OpenGL (like NeHe) that a lot of people don't realize they're reading something out of the 90s.

Paniolo
Oct 9, 2007

Heads will roll.

Orzo posted:

I think you might be slightly misunderstanding, XNA source and dest represent a source texture and a dest rectangle render target. Basically what I need is tiling from a sprite sheet, which I now know is impossible (from googling this issue) without the use of pixel shaders. Oh well, time to learn shaders!

A little late but yeah you need to write a pixel shader and pass it two sets of texture coordinates, the logical set and physical set. In the pixel shader, take the logical set and chop off the integer component and use the fractional component to lerp between the physical set.

The downside here is that you won't be able to use hardware texture filtering or mipmapping without getting artifacts. If filtering is needed you'll need to implement it yourself in the pixel shader.

Paniolo
Oct 9, 2007

Heads will roll.

Orzo posted:

Thanks for the response, I'm already in the middle of doing pretty much that (the first part, not the filtering). The upside is that this got my away from crappy flexible vertex formats and into vertex declarations! Always nice to learn the better way to do something.

I forgot to mention, if your tiles are all identical in size (or you aren't pressed for texture memory) you could use 3D textures instead, with each slice containing one tile. Then you could still take advantage of hardware filtering and the like.

Paniolo
Oct 9, 2007

Heads will roll.
Would anyone happen to have any experience with Autodesk's FBX SDK?

Paniolo
Oct 9, 2007

Heads will roll.

OneEightHundred posted:

My limited experience is that it's terrible and you should probably use COLLADA in combination with FCollada or Assimp instead. FCollada is lower-level but supports basically the entire format, Assimp is more of a high-level general purpose model loader that supports a bunch of other formats as well and is quite handy.

(COLLADA and FBX are nearly the same feature-wise)

Yeah I managed to figure out everything I needed, but it was a huge pain (and takes loving forever to build.) Assimp looks much better to work with, thanks for the tip.

Paniolo
Oct 9, 2007

Heads will roll.

haveblue posted:

FBX is terrible for live engines, it's meant for writing exporters.

Why would you assume I'm not writing an exporter?

Paniolo
Oct 9, 2007

Heads will roll.

OneEightHundred posted:

Because the FBX SDK is also used for importers/converters (much more often than writing exporters for that matter).

Oh, I misunderstood what you meant by exporter. My project is a model viewer for my game engine that can import FBX/other formats, allow me to make some tweaks and add some game-specific metadata and export it in my engine-specific format. So I was using FBX SDK for importing, not exporting.

Just in the last couple of hours I got importing via assimp working so I'll probably end up scrapping the FBX SDK importer.

Paniolo
Oct 9, 2007

Heads will roll.

HaB posted:

Wasn't really a complaint so much as an observation. I guess I will see how well Unity performs for what I want to do when I get far enough along. I guess I'm just used to being a coder - so the drag and drop thing is sort of alien to me.

I'd suggest deciding if you want this project to be about making a game, or programming a game. Because if you're turned off by not writing code, then my advice is to just work on a programming project, like a hobby engine or tech demo. If you actually want to make a finished game then use Unity or GameMaker or mod an existing game or whatever is at your disposal, because actually making a game is such an enormous amount of work that an individual simply cannot afford to not take every shortcut possible.

Paniolo
Oct 9, 2007

Heads will roll.

OneEightHundred posted:

What heavyweight library? Use FreeType. You don't need to use some bullshit with an OpenGL integration layer, just render glyphs to bitmaps, store them in a texture, and keep track of the coordinates/dimensions.

FreeType's a reasonably heavyweight library.

Then again, if you want to do anything with vector fonts, a heavyweight library is basically necessary, because vector fonts are loving complicated.

Rocko Bonaparte posted:

What annoys me is that we are here in 2011 and working with text is still such a huge chore in OpenGL. All those solutions shouldn't have to be necessary.

Text layout and rendering is not, and should not, be a part of OpenGL; OpenGL is a low level interface to the graphics hardware, not a graphics engine. Virtually any engine or framework built over OpenGL will have text layout and rendering features, so maybe the issue is you're trying to work too close to the metal.

Paniolo
Oct 9, 2007

Heads will roll.
Or you could just use a program like this one to generate the font texture ahead of time.

Paniolo
Oct 9, 2007

Heads will roll.

Rocko Bonaparte posted:

Is there a good online primer about different model animation file formats and their limitations? I was toying around with loading and animating an MD2 model in Irrlicht and found it was a bit counter-intuitive. There is some concept of fixed actions that use a compiler enumeration, but it looks like there isn't something in the format for defining arbitrarily different animations. I assume most of the formats have their little quirks like that, so I hoped there was a programmer's primer for these so I can go in understanding all their little limitations.

If you just want to get some pre-existing assets into your program I'd recommend using assimp as an importer and rolling your own model file format based on your own needs. Assimp will deal with the quirks of the various formats it imports and put everything in a standardized data structure for you.

Paniolo
Oct 9, 2007

Heads will roll.
In Starcraft 2, placing a building flattens the terrain underneath to the height at the centerpoint of the building.

Terrain flattening is the way to go, because that's how construction works in real life anyway.

Paniolo
Oct 9, 2007

Heads will roll.

MonsterUnderYourBed posted:

I honestly think that's more of a case of people still seeing things like trophies etc as something outside the game, rather than just another experience you can utilize. Looking at it from a traditional design point of view, and applying the idea of a design is perfect when you can't cut anything more out, you would be tempted to remove them, but if you see them as part of the core game you can acknowledge them as having tangible design benefits, this will also lead to better pacing of these features, as rather than just having them placed on top of existing progression, they can fit lulls in your game.

Achievements offer a nice way to give a player goals without railroading them towards specific objectives, especially in open-ended games like MMOs or sims where there isn't really a way to 'win' anyway. Just consider how much they could add to a SimCity-like game, for example.

Paniolo
Oct 9, 2007

Heads will roll.

Cray posted:

On the flip side, open games like that are all about setting your own goals. With a limited achievement set you can end up stifling player creativity by only rewarding actions you've been able to anticipate. "Oh, I'm supposed to be doing this and that... OK, all achievements unlocked, time to uninstall." Some sort of dynamic achievement system that automatically detects that the player did something cool would be nice, but I have no idea how that would work.

This doesn't make any sense; if a player exhausts all available achievements, then they're in exactly the same position as if the game didn't have them in the first place. Unless you're suggesting that someone would say "Well, I enjoy playing this game, but since I've gotten all the unlocks I guess I have to stop playing now!"

Achievements might compel someone who would otherwise stop playing your game to play it a bit longer, but they aren't going to make someone who'd be willing to play without any objectives stop playing because they've all been unlocked.

Paniolo
Oct 9, 2007

Heads will roll.

Rocko Bonaparte posted:

I've read enough into the Blender n00b to pro guide to know a little bit about making some meshes now and animate them with bones in place. Now I'm thinking about how this stuff makes it over to an engine in some meaningful way. I was hoping for some modularity in particular. I am trying to use Irrlicht, but if another engine has solutions for what I was hoping to find, I'd look at it.

For all of these, I'm assuming a model of a humanoid character.

I was wondering how to manage things like holding different items without redoing all the animations for a model. I assume one can split the upper and lower body to some extent and just animate the upper body separately, but generally how does one accomplish this and have the engine know what to do?

Now what about a head that moves and turns and shifts eyes and possible opens it's mouth to feign speaking--which is the best I could ever expect to do myself. I assume there is some programmatic control here. Is there a general method for these?

Is there a way to define general animation with bones and have different humanoid meshes all use those animations? It would suck a lot to be forced to animate slightly different sized and shaped people over and over for each new one.

An animation doesn't need to modify every bone in a skeleton, and you could specify a per-bone weight for each animation. So a full-body walking animation would have a weight of 1.0 for the legs, but only 0.1 for the arms, which means another animation being blended with it would have more control over the arm movement. Animation blending can be as simple or as complicated as you need it to be; you can have a complex tree structure with animation nodes and blend nodes, for example. Or you can just specify that each model can play one baseline animation and one additional animation at a time.

The most common way of using animations with different skeletons is to assign a unique id value (such as a string name) to each bone and when you start to play the animation, figure out at runtime out which animation track goes with each bone. This makes it so your bones don't necessarily need to be in the same order for each of your models, so long as their ids are set correctly.

Paniolo
Oct 9, 2007

Heads will roll.

Physical posted:

Now I'm doubting what I thought I already had figured out. Can someone with DX10 shader experience help me: Can DX10 shaders be called in any order? e.g. Pixel shaders -> Geometry Shader -> Vertex shader or VS->GS->PX or any combination?

I don't think you quite understand how the rendering pipeline works. A geometry shader takes input geometry and outputs a set of vertices; a vertex shader takes a vertex as input and performs transformations on it; a pixel shader takes a transformed vertex and outputs a color value.

From there, it's pretty easy to see that the shaders must execute in that order, because the output of each one is the input of the next shader.

Paniolo
Oct 9, 2007

Heads will roll.

HappyHippo posted:

I don't think this is quite right. Pixel shaders don't take vertices - after the vertex shader the triangles are rasterized and the pixels produced are sent to the pixel shader.

I was simplifying it for his benefit. And Physical, you're confused because it's a multipass algorithm. The first pass renders to a texture which is used as input for the second pass.

Paniolo
Oct 9, 2007

Heads will roll.

roomforthetuna posted:

This suggestion might, of course, be wrong - it appears that the popular thing to do these days is just always treat the player like a retard, and maybe there's a good reason for that.

Honestly, if a game treats me like I'm retarded, at worst I get a little less enjoyment out of it than I would have otherwise. OTOH, if at some point I get completely stuck and have no idea what to do, if I'm not enormously invested in the game by that time, I'll probably just give up on the game.

I'm not disagreeing that a balanced approach is best, but between the two it's probably better to error on the side of giving the player a little too much guidance. A lot depends on the genre though.

Paniolo
Oct 9, 2007

Heads will roll.
I haven't used it myself, but I've had this sitting in my bookmarks for a time where I need to generate trees or foliage for a game:

http://ngplant.sourceforge.net/

quote:

ngPlant is a plant modeling software suite. Designers can use interactive tool to create 3D models of different plants and trees. Software developers can use 3D API-independent library to use generated plant models in their 3D applications, or to create plant modeling plugins for different 3D modeling tools.

Free and open source.

Paniolo
Oct 9, 2007

Heads will roll.
http://www.youtube.com/watch?v=QZxRauOpfwo

I've been working on a voxel-based procedural level generator, loosely inspired by this article from GPU Gems 3:

http://http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html

While they do everything on the GPU and use perlin noise as a density function, I'm doing it on the CPU and sampling a voxel map + filtering for the density function. Eventually I will add noise to displace the vertices slightly, so the edges aren't quite so straight.

The voxel map generation algorithm is stupidly simple. Eventually I want to feed it data from a roguelike-style dungeon generator. My long term goal is to see how far I can push the kind of procedural level generation you see with roguelikes into the realm of hi-fi graphics.

Paniolo
Oct 9, 2007

Heads will roll.

PDP-1 posted:

The only tricky bit would be figuring out how to do path finding on a randomly-generated map in some efficient way. I suppose you could derive a set of A* nodes from the density function pretty easily (hollow = passable) but you'd have to find the 'floor' of each hollow section and then stitch the maps of generated blocks together and oh god that does not sound like a fun evening of hobby programming at all.

Anyway, keep posting your results - this looks like a neat project.

Thanks! I don't expect pathfinding to be a problem since the geometry generation is set up such that empty cells are guaranteed to not have any geometry in them, and solid cells will be sparsely to densely filled with geometry based on the density of the voxel and its neighbors. Each voxel is rather large (the maximum floor to ceiling distance in the video is only 3 voxels), so I just need to treat every empty cell as completely pathable and every solid cell as completely blocked. That should make course pathfinding and collision detection trivial.

Paniolo
Oct 9, 2007

Heads will roll.

Physical posted:

Looks great! And my jaw hit the ground because you are doing the same thing I am using the same article. It looks like you understand it better. I need help understanding in which order the dx10 shaders get called so that I can convert it to the CPU. Can you help me out?

I do everything on the CPU, I don't use geometry shaders (using DirectX 9.) I would recommend first getting a working marching cubes implementation that just spits out positions and normals to a vertex buffer from an arbitrary density function (a good one to test is the function for a sphere.) Once that's working then you can work on a density function that samples your voxel map, and then finally you can improve you shaders to add lighting and texturing.

I am not actually using any code from that article, I developed my marching cubes implementation based on this: http://paulbourke.net/geometry/polygonise/ and my voxel sampling function was entirely custom. I guess you could say I took inspiration from the GPU Gems article but I don't like their implementation since it gives you very little control over your geometry and no way of accessing it from the CPU to extract collision data.

Paniolo
Oct 9, 2007

Heads will roll.

Physical posted:

Marching cubes makes "smoothish" connected polygons. Is that a correct line of thinking?

Yeah, marching cubes is not actually a voxel algorithm, it operates on a density field. It's just relatively trivial to sample a voxel map as a density field by interpreting filled cells as some positive value and empty cells as some negative value.

The GPU gems article is misleading as hell because it refers to the cubes in the marching cubes algo as voxels but really nothing in that article has anything to do with voxels as a way of representing the world.

Rocko Bonaparte posted:

Hah I can understand the confusion. I didn't mean to infer one directly lead to the other. I don't even necessarily imply that collision detection is particularly a thing. I am more thinking about being able to have meshes of significant complexity and detail and be able to have them interact with stuff. It's one thing in my mind to understand them all as different entities and know how to move them around and stuff, but it's something else to go that last bit and have meshes representing them doing their thing. That's where I was getting overwhelmed.

Collision engines generally simplify the world into simple primitives like axis-aligned bounding boxes, spheres and cylinders. Doing collision detection against an arbitrary mesh is only needed for things like hit testing in a FPS. Even then the mesh is usually simplified into a convex hull.

Paniolo fucked around with this message at 07:13 on Apr 7, 2011

Paniolo
Oct 9, 2007

Heads will roll.

Physical posted:

What would be a voxel algorithm?

The voxel rendering algorithms I'm aware of either involve raycasting/raytracing (this is what Carmack thinks the future of 3D graphics is), generating a quad for each voxel face that is next to an empty cell (Minecraft) or sampling the voxel map as a density field and using a isosurface generation algorithm like marching cubes or dual contouring.

Physical posted:

How is it trivial? Do you mean easy or there is no point to do it?

Easy.

Paniolo
Oct 9, 2007

Heads will roll.
Added texture blending - each voxel has a material assigned and the sampling function filters blending weights based on the surrounding voxels. Up to four materials per level are supported right now, and the pixel shader is definitely starting to cause some slowdown, since I'm sampling each texture 3x for the triplanar projection. Time to add visibility culling and geometry sorting!



Here's a shot showing the boundaries of the voxels on the y=1 plane (the ground plane), so you get an idea of how easy pathing and collision is.



And here's a birds eye view of the voxels:



edit: Video with the new stuff in: http://www.youtube.com/watch?v=LeISMAg_XgA

Paniolo fucked around with this message at 20:23 on Apr 7, 2011

Paniolo
Oct 9, 2007

Heads will roll.

Vino posted:

Think that could be done using hex grids and simplex noise instead of those obvious boxes?

Definitely possible but just thinking about the sampling equations makes my head hurt.

Paniolo
Oct 9, 2007

Heads will roll.
Last update I'll post for a while, because I'm going to start working on behind the scenes stuff like occlusion culling. My level generator is now procedural rather than random, so it produces continuously pathable levels.

http://www.youtube.com/watch?v=yiU47B-oR48

The generator is split into several parts. The first stage is to produce a 2D tile map using a tunneling algorithm. The map generated in this stage looks like something out of a very basic roguelike - every cell is either floor, wall, or obstacle. In the future I'll add more tiles, like 'pit', 'water', etc.

Next that 2D map gets converted to a a 3D voxel map by following some basic rules. For example, floor tiles are empty from y-layers 1-3, walls are completely solid across all layers, and obstacles are solid on layer 1 and have a chance of extending vertically into layer 2. From there the mesh generation algorithm is run on the voxel map.

Each stage of the generator is completely independent. So I could have multiple map generators and multiple rules for transforming tilemaps into voxel maps, and mix them up for a lot of variety in possible level designs.

Paniolo
Oct 9, 2007

Heads will roll.

Gerblyn posted:

That's pretty loving cool man. Are you intending to turn this into a game or is it more of a tech demo thing that you're making?

I'd love to turn it into a game (my loose concept is a mashup between DOOM and rogue. Think old-school, Serious Sam-style shooting but with permadeath and an inventory.) But mostly it's a portfolio piece, trying to get a job in the industry.

Paniolo
Oct 9, 2007

Heads will roll.

ShinAli posted:

Love the stuff you've been posting, procedural things are always real cool.

I'm starting to get into shaders more after writing out my phong shader (which is a milestone for me because I actually understand the math). I'm wondering though how would multiple lights be handled? I'm using OpenGL so would I define the lights using glLightfv and iterate through them inside the shader? Or would I be doing something completely different?

glLight* functions won't work with shaders, they're for the fixed-function pipeline. Pass the relevant lighting info into the shaders via constants. Within the fragment shader iterate over all the lights (you can set the number of lights via a shader constant) and apply their contribution to the pixel.

Adbot
ADBOT LOVES YOU

Paniolo
Oct 9, 2007

Heads will roll.

Erotic Crab posted:

I am working on my thesis which partially involves developing a game that I need to run on pretty much all platforms simultaneously (OSX, Windows, Linux, Android, iPhone, etc). Yes, I know that these all use vastly different languages and resources, but I have heard of development software that makes it easy to port...

I am looking for something easy to develop with, either in 2d or 3d, that wouldn't be too much of a hassle to port. I am somewhat versed in C++ and Java, but would be willing to learn some other language to make this happen quicker.

What would you recommend?

I think Unity can hit all of those except for Linux. SDL could probably target all of them but you'll have to write platform-specific code for stuff it doesn't do. Plus I don't know if you can use OpenGL with SDL on all of the platforms it supports, but the 2D functionality should work.

HTML5 might be your best bet.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply