Game Development Megathread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »

Benji the Blade: Jun 22, 2004; Plate of shrimp.

Way back towards the beginning of all this multiprocessing discussion this came out,

ehnus posted:

Or if you really plan on going with a massively multithreaded system try a language/environment that's better suited for it, like... Stackless Python....

And I wanted to point out that it's a common misconception that Stackless Python in any way helps parallelism of processing. It doesn't. By not running threadlets concurrently, you can avoid all synchronization issues and with a little more work, you can even avoid deadlocks.

So what's the point? Well, initially the idea was to add continuations to Python, although what's actually in Stackless turned out to be rather limited form of them, from my understanding. From what I can tell, the draw is that Stackless allows you to write code that calls into asynchronous functions in a manner that looks looks synchronous.

As far as multiprocessing goes, the "Stackless" features of Stackless Python are pretty much orthogonal.

# ? Sep 15, 2008 18:35

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 17:16

Mustach: Mar 2, 2003; In this long line, there's been some real strange genes. You've got 'em all, with some extras thrown in.

tyrelhill posted:

Anyone know about a leak detector for COM objects, specifically DirectX objects in C/C++?

Anyone? I cant find anything!

I'm pretty sure that running a DirectX program in debug mode in Visual Studio will give some info in the Output pane. From what I remember it's something simple like a count of leaked resources, but maybe there're ways to get more info. I can't confirm anything, though, because I don't have the SDK installed.

# ? Sep 15, 2008 23:22

Avenging Dentist: Oct 1, 2005; oh my god is that a circular saw that does not go in my mouth aaaaagh

ATL lets you keep track of reference counts in the output window:

http://msdn.microsoft.com/en-us/library/6x61t5y4(VS.80).aspx

# ? Sep 15, 2008 23:27

Scaevolus: Apr 16, 2007

Kimani posted:

Now before I go too far, while I do intend to use this game environment for future projects ( wouldn't want to waste the effort... ) for this program I sort of fudged the collision detection because it needed more work and it was fudgable - and I wanted to finish the drat thing.

The simplest way to do it is just lock the whole scene graph, do your collision test, and get out. But there's multiple things wrong with that. If all you're doing is testing, and not moving things around within the scene graph, then you don't need to impede other threads from doing testing at the same time. So you don't need to lock. But if you are moving things around in the scene graph, you do need to lock so that you don't get 'bad things'.

However, if you're moving things around in area A, there's no reason to deny another thread to do testing in area B. So rather than lock the whole scene graph, you only lock a portion.

What you're describing is a classical problem in concurrent programming, called "readers-writers". You should read The Little Book of Semaphores. It's on page 71.

Scaevolus fucked around with this message at 01:09 on Sep 16, 2008

# ? Sep 16, 2008 01:07

Kimani: Dec 20, 2003; Anime avatar - check
ADTRW poster - check
Defends watching child porn - CHECK!!!

Alright, I slept on the jist of the suggestions here. While I want to keep AIDemo2 the way it is ( because massive parallelism is it's gimmick and I'm sticking to it ) I'll modify the environment for the next project so that it uses a finite amount of worker threads. Shouldn't be too hard to modify, it's just a matter of telling the entity to stick itself into a worker thread instead of spawning a thread.

akadajet posted:

Bad idea or not, I'm just impressed that you went all the way through with it.

In the face of massive, yet just criticism, thanks

Scaevolus posted:

What you're describing is a classical problem in concurrent programming, called "readers-writers". You should read The Little Book of Semaphores. It's on page 71.

Ah cool, thanks. I've read some of it before but not all.

# ? Sep 16, 2008 06:48

Luminous: May 19, 2004; ~~Girls~~
Games
~~Gains~~

I think this is cool for the sheer novelty of it, proper or not. Lots of things that are improper can still be interesting and fun.

I haven't tried your demo thing (work computer), but you mention 299 threads and only 18 entities active. You also mention you want this to be used in other projects, presumably more robust and complex (although it sounds like you do plan on changing it to finite anyway).

But, if you are looking to the future, you really need to look to the future. Plenty of games are going to have many more than 18 active entities, for instance. Think about the games you envisioned might use this, and then think about current games of a similar sort, and then simply guess at how much is and is not active at any given time, and then think about if what you have would actually scale well to that in light of some of the information here (synchro, etc).

# ? Sep 16, 2008 18:53

Seat Safety Switch: May 27, 2008; MY RELIGION IS THE SMALL BLOCK V8 AND COMMANDMENTS ONE THROUGH TEN ARE NEVER LIFT.; Pillbug

Mustach posted:

I'm pretty sure that running a DirectX program in debug mode in Visual Studio will give some info in the Output pane. From what I remember it's something simple like a count of leaked resources, but maybe there're ways to get more info. I can't confirm anything, though, because I don't have the SDK installed.

Run PIX along with DirectX in debug mode; if you take frame captures PIX can track the allocations over time. Then you can step through call by call and see where the memory is first allocated.

I have no idea if PIX works for DX10.

# ? Sep 17, 2008 21:45

Morpheus: Apr 18, 2008; My favourite little monsters

Hello folks I would like to ask a question about code design for a somewhat simple 2D platformer. I'm pretty sure how I'm going to go about doing all the design, but the biggest thing I'm not sure about is the most important: collision detection. This ties into the very core of the code, so it's kind of important to decide before I start, as this is my first 2D platformer.

I would imagine something to do with a tile-based world, where one tile could be 'terrain' and I'd check against the tiles around my character to see if he's colliding with any of them. I feel like this really limits level design to a NES-era platformer, with bricks and blocks and no curves. Is there a better, more expandable approach available?

# ? Sep 18, 2008 09:31

TSDK: Nov 24, 2003; I got a wooden uploading this one

Morpheus posted:

Hello folks I would like to ask a question about code design for a somewhat simple 2D platformer. I'm pretty sure how I'm going to go about doing all the design, but the biggest thing I'm not sure about is the most important: collision detection. This ties into the very core of the code, so it's kind of important to decide before I start, as this is my first 2D platformer.

I would imagine something to do with a tile-based world, where one tile could be 'terrain' and I'd check against the tiles around my character to see if he's colliding with any of them. I feel like this really limits level design to a NES-era platformer, with bricks and blocks and no curves. Is there a better, more expandable approach available?

Check out the replies given to a similar question earlier in the thread.

# ? Sep 18, 2008 10:19

Morpheus: Apr 18, 2008; My favourite little monsters

TSDK posted:

Check out the replies given to a similar question earlier in the thread.

Argh, he asks the exact same question, too. I'm some kind of retarded. Thanks. I think the XNA has sprite-to-sprite collision checking, and since the platformer I'm making is fairly simple, I doubt I'll need anything more complicated than that. Implement a few quad-trees for not-retarded running times, and I think that's all I need.

Morpheus fucked around with this message at 02:41 on Sep 19, 2008

# ? Sep 19, 2008 02:33

guenter: Dec 24, 2003; All I want out of life is to be a monkey of moderate intelligence who wears a suit. That's why I've decided to transfer to business school!

Anyone used the DirectX effects framework? Or rather, anyone with experience with shaders at all because this doesn't really have anything to do with the framework. I'm kind of curious how people deal with effect parameters that change every frame.

I'm making a simple effect for rendering particles and I need a "Life" parameter so I can fade particles from a start to end color.

Right now in my rendering code I have some hacky stuff that checks if the effect uses an Age parameter and then assumes the entity is a Particle and goes on to set it.

code:

void Renderable::Render(boost::shared_ptr<Entity> camera, boost::shared_ptr<Device> device)
{
    effect_->Parameter("World", Owner()->FindComponent<WorldTransform>()->Matrix());
    effect_->Parameter("View", camera->FindComponent<ViewTransform>()->Matrix());
    effect_->Parameter("Projection", camera->FindComponent<ProjectionTransform>()->Matrix());

    if(effect_->GetParameterByName(NULL, "Age"))
    {
        effect_->Parameter("Age", Owner()->FindComponent<Lifetime>()->Age());
    }

    // ...
}

Excuse the FindComponent stuff. All my entities use composition instead of inheritance.

Ideally there'd be some way I could bind the data to the effect parameter when I created the effect so I didn't have to worry about setting it explicitly. I'm not sure how I would actually go about doing that though. The SAS stuff looked promising but turned out to be not what I was looking for.

If that's not how people do it, then I guess this is more of a software design question. When/where do you set the effect parameters and who is responsible for it?

guenter fucked around with this message at 01:17 on Sep 20, 2008

# ? Sep 19, 2008 03:17

Sylink: Apr 17, 2004

Is XNA easy to understand for a novice who wants to try out 2D game programming? I want to make a sort of autonomous animation program and a game library would be the best choice. All i want to do is animate sprites for the most part, I dont need crazy 3d or anything.

# ? Sep 19, 2008 04:31

MizterD99: Apr 12, 2003; "Ohhh, I just ate a whole bathtub full of cherry cobbler.. it was delicious."

Sylink posted:

Is XNA easy to understand for a novice who wants to try out 2D game programming? I want to make a sort of autonomous animation program and a game library would be the best choice. All i want to do is animate sprites for the most part, I dont need crazy 3d or anything.

I'd think so. I'm still pretty new to XNA, but you can set up C#, XNA 2.0, and go through the 2D tutorial they have on their site in just a few hours (the tutorial is very accessible and 99% video). This would give you a good feel for what you're getting yourself into. Here's the tutorial:
http://creators.xna.com/en-us/education/gettingstarted/bg2d/chapter1

They have all the info for getting C# and XNA 2.0 setup on their site as well (both free).

# ? Sep 19, 2008 14:23

Sylink: Apr 17, 2004

MizterD99 posted:

Thanks a lot, Ill give this a try.

# ? Sep 19, 2008 15:37

tyrelhill: Jul 30, 2006

guenter posted:

DirectX

ID3DXEffect has a function called GetParameterByName that returns a D3DXHANDLE to the shader variable. To set it, you can do SetMatrix(4x4), SetVector(4D), SetFloat, and SetValue which is like a memcpy.

# ? Sep 19, 2008 17:13

guenter: Dec 24, 2003; All I want out of life is to be a monkey of moderate intelligence who wears a suit. That's why I've decided to transfer to business school!

tyrelhill posted:

ID3DXEffect has a function called GetParameterByName that returns a D3DXHANDLE to the shader variable. To set it, you can do SetMatrix(4x4), SetVector(4D), SetFloat, and SetValue which is like a memcpy.

Yeah, I use that in the little code sample I posted. It just feels a little dirty - the renderer has to know about particles and any time I add a new kind of effect I would need to modify the renderer.

Maybe you're suggesting I do something with the handle? Do you have any examples I could take a look at? For something that seems like it should be a pretty common problem I'm having a lot of trouble finding references.

# ? Sep 20, 2008 01:17

Hubis: May 18, 2003; Boy, I wish we had one of those doomsday machines...

guenter posted:

Yeah, I use that in the little code sample I posted. It just feels a little dirty - the renderer has to know about particles and any time I add a new kind of effect I would need to modify the renderer.

Maybe you're suggesting I do something with the handle? Do you have any examples I could take a look at? For something that seems like it should be a pretty common problem I'm having a lot of trouble finding references.

You can separate it by having a "ParticleEffectShader" class, which handles the renderer state related to the shader, and a "ParticleShaderEffectProperties" class, which is associated with each effect system instance. When you create/update an instance, you give it it's own ParticleShaderEffectProperties instance, which contains values for the "life", etc. When it's time to render, you feed the particle system instance to the renderer, which feeds (a) the input geometry, and (b) the render state (which should include the ParticleShaderEffectProperties) and it will then feed that to the ParticleEffectShader, which does all the API-level work.

# ? Sep 20, 2008 03:36

Jake Armitage: Dec 11, 2004; +69 Pimp

Most people working with XNA are already probably aware, but just in case, XNA 3.0 Beta is out. This isn't the community preview thing anymore, and MS is recommending everyone convert their projects since the community games thing is going to require 3.0.

Good news: works with VS2008
Bad news: can't connect to X360 yet

Other than that, I have no idea what they changed.

# ? Oct 7, 2008 07:01

akadajet: Sep 14, 2003

I've yet to try it, but they say you can actually compress your audio with mp3 now.

# ? Oct 7, 2008 13:32

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

Can anyone remember what target max scene poly counts, max texture changes, state changes, blah de blah were for cards back in the Radeon 9500/9600 era? Or does anyone have a good reference for that sort of data?

(I realize they were always estimations, that they varied from card to card or game to game, etc - I'm just looking for the ballpark figures that were thrown out in the FAQs from back then that have since mostly disappeared)

# ? Oct 7, 2008 16:00

nihilocrat: Jun 8, 2004; all the hep cats jam to "cat /dev/hda1 > /dev/audio"

akadajet posted:

I've yet to try it, but they say you can actually compress your audio with mp3 now.

Wow... apparently I have overestimated the maturity of XNA just because I assumed it was a thinly-veiled attempt to get people to create games for Windows and the 360, and thus Microsoft would do a good job at making it very well-polished and feature-rich.

# ? Oct 7, 2008 16:50

Intel Penguin: Sep 14, 2007; hooray

So what exactly is the standard way of dealing with 2D physics? I downloaded farseer for xna. I can have my little guy move around based on controller input, but he's skating on nice. I'm also not sure if I'm actually rotating him or just applying force in the direction I want him to go (I'm using ApplyForce right now).

# ? Oct 9, 2008 02:36

nihilocrat: Jun 8, 2004; all the hep cats jam to "cat /dev/hda1 > /dev/audio"

Intel Penguin posted:

So what exactly is the standard way of dealing with 2D physics? I downloaded farseer for xna. I can have my little guy move around based on controller input, but he's skating on nice. I'm also not sure if I'm actually rotating him or just applying force in the direction I want him to go (I'm using ApplyForce right now).

Having zero knowledge of actually working with XNA, I am figuring you aren't actually rotating the guy, and depending on what sort of movement you are looking for, you might be better served by alternate control methods.

If you want the guy to accelerate around like he does now, but have him slowly come to a stop while no controls are being used, you could probably set some sort of damping or friction on the simulation. If you want him to move in the direction you point to and immediately stop, then you might be better off just modifying his x,y coordinates based off a constant speed factor and the timestep of the simulation to reflect the fact that he is moving.

# ? Oct 10, 2008 00:51

Jake Armitage: Dec 11, 2004; +69 Pimp

I've been playing with Farseer for a couple days now and I dig it, but drat someone needs to document the thing.

# ? Oct 13, 2008 04:37

Pfhreak: Jan 30, 2004; Frog Blast The Vent Core!

stromdotcom posted:

I've been playing with Farseer for a couple days now and I dig it, but drat someone needs to document the thing.

I believe it is a port of an old version of Box2D. We used it for our game dev project, but it turned out to have lots of trouble with the more complex things we wanted to do.

# ? Oct 14, 2008 02:09

nihilocrat: Jun 8, 2004; all the hep cats jam to "cat /dev/hda1 > /dev/audio"

Hey guys, check out my game, it's a spacewar clone, nothing fancy, other than the ships getting spun around when they are hit thanks to the fancy physics engine.

Click here for the full 805x624 image.

Requires Python 2.5, pyglet 1.1.1, pymunk 0.7.1 or above. Psyco is optional. Source is here: http://nil.cjb.net/code/raumkrieg-0.0.1-src.zip

bzr repo is here, if you swing that way: bzr branch http://nil.cjb.net/raumkrieg/ . The source is under the BSD license so basically do whatever you want with it.

I am trying to make an exe package with py2exe, but it manages to screw it up somehow. I will probably post details when I get frustrated enough.

caveat ludio (yeah, i looked it up): The game takes up about 24 meg of RAM on my system and leaks about 40k a second. If you are running a remotely modern system, you won't see issues for a loooooooooooooooong time.

nihilocrat fucked around with this message at 17:46 on Oct 17, 2008

# ? Oct 17, 2008 17:40

Lifespan: Mar 5, 2002

What's the general consensus on the Torque engine? I've done some work on my own engine before and found that I often got burnt out before I really reached an end product I was proud of. I'd like to able to offload most if not all of the graphics, collision detection, and much of the audio so I can focus on gameplay. I can't seem to find much in the way of free/open source engines out there and it seems like most of the respected open source engines things like Ogre that focus more on a single element, meaning I would have to patch together a lot of complex and unrelated libraries which might negate the point of avoiding writing my own engine again. I'm a fan of some of the smaller titles I have played that use Torque, but I'm not about to to just throw $150 for a license when I don't even know if the engine is what I would want (and I'm not looking to sell the title either). I wish they at least had an SDK demo or non-redistributable single chair license I could use to do some development before dropping the coin...

# ? Oct 20, 2008 01:57

nihilocrat: Jun 8, 2004; all the hep cats jam to "cat /dev/hda1 > /dev/audio"

I have no experience using Torque, but compared to what's out there it seems to be the bee's knees. As you've noticed, most of the free/open source stuff either requires you to cobble your own libraries together or are weak/too focused on making FPSes. 3D all-in-one game engines seem to be one of the weak spots of open source (also, music composition apps) compared to the commercial alternatives. I would be pleasantly surprised if anyone called foul on me and has been impressed enough with an open-source/free engine to feel there's no reason to look into commercial ones.

There are a large number of tutorials/examples written for integrating OGRE3D with OpenAL, Bullet, ODE, a series of GUI packages, etc.. I have probably been hopped up a little too much on the MVC model, but I actually like having the different components of the engine seperate and force them to communicate through events. If you plan to use one of the alternate language bindings (i.e. not C++, thus avoiding dependency hell), then using these external lib isn't a problem at all. There are also Irrlicht, Crystal Space 3D, Sauerbraten, and probably some others which don't just concentrate on the 3d engine. Blender also has some sort of game engine built into it which I've never ever looked into (but I probably should!). Don't forget the Quake 3 engine, either, which is open source.

There's also Panda3D, which provides everything (3d, events, controls, collisions, networking) via C++ or Python, but it's got issues like "hurr, we can't figure out a test for collisions from capsules into other capsules, so it's not implemented", somewhat sparse docs, a tiny community, and just a sort of odd way of doing things that make it obvious Disney/CMU took their internal engine, polished it just enough to make their API not look like trash, and released it. It doesn't have the wealth of examples for integrating into other libraries that OGRE3D has. It's still a nice engine which you should seriously consider, but I feel it's a little too hard to figure out how to get things done.

nihilocrat fucked around with this message at 02:54 on Oct 20, 2008

# ? Oct 20, 2008 02:52

Luminous: May 19, 2004; ~~Girls~~
Games
~~Gains~~

You could also check out Delta3D. I am not overly fond of it, personally, but we use it for projects at work. It is fairly military/GIS focused, but is a pretty general 3D engine as well.

# ? Oct 20, 2008 02:56

captain_g: Aug 24, 2007

Kimani posted:

Well, you can do that. The system is very flexible!
This is the plan. We'll have, say, 1024 core machines sometime in the future, and this system will take full advantage of them. All new PCs sold today are dual core or better as it is.

Well, it actually runs pretty darn smoothly. I'm running a Q6600 and a 9800 GT and it works swell, but it was running okay on my laptop with a AMD Turion 64 X2 2.3GHz and GeForce Go 6150.

As for threads fighting for cycles, it's actually pretty fine. You see, each entity isn't just looping as fast as it can. Some threads can be set to "inactive", where they only loop occasionally to process messages passed to it, but "active" threads... their Update function returns a value which says how long it wants to wait until the next update. I used 1/30th of a second for a lot of the entities. This means except for the time taken to do the updating and parsing any messages, it's sleeping the better part of 1/30th of a second.

Running it in the debugger affirms my theory when I designed it - whenever I paused execution, the overwhelming majority of the threads are asleep! Only some threads are really processing, and the ones that really matter - the primary update thread and rendering thread - are on a much higher priority such that they're always chugging along. As long as those two aren't getting interrupted much, the framerate will always be just fine. I was getting ~200 fps at times.
Although I can't say I know any of those, I chose Lua as the scripting language for a good reason - it's extremely fast and extremely small. The virtual machine takes about 100kb of memory when it's fully up and running.
Yeah, it's not really a problem with the system, it's just some weird bug I need to track down still. It runs well enough for me to want to get some input on it / declare it finished for the moment so I can work on something else for a change for a little while.

You've got to be trolling.

# ? Oct 20, 2008 16:01

nihilocrat: Jun 8, 2004; all the hep cats jam to "cat /dev/hda1 > /dev/audio"

Kimani posted:

stuff about concurrency

Have you checked out functional or semifunctional languages like Erlang or Stackless Python?

edit: After more reading, yes, other people have done this sort of thing, but the industry is so short-sighted that only a scant few have. The most visible is EVE Online, they have a powerpoint up from about three years ago explaining how their system works from a birds-eye view. The massive parallelism is supposedly what lets them have a shardless server with tens of thousands of players on the same shard.

I've also gradually noticed that the more seperation you have of specific entities from their context (i.e. game entities from game state) the easier it is to understand them or make changes without unwanted side-effects. It makes a lot of sense when you consider that the entirety of modern science is based off of trying to remove all side effects in a phenomenon to observe the operating paramaters of just the phenomenon itself.

nihilocrat fucked around with this message at 18:35 on Oct 20, 2008

# ? Oct 20, 2008 18:24

JohnyTex: Jan 10, 2005

stromdotcom posted:

Most people working with XNA are already probably aware, but just in case, XNA 3.0 Beta is out. This isn't the community preview thing anymore, and MS is recommending everyone convert their projects since the community games thing is going to require 3.0.

Good news: works with VS2008
Bad news: can't connect to X360 yet

Other than that, I have no idea what they changed.

Support for making Zune games and C# 3.0, and some new community / multiplayer stuff are the big news afaik.

# ? Oct 20, 2008 21:54

Kimani: Dec 20, 2003; Anime avatar - check
ADTRW poster - check
Defends watching child porn - CHECK!!!

captain_g posted:

You've got to be trolling.

Totally not. Implementing that beast over that long of time would be a rather elaborate attempt at trolling, no?

nihilocrat posted:

Have you checked out functional or semifunctional languages like Erlang or Stackless Python?

Not really. I haven't delved into too many nerd languages besides Lua; my nerd language of choice for this project. Lua works very well because it's very easy to program in ( although it being dynamically typed and all that means whenever I get a bug it's usually due to typos... ) and it's extremely fast. You can write game logic on an easy to use, high level and it's currently very solid.

quote:

I've also gradually noticed that the more seperation you have of specific entities from their context (i.e. game entities from game state) the easier it is to understand them or make changes without unwanted side-effects.

Heh, my environment is pretty much exactly this. Funny thing - at first I had a single Lua virtual machine, and I found out ways to spawn off threads within the virtual machine to handle multiple entities. But the game tended to crash within 5-30 seconds, and the debugger always complained about something deep within Lua's virtual machine. I guess it just isn't about to handle that sort of concurrency within a single VM.

So I ran some tests, checking the amount of RAM each VM uses. Fully initialized, with all my bindings registered, each VM takes about 100-150 kb of RAM. Hell, that's only 15MB for 100 VMs, so to fix the problem each entity in my environment has it's own Lua VM. Running the program yourself, you can see that the RAM requirements don't get out of hand, so it works well!

I get a lot of good side effects for implementing the system in this manner, one of which being what you mention. Every entity is very self contained, and they only communicate through message passing. The game becomes easy to write, although you need to design it with this in mind. Because I didn't need to dick around with Lua's *cough* "user friendly" version of object orientation, writing the actual code is a lot easier. Also loading scripts becomes a lot simpler.

As for what people suggested last time I was here, I tried converting the system to use worker threads but it ended up slowing down the system quite a bit. Just didn't seem like each worker thread could loop through all it's assigned entities quick enough. I made so I can switch between modes in the future if I need to.

I also attended a Graduate Student Workshop where many people were presenting their research along with Keynotes by Google and stuff. One of the presenters was presenting an alternate system ( than just locks ) for synchronizing many threads with a shared resource. It was, in a nutshell, putting jobs onto a queue and having the thread using the resource do all the things in the queue before it leaves. Funny thing is that he wasn't all that concerned about the locks being used in putting things into the queue.

Which is all the synchronization I'm doing. Putting things into a queue. Real quick, barely any time holding that lock.

I don't have too many industry connections but I did speak with someone that day who I worked on a (non-game) project with before, who has been involved with several start-ups and has been the CTO of several companies. We were discussing that particular talk and I described my system - he figured not the worry about the queue locking, that it's way fast enough and shouldn't be a problem.

So I might just stick with that! I'm working on prototyping the actual game I plan on developing ( not just a demo ) and it's coming along swiftly.

# ? Oct 20, 2008 23:11

Morpheus: Apr 18, 2008; My favourite little monsters

I'm having some real problems with slopes in a 2D platformer, and except for collision detection, I can't find anything about it online (I need collision resolution).

I already know everything about how high I should put my character so that he is 'resting' on the slope, with a little bit of him overlapping with the terrain so that he looks like he's on the slope and not just a pixel of him is. That's all easy. My problem is that, if there's a normal piece of terrain next to the slope:

code:

Combined terrain tiles:
   ___
 /|   | < 'normal' terrain
/_|___|
 
 ^ sloped terrain

Then he just walks up the slope until he collides with the terrain, then can't walk up the rest of the slope. How is this usually worked around? I'm not sure if it has to do with the collision detection, the bounding boxes, or some other weird thing I'm not thinking of, but the internet so far has not been forthcoming.

# ? Oct 20, 2008 23:27

Luminous: May 19, 2004; ~~Girls~~
Games
~~Gains~~

Kimani posted:

stuff

Your worker thread attempt probably wasn't as good because you probably 1) didn't spend anywhere near as much time on it as your other method, and 2) you probably - consciously or not - didn't think it was truly a necessary thing to do and didn't care to go through it with the same vigor as the other.

Also, "this is way fast enough, no worries" is a very bad choice. Just because you never see a side effect of that choice doesn't make it otherwise. It is your choice, but intentionally leaving a bug in just because it probably will never occur is...bad. Also, if the guy is so great, why is he hopping around so many jobs?

# ? Oct 21, 2008 00:24

Luminous: May 19, 2004; ~~Girls~~
Games
~~Gains~~

Morpheus posted:

I'm having some real problems with slopes in a 2D platformer, and except for collision detection, I can't find anything about it online (I need collision resolution).

I already know everything about how high I should put my character so that he is 'resting' on the slope, with a little bit of him overlapping with the terrain so that he looks like he's on the slope and not just a pixel of him is. That's all easy. My problem is that, if there's a normal piece of terrain next to the slope:
code:
Combined terrain tiles:
   ___
 /|   | < 'normal' terrain
/_|___|
 
 ^ sloped terrain
Then he just walks up the slope until he collides with the terrain, then can't walk up the rest of the slope. How is this usually worked around? I'm not sure if it has to do with the collision detection, the bounding boxes, or some other weird thing I'm not thinking of, but the internet so far has not been forthcoming.

It sounds like you are making a special case for when you encounter a slope, in order to position your character appropriately, yes? If so, since you know you are in that special case, change whatever your collision detection is to take that into account.

So, for instance, if you adjust your character 10 pixels to the right so he looks like he is standing on the slope, be sure you subtract those ten pixels from the position when checking for a collision. That would be my first plan of attack anyway, not that it is necessarily the best way or anything. Of course, you would want to take care to make sure the collision detection still behaves as you would expect for everything else (say he gets shot while moving up the slope, obviously you wouldn't want him to die when the bullet hits at -10 pixels).

Another method might be to just modify the bounding box to somehow exclude the part under the slope while on a slope.

Luminous fucked around with this message at 00:32 on Oct 21, 2008

# ? Oct 21, 2008 00:28

t_rf: Nov 24, 2006

The way I did slopes(a way which is probably a sin against performance, if you're trying to do everything "as it was done back in the day") was to ignore terrain-specific stuff and instead run a speculative collision test where the character is moved a little bit higher on the vertical axis, ignoring physics, and then is subsequently swept horizontally.

If that test works, but a test where they move horizontally without vertical movement fails, then I flip on the "slope-climbing" bit and let them move up vertically without falling in that frame. Then on the next frame they repeat the test and can now move a little bit horizontally...etc. It takes three different tests(horizontal only, vertical only, horizontal after vertical projection) but is very stable. With a little bit of tuning, this lets you climb any slopes your collision detection can support.

# ? Oct 21, 2008 02:40

Morpheus: Apr 18, 2008; My favourite little monsters

t_rf posted:

The way I did slopes(a way which is probably a sin against performance, if you're trying to do everything "as it was done back in the day") was to ignore terrain-specific stuff and instead run a speculative collision test where the character is moved a little bit higher on the vertical axis, ignoring physics, and then is subsequently swept horizontally.

If that test works, but a test where they move horizontally without vertical movement fails, then I flip on the "slope-climbing" bit and let them move up vertically without falling in that frame. Then on the next frame they repeat the test and can now move a little bit horizontally...etc. It takes three different tests(horizontal only, vertical only, horizontal after vertical projection) but is very stable. With a little bit of tuning, this lets you climb any slopes your collision detection can support.

The way I finally went about doing it was to have a variable called onSlope in the entities (the player and enemies). When they collide with a TerrainSlope* object, onSlope is set to true. While onSlope is true, the game ignores all collisions with other terrain objects that aren't slopes. When the player's state** is changed to FALLING or JUMPING, onSlope is set to true.

*A TerrainSlope object is a piece of terrain with a slope to it (duh). The actual slope is based on the sprite passed in, so it can technically be any size or shape.
** The entity's state is an enumerator that changes every tick depending on its state.

In any case it seems to work, though I haven't extensively tested it. Just the simple example I gave earlier.

# ? Oct 21, 2008 05:11

Shalinor: Jun 10, 2002; _{Can I buy you a rootbeer?}

Luminous posted:

Another method might be to just modify the bounding box to somehow exclude the part under the slope while on a slope.

The most correct solution to cases like this is to modify your bounding box algorithm so that it has two modes. In simple mode, for simple tiles, the box is collided as just that, a box. Simple and fast. Mode two, for complex tiles, uses a concept of a "solid" half of a tile and an "empty" half of the tile, with the division defined via an equation. For slopes, you could get away with a simple line, or even more simple, a fixed 1:1 line that goes from corner to corner, but you might want to consider making the system slightly more complex than that for futureproofing. (ie. imagine if you later want smooth undulating curves on your terrain - for that, you'd need something more complicated than a straight line)

The idea then is to figure out the relative position of the entity within the tile, and compare that to the line, however you define it, with positions above the line being non-colliding and below being colliding (or vice versa). Depending on how fancy you let your line equations get, you'll need to add some anti-jitter to prevent numerical inaccuracy from making your dude shake vertically.

Another alternative is to take the relative position of the entity within the tile and do a straight-up pixel comparison. Is the pixel transparent? Yes, then no collision, no, then it collides. However, unless your tiles are high resolution a/o you do multiple comparisons / effectively compare against a gaussian blurred version of the tile, you'll get serious aliasing of movement as your guy stairsteps up the pixels. It's also more expensive. That said, this approach supports absolutely any kind of geometry you could ever imagine, just paint it in and forget about it, so it's certainly the most convenient once you get it running.

Shalinor fucked around with this message at 16:55 on Oct 21, 2008

# ? Oct 21, 2008 16:52

Adbot: ADBOT LOVES YOU

# ? May 10, 2024 17:16

TSDK: Nov 24, 2003; I got a wooden uploading this one

Good grief, you're all making it more complex than it needs to be. The original question is essentially how do you move a 2D character along, given sloped and non-sloped tiles.

The easiest method to get the same sort of behaviour as old-school platformers is to move the character along horizontally, perform your collision check downwards from a central point:

code:

'

      X ----> X'
      |       |  M
    N |       V
      V     /---------
-----------/

Call the rest height for the character N, and the new height above the terrain M. Provided N - M is less than some given amount, then you allow the character to move to that point, and adjust their position to be N, the rest position above the terrain.

code:

'

              X''
      X ----> |
      |       |  N
    N |       V
      V     /---------
-----------/

If M is smaller than N by a predefined amount, then it counts as a collision, and the character is stopped from moving to the new point.

This also works when M is greater than N by less than a predefined amount, and the character will stick to the slope when walking downhill. Note that the predefined amounts by which you're comparing the difference essentially determine how steep the steepest slope can be for your character to walk up.

Doing it this way gives you a relatively nice behaviour, without having to special case slopes with state machines etc...

# ? Oct 21, 2008 19:06

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread

«‹›622 »