|
md3 has some bones for aligning sub models, they are called tags I think. I used md2 for a while, but it has a problem that the vertex coordinates are compressed and the compression is lossy. I recommend MD3.
|
#
?
Apr 15, 2009 12:02
|
|
|
|
| # ? May 24, 2024 11:54 |
|
|
OK, so, I'm writing a game in COBOL(Yes, I hate happiness). I was wondering if anybody knew of any previous games that were written in COBOL. My instructor said that some students some time ago made like a tic-tac-toe game. What I'M doing, however, is a rougelike. It's the only feasible game that I think might be easily done in COBOL, plus I get to do graphics. So far I have the map displaying to the screen, and next I'm going to code in a search for the player and a player move. As to why I'm doing this, if you've taken COBOL classes before, you probably understand how boring an hour and a half of it is twice a week. I'm just trying to apply my skills and do something entertaining at the same time.
|
|
#
?
Apr 16, 2009 05:37
|
|
|
That sounds too interactive, you should print to a dot matrix printer after every move.
|
|
#
?
Apr 16, 2009 07:04
|
|
|
The_Frag_Man posted:md3 has some bones for aligning sub models, they are called tags I think. I used md2 for a while, but it has a problem that the vertex coordinates are compressed and the compression is lossy. I recommend MD3.  There isn't really a whole lot of reason to use it, skeletal animation opens up many more possibilities and the only drawback is you can't leech existing content as easily. Well, that and you have to figure out how to make it either not suck up all your CPU, or do the transforms in the vertex shader (do this). OneEightHundred fucked around with this message at 08:24 on Apr 16, 2009 |
|
#
?
Apr 16, 2009 08:19
|
|
|
I have an OpenGL question about vertex buffer objects. All the tutorials are dealing with a single buffer. They may be pulling vertices, normals, and other components from different buffers, but they're using them together. What I'm thinking instead is multiple buffers of vertices, normals, etc. Right now I am trying to draw something from multiple buffers of triangle strips, with matching buffers of normals. When I draw it using vertex arrays, it does render correctly. I suspect I am screwing something up in how I go through the code. I don't have access to the exact code right now, but I can review my thought process here. If it seems correct then I can post the code tonight. I'm writing in C, or rather procedural C++, if that means anything to you. code:Side note: I originally had the buffers interleaved, but tried to factor that out in case it was causing trouble. Again, that worked with vertex arrays, but not the vbos. I assume I'm doing something bad with the OpenGL state machine. Say, maybe I need to unbind someplace either while loading or rendering, but I wouldn't know.
|
|
#
?
Apr 16, 2009 17:19
|
|
|
Scarboy posted:That sounds too interactive, you should print to a dot matrix printer after every move. I toyed with the notion, maybe in an advanced version as a joke. For now in the early stages, display screen only.
|
|
#
?
Apr 16, 2009 17:57
|
|
|
OneEightHundred posted:MD3 also has the problem that verts are stored as shorts and consequently have a hard limit on how large the model can be. There are obvious ways you can deal with this, but it's definitely a design issue to be aware of.
|
|
#
?
Apr 16, 2009 21:43
|
|
|
e: Nevermind, read that wrong, not sure what's wrong with the draw buffers thing. FYI though, you should consider a few optimizations: - Keep all data in the same buffer if at all possible. Changing buffers is expensive, using a different location/stride in the same buffer is cheap. - Use an index buffer and draw using glDrawRangeElements with GL_TRIANGLES as the mode I hope you're not doing exactly this though: code:supster posted:The models will be relatively small and low poly count. This project won't really benefit from skeletal animations so I would really like to avoid implementing it. Are there any suggestions for other formats to use other than MD2 and MD3 that are simply a list of a set of verts for each animation keyframe? MD2 seems to be the best fit for this, no? I am even considering just coming up with our own format that is basically verts stripped from OBJ files of each keyframe appended together in a single file. OneEightHundred fucked around with this message at 06:51 on Apr 17, 2009 |
|
#
?
Apr 17, 2009 06:40
|
|
|
Are there any good website-based tutorials or information about BSP tree implementation? Yes I know about the collision detection book. I plan on buying it. I just need to give a friend of mine a place to start on the subject before I can get the book.
|
|
#
?
Apr 17, 2009 07:07
|
|
|
OneEightHundred posted:FYI though, you should consider a few optimizations: I originally was interleaved but unwound it all while trying to sort out why I was getting garbage. I thought it might have been rendering some of my normals as vertices in particular.
|
|
#
?
Apr 17, 2009 19:41
|
|
|
Contero posted:Are there any good website-based tutorials or information about BSP tree implementation? Yes I know about the collision detection book. I plan on buying it. I just need to give a friend of mine a place to start on the subject before I can get the book. Michael Abrash's Graphics Programming Black Book has a couple chapters dedicated to BSP trees. It's kind of old but may be a decent place to start off with: http://www.gamedev.net/reference/articles/article1698.asp Check out chapters 59-62
|
|
#
?
Apr 18, 2009 07:59
|
|
|
The problem I was having had something to do with the buffer lengths I was specifying to the draw routines, so I got past that. The next thing I wanted to try was a pixel/fragment shader. Is Nvidia's Cg toolkit the accepted standard for developing shaders with OpenGL?
|
|
#
?
Apr 20, 2009 14:00
|
|
|
I've been taking programming classes the past year or so and I've written a couple text based games, but I think I'm ready to move onto the 2D world. Is there a library that's well renowned around here, written in either C++ or Java, that is easy for beginners and has a nice database of tutorials and such? I've googled quite a bit for these and there just seems to be an overwhelming amount. I don't want to waste time learning a library to turns out to be rather crummy. Sorry if this has been asked, but there isn't really any information like this in the OP and I'm not seeing any threads for beginners.
|
|
#
?
Apr 20, 2009 17:11
|
|
|
Bakkon posted:I've been taking programming classes the past year or so and I've written a couple text based games, but I think I'm ready to move onto the 2D world. Is there a library that's well renowned around here, written in either C++ or Java, that is easy for beginners and has a nice database of tutorials and such? I've googled quite a bit for these and there just seems to be an overwhelming amount. I don't want to waste time learning a library to turns out to be rather crummy. I've had a bit of experience with Slick (slick.cokeandcode.com) and while there's a few odd design decisions in there I like that it just handles the game loop / render loop for you and leaves you to game logic. EDIT : To clarify Slick's more a framework and it handles a LOT of behind the scenes stuff. Shavnir fucked around with this message at 17:47 on Apr 20, 2009 |
|
#
?
Apr 20, 2009 17:41
|
|
|
Bakkon posted:I've been taking programming classes the past year or so and I've written a couple text based games, but I think I'm ready to move onto the 2D world. Is there a library that's well renowned around here, written in either C++ or Java, that is easy for beginners and has a nice database of tutorials and such? I've googled quite a bit for these and there just seems to be an overwhelming amount. I don't want to waste time learning a library to turns out to be rather crummy. SDL. It's -very- widely used, it's cross platform, and handles window management, graphics, sound, input, etc.
|
|
#
?
Apr 20, 2009 17:45
|
|
|
SDL is not a game engine or framework, and it seems like Bakkon is looking for one of those, because of his "easy for beginners" requirement.
|
|
#
?
Apr 20, 2009 18:14
|
|
|
Looks like Slick will cover me for Java and SDL for C++. I'll tinker around with them a bit this summer. Thanks guys. When a said "for a beginner," I just meant something that's simple to understand for someone who hasn't programmed outside of the standard provided libraries. SDL seems to have plenty of tutorials, so I think I'll be able to handle it.
|
|
#
?
Apr 20, 2009 18:19
|
|
|
I've recently started looking into programming games with GUIs, and I haven't really thought about it before, but I realize that I have no idea how game GUIs are made. Are each of the components created anew to each engine? How does one make a text box (buttons and the like are easy)? How do you go about making an in-game dialog box that returns a value? (I'm really curious about that one) I'm using XNA right now, and that has some libraries that I might be able to use, but I'm frankly more interested in how they actually work, code wise. VVV Tons of help, thanks! Morpheus fucked around with this message at 15:53 on Apr 21, 2009 |
|
#
?
Apr 20, 2009 18:51
|
|
|
Morpheus posted:I've recently started looking into programming games with GUIs, and I haven't really thought about it before, but I realize that I have no idea how game GUIs are made. Are each of the components created anew to each engine? How does one make a text box (buttons and the like are easy)? How do you go about making an in-game dialog box that returns a value? (I'm really curious about that one) A basic approach: * Make a class that can render a bitmap to your screen, alpha-blended, at certain x,y coordinates and with a set width/height. This is your base class, call it GUIElement. * Make a Text class which inherits from this, and can render a given text string into the bitmap (probably using a library like freetype2 in C++, presumably XNA has some inbuilt stuff for this). * Make a Button class which also inherits from GUIElement, and changes its bitmap based on state (Normal, pressed, etc). * Make a Container object which can contain several GUIElement objects, with a specific layout (at a basic level, each component could have offsets where they should be rendered, from its parent Containers position). * From the above components and a few other basic types, you can build pretty much any type of GUI. A Dialog, for example, would probably have some kind of basic GUIElement object(s) for the background and frame, a Text object that you'll update when the user enters text, and one or more buttons. Your widgets can then receive input events (mouse, keyboard) if they need it (with the GUI handler doing hit tests to see which exact GUI element the cursor is over when a mouse is pressed), and have some sort of callback system to the rest of your code for things like Yes/No dialog boxes and text input (i.e. whatever part of your code creates a specific GUI element can tell it to call local function X with the result). Most basic GUI systems will be a variation of this, I believe .
|
|
#
?
Apr 20, 2009 20:01
|
|
|
Vinterstum posted:stuff about programming GUIs Good stuff, goon sir 
|
|
#
?
Apr 22, 2009 02:17
|
|
Indie Game Dev and
|
Does anyone have any suggested resources for doing 2d collision detection and resolution with bounding circles and (non axis-aligned) rectangles? Right now I plan on using a quadtree for static objects, but am not sure what structure to use for dynamic objects - however this may be few enough that it won't matter (less than 100). I have a pretty good general understanding of how to do efficient simple collision detection (i.e., is a bounding circle/rectangle overlapping with another?), but there are two areas where I am a bit unsure: 1) Consider a player (dynamic circle) moving into a wall (static rectangle) and performing collision detection against it before the move occurs to prevent the move from happening if there would be a collision. What if the player is moving such a large amount (in one frame) that it would be completely jumping over the wall. How do I prevent this? In simple terms, I would need to perform ray casting between the player's current position and the move position to make sure there's nothing in between. How is this done? 2) When the above collision detection occurs and the player is going to be colliding with a wall, I don't want to simply deny the move, I would want to move the player as close to the wall as possible. How is this done? I.e., how do I get the distance between the player's circle and the wall's rectangle given the movement vector? This also seems like it would be solved with ray casting. Keep in mind that this is being done in a relatively simple 2d non-tiled world with not so many objects. edit: I guess what I am describing is more so collision detection between a line and a circle/rectangle than it is ray casting. supster fucked around with this message at 12:07 on Apr 26, 2009 |
|
#
?
Apr 26, 2009 11:57
|
|
|
I am by no means an expert on collision detection, so keep that in mind.supster posted:1) Consider a player (dynamic circle) moving into a wall (static rectangle) and performing collision detection against it before the move occurs to prevent the move from happening if there would be a collision. What if the player is moving such a large amount (in one frame) that it would be completely jumping over the wall. How do I prevent this? In simple terms, I would need to perform ray casting between the player's current position and the move position to make sure there's nothing in between. How is this done? This is usually referred to as "tunneling", and most collision detection approaches simply assume that the time step and object velocities are small enough to prevent it. If you want a 100% guarantee that objects will never tunnel, you need to implement continuous collision detection. I have implemented continuous collision detection with AABBs in a project I'm working on. Extending it to arbitrary polygons isn't that hard, either. Essentially you can reduce testing for the collision of any two moving polygons to testing for the collision of a static polygon and a ray, i.e. between the objects' Minkowski difference and their relative movement vector. The general idea can be gleamed from some 2006 GDC slides on the subject which you can find here. I'm not sure how difficult it would be to support rotation as well, but I can't imagine it would be that bad.
|
|
#
?
Apr 26, 2009 12:33
|
|
|
The simplest thing to do would be to treat the wall/OBB as individual lines. Then you can take the circle's current and projected positions and create a line from them to test against the wall lines.
|
|
#
?
Apr 26, 2009 13:10
|
|
|
I'm looking to play around with an idea similar to that of The Unfinished Swan, in terms of the presentation. I'm not replicating the paint throwing mechanic at all. I suspect all I need is a mapping tool and an FPS engine to use. I could always use the Source engine, but I was wondering if anyone had any alternate suggestions? The game would feature an all-black world, with nothing but black textures and some lighting at some points. It would also have no guns or any other player models on screen. A different engine would also (Potentially) mean if I ever got around to making anything out of it I could distribute it stand-alone rather than as a mod for Source. I guess, however, that the only real reason I'm asking is that there might be something simpler out there than the Source engine/Hammer editor, given that my needs aren't great.
|
|
#
?
Apr 26, 2009 23:22
|
|
|
not a dinosaur posted:I am by no means an expert on collision detection, so keep that in mind. I am now more interested in what data structures to store my static and dynamic data in. For static structures I'm pretty sure I'll be using a quadtree. For dynamic objects (i.e., constantly moving) I am not sure what data structure to use. supster fucked around with this message at 10:07 on Apr 29, 2009 |
|
#
?
Apr 29, 2009 09:45
|
|
|
Until you have a pressing reason to do otherwise (with < 100 objects you do not), just throw them in a linked list.
|
|
#
?
Apr 29, 2009 11:14
|
|
|
supster posted:Thanks for the info. You could use a quad tree for dynamic objects as well or use a kd-tree. The benefits of a kd-tree are fast range-checks and nearest neighbour search on a per-object basis but you need to decide whether you need that or not. Building a kd-tree is more expensive than a quad tree but not so much that it's impractical. Also like not a dinosaur said if you have only a few objects it might be easier to just store them in an array or whatever until the cost of working with unsorted data outweighs the cost of building a more efficient data structure, but that sucks for scalability (obviously) and can lead to refactoring troubles down the road if you code too much around a basic array or linked list.
|
|
#
?
Apr 29, 2009 18:17
|
|
|
The1ManMoshPit posted:You could use a quad tree for dynamic objects as well or use a kd-tree. A quad tree for dynamic data is not so good unless you modify it a fair amount. Any object near the origin will be in the root node, so if you have a lot of action happening near the origin, you won't be seeing much benefit from using a quadtree. You can modify the quadtree implementation to overcome this issue by allowing objects to overlap the boundaries, but that requires you to traverse more nodes when detecting collisions and results in most of the shallow (near root) nodes to be empty, which needlessly increases traversal cost. At that point, you might as well nix the quadtree entirely and use a hierarchical grid instead.
|
|
#
?
Apr 29, 2009 18:53
|
|
|
That's true, but in general it's not horribly inefficient either. Plus if he's already got a quadtree for his static data he can reuse some work for his dynamic stuff with really little effort. Its worst-case performance is going to be close to a flat array anyway so if he's considering quadtree or flat array quadtree isn't a bad choice. A kd-tree or sparse grid of some sort is probably best, I just tend to avoid grids because I find the code for them harder to write, but that's personal preference really. Other people probably feel the same way about trees.
|
|
#
?
Apr 29, 2009 19:09
|
|
|
I was curious if anyone knew of the most efficient way to spawn an arbitrary number of bullets from a specified point in a "fan" type pattern. This image should help illustrate what I mean:  So if I spawn one bullet, it more or less goes straight down, two bullets is split left and right, three has a left, a center, and a right, and so on. It sort of makes me think of drawing a circle out of multiple points, but even that is a bit beyond me.
|
|
#
?
Apr 29, 2009 23:00
|
|
|
Think of it this way: you want to have n bullets' angles spaced evenly over the x-axis. So, assuming it's firing from the origin, one bullet is being fired at -90 degrees, two are at -60 and -120, three are at -45, -90, and -135 degrees...think about how these values are related to one another. or just give it away AD sure that's ok too I guess 
Dijkstracula fucked around with this message at 23:10 on Apr 29, 2009 |
|
#
?
Apr 29, 2009 23:07
|
|
|
Just pick a minimum and maximum angle for the bullet spread and then step through that range and use sin/cos to get the x and y deltas. e.g. θmin = 240° θmax = 300° n = 5 s = 10 m/s Δθ = (θmax - θmin)/n = (300°-240°)/5 = 12° for &theta = θmin to θmax step Δθ v = s ⋅ (cos θ, sin θ) new Bullet(v) Avenging Dentist fucked around with this message at 23:12 on Apr 29, 2009 |
|
#
?
Apr 29, 2009 23:08
|
|
|
Dijkstracula posted:or just give it away AD sure that's ok too I guess Hey gently caress you buddy I wanted to use math symbols in HTML today. 
|
|
#
?
Apr 29, 2009 23:11
|
|
|
Avenging Dentist posted:Hey gently caress you buddy I wanted to use math symbols in HTML today. ...all right, sorry, I'll get back on track
|
|
#
?
Apr 29, 2009 23:14
|
|
|
Avenging Dentist posted:Just pick a minimum and maximum angle for the bullet spread and then step through that range and use sin/cos to get the x and y deltas. e.g. How does this work for one bullet? The bullet wouldn't be pointing at 270° like you'd expect it to from his drawing. Edit: Don't you want to split the semi-circle (or whatever the arc is between min and max degrees) into n regions, and then in each of those regions fire a bullet toward the center of that region's arc? Then it would work for 1 bullet, it just means that the min and max will never actually have a bullet fired at that angle, though it will tend toward them as n increases... POKEMAN SAM fucked around with this message at 23:32 on Apr 29, 2009 |
|
#
?
Apr 29, 2009 23:30
|
|
|
Ugg boots posted:How does this work for one bullet? The bullet wouldn't be pointing at 270° like you'd expect it to from his drawing. It doesn't, that's why I specified n=5. (I assumed he could figure out how to make the n=1 case work on his own because it's not exactly complicated).
|
|
#
?
Apr 29, 2009 23:33
|
|
|
Thanks Dijkstracula and Avenging Dentist. The theory behind it was my stumbling block. I think I have a better idea how I want to handle this now.
|
|
#
?
Apr 30, 2009 00:10
|
|
|
Avenging Dentist posted:A quad tree for dynamic data is not so good unless you modify it a fair amount. Any object near the origin will be in the root node, so if you have a lot of action happening near the origin, you won't be seeing much benefit from using a quadtree. Traversal costs should be pretty drat negligible unless you're doing a freaking lot of traversals every frame. But yes, the "oversized" quad-tree or Sphere-tree is definitely the way to go, even for static objects (you can imagine the same problem occuring with a static object near the origin whose bounds overlap multiple regions).
|
|
#
?
Apr 30, 2009 15:08
|
|
|
Hubis posted:But yes, the "oversized" quad-tree or Sphere-tree is definitely the way to go, even for static objects (you can imagine the same problem occuring with a static object near the origin whose bounds overlap multiple regions). Static objects would probably benefit from a fixed-size grid, where each object is a member of all the grid cells it overlaps. Fixed-size grids are really easy to write, too.
|
|
#
?
Apr 30, 2009 16:26
|
|
|
|
| # ? May 24, 2024 11:54 |
|
|
Avenging Dentist posted:Static objects would probably benefit from a fixed-size grid, where each object is a member of all the grid cells it overlaps. Fixed-size grids are really easy to write, too. That part is true. Unless you're working on a project where you have the "Teapot in a Stadium" problem, don't worry about it.
|
|
#
?
May 1, 2009 01:36
|
|