 Home
 » Viewing Profile: Reputation: JTippetts
JTippetts
Member Since 04 Jul 2003Online Last Active Today, 05:15 AM
Community Stats
 Group Moderators
 Active Posts 3,307
 Profile Views 30,391
 Submitted Links 0
 Member Title Moderator
 Age Age Unknown
 Birthday Birthday Unknown

Gender
Not Telling
User Tools
Latest Visitors
#4934414 Links to Pseudorandom Theory?
Posted by JTippetts on 24 April 2012  06:36 AM
For games in general, you are mostly going to be looking for speed, as opposed to highquality. 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 lookup 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
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
#4931730 Using atan2 to find an angle between two points
Posted by JTippetts on 16 April 2012  07:35 AM
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.positionhitbox.center) would be (2,0). But the vector you are calculating with (mouseYhitBox.y+(hitbox.h/2), mouseXhitBox.x+(hitbox.w/2) is not equal to (2,0). It's equal to (41+1, 41+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 (AB+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
#4931455 Distance to ray intersection
Posted by JTippetts on 15 April 2012  10:01 AM
#4931430 Distance to ray intersection
Posted by JTippetts on 15 April 2012  08:01 AM
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:
P=P1+u*(P2P1)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.xP1.x)*(P2.xP1.x) + (P.yP1.y)*(P2.yP1.y)) / length(P2P1)^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.xp1.x)*(p2.xp1.x) + (p2.yp1.y)*(p2.yp1.y)) return ((p.xp1.x)*(p2.xp1.x) + (p.yp1.y)*(p2.yp1.y)) / (length*length) end 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.xp1.x), y=p1.y+u*(p2.yp1.y)} end function distanceToLineSegment(p, p1, p2) local closest=closestPointOnLineSegment(p,p1,p2) return math.sqrt((p.xclosest.x)*(p.xclosest.x) + (p.yclosest.y)*(p.yclosest.y)) end 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) endNote 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
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
#4930223 Procedural Texture Generation
Posted by JTippetts on 11 April 2012  07:03 AM
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 antialiasing in order for the picture to not "sparkle". You can antialias 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
#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 selfrighteous 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 turnbased. 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
Then you set up the shader such that the greyscale color is obtained from the model's texture, and used as the vcomponent of the texture coordinate used to index the above colorscale texture, with the ucomponent 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
If you don't like turnbased, don't make a turnbased 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(DiskOperatingSystem)directly?
Posted by JTippetts on 07 April 2012  02:24 PM
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 16bit era. The good thing about emulators is that you don't have to worry about the vendorspecific 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 retrolooking game using these so, so lovely modern tools that we have.