Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Jul 2003
Offline Last Active Jul 23 2014 10:05 PM

#4931730 Using atan2 to find an angle between two points

Posted by JTippetts on 16 April 2012 - 07:35 AM

What exactly is happening?

One possible issue I see might be the order of operations of your relative vector calculation. If the center of your hit box is calculated as (rect.position + rect.size/2) then what you are actually doing in your call to atan2 is not correct. Consider the case of a hit box at (1,1) and sized (2,6). The center of the hitbox will be at (2,4). Now, consider a mouse location at, say, (4,4). Logically, the vector (mouse.position-hitbox.center) would be (2,0). But the vector you are calculating with (mouseY-hitBox.y+(hitbox.h/2), mouseX-hitBox.x+(hitbox.w/2) is not equal to (2,0). It's equal to (4-1+1, 4-1+3), or (4,6). You see? It's the order of operations. What you want is (A-(B+C)) but what you are doing is (A-B+C), which is not the same.

So try parenthesizing to get the correct order of operations atan2(mouseY-(hitbox.y+hitbox.h/2), mouseX-(hitbox.x+hitbox.w/2)) and see if that makes any difference.

#4931726 Component Object Model Examples?

Posted by JTippetts on 16 April 2012 - 07:20 AM

I highly doubt you have a need for it, if all you do is basic games and engines. COM is a process designed to allow object creation across language boundaries, allowing access to those objects from anywhere, regardless of the language being used. While it is still used under the hood in some places, it's an aging technology and a complex beast, and if you find yourself posting forum threads to get people to tell you why and how you should be using it, that's a strong indicator that you have no need for it and shouldn't be using it.

#4931455 Distance to ray intersection

Posted by JTippetts on 15 April 2012 - 10:01 AM

Heh, yeah, alvaro's code is the way to go if your boxes are axis-aligned. The algorithm I presented will work for any arbitrary box, but is overkill if your boxes never rotate. And looking at his, I realized that I didn't include the tests for if a point is inside the box, return 0 distance. As it stands, the code I presented will give the distance to the box's wireframe, so points inside the box will have a non-0 distance value. On an arbitrary box (as long as it is a box, and not a rhombus or trapezoid or other funny shape) you can test this easily by checking the values for u of the A->B and A->C tests, and if both do not require clamping (ie, both are in the range of [0,1]) then the point is inside the box, and you can return 0 for the distance.

#4931430 Distance to ray intersection

Posted by JTippetts on 15 April 2012 - 08:01 AM

Consider that the box is formed by the points A,B,C,D


From these points, you can obtain the equations of the lines forming the edges of the box: A->B, C->D, A->C, B->D. Recall that the parametric form of a line can be expressed as:
for any 2 points, P1 and P2, on a line. This means that any point along the line can be expressed in terms of the parameter, u. A value of u=0 evaluates to P1 on the line, a value of u=1 evaluates to P2 on the line, and values of u in between 0 and 1 evaluate to points on the linesegment described by P1 and P2. Values of u less than 0 or greater than 1 evaluate to points beyond the ends of the line segment.

For a given point, P, you can find the value of u that corresponds to the closest point on the line, P1->P2, by:

u=((P.x-P1.x)*(P2.x-P1.x) + (P.y-P1.y)*(P2.y-P1.y)) / length(P2-P1)^2

In essence, you project the point, P, onto the line. You calculate the dotproduct of the vectors P1->P and P1->P2, and divide this dot product by the length of P1->P2 squared.

This will obtain the value of u for that particular line that denotes the point on the line nearest to P. Since you are testing for distance to a box made of line segments, then you have to account for the fact that this nearest point might not lie on the box. In this case, you can simple clamp the value of u to the range [0,1]. If u is less than zero, then the closest point on that line segment to P is the point P1. If us is greater than 1, then the closest point is P2.

Once u is clamped, you can plug it into the parametric form of the line being tested, to find out the actual coordinates of the point. Perform this test for all four of the line segments forming the box, then calculate the distances between P and the closest points, returning the smallest of these four distances as the result.

Some sample Lua code is as follows:

function closestPointOnLineU(p, p1, p2)
local length=math.sqrt((p2.x-p1.x)*(p2.x-p1.x) + (p2.y-p1.y)*(p2.y-p1.y))
return ((p.x-p1.x)*(p2.x-p1.x) + (p.y-p1.y)*(p2.y-p1.y)) / (length*length)

function closestPointOnLineSegment(p, p1, p2)
local u=closestPointOnLineU(p,p1,p2)
u=math.max(0, math.min(1, u))
return {x=p1.x+u*(p2.x-p1.x), y=p1.y+u*(p2.y-p1.y)}

function distanceToLineSegment(p, p1, p2)
local closest=closestPointOnLineSegment(p,p1,p2)
return math.sqrt((p.x-closest.x)*(p.x-closest.x) + (p.y-closest.y)*(p.y-closest.y))

function distanceToBox(p, A, B, C, D)
local d1=distanceToLineSegment(p, A, B)
local d2=distanceToLineSegment(p, C, D)
local d3=distanceToLineSegment(p, A, C)
local d4=distanceToLineSegment(p, B, D)
return math.min(d1,d2,d3,d4)

Note that it's quick code, so I might have made an error somewhere, but initial tests indicate it works.

#4931362 How to read PNG images without a library?

Posted by JTippetts on 15 April 2012 - 12:09 AM

Wait, you're going to write a test renderer in XNA, optimize it, then write it in C++? For the love of all that's holy, why? Why bother with the "write it in C++" step at all, and undo all that effort you just spent to optimize it for XNA?

It seems to me like you ought to sit down and think about exactly what it is you want to accomplish. You seem to be heading down a path that's going to waste some time. First of all, given what I've read in this thread so far, you simply do not know enough about the language(s) to optimize anything. Optimization is often a trap in and of itself, since beginners rarely write code that challenges modern hardware, and if they do it's more along the lines of "choose a more optimal algorithm" than it is "optimize this algorithm". Second of all, if you do want to write a renderer, then the place to start is not with PNG loading code. This is a bad place to start. As many others have indicated, loading PNGs is a solved problem. The work is done for you. That is many, many lines of code that you do not have to write. Why in the name of Pete would you waste your time writing PNG loading code, rather than writing the renderer that you want to write?

Allow me to tell you a story. Once upon a time, I needed to write some code to pack a bunch of sprite rectangles tightly into a texture. So I googled rectangle packing, and I stumbled upon some algorithms. I knew just enough about the languages at the time to be able to adapt the code to my needs without fully understanding what it was doing. Eventually, I got to the point where I did understand it, but not by studying that code. I got there by writing game code, learning more about the language as I went. I somehow knew that studying rectangle packing code until I understood it completely was not the optimal route to becoming a better programmer. I also understood that spending a whole bunch of time writing my own packing code, when there was packing code readily available, was not going to get me closer to finishing my game. It would just be a waste of time, and I waste enough time as it is.

#4930563 2D Isometric vs 3D Isometric

Posted by JTippetts on 12 April 2012 - 07:24 AM

In this day and age, the only reason to go with pure 2D for an isometric is if the platform doesn't support 3D. Using 3D, even if you continue to use textured billboard sprites rather than actual models, opens up so many options and possible effects. Not to mention, as was already noted by Krohm, it fixes the draw order which in pure 2D isometric has always been problematic and riddled with edge cases. Doing basic 3D is scarcely more difficult than 2D anyway. As far as learning, you might check out the NeHe tutorials for OpenGL. They are re-tooling everything for more current GL, I understand, but even their legacy tutorials might be good to learn the basics.

#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.