|
Shalinor posted:... and in the process, destroy the video card's cache. That's not going to matter, and Z-buffer clears are pretty darn cheap/free. You'll invalidate the coarse Z-buffer cache, but that doesn't cost you anything because you're not going to gain anything from it anyways (since the cockpit is in front of everything in the world). The biggest possible cost you might have is that the pipeline would have to drain if you clearing and then re-binding the main depth buffer, because you'd have to wait for the clear to finish before submitting new rendering work. You can get around that by just creating a second depth target and using that for cockpit rendering, though. Honestly, worrying about this is all seriously pre-mature optimization. If it's something that lets you avoid depth artifacts, go for it. Hubis fucked around with this message at 21:53 on Oct 17, 2011 |
#
?
Oct 17, 2011 19:31
|
|
|
|
| # ? Jun 9, 2024 17:49 |
|
|
Yeah, fair enough. Cards have gotten better, my optimization instincts are still somewhat stuck back in the SM2.0/3.0 age.
|
|
#
?
Oct 17, 2011 20:42
|
|
|
BizarroAzrael posted:Does anyone know how to export from Autoidest Softimage XSI Mod Tool or whatever I'm supposed to call it/google into .fbx? I want to get stuff out of it into UDK but I'm having a hard time finding guides on how to do it. Most of what I find seems outdated. http://usa.autodesk.com/adsk/servlet/item?siteID=123112&id=13525184&linkID=12544121 The ActorX plug-in (which is under /Binaries/ActorX/ in your UDK install) reportedly works as well and exports Unreal PSK/PSA files. Also god drat, they bought XSI? Are there any 3D packages left that they don't own? e: They doubled the price too, gently caress Autodesk forever. OneEightHundred fucked around with this message at 18:27 on Oct 18, 2011 |
|
#
?
Oct 18, 2011 17:08
|
|
|
Vino posted:And as for memory, as it stands it doesn't really take all that much. The plan is that the game deterministically generates random terrain that it can re-generate again each time. If the player leaves an object there then that must be remembered, but the terrain itself would just be re-generated on the fly. So the entire universe could be explored without having to fit the entire universe in memory. I would suggest you don't get too stuck on the infinite concept and instead try to focus on fun gameplay elements. If you consider a game like Diablo or Minecraft you can say that it has near-infinite content since major elements of the game are randomly generated. Yet people will still get bored and stop playing even though there exists 'more content'. The problem is, not all content is created equal. Content created procedurally will generally be less interesting than hand crafted content. And it doesn't matter whether your content spans a village or a galaxy if it's not very interesting. If you check out the games that already exist similar to what you're building you'll notice that it's neat to play with but there really is no game. And in these games you'll quickly reach a point where the procedurally generated content all starts to look similar because there is an unavoidable limit to the amount of content. http://www.youtube.com/watch?v=v6shurn2W0w http://www.youtube.com/watch?v=68YK2FHkFjw
|
|
#
?
Oct 18, 2011 21:32
|
|
|
Xel: This brings up an interesting point that I've been thinking about for a while. I think the key which separates procedurally generated content as we generally think of it and handcrafted content is narrative. Dwarf Fortress probably has one of the richest procedurally generated worlds of any game today. The world generator simulates the passage of time as water erodes and shapes land. Biomes arise as a result of environmental parameters like humidity and temperature, rather than the other way around. In general, the world has both history and internal consistency. I think if we want to produce compelling content this way we should think in terms of creating agents which explore and interact with procedurally generated environments during a "weathering" phase. By leaving behind evidence of intelligent behaviors and previous exploration- everything from footprints and bloodstains to buildings and ruins- we leave stories for explorers to find and piece together.
|
|
#
?
Oct 18, 2011 22:45
|
|
|
But even with Dwarf Fortress, the procedural part is still just a vehicle for the actual gameplay. If you didn't have the ability to control dwarfs then you would get bored exploring the procedural content very quickly. And that's with a very well crafted algorithm for generating the world. So I think procedural algorithms often as seen as a way to avoid hand crafting content, but you're actually just creating a higher quantity of less interesting content. I mentioned Diablo because it has a good mix of procedural and hand crafted content and good gameplay. Yet even with its 'infinite world' it's very easy to get bored of it quickly. Anyway, if you want to make a fun game, focus on figuring out what that fun gameplay is. Procedural content is fun programmer masturbation but rarely makes a great game by itself.
|
|
#
?
Oct 18, 2011 23:01
|
|
|
Xel posted:Anyway, if you want to make a fun game, focus on figuring out what that fun gameplay is. Procedural content is fun programmer masturbation but rarely makes a great game by itself. Early example: Arena / Daggerfall. Take some limited designer input, spin it out into a ton of randomized quests. That taken further, or thinking in terms of AI antagonists that are out there also playing with the simulated world to some devious end, could eventually generate some pretty compelling content. ... but yes, it all still does boil back down to the gameplay systems. NetHack works because the systems themselves are solid, and random enemies thrown at you with some interesting framing makes you really use all your available options. Diablo is fun because they're really polished the "cave skull in -> take shiny and put it in your pocket" cycle. Even with an AI antagonist, it would be less about their AI, and more about the systems that both you and the AI were exploiting to cause things to happen.
|
|
#
?
Oct 19, 2011 00:01
|
|
|
OneEightHundred posted:Install Crosswalk There's Blender, which I might switch to since can make money with off using it without paying for a licence as I would need to with XSI.
|
|
#
?
Oct 19, 2011 00:25
|
|
|
Xel posted:I would suggest you don't get too stuck on the infinite concept and instead try to focus on fun gameplay elements. Wondering why nobody suggested this earlier, but I suppose it is a programming thread after all. This is the essential reason I stopped working on it - taking too long to get to the fun gameplay elements. If I could do something like steal the Space Engine and just get to work on gameplay stuff then I would. I'd rather get to work on something else that I can actually start prototyping gameplay.
|
|
#
?
Oct 19, 2011 18:51
|
|
|
I have no idea where to ask this, so I have chosen YOU, Game Development Megathread! Are there any pygame/Python experts out there? I'm trying to get this Python version of Pac-Man running on my machine (http://pinproject.com/pacman/pacman.htm) and it seems to be impossible. I'm running OSX v. 10.7.1. I followed the tutorial to set it up on Lion. I installed the SDL frameworks. I installed a shitload of other libraries...yet it still refuses to launch. Any help would be greatly appreciated, thanks!
|
|
#
?
Oct 21, 2011 04:08
|
|
|
I'm no python/pygame expert but I've used both for a couple of projects. If you could post whatever error is giving you it would help. I don't think you need to install SDL if you are using pygame (though it shouldn't be a problem either), maybe you are using a wrong python or pygame version?
|
|
#
?
Oct 21, 2011 12:44
|
|
|
Is there a 2D physics engine that implements 'snapshots' or any other method of rewinding time? I'm currently integrating Box2D, but I'm not sure if turning off warm starting, and putting all the mobile object locations and velocities (including angular) into a snapshot is enough to make the physics play out identically a second time, or even identically across two Windows machines given the same starting conditions. Mostly what I see in Box2D forums about doing this is "make sure you snapshot a lot of things, not sure what!" or "don't do it that way at all, do client-server and interpolation to hide the bad physics." I don't want to do it that way, I'm pretty set on my "everyone is the server for their own controlled objects" model, which either means rewinding when you get an update about someone else's controls, or horrible delayed controls, or sending a hell of a lot more data across the network and further complicating the general running of things. Also fun: trying to implement a clean world-wraparound (so an object can be half on one side and half on the other, and collisions continue to work properly during wraparound) in a physics engine that doesn't have any support for it. Current best guess as to how to do it most easily; attaching a second identical body to each moving body, held exactly one world-width away (by pinning them both to an invisible body with a revolute joint) with their angles locked together (using a gear joint, in Box2D), teleporting them both to the right if the clone is fully on screen, and both to the left if the main body touches the right side of the screen.
|
|
#
?
Oct 25, 2011 06:09
|
|
|
roomforthetuna posted:Is there a 2D physics engine that implements 'snapshots' or any other method of rewinding time? I'm currently integrating Box2D, but I'm not sure if turning off warm starting, and putting all the mobile object locations and velocities (including angular) into a snapshot is enough to make the physics play out identically a second time, or even identically across two Windows machines given the same starting conditions. (most physics sims are lossy for a reason, they use approximations that let the sim run much faster)
|
|
#
?
Oct 25, 2011 15:53
|
|
|
roomforthetuna posted:Mostly what I see in Box2D forums about doing this is "make sure you snapshot a lot of things, not sure what!" or "don't do it that way at all, do client-server and interpolation to hide the bad physics." I don't want to do it that way, I'm pretty set on my "everyone is the server for their own controlled objects" model, which either means rewinding when you get an update about someone else's controls, or horrible delayed controls, or sending a hell of a lot more data across the network and further complicating the general running of things. Asynchronous updates are pretty much impossible in a peer-to-peer setup, so what you're probably better off with is a buffered simulation. What this means is that two simulations run: One is the predictive simulation which runs immediately and is visible, one is the authoritative simulation which runs later. If misprediction occurs, there are several things you can do. You can reset the prediction to the authoritative simulation and replay it, which is more accurate but slower, or you can do simpler correction like storing old predicted states, comparing them to the authoritative states they were guessing at, and apply the position/rotation(/velocity) differences to the current simulation and all other recorded snapshots. This is faster, but can result in things winding up in floors or walls for a bit. One nice thing about doing things this way is that you don't have to worry about accurately restoring physics state: The prediction state can get pretty sloppy and it will gradually get corrected. The downside is that it necessarily lags all actual interactions. Shalinor posted:You're not looking for snapshots, you're looking for determinism - a whole other kettle of fish. I want to say Newton has a deterministic mode, if you turn it on, but realize that your game will be massively slower if you enable such. The approach I've outlined does cold-start and use consistent inputs though, so it's reasonably likely to work. OneEightHundred fucked around with this message at 16:21 on Oct 25, 2011 |
|
#
?
Oct 25, 2011 16:11
|
|
|
Took me a minute to figure out what the practical difference was between my snapshot method and OneEightHundred's authoritative/predictive method - eventually realized that the difference is, if the copy doesn't properly convey all the information, it doesn't have long-term consequences in OneEightHundred's model. But it does still require the ability to approximately duplicate a complete world state from one model to the other, right? That's probably a better idea, and similar enough that I can switch over from what I was doing almost effortlessly. Added advantage of only needing to copy states in one direction rather than both saving and restoring states, though disadvantage of simulating twice even when there's no input. My system already has an "everyone is in sync and all commands are in up to time t" value, so that gives me a handy threshold that I can run the authoritative system [almost] to. Plus, this way I don't need to disable warm starting, because the slightly inaccurate copy doesn't really matter. In the authoritative model, all systems will have objects created in the same order, same size time steps, etc. so hopefully those should be able to remain in sync on different machines.
|
|
#
?
Oct 25, 2011 18:29
|
|
|
roomforthetuna posted:But it does still require the ability to approximately duplicate a complete world state from one model to the other, right?
|
|
#
?
Oct 25, 2011 18:43
|
|
|
Does anybody here have a recommendation of existing examples or a middleware project that implements A* in C++? To be honest I'm lazy and would rather work from pre-existing code than craft something from scratch, especially since it seems to be common enough now. I see a lot of stuff online and might just start banging away, but I'd love to hear from anybody that has tried any stuff already.
|
|
#
?
Oct 25, 2011 21:08
|
|
|
This guy posts his source code (C++) at the bottom of the page, dunno if that helps you or not. http://www.policyalmanac.org/games/aStarTutorial.htm
|
|
#
?
Oct 25, 2011 21:09
|
|
|
roomforthetuna posted:Took me a minute to figure out what the practical difference was between my snapshot method and OneEightHundred's authoritative/predictive method - eventually realized that the difference is, if the copy doesn't properly convey all the information, it doesn't have long-term consequences in OneEightHundred's model. But it does still require the ability to approximately duplicate a complete world state from one model to the other, right? I would highly suggest you watch this GDC video explaining Halo's networking system (regardless of whether you like Halo or not, their tech is great). It's a great overview of how to handle the exact problem you are describing. http://www.gdcvault.com/play/1014345/I-Shot-You-First-Networking
|
|
#
?
Oct 25, 2011 21:17
|
|
|
So I've been intrigued by component-based programming for a while, and I recently decided to create a simple 2D component-based game engine for a project I'm working on. Things are going pretty well so far, but I've come across a few situations where I'm stumped about how to structure the code properly. I have a pretty typical set up. At any given point the game is in a particular state which manages a list of entities, each of which manages a list of components. Each component has standard update and render methods. Currently, when a component needs to communicate with a sibling component, I have it grab the component from the parent entity by its type. So the shape component can look at the parent's bounds component to figure out where to draw itself. This has worked really well so far for implementing a basic player character entity. But it's not working so well for implementing, say, a HUD. A basic health meter could be composed of a few shape components to render the empty and filled parts of the meter, with a new meter component to coordinate them. But because components reference their sibling components by type, having multiple shape components doesn't work. The meter component has no way of asking for just the empty or filled shape components, just the shape component. I've come up with some potential solutions that aren't very good. Instead of the parent entity having some shape components, the meter component could just draw the meter itself. This sucks because it reuses a bunch of the shape drawing code from the shape component. Plus, we start to lose most of the value of a component-based system when our entities are comprised of a single monolithic component. The meter component could also just create and manage its own shape components itself in order to maintain reuse of the shape drawing code. This runs into the same monolithic component issue as above, and components aren't really designed to manage other components anyways. This will start to get messy very quickly. We could reference components by a custom name rather than by their type -- the meter entity could have an "empty shape component" and a "filled shape component". This will work fine in this particular case I guess, but what about the case where I want to have an arbitrary number of shape components attached to some entity? tl;dr: How does an entity in a component-based engine manage multiple components of the same type? Any advice on how to handle this situation would be hella appreciated.
|
|
#
?
Oct 25, 2011 22:19
|
|
|
Xel posted:I would highly suggest you watch this GDC video explaining Halo's networking system (regardless of whether you like Halo or not, their tech is great). It's a great overview of how to handle the exact problem you are describing. Always buffer input in peer-to-peer, the only way to have the game not stall in peer-to-peer is to have a buffer period exceeding the highest game-wide ping. If two people have 250ms to each other, and you're not buffering, your game runs at 4 FPS.
|
|
#
?
Oct 25, 2011 23:09
|
|
|
Gordon Cole posted:tl;dr: How does an entity in a component-based engine manage multiple components of the same type? I posted a response to a similar question a few pages ago. Basically this is the exact problem that you generally face with entity/component architectures and it's why some people advocate an entity/component/system architecture instead. Long story short, components only store data and instead systems contain all the logic that use the components. This article does a decent job going into more detail on the idea. http://piemaster.net/2011/07/entity-component-primer/ http://piemaster.net/2011/07/entity-component-artemis/
|
|
#
?
Oct 26, 2011 01:06
|
|
|
Xel posted:I posted a response to a similar question a few pages ago. Basically this is the exact problem that you generally face with entity/component architectures and it's why some people advocate an entity/component/system architecture instead. Hmm, maybe I'm being dense, but I'm not sure how this will solve my particular problem. It seems like I'd still run into issues with an entity having multiple components of the same type. It's a pretty cool system though, I really like how it iterates through components by type rather than by entity. Actually though I could see that causing issues with the execution order if you have, say, system A and system B and on one entity you want A to run before B, and on another you want B to run before A.
|
|
#
?
Oct 26, 2011 03:47
|
|
|
Gordon Cole posted:Hmm, maybe I'm being dense, but I'm not sure how this will solve my particular problem. It seems like I'd still run into issues with an entity having multiple components of the same type. It's a pretty cool system though, I really like how it iterates through components by type rather than by entity.
|
|
#
?
Oct 26, 2011 04:20
|
|
|
Gordon Cole posted:Hmm, maybe I'm being dense, but I'm not sure how this will solve my particular problem. It seems like I'd still run into issues with an entity having multiple components of the same type. It's a pretty cool system though, I really like how it iterates through components by type rather than by entity. Sorry, I kind of missed the point. To solve that problem you could create the shape components on separate entities and store the references to those entities on the meter component. That shouldn't really be a problem since the cost of creating a new entity should be similar to creating a new component anyway. The other option is to draw all of the shapes for the meter solely from that component. But you have a much better ability to do that and still reuse code when you use the systems architecture from those articles. If you move the code for drawing shapes out of the shape class and into the render system class, suddenly it's much simpler to use that same code for drawing the meter.
|
|
#
?
Oct 26, 2011 05:21
|
|
|
Thanks for all the ideas. There's a couple that I'm considering going with now. Storing the shape components on entities inside the meter component kind of makes sense now that I think about it. The only problem I have with it is that the component will need to explicitly call the sub-entities' update and render methods, which is pretty cumbersome, especially when there are pre- and post-update/render methods as well. Maybe I'll give components a list of sub-entities they can add to that will update and render automatically. My other option is to just store a list of components of each type like roomforthetuna mentioned. I'm thinking of actually creating two new container components -- a list component and a map component that could handle that functionality. Thanks again for the help. I figured I may have been overlooking an obvious solution but it seems the situation is as complicated as I thought.
|
|
#
?
Oct 26, 2011 09:54
|
|
|
I think I'm using a different communication structure than you, which probably will just make things more confusing. But I'll try anyways. I'm using a message bus for my entities, where components register messages that they're planning to send, and there are subscribers to them as well. Other entities can subscribe to the messages. A big one would a GUI entity for a health bar signing up for health change events in another entity. I guess that's along the lines of the kind of thing you needed. I don't think in my own stuff I have a good solution for having multiples of the same component in my design. It will not accept the second one. By chance, if the copies of the component really are doing distinct things, then perhaps you have two different components after all.
|
|
#
?
Oct 26, 2011 13:53
|
|
|
HolaMundo posted:I'm no python/pygame expert but I've used both for a couple of projects. If you could post whatever error is giving you it would help. That's the greatest part! The error just says, "pygame error". That's literally it. In running that PacMan port, it dies at line 43: code:
|
|
#
?
Oct 26, 2011 18:57
|
|
|
No error? Gah, that sucks. Never had that happen. If the path is correct then hmmm, I dunno, I'd probably try erasing the call to convert() and see if it works. Convert() is a function which changes the pixel format for the surface. http://pygame.org/docs/ref/surface.html#Surface.convert
|
|
#
?
Oct 26, 2011 19:03
|
|
|
Rocko Bonaparte posted:I think I'm using a different communication structure than you, which probably will just make things more confusing. But I'll try anyways. I'm using a message bus for my entities, where components register messages that they're planning to send, and there are subscribers to them as well. Other entities can subscribe to the messages. A big one would a GUI entity for a health bar signing up for health change events in another entity. I guess that's along the lines of the kind of thing you needed. Well I don't really have any problems with passing messages. I can get the meter to respond to changes in its value pretty easily, my problem was with organizing its supporting components.
|
|
#
?
Oct 26, 2011 19:23
|
|
|
Gordon Cole posted:Thanks for all the ideas. There's a couple that I'm considering going with now. You could make a component called "My Magic Multi Render Component", rather than adding it to the base class, and that component would know how to deal with rendering multiple nested entities, and it would manage it itself. That way your common base object class would remain simple, unless it had a magic multi-render component.
|
|
#
?
Oct 26, 2011 20:23
|
|
|
Prologue: Using obscure 2d lib Gorgon to make a 2d spacemans game. I'm writing some code (c# + Gorgon, hlsl) right now that will draw a 2d sprite with an arbitrary number of decals applied. The decals are all in a texture atlas. As far as I can figure, to get the right decal colors overlaid on top of the base sprite, I'll have to feed the decal atlas texture in to a texture2d in my shader, then pass in each decal's offset coordinates against the base sprite, the decal's offset within the atlas, the size of the atlas, and the size of the decal, and then calculate the texcoord to pass to the sampler to get the right decal pixel to draw over the base sprite. This seems like there must be a better way. Does anyone know that better way?
|
|
#
?
Oct 26, 2011 20:41
|
|
|
edvincent posted:This seems like there must be a better way. Does anyone know that better way? You'd still need to do all the calculations you suggest, but most of them just once, and the remainder once per render. You don't want to be doing any calculations like that inside the shader.
|
|
#
?
Oct 26, 2011 20:54
|
|
|
Unormal posted:You could make a component called "My Magic Multi Render Component", rather than adding it to the base class, and that component would know how to deal with rendering multiple nested entities, and it would manage it itself. That way your common base object class would remain simple, unless it had a magic multi-render component. Yeah, that's more or less what I was thinking of with the list and map components. A list component would let you automatically manage an arbitrary number of components of a given type, and a map component would let you have multiple distinct, named components of a given type.
|
|
#
?
Oct 26, 2011 22:14
|
|
|
HolaMundo posted:No error? Gah, that sucks. Never had that happen. code:
|
|
#
?
Oct 27, 2011 02:09
|
|
|
Maybe the game uses a different python/pygame version that the one you are using? I'm really clueless, heh.
|
|
#
?
Oct 27, 2011 12:24
|
|
|
HolaMundo posted:Maybe the game uses a different python/pygame version that the one you are using? It's cool, thank you for trying, at least 
|
|
#
?
Oct 29, 2011 12:51
|
|
|
Anyone have a suggestion on the best (or at least a really great) book on Unity3D? I know there are countless tutorials online, including the very-excellent TornadoTwins, and I use them, but I definitely prefer having a book as well. I tend to read and learn stuff even away from the computer and actually enjoy doing it that way. There seem to be two main choices out there for Unity books (without looking, one is written by some guy named Ryan, who actually spoke at a college my gf attended a couple years ago, and the other is by a guy named Will). EDIT: Just looked again (it's been a while since I searched for Unity books) and there seem to be quite a few more in the running. Rupert Buttermilk fucked around with this message at 18:51 on Oct 29, 2011 |
|
#
?
Oct 29, 2011 18:43
|
|
|
The kind of bugs specific to game programming I think have to be the coolest and funniest bugs of any kind of programming. I was testing out my attack box applying damage to enemies last night, when I'd find both the enemy and the player dying. I found out that the player's bounding sphere was touching the box too, so it was getting hit by itself too. So the player was killing itself with the attack.
|
|
#
?
Oct 31, 2011 18:52
|
|
|
|
| # ? Jun 9, 2024 17:49 |
|
|
One of the games made for the SA Gamedev challenge this past August had a fantastic glitch the author turned into a gif, which I think sums up hilarious glitches perfectly:
|
|
#
?
Oct 31, 2011 23:57
|
|
