Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Jul 2003
Online Last Active Today, 05:15 AM

#4934414 Links to Pseudo-random Theory?

Posted by JTippetts on 24 April 2012 - 06:36 AM

George Marsaglia posted several relatively simple generators to the old newsgroups many, many years ago. They're decent generators, and simple to implement. Alternatively, the boost library offers up good choices for high-quality generators, including lagged Fibonacci and Mersenne Twister. Knuth, of course, as you posted in your edit is always a good authority on PRNGs.

For games in general, you are mostly going to be looking for speed, as opposed to high-quality. Especially in noise applications, where you are layering many layers of noise together, you want your PRNG hash to be a fast as possible while still providing decent output. The reference implementation of Perlin noise provides a hash algorithm that makes use of a look-up table to "fold" bytes together to get the lattice hash for each point. The benefit of a look up table in this manner is relatively fast performance. As well, for a noise implementation you want to avoid any generator that requires internal state. Mersenne Twister, for example, stores internal tables and is complicated to seed, thus making it unsuitable for noise generation.

The link in my signature goes to the sourceforge page for my personal noise library. It's still (perpetually) under construction. As well, I have written quite a few journal posts regarding noise generation, seamless noise, etc... a few of which were published in Game Developer Magazine last year.

#4933180 Why don't Game Designers get respected in indy teams?

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

glhf, why do you always insist on taking it personally when nobody agrees with you? You have unrealistic expectations, and any time you are challenged on them you get angry and begin with the personal attacks. You are obviously wanting to fill the role of dictatorial-style game-designer that you so fervently argue for, and it seems like you want us all to collectively agree with your crap, and start hiring you on so you can be an idea man without doing an ounce of real work. Sorry if the world doesn't bend to your childish tantrums and unrealistic fantasies.

You all can keep on creating garbage indy games since you don't have any designers (since you dont understand their great value) in your games.

That's fine by me, Less competition

Best of luck being the guy with no competetion when you continually antagonize the people who have the skills that you need, the skills to actually make a video game (as opposed to just having an idea).

#4933089 Why don't Game Designers get respected in indy teams?

Posted by JTippetts on 20 April 2012 - 12:13 AM

In the end, I think it comes down to the fact that an indie game is a pretty small pie, that can only be cut so many ways. By that light, people start looking for places where they can trim the fat, so to speak. The designer tends to be the first one cut, because every indie fancies themselves a designer, and a designer who is only a designer (ie, who doesn't program, doesn't do art or sound or music) is deemed to be dead weight. Whether or not this is an accurate assessment is irrelevant. When there is only so much money to be thrown around, something has got to give. Would it be great if every good indie team had sufficient funding to pay a good designer? Absolutely. But for many of them, that's just wishful thinking. It's not a question of respect, or lack thereof. It's just economics.

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