|
If anyone is planning on using evolver to generate their generic programmer-art characters for stuff, I suggest you hurry up, because Autodesk if following up its aqusition of evolver by closing it down. Because AUTODESK totally isn't evil guys, honestly.
|
# ? Jan 16, 2012 09:09 |
|
|
# ? May 12, 2024 05:40 |
|
Is there any Spriting/Pixel Art thread around in SA? I looked around in Creative Commons but only saw general art threads, which I'm sure might be useful but I'm looking for something more focused on the subject. Alternatively, any starting tutorials/tips/recommended readings?
|
# ? Jan 16, 2012 16:12 |
|
Markovnikov posted:Is there any Spriting/Pixel Art thread around in SA? I looked around in Creative Commons but only saw general art threads, which I'm sure might be useful but I'm looking for something more focused on the subject. Alternatively, any starting tutorials/tips/recommended readings? No, but I'd like there to be one. Try asking Internet Janitor if he'd care to make one in CC, since he's the first that comes to mind.
|
# ? Jan 16, 2012 16:36 |
|
Markovnikov posted:Is there any Spriting/Pixel Art thread around in SA? I looked around in Creative Commons but only saw general art threads, which I'm sure might be useful but I'm looking for something more focused on the subject. Alternatively, any starting tutorials/tips/recommended readings? Oh man, that would be an awesome thread! Please, post a link to it here if it ends up being made.
|
# ? Jan 16, 2012 16:41 |
|
I remembered TIGSource has a forum thread with some Pixel Art tutorial links here, but most of them are dead links (go to the latest page for I hope less dead links) and the thing is disorganized. Still, it might be worth trawling through it. Edit: Also, to the people talking about Forth, I think Evolve 4.0 (an "evolve programmable life" deal) uses something based on it to program the AI of the critters. It has some tutorials for the language it uses also. It might be worth giving it a try to have some fun with something resembling Forth maybe? I started looking at it but the Stack concept and reverse notation blew my mind . (Here is the programming -"KFORTH"- language page specifically) Markovnikov fucked around with this message at 17:08 on Jan 16, 2012 |
# ? Jan 16, 2012 16:48 |
|
duck monster posted:Because AUTODESK totally isn't evil guys, honestly. Oh yeah and for anyone interested in tinkering around with portal visibility, I'm starting to think that you could theoretically retrofit the Quake 3 format to do it, possibly without even modifying the map format, using the existing areaportal functionality. Basically if you plop a common/areaportal brush down, it attempts to change the "area" value of leafs on both sides to be unique. The key is that the portal itself leaves a leaf with CONTENTS_AREAPORTAL and you can find the brush that created it by looking in its brush list for one with CONTENTS_AREAPORTAL. It doesn't store which sides of it are in which area, but hacking that in to the map compiler is trivial, or you can just do point checks. That's basically everything you need to do portal flow in real time. OneEightHundred fucked around with this message at 17:24 on Jan 16, 2012 |
# ? Jan 16, 2012 17:08 |
|
The 3D tools market is best served by fierce competition. Maya and 3DS shouldnt be "complimentary", they should be at war with each other with both trying to be so drat good it nukes the other out of the water. But as it stands. the only real alternative to an autodesk suite for big work, is either Maxon's cinema4d which has poor third party support because its not a well known package and blender which is loving mystifying to use sometimes. God help us all if Autodesk ever manages to aquire something like the UDK or whatever, because it'd handball autodesk way too much industry control.
|
# ? Jan 16, 2012 17:54 |
|
Rupert Buttermilk posted:Oh man, that would be an awesome thread! Please, post a link to it here if it ends up being made. Thirding this, especially since I just got back into doing pixel-art myself.
|
# ? Jan 17, 2012 00:47 |
|
Internet Janitor posted:I really like the graphics, they remind me of Gameboy.
|
# ? Jan 17, 2012 16:01 |
|
2D is a little boring for me and I'd love to dabble in some voxel based terrain stuff ala minecraft world generation. However, I know absolutely 0 about drawing anything in 3 dimensional space or what's required by XNA (I know 2D XNA way too well). I'm looking for some direction, maybe a few tutorials on drawing something in XNA in 3d as well as maybe some guide from going from a cube to a world. I can read all the wiki articles in the world as well as blogs but I just don't know anything about ray tracing or 3 dimensional points. My basic assumption is this: 1. There's a 3 dimensional array of values (at least bool). 2. Fill this array by hand or use some algorithm to do it (perlin noise heightmap is probably what I'm looking at first since it's easiest.) 3. A ray tracer points from somewhere within or outside the cube of values. 4. If a ray hits a surface of a 'true' value, it renders the face of the voxel. 5. Poof you now have some landscape! Am I close on this? If so, should I look at implementing some ray tracer first? Help!
|
# ? Jan 18, 2012 05:58 |
|
Gordon Cole posted:In addition to implementing acceleration as mentioned above, it sounds like you might be tying the movement speed to the frame rate. Rather than moving a fixed number of pixels per frame, you should move in pixels per second, so something like 150.0 * timeSinceLastFrame to get 150 pixels per second. Out of curiosity, is there a way to very stringently enforce a certain framerate and do movement and actions on a per-frame basis without it being jerky? This is basically crucial for some types of games, like fighting games. On the rare occasion that they do get slowed, they can't go about dropping frames because it messes up and possibly randomizes interactions between specific characters and attacks.
|
# ? Jan 18, 2012 08:51 |
|
poemdexter posted:1. There's a 3 dimensional array of values (at least bool). quote:3. A ray tracer points from somewhere within or outside the cube of values. Voxel engines are a cache nightmare. A simple thing like checking neighbouring voxel to see if you should render a face, can cause huge amount of trashing. To make them work in practice you need a combination of techniques to handle the huge amount of data. Some ways are: - Divide it into sections (in Minecraft called "chunks" and I beleive of size 16x16x64) to avoid cache trashing when reading back and forth in a 3D array. Basically you want it small enough that 1) most/all of a chunk can fit in cache to avoid cache misses, 2) reading back-and-forth (checking neighbour voxels for example) does not jump around too much in memory. - Calculate the geometry only when something changes. Save the geometry on the graphics card as some form of array/buffer. You'll want to use non-blocking rendering calls to the graphics hardware, so you can tell it to render a huge amount of stuff and then do something else in the meantime. - Render some objects separately (particles for example) to avoid having to update chunks, you don't want one particle flying around causing huge geometry recalculations. - Be mindful of data structure and render order. Try to put the voxels in memory in the order they are read to avoid jumping back and forth. - You'll want to run your chunks in separate threads, but not so many threads that cache is overflowed. Raytracers are a bad idea for a voxel engine, they can be made to work and even give a performance advantage but you have to be very careful with the design. quote:Am I close on this? If so, should I look at implementing some ray tracer first? Help! Bisse fucked around with this message at 10:41 on Jan 18, 2012 |
# ? Jan 18, 2012 10:32 |
|
poemdexter posted:1. There's a 3 dimensional array of values (at least bool). So far, so good. The rest of the stuff (ray tracing) may not be the best way to go for your first attempt at 3D. Instead, consider using these steps: 3. Divide the world into chunks like Bisse suggested. 4. For each chunk, build two arrays: (1) A vertex array containing information for the corner of each solid part of the chunk. At each corner you store the position of the corner point in 3D space, plus any other optional information like colors, textures, etc. (2) An Index array that contains a list of integers. Each group of three integers are the index values from your vertex array that define one triangle. For example, the index array {0,1,2,0,1,3} defines two triangles - one triangle defined by vertex array points {0,1,2} and a second triangle defined by vertex points {0,1,3}. 5. Put your vertex and index data into XNA's VertexBuffer and IndexBuffer types, respectively. 6. To draw the scene you'll also need a shader, or Effect in XNA language. This is a C-like program that runs on the graphics card and does at least two things (1) The vertex shader takes your vertex data and figures out where each corner point should be drawn on your screen, given the current location of the camera, and (2) a pixel shader that takes each triangle defined by your index data and fills in the center of the triangle by interpolating the values at the corners throughout it's surface. OK, that's maybe not a great explanation but it's a rough outline. For a more detailed walk-thru you might check out Reimer's tutorials, starting with the Terrain example. I don't know if he's updated everything for XNA 4.0 yet, if not the only thing that is likely to have changed will be some of the API calls for defining vertex/index buffer types and you should be able to find the new definitions on MSDN when you get there.
|
# ? Jan 18, 2012 14:55 |
|
poemdexter posted:Am I close on this? If so, should I look at implementing some ray tracer first? Help! Ray casting is one technique for voxel-based rendering. It's not even close to how Minecraft works, though, which is to create polygons representing each exposed face of a block and then render them using a traditional triangle-based(and hardware accelerated) rendering pipeline.
|
# ? Jan 18, 2012 16:51 |
|
aha. Thanks for the input. I'll definitely take a look at Reimer's tutorials since I still have no idea what the basic steps for drawing anything in XNA are. I think that's my first step.
|
# ? Jan 18, 2012 17:49 |
|
Shalinor posted:I'm really looking forward to Global Game Jam at the end of this month. Stuff like Cardboard Combat just seems so straight-up weirdly awesome, but I've never wanted to invest the team's time in it previously. We got a lot of people coming in at Qantm London. There may be some surprise gusts there too. I've heard this rumour that John Romero is going to be at one of the Jams. I'm hoping for everyone to have robofrogs in their games.
|
# ? Jan 18, 2012 18:29 |
|
PalmTreeFun posted:Out of curiosity, is there a way to very stringently enforce a certain framerate and do movement and actions on a per-frame basis without it being jerky? This is basically crucial for some types of games, like fighting games. On the rare occasion that they do get slowed, they can't go about dropping frames because it messes up and possibly randomizes interactions between specific characters and attacks. You can (and should) certainly cap the max framerate of your game, but you can't really go the other way and enforce a minimum framerate. If a particular frame takes too long then your framerate is going to slow down. If I'm understanding you correctly, the situation you're worried about in a fighting game is that the hitbox for an attack would be associated with a particular frame of animation, and the attack wouldn't land if that frame gets skipped due to slowdown. I'm not too familiar with how fighting games are typically implemented, but if you run hitbox collisions for skipped frames it shouldn't matter if a frame gets skipped or not. Basically for those kinds of games where precision is very important you just need to be smart about your implementation. For a platformer or action game you don't really run into those kind of issues that much, at least in my experience.
|
# ? Jan 19, 2012 05:59 |
|
Gordon Cole posted:You can (and should) certainly cap the max framerate of your game, but you can't really go the other way and enforce a minimum framerate. If a particular frame takes too long then your framerate is going to slow down. You're better off running with a fixed timedelta for updates and a variable timedelta for rendering (Lerping between states as needed). It can be a little more complicated to manage, but it gives the best accuracy while still keeping everything smooth.
|
# ? Jan 19, 2012 06:21 |
|
AntiPseudonym posted:You're better off running with a fixed timedelta for updates and a variable timedelta for rendering (Lerping between states as needed). It can be a little more complicated to manage, but it gives the best accuracy while still keeping everything smooth. Yeah, this would work nicely. Would a really low timedelta for game updates (e.g. 30-60 times per second) work, or would that be too hard on the computer/console for what you're doing?
|
# ? Jan 19, 2012 21:17 |
|
PalmTreeFun posted:Yeah, this would work nicely. Would a really low timedelta for game updates (e.g. 30-60 times per second) work, or would that be too hard on the computer/console for what you're doing? Yeah, I'd definitely recommend going with a timestep of 1 / 60, or 1 / 30 for games locked to 30fps. As long as the timestep is constant, the results will be predictable and repeatable, which is what you want. For anyone that's interested about implementing a fixed timestep, there's a good article here: http://gafferongames.com/game-physics/fix-your-timestep/
|
# ? Jan 20, 2012 00:57 |
|
PalmTreeFun posted:Out of curiosity, is there a way to very stringently enforce a certain framerate and do movement and actions on a per-frame basis without it being jerky? This is basically crucial for some types of games, like fighting games. On the rare occasion that they do get slowed, they can't go about dropping frames because it messes up and possibly randomizes interactions between specific characters and attacks.
|
# ? Jan 20, 2012 09:19 |
|
ShinAli posted:I work on MonoGame/MonoXNA (open source XNA implementations) and they both do 2D pretty well. MonoGame is also actually getting DirectX fx files working with it pretty soon and we should get 3D support this year. Content built from Microsoft's XNA tools will work on these as well (trying to work up a pipeline to build the same content data files on the other side as well). You can make a game like Bastion (currently only on my personal branch of MonoXNA) or WizOrb on either project. Thanks, these both sound really promising, only thing is I'm a little frustrated by the lack of documentation for getting up and running, all of which seems to assume pre-existing familiarity with XNA and MonoDevelop. I'm reasonably experienced with Java and AS3/Flex, I know how to look things up in API docs, but I'm new to Mono and C# and I'm not quite sure how to get started with the new environment. I have MonoDevelop running, have MonoTouch installed (which apparently is a prerequisite of MonoGame), and have downloaded MonoGame and MonoXNA from their respective repositories. I don't know quite what to do next, how to link the libraries into into a MonoDevelop project and such. Any suggestions for how I could get up to speed?
|
# ? Jan 20, 2012 23:46 |
|
h_double posted:Thanks, these both sound really promising, only thing is I'm a little frustrated by the lack of documentation for getting up and running, all of which seems to assume pre-existing familiarity with XNA and MonoDevelop. MonoGame for now would just be fine (unless you have a reason to need an implementation of XNA 3.1), and you don't need MonoTouch to use it either. I'll try to write something more detailed, but the process right now is essentially building MonoGame from a solution for your current platform, like MonoGame.Framework.MacOS if you're on a Mac, then adding the built assemblies as references to your project (right click on the little References folder in project view and go to Add Reference, etc). After which you can just follow regular XNA tutorials for almost anything involving 2D games. Only difference right now is that MonoGame does not have a real content pipeline at the moment but you can just use regular png/bmp/jpgs/wav/mp3/etc files with the code for now.
|
# ? Jan 21, 2012 00:04 |
|
So I'm working on something where I need to do Cylinder/Cylinder collision. The only problem that I can find with this is that every place I can something close to algorithm includes a preamble to never try this in an engine as it is slow as gently caress. I'm working in UDK, so this kind of functionality might be built in, but I'll be hosed if I can find it the API. The tech lead is telling me I need cylinders, since currently we are using spheres and they are too imprecise. My programmer sense is telling me I ought to be to do this with modified capsule/capsule collision, but I can't seem to find any good algorithms for implementing that either (ie standard capsule/capsule collison, I think I have an idea for how to modify it). If anyone knows of some good resources, it would be greatly appreciated.
|
# ? Jan 21, 2012 04:05 |
|
crazylakerfan posted:So I'm working on something where I need to do Cylinder/Cylinder collision. The only problem that I can find with this is that every place I can something close to algorithm includes a preamble to never try this in an engine as it is slow as gently caress. I'm working in UDK, so this kind of functionality might be built in, but I'll be hosed if I can find it the API. The tech lead is telling me I need cylinders, since currently we are using spheres and they are too imprecise. i probably can't help you, but are the cylinders axis aligned?
|
# ? Jan 21, 2012 04:12 |
|
mewse posted:i probably can't help you, but are the cylinders axis aligned? I believe it has to work for arbitrarily oriented cylinders. I found a paper on how to do it, but I'm struggling with it. Here it is in the event that someone else is familiar with it. http://www.geometrictools.com/Documentation/IntersectionOfCylinders.pdf Acceptable solutions would also include getting UDK to do it for me, but the API is worse than the OpenGL API. The Glumslinger fucked around with this message at 04:19 on Jan 21, 2012 |
# ? Jan 21, 2012 04:16 |
|
crazylakerfan posted:My programmer sense is telling me I ought to be to do this with modified capsule/capsule collision, but I can't seem to find any good algorithms for implementing that either (ie standard capsule/capsule collison, I think I have an idea for how to modify it). If anyone knows of some good resources, it would be greatly appreciated. The problem then becomes one of finding a good engine-speed distance between two lines algorithm.
|
# ? Jan 21, 2012 04:46 |
|
In Game Physics by Eberly the author advises avoiding cylinders and using capsules instead. Then, because he's a huge math nerd and can't help himself, he goes ahead and derives equations for cylinder collisions anyway. If you have to go that route it might be worth checking out - he gives pseudocode examples that you should be able to translate into whatever language you're using. e: poo poo, I just clicked on the link you posted and it's an article by the same author as the book I linked to. Nevermind then. PDP-1 fucked around with this message at 05:10 on Jan 21, 2012 |
# ? Jan 21, 2012 05:06 |
|
PDP-1 posted:In Game Physics by Eberly the author advises avoiding cylinders and using capsules instead. Then, because he's a huge math nerd and can't help himself, he goes ahead and derives equations for cylinder collisions anyway. If you have to go that route it might be worth checking out - he gives pseudocode examples that you should be able to translate into whatever language you're using. Yeah, the problem with that is since I'm having some trouble understand the working leading up to it, I can't tell whether than first algorithm covers all of the cases, or if I need to then separately run the other tests. Unfortunately, I can't tell which function correlates to which situation.
|
# ? Jan 21, 2012 05:29 |
|
crazylakerfan posted:I believe it has to work for arbitrarily oriented cylinders. I found a paper on how to do it, but I'm struggling with it. I'm pretty sure you could make UDK do it even with perfect cylinders, though, it's just obnoxious. You'd need to create an actor with a cylinder collision volume that exists only to monitor for collisions and report them back to whatever actually cares. If this is an actor that has some cylinder shaped component, that just means that the owner actor creates and destroys the sensor cylinder actor as required. Shalinor fucked around with this message at 05:53 on Jan 21, 2012 |
# ? Jan 21, 2012 05:50 |
|
Shalinor posted:Just use a bunch of sphere checks to approximate a capsule. Or is there some constraint in play that requires this to be two perfect cylinders? The reason why is that we are testing things where the radius>>height for the cylinders. So using a capsule would basically be using a sphere, except it would stick out even further from the surface. We want to able to test for collisions which could occur at almost any orientation, but we want to be able to stack them like || and not have them be considered colliding. These objects will have DrawCylinderComponent on them, so those could be used. But I have pretty much 0 UDK experience, so I wouldn't really know how to use any built in functionality to do it. Basically, we only need to check collisions at set-up and then at certain points during runtime, but it won't be a frequent check. EDIT: And I finally see what I missing in that psuedocode. Gonna try that. EDIT2: ANd the drat thing is missing the last function The Glumslinger fucked around with this message at 08:59 on Jan 21, 2012 |
# ? Jan 21, 2012 06:08 |
|
crazylakerfan posted:EDIT: And I finally see what I missing in that psuedocode. Gonna try that. ... and also post in the UDK thread, because darn it, it'd be nice if it were more active. http://forums.somethingawful.com/showthread.php?threadid=3331710
|
# ? Jan 21, 2012 23:23 |
|
PDP-1 posted:In Game Physics by Eberly the author advises avoiding cylinders and using capsules instead. Then, because he's a huge math nerd and can't help himself, he goes ahead and derives equations for cylinder collisions anyway. If you have to go that route it might be worth checking out - he gives pseudocode examples that you should be able to translate into whatever language you're using. If you understand how that works, can you explain to me an issue I am having with trying to implement it? I've gotten down to SeperatedByCylinderPerpindulars part of it. For the functions F and FDER, the method signature is a rather long set of things. But when it is called in code, they just use F(0), etc. I can't understand what the hell that means. Plus the trouble of me not being to understand what in the hell I am supposed to do for the last part. EDIT: Holy poo poo, I think I have a good enough solution that should cheap and easy as hell to implement. After the first sphere culling, then do bounding box collision. Any thing that gets both is in the cylinder And yes, I know this won't work for the generalized case, but since our r>>h, it is close enough for us. The Glumslinger fucked around with this message at 02:30 on Jan 22, 2012 |
# ? Jan 22, 2012 01:29 |
|
Just curious if anyone has seen a complete tileset suitable for 2D RTS use? I know most everything is done in 3D these days so... I probably won't have any luck, but I thought I would ask.
|
# ? Jan 22, 2012 14:48 |
|
My Rhythmic Crotch posted:Just curious if anyone has seen a complete tileset suitable for 2D RTS use? I know most everything is done in 3D these days so... I probably won't have any luck, but I thought I would ask. Graphics is kind of a bitch I'm afraid. But maybe have a poke around Creative convention, and see if theres a thread for folks looking for commissions. Your always going to get a more original looking app if you avoid using the same frigging zelda clone sprite sheet as the other 50% of apps out there. Goons are pretty cheap considering the amount of college kids on here.
|
# ? Jan 22, 2012 14:58 |
|
My Rhythmic Crotch posted:Just curious if anyone has seen a complete tileset suitable for 2D RTS use? I know most everything is done in 3D these days so... I probably won't have any luck, but I thought I would ask. If you are looking to use it in not commercial stuff, you could try with the results of the TIGSource Asemblee Competition (this is the competition Realms of the Mad God came from), which had two parts: first people made assets for games (graphics and sounds), and in the second part you had to use ONLY the previous assets to make your game. The assets are still around (warning, the page has a LOT of images and gifs) and available under a Creative Commons License, and there are some nice sprite sheets available (as well as some really bad stuff ). Some Highlights: Odball's and Oryx's: Retro fantasy tiles and sprites (monsters, characters, items); also some black only "1 bit" sprites. The best of the bunch really. Turbo's: Isometric Tileset Yokomeshi's: "1 bit" sprites, more Sci Fi oriented. Easyname's: Retro Sprites for characters, Shmup ships and gates (and some weird monsters). Arachne's: Some modern sprites, but mainly a modern tileset of a rocky/cavernous landscape.
|
# ? Jan 22, 2012 16:48 |
|
Markovnikov posted:If you are looking to use it in not commercial stuff, you could try with the results of the TIGSource Asemblee Competition (this is the competition Realms of the Mad God came from), which had two parts: first people made assets for games (graphics and sounds), and in the second part you had to use ONLY the previous assets to make your game. The assets are still around (warning, the page has a LOT of images and gifs) and available under a Creative Commons License, and there are some nice sprite sheets available (as well as some really bad stuff ). This should really be in the OP
|
# ? Jan 22, 2012 16:52 |
|
Markovnikov posted:If you are looking to use it in not commercial stuff, you could try with the results of the TIGSource Asemblee Competition (this is the competition Realms of the Mad God came from), which had two parts: first people made assets for games (graphics and sounds), and in the second part you had to use ONLY the previous assets to make your game. The assets are still around (warning, the page has a LOT of images and gifs) and available under a Creative Commons License, and there are some nice sprite sheets available (as well as some really bad stuff ). Even though I don't plan on selling this game, I have thought about hiring someone to do a tileset or two, and I guess unit artwork, simply because I'll get completely bogged down if I have to do the artwork. I guess I should keep developing the game and see if it warrants spending anything on "real" artwork. Or who knows, I could open source it and let other people do the graphics.
|
# ? Jan 22, 2012 17:16 |
|
My Rhythmic Crotch posted:Just curious if anyone has seen a complete tileset suitable for 2D RTS use? I know most everything is done in 3D these days so... I probably won't have any luck, but I thought I would ask. http://lunar.lostgarden.com/game_HardVacuum.htm
|
# ? Jan 22, 2012 17:16 |
|
|
# ? May 12, 2024 05:40 |
|
I am probably overcomplicating what I'm about to discuss. I've been thinking about ways to describe movement on a grid. Say you have two objects that can move orthogonally or diagonally on a grid. If one object moves toward another (assuming no obstacles), there can be up to three "sensible" directions it might move in to get closer. For smooth movement, it would be nice if our object moved in something approximating a straight line to the target rather than taking an unnatural-looking manhattan path. Can we do this without storing any persistent state, such as a precomputed path? If we represent the 8 directions we might move in as colors we could graph the "ideal" direction to move in as something like this: It's easy to determine these directions by finding the angle between the objects using atan2() and scaling/rotating the result. However, trig can be expensive. There are several other possible approaches. Favor diagonal movement: code:
Favor orthogonal movement: code:
Or we could choose between those approaches based on the distance from the target: Thoughts?
|
# ? Jan 22, 2012 18:00 |