Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Jul 2003
Offline Last Active Yesterday, 05:47 PM

#4930223 Procedural Texture Generation

Posted by JTippetts on 11 April 2012 - 07:03 AM

You don't need to do anything special in regards to the function itself, just use a 3D Perlin noise fractal function, and ensure that the fractal is composed of enough layers, or octaves, to produce the desired detail at the highest level of zoom.

Each point on the surface of a sphere has an associated 3D coordinate, which is used to index the Perlin function. At low levels of zoom, ie from outer space, the sampling granularity is more coarse, meaning the samples are taken quite far apart, and each pixel covers a quite large area. In cases like this, you need to perform filtering or anti-aliasing in order for the picture to not "sparkle". You can anti-alias a Perlin function by sampling an area of pixels or values, and performing a weighted blend of them together to get the final pixel value that is more representative of the area than a single point sample would be.

#4929542 Tiles with light blue showing white on Laptop

Posted by JTippetts on 09 April 2012 - 07:05 AM

On my desktop LCD monitor, I can barely see the blue in your second picture. I have to stand up from my chair to do it, so that I kind of look down on the monitor from above. Probably just a weakness of certain LCD monitors. Maybe try upping the contrast just a little bit, so that the blue isn't so close to white?

#4929342 What do you think about Turn based combat?

Posted by JTippetts on 08 April 2012 - 09:54 AM

It seems the only argument for turn based combat is that bad players think it's not possible to think through their actions in real time.

Sorry, but by anybody's definition of trolling, this is it. That's all it is. Just trolling, no redeeming value whatsoever in such statements. All your self-righteous claims that you're just trying to help us poor stupid bad players, because you've got a whole 15 years experience, only adds to the troll. You didn't, as you claim, make this thread to find out the advantages. You made this thread to bash turn-based. I haven't seen any evidence otherwise.

I am sorry I contributed to this thread, though. It made me feel dirty.

#4929341 Different outfits for a character? (low poly)

Posted by JTippetts on 08 April 2012 - 09:46 AM

Mapping a greyscale value to a color value is as simple as using a color curve or a color scale. You set up some sort of gradient, with as many colors in it as you need, arranged in a texture like so:
Posted Image

Then you set up the shader such that the greyscale color is obtained from the model's texture, and used as the v-component of the texture coordinate used to index the above colorscale texture, with the u-component as 0, in order to obtain the color to draw. A greyscale value of 0 would draw color from the left side of the colorscale, while a value of 1 would draw from the right. Values in between, of course, would draw from the inbetween scales.

And no, you don't necessarily have to put all the unwrapped components onto a single texture. Some state change such as a texture swap here and there isn't going to kill you.

#4929337 What do you think about Turn based combat?

Posted by JTippetts on 08 April 2012 - 09:32 AM

In this thread, yet another troll disguises a stupid bash post with a thin veneer of "discussion", then gets angry when nobody agrees with him. I'm sorry, but trying to say that a turn-based game is "less skillful" than an action game is just... God, it's just stupid. No, glhf, you are not as awesome as you are trying to say you are. Sorry, but no.

If you don't like turn-based, don't make a turn-based game. Simple as that. But don' get mad if nobody else jumps on the bash train with you, and don't make stupid blanket statements under the guise of "discussion".

#4929137 How do I program in DOS(Disk-Operating-System)directly?

Posted by JTippetts on 07 April 2012 - 02:24 PM

I fear you have a few misconceptions. DOS didn't work in a "1 bit per pixel" style. It worked in a "this vendor does it this way with 4 bit-planes per pixel addressed at such and such or accessed by way of these interrupts, that vendor does it that way, and I need to write about 7 different 'drivers' for the most popular EGA/CGA/MCGA/VGA cards if I want to expose my game to the widest possible audience. And I have to hand-code them in assembly. I also have to be careful, because squeezing the best bare-metal performance out of these vendor-specific cards can be a pain in the ass." The VGA era of cards started to bring some sanity to the whole mess, but it wasn't really until the Windows era that developers could start to count on a consistent interface with the video drivers and not worry about coding for several different popular vendors.

These days, it is hard to find retro PC platforms to develop upon. Your best bet is to find a VM or emulator. You can dig around with old projects like DJGPP, which was once upon a time a pretty active project in the 16-bit era. The good thing about emulators is that you don't have to worry about the vendor-specific crap. Just code to the emulator.

As far as my personal opinion, I'm glad those days are past. GLAD, I say. I have 0 nostalgia for them. I still remember my very first graphical game written in DOS using the A86 assembler on an old 8088. 32x24 tiles at 16x16 pixels per tile on an EGA, and you could literally eat two bites of your PB&J while waiting for the screen to redraw because I knew exactly dick about the hardware and optimization. My personal opinion is to forget DOS assembly coding and emulators, and just code a retro-looking game using these so, so lovely modern tools that we have.

#4927092 What is this I don't even? (How does I make game?)

Posted by JTippetts on 31 March 2012 - 09:40 PM

Whatever book told you that, throw it away. The Lua distribution comes with the interpreter, as well as the library code needed to embed the interpreter in your application if so desired. Just head to Lua's webpage, download an installation, fire up lua.exe and go to town. And if you want to eke out that last little bit of performance (note: you probably won't need to), there is always LuaJIT, a drop-in replacement .DLL that implements the Lua virtual machine as a just-in-time compiler.

So, no, you don't need to write an interpreter. All the hard work is done for you in that regard.

#4927084 What is this I don't even? (How does I make game?)

Posted by JTippetts on 31 March 2012 - 08:33 PM

Why would you need to "write an interpreter in C basic"?

I'd say a good place to start would be Love's own tutorial section.

#4927023 Realistic movement in Diablo like game

Posted by JTippetts on 31 March 2012 - 03:27 PM

The problem I've found with trying to implement realistic movement and AI in a Diablo-clone is that nobody notices. They're too busy pounding the buttons that make things die to realize that those six Cannon Fodders they just killed, like, totally worked together and stuff. The outcome of the fight was completely uninfluenced by their working together. Diablo-clones by nature are mow-em-down type games, so it's probably a waste of development time to get too complex with the behavior systems. There seems to me to be an inversely proportional relationship between the number of enemies on-screen and the amount of time the player spends thinking about the behavior of those enemies. To make AI and behavior actually have an influence on the outcome of the fight and make an impression on the player, I think there needs to be a dramatic reduction in monster count, and Diablo-clones are more interested in throwing more and more mobs at the player, not less and less.

Furthermore, the scenario of your typical Diablo-clone doesn't really necessitate complex reasoning. Bear in mind, of course, that when I mean Diablo-clone, I mean Diablo-clone. Hordes of baddies, flashy special effects, gold and loot and items and spells flying all over the place. You know, like Diablo. In such a scenario, the two opposing factions (player and mobs) each have the same goal: kill the other. They do so with resolute intensity, pouring all of their focus into that task. The player collects items and skills and levels for the sole purpose of being more effective at killing the mobs, and the mobs use their special mobly powers of mobbiness to... well... kill the player. Maybe some do it in a sneaker fashion (teleport+shoot, retreat+summon, what have you) but the overriding goal is still the same. In such a scenario, there really doesn't need to be a complex behavioral system driving it. A few randomized behavior trees can give the appearance of intelligence on a passing glance, and that is about all that is necessary.

If the intention is to move beyond this, then by nature you are moving beyond being a Diablo clone. But still, it's not exactly a field requiring complex AI. Have you ever been in a bar fight, or a school-yard scrap, or just a ninja-swords-made-from-PVC-pipe-fight with your cousins? Try to imagine that scenario only bigger. Deadlier. In the vast majority of these cases, there is going to be a straight-line approach made to the most dangerous opponent, followed by perhaps a bit of circling and dancing in the course of what is mainly a frontal assault. The main baddy's friends will circle around, maybe some will be too scared to approach, maybe others will try to jump in, but for the most part these untrained combatants will not cooperate and will, in fact, just bumble around doing their own thing and getting in each other's way. Trained combatants, on the other hand, will cooperate. But so often, this cooperation can simply be simulated in-game with a few clever tricks like evenly spacing the mobs around an opponent to threaten him from all sides, throwing buffs on one another as needed, prioritizing certain abilities based on an analysis of the player's build, etc...

In all of this, the actual mechanical act of moving is the simplest part, and any basic A* shortest-path-finder with some dynamic obstacle handling is probably going to be more than sufficient.

#4925027 Math and 2D game development

Posted by JTippetts on 24 March 2012 - 08:57 PM

The thing is, you don't really need in-depth knowledge of any given field. You end up cherry-picking a few bits here and there. And like alvaro said, you don't necessarily need to understand it all, as long as you can at least get it functional. Additionally, if you start on a game project of any significant length, there will come a time when you no longer deal with the math at all. Once the framework is done, and you are well into the content generation phase, it is entirely possible that you will forget everything you knew about linear algebra and calculus as regards game development, such that when you start writing the next framework you have to learn it all over again. Happens to me all the time.

Also, don't postpone working on anything until after you feel you know all the math you'll need. Getting a project to work offers a fantastic learning experience to help you pick up the knowledge as you go. You'll go into it a math noob and come out... well, maybe still a noob, but at least a noob with a working 2D game framework under his belt and a better grasp on things than before.

#4924991 Get a point along a bezier based on distance

Posted by JTippetts on 24 March 2012 - 04:43 PM

Solving this problem analytically is hard. It requires integrating the curve, and in many cases the integral can not be computed analytically, so a numeric approximation might be your only solution.

An optimization that you can make involves constructing a look-up table that maps t to s, t being the parameter and s being the arc-length, and another table that is the inverse, mapping arc-length s to the parameter t. This way, if you need a particular arc-length point, rather than iterating the curve you can just dereference s in the s->t table, and solve for the t value the table stores.

#4923076 Skeletal animations and skinning

Posted by JTippetts on 18 March 2012 - 11:16 AM

Yes, you can do all the skinning and animation in Blender, export to the Ogre format, then load in your app. Ogre also supports blending different animations together to support, for example, running+shooting, running+dodging, etc... types of scenarios.

Note that the Ogre format is just one possibility, but it is a well-supported format with an active community.

#4922905 Skeletal animations and skinning

Posted by JTippetts on 17 March 2012 - 04:32 PM

.OBJ doesn't support animation.

You'll probably want to look into other available formats for exporting animations from Blender. Possibilities include the DirectX .X format (which isn't DirectX specific, so is just fine for even OpenGL apps), Collada, Ogre's mesh formats, etc... Personally, I like the Ogre format. The unofficial Blender 2.6 exporter can be found here (the official exporter for 2.6 is still in progress) and it exports mesh and armature data to XML which can be processed to a binary format by Ogre's command-line tools, or which can be parsed by your own application instead.

The Ogre format supports up to 4 bone weights per vertex, though of course Blender supports many more. The exporter will choose the 4 largest weights and spit out a warning upon export, that can safely be ignored. You perform vertex weight painting in Blender itself; the vertex weight painting is fairly intuitive and easy to do.

There are many tutorials available for the actual acts of rigging the mesh with an armature, painting the vertex weights (Blender also provides a few options for automatically assigning weights based on bone envelopes) and parenting the armature to the mesh. Once this is complete, you can pass the mesh/armature assembly through the Ogre exporter to get the XML files.

The Ogre exporter will generate two files (well, 3, since it also outputs materials; if you are doing your own system rather than using Ogre, you can ignore the material export). One file defines the mesh, and specifies vertex data and bone weights per vertex. The other file defines the skeleton and the keyframes of the exported animations.

#4921037 Geometry triangle problem

Posted by JTippetts on 10 March 2012 - 09:17 PM

Given that you know r and d, and that you can calculate the distance between D and C, you can use the Law of Cosines.

c^2 = a^2 + b^2 - 2ab*cos(theta)

In this case, the distance between D and C is a and the distance between A and D is b. The distance between A and C is c. Re-arranging the above equation gets you:


Thus, the angle ADC would be calculated as:

ADC=acos( ( (AD)^2+(CD)^2-(CA)^2 ) / 2*(AD)*(CD) )

#4920422 Drawable entities and fast isometric depth sorting

Posted by JTippetts on 08 March 2012 - 08:31 AM

In my game, any entity that is to be drawn is given a renderable component of some type, be it static or animated. Rendering is handled by a Scene structure that implements the map with the tiles and the animated objects. A renderable component will create an animated object or static tile and place it in the map, and will listen for movement commands from the parent object. Any object that is not to be rendered is not given a renderable component, and thus is simply never considered for rendering.

The map is implemented as an array of buckets, where each bucket holds a list of SceneEntity. SceneEntity is currently either a StaticSceneEntity (something that is only a static image or tile, such as a ground tile, a tree/bush/rock, etc...), an AnimatedEntity (contains an animation set, which includes all animations in all facing directions the entity needs) or a TextSceneEntity (for over-the-head floating text). The map is iterated based on the current view or camera, and a render list is constructed that is sorted from back to front based on the RenderLayer of the entity as well as the back-to-front sorting. This way, I can implement underlay/overlay effects, blob shadows, and so forth by using RenderLayer to control ordering. Once the master list is constructed, it is iterated to draw the objects.

Every frame, the Scene is rendered. Now, in order for a game object to be drawn it needs a renderable component. Objects are implemented as basically a bucket of components. (You can read a bit about how my system works here). So if I want to create a static object such as a rock, I would do:

obj:handleMessage("SetObjectLogicalPosition", {x=20, y=0, z=35})

Simple as that. If I leave out the step of adding a StaticSceneEntityComponent, then no entry for the rock is made into the Scene structure, so nothing is drawn for it.