Game Development Megathread

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

«‹›623 »

MrZig: Aug 13, 2005; I exist onl because of Parias'
LEGENDARY GENEROSITY.

brian posted:

Well for a start you're doing test(enemy.x - this.x, this.y - enemy.y) when you want it to be test(enemy.x - this.x, enemy.y - this.y). Other than that I don't know. Just work out what should be happening on one test and what's actually happening and work out what you're doing wrong from the difference. It's really what you end up doing most of the time in game development.

Yeah, funny thing is I flipped the y values because it seemed to make it more accurate when I first started - then right before you replied I switched it back and presto it works much better. It still doesn't seem to be exactly perfect but I'm very happy with the results from where I was.

Thanks for the tips! I'm one step closer to the release.

Edit: false alarm, it seems as though sometimes it works perfectly, and other times its way off. I need to completely re think this.. I think I might go with my boxes idea.

MrZig fucked around with this message at 07:15 on Feb 19, 2012

# ? Feb 19, 2012 05:40

Adbot: ADBOT LOVES YOU

# ? May 26, 2024 05:18

resting bort face: Jun 2, 2000; by Fluffdaddy

I'm diving into XNA after some experience with C++ (and a little experience with C#).

I have been reading about different approaches to employing delta time into one's update loop. I've read and re-read the "Fix Your Timestep" article (http://gafferongames.com/game-physics/fix-your-timestep/).

What I'd like to do is learn how to apply acceleration to a player-character's velocity so that one runs at a slow speed at first and then speeds up, or so that one slows down before reversing directions, etc.

I'm aware there are libraries out there that will solve the problem for me, but I'd really like to understand the basic principles at work and incorporate them by hand so that I have a firm grounding.

Could some kind soul help me adapt the final code snippet in the Fix Your Timestep article toward this purpose?

# ? Feb 20, 2012 03:27

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

Mastiff posted:

I'm diving into XNA after some experience with C++ (and a little experience with C#).

I have been reading about different approaches to employing delta time into one's update loop. I've read and re-read the "Fix Your Timestep" article (http://gafferongames.com/game-physics/fix-your-timestep/).

What I'd like to do is learn how to apply acceleration to a player-character's velocity so that one runs at a slow speed at first and then speeds up, or so that one slows down before reversing directions, etc.

I'm aware there are libraries out there that will solve the problem for me, but I'd really like to understand the basic principles at work and incorporate them by hand so that I have a firm grounding.

Could some kind soul help me adapt the final code snippet in the Fix Your Timestep article toward this purpose?

The very basics of it is you have a Vector2 position and a Vector2 velocity. Let's say you are at (0,0) and your velocity is (1,2). On each tick, you add your velocity to your position so your position becomes (1,2) for the first tick then (2,4) on the second tick. This is constant velocity and it'll look like you have cruise control on.

All acceleration does is add another Vector2 into the frey. Every tick, add acceleration to velocity. Then do the regular velocity + position to get placement.

tick 1:
acceleration (1,2) + velocity (0,0) = (1,2) our new velocity
velocity (1,2) + position (0,0) = (1,2) our new position

tick 2:
acceleration (1,2) + velocity (1,2) = (2,4) our new velocity
velocity (2,4) + position (1,2) = (3,6) our new position

This gives us a sense that we're moving faster and faster after every tick. To tie it into movement, you're probably pushing Up and then adding the velocity to the position. This is giving you cruse control. Instead, pushing up should add acceleration to the velocity (make sure you cap velocity). Pushing the opposite direction works the same where you just add acceleration in the opposite direction you are moving and you'll slow, stop, then start moving the other direction.

# ? Feb 20, 2012 04:13

resting bort face: Jun 2, 2000; by Fluffdaddy

poemdexter posted:

The very basics of it is...

Thanks for your thoughtful answer. The very basics is about all I have at this point: http://pastebin.com/VP2GiD7x

As you described, the sprite accelerates to a maximum speed and continues skating in that direction until we give it new input in the opposite direction at which point it slows and then gains speed in the opposite direction. Releasing the arrow keys doesn't slow it -- though I'd like to implement that. I'm sure it's a very obvious bit of code but I'm having trouble ironing that out.

But what I'd really like to do is implement the semi-fixed step as described by Glenn Fiedler (repasted here):

code:

    double t = 0.0;
    const double dt = 0.01;

    double currentTime = hires_time_in_seconds();
    double accumulator = 0.0;

    State previous;
    State current;

    while ( !quit )
    {
         double newTime = time();
         double frameTime = newTime - currentTime;
         if ( frameTime > 0.25 )
              frameTime = 0.25;	  // note: max frame time to avoid spiral of death
         currentTime = newTime;

         accumulator += frameTime;

         while ( accumulator >= dt )
         {
              previousState = currentState;
              integrate( currentState, t, dt );
              t += dt;
              accumulator -= dt;
         }

         const double alpha = accumulator / dt;

         State state = currentState*alpha + previousState * ( 1.0 - alpha );

         render( state );
    }

A version of that code would go into my Game1.cs, but I don't know the proper syntax, or how to integrate it into the simple physics of my hero.cs class.

# ? Feb 20, 2012 07:11

PDP-1: Oct 12, 2004; It's a beautiful day in the neighborhood.

Mastiff posted:

As you described, the sprite accelerates to a maximum speed and continues skating in that direction until we give it new input in the opposite direction at which point it slows and then gains speed in the opposite direction. Releasing the arrow keys doesn't slow it -- though I'd like to implement that. I'm sure it's a very obvious bit of code but I'm having trouble ironing that out.

In this kind of physics code it's useful to remember that nearly everything comes down to the equation F=m*a, and that a=dv/dt. With that in mind you can write

F=m*dv/dt

and re-arrange to get

dv = F/m*dt

where dt is your timestep, m is the mass of whatever object you're dealing with, F is the sum of all vector forces on that object, and dv is the amount that the velocity is going to change during this timestep.

Since m and dt are relatively fixed quantities all you have to do is worry about F. Forces might come from two sources here, the player's commands and friction. On each update loop set F to (0,0) then look for any player commands and if they're pressing the 'go right' key do F+=(1,0) to apply a right-going force. The easiest way to model friction is to have another force that always tries to oppose the current direction of motion, so F-=k*v where k is some frictional constant and the -= operator causes the friction force to always be applied in the opposite direction of v.

A pseudocode update loop might look like this

code:

F=(0,0)

// player commands
if(playerWantsToMoveRight) F+= Vector2.Right * moveForce
if(playerWantsToMoveLeft)  F+= Vector2.Left  * moveForce

// friction
F -= k*v

// velocity/position updates
v += F/m*dt
p += v*dt

Mastiff posted:

A version of that code would go into my Game1.cs, but I don't know the proper syntax, or how to integrate it into the simple physics of my hero.cs class.

I'm not totally sure why you'd want to write your own timing code in XNA, the base Game object takes care of that all for you, locks to 60FPS by default, and you can get the actual timestep size from the GameTime struct that is passed into the Update and Draw calls.

If you have some real driving reason to do things yourself, I'd guess you would need to go into the Program.cs file and eliminate the Game.Run() call, since the Run method initializes the game and starts the timing loop. Then you'd write your own MyRun method that calls Initialize and LoadContent on startup and then sets up your timer to call Tick() in the base Game class manually. Finally, go back to Program.cs and put Game1.MyRun() where the old Run command was.

# ? Feb 20, 2012 15:52

resting bort face: Jun 2, 2000; by Fluffdaddy

PDP-1 posted:

I'm not totally sure why you'd want to write your own timing code in XNA, the base Game object takes care of that all for you, locks to 60FPS by default, and you can get the actual timestep size from the GameTime struct that is passed into the Update and Draw calls.

From a thread on GameDev last year:

quote:

The dropped frames in the default XNA FixedTimeStep makes it un-usable. It has been brought up many times on the forum:

http://forums.create...ums/t/9934.aspx

... but I've never seen someone post a way to use XNA FixedTime step and not have jerky motion updates.

So the general recommendation seems to be the approach in the Fix Your Timestep article if one wants smooth motion. You can use the default approach and get jerky movements, or a second approach to get the old-school "everything slows down" look when there's too much going on, but for smooth movement everyone seems to agree that it's the semi-fixed timestep (i.e. decoupling the simulator & rendering framerates) or bust.

# ? Feb 20, 2012 19:09

Shameproof: Mar 23, 2011

I'm trying to make an expansion on Slime Volleyball (http://oneslime.net/) using Farseer and XNA. Does anyone know a way I can make the player avatars behave like Semi-Circles? I suppose the easiest way would be to override the Shape's collision logic to exclude collisions with objects that fall underneath its horizontal diameter, but I don't see any method for that and there's just so darned many.

EDIT: Oy, the collision logic is not Object Oriented AT ALL. It's just a list of methods like CollidePolygonAndCircle, CollidePolygonAndEdge, etc.

Shameproof fucked around with this message at 20:41 on Feb 20, 2012

# ? Feb 20, 2012 20:38

OneEightHundred: Feb 28, 2008; Soon, we will be unstoppable!

Shameproof posted:

EDIT: Oy, the collision logic is not Object Oriented AT ALL. It's just a list of methods like CollidePolygonAndCircle, CollidePolygonAndEdge, etc.

This is actually pretty typical because the math for colliding any two shapes tends to be extremely specialized.

# ? Feb 20, 2012 21:08

Bongo Bill: Jan 17, 2012

Today I got out and got some work done on my game. Still very early in development, but even having a small and clear list of things to implement now doesn't stop it from being hard to work from home when you're surrounded by all your favorite distractions. I may have to increase my coffee-house budget if I'm to meet my goal of a release by the end of the year.

I'm writing this in C with SDL SQLite mostly because I like like C and SDL and I'm likely to need to be familiar with SQLite at some point in the future, but this has the convenient property of being about as platform-independent as anything can be. The interface lends itself naturally to buttonless control as well, so, happily, if there's interest for it, mobile ports will be possible without extensive reworking. But that's a long ways out. Today I did exactly what I needed, which was to stop planning and start acting.

I also found Jeff Vogel's recent article about independent business practices to be quite inspiring.

# ? Feb 20, 2012 21:22

Shameproof: Mar 23, 2011

I just decided to make a polygon that approximates it. w/e

# ? Feb 20, 2012 21:30

My Rhythmic Crotch: Jan 13, 2011

I have been coding a small RTS for several weeks now. I was wondering if this thread is an appropriate place to discuss ideas, concepts and mechanics for a game or is this thread strictly for technical questions?

# ? Feb 20, 2012 22:06

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

My Rhythmic Crotch posted:

I have been coding a small RTS for several weeks now. I was wondering if this thread is an appropriate place to discuss ideas, concepts and mechanics for a game or is this thread strictly for technical questions?

There's another thread in Games forum aimed at more general game design talk: http://forums.somethingawful.com/showthread.php?threadid=2711122

EDIT: (but mind, I am not the OP of this thread, just offering what exists - pretty sure you'd be fine with some of that over here too)

Shalinor fucked around with this message at 22:11 on Feb 20, 2012

# ? Feb 20, 2012 22:08

My Rhythmic Crotch: Jan 13, 2011

Cool, thank you.

# ? Feb 20, 2012 22:10

Lucid Dream: Feb 4, 2003; That boy ain't right.

I'm trying to draw a bunch of sprites in XNA, and I want to draw them with varying transparency, but I don't want the sprites below showing through. I've got them sorted so they draw in order from back to front properly and have the right transparency, but of course they stack like A in the example below. Anyone have a method of doing this in XNA or just a general approach?

Here is an example of what I mean, A is what I'm getting, B is what I'm after.

# ? Feb 22, 2012 12:13

My Rhythmic Crotch: Jan 13, 2011

I think you need something like this to detect the intersections and do the clipping: http://sourceforge.net/projects/polyclipping/

I can't really think of a simpler way to do it...

# ? Feb 22, 2012 13:26

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

My Rhythmic Crotch posted:

I think you need something like this to detect the intersections and do the clipping: http://sourceforge.net/projects/polyclipping/

I can't really think of a simpler way to do it...

Simpler could be to just redraw the piece of background that's about to be covered before you draw each sprite.

vvvv if doing what this guy says, you'd be wanting to render your sprites front-to-back not back-to-front if it makes any difference which one is the visible one. And in fact, then you wouldn't need to do any special z-buffer things at all, that's exactly the result you get with z-buffers and front-to-back drawing, that's exactly why you're supposed to render transparent things from back to front normally, because most people want the result you don't.

roomforthetuna fucked around with this message at 14:26 on Feb 22, 2012

# ? Feb 22, 2012 14:18

ynohtna: Feb 16, 2007; backwoods compatible; Illegal Hen

Is there no depth buffer in XNA, then?

I.E. draw each at the same Z depth, with the depth buffer function set to exclude pixels already rendered at that depth.

# ? Feb 22, 2012 14:23

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

Here's something I whipped up for Mastiff. It's extremely simplified but should be a good base for anyone wanting acceleration in an XNA game instead of static velocity.

https://gist.github.com/1885471

# ? Feb 22, 2012 16:13

resting bort face: Jun 2, 2000; by Fluffdaddy

poemdexter posted:

Here's something I whipped up for Mastiff. It's extremely simplified but should be a good base for anyone wanting acceleration in an XNA game instead of static velocity.

https://gist.github.com/1885471

My God, it's beautiful.

# ? Feb 22, 2012 16:35

poemdexter: Feb 18, 2005; Hooray Indie Games!; College Slice

Mastiff posted:

My God, it's beautiful.

From the code you sent me, it wasn't obvious that you had a firm grasp on how acceleration, velocity, and position all work together. When you start throwing in Vectors, it ends up being something straight out of a college Physics 101 class. Once you wrap your head around how they all derive from one another, you should be solid.

Also, XNA's Vector classes are just amazing with so much built in functionality. Normalize() by itself sold me on it.

# ? Feb 22, 2012 18:03

Mata: Dec 23, 2003

Lucid Dream posted:

I've got them sorted so they draw in order from back to front properly and have the right transparency, but of course they stack like A in the example below.

Like room-for-the-tuna said, it should work the way you want if you reverse the drawing order (and enable the depth buffer and all that stuff)

# ? Feb 22, 2012 21:48

Lucid Dream: Feb 4, 2003; That boy ain't right.

Thanks guys, I'll give it a shot.

edit: Ok, so the depth buffer stuff worked for a rectangle, but when I use a sprite that isn't a rectangle the transparent bits do this:

I tried using an alpha test to eliminate the transparent parts, which gets me pretty close but because I've got some partially transparent bits around the edges of the sprites that causes a problem. The hard edge from the alpha test is also not anti-aliased so it looks kinda ugly when it moves. Heres what it looks like with the alpha test and the depth buffer crap:

I'd considered just tinting the sprites so they appear to fade into the background, but the background is a gradient, so I can't just tint the clouds with a static color, but i'm considering checking the color of background at the center of the cloud and tinting it based on that, but I figured I'd see if anyone else had a better way of doing it first.

Lucid Dream fucked around with this message at 03:15 on Feb 23, 2012

# ? Feb 23, 2012 00:08

resting bort face: Jun 2, 2000; by Fluffdaddy

poemdexter posted:

From the code you sent me, it wasn't obvious that you had a firm grasp on how acceleration, velocity, and position all work together. When you start throwing in Vectors, it ends up being something straight out of a college Physics 101 class. Once you wrap your head around how they all derive from one another, you should be solid.

Also, XNA's Vector classes are just amazing with so much built in functionality. Normalize() by itself sold me on it.

This is a tremendous help. Thank you so much for your time & effort.

# ? Feb 23, 2012 02:24

ZombieApostate: Mar 13, 2011; Sorry, I didn't read your post.

I'm too busy replying to what I wish you said

Lucid Dream posted:

Clouds

It looks like your first image your depth buffer isn't working, but it is in the second... In any case, drawing front to back with partially transparent stuff basically always looks like crap (without multisample/supersample magic at least). Alpha testing anything with edges that blend from opaque to transparent is always going to have that poo poo looking shadow around the edges. I'm not seeing why you need what you were asking for if you're just drawing opaque clouds with semi-transparent edges though. It would work just fine drawing back to front. Or I could just be too sleep deprived to think it through.

ZombieApostate fucked around with this message at 08:14 on Feb 23, 2012

# ? Feb 23, 2012 08:02

Lucid Dream: Feb 4, 2003; That boy ain't right.

ZombieApostate posted:

It looks like your first image your depth buffer isn't working, but it is in the second... In any case, drawing front to back with partially transparent stuff basically always looks like crap (without multisample/supersample magic at least). Alpha testing anything with edges that blend from opaque to transparent is always going to have that poo poo looking shadow around the edges. I'm not seeing why you need what you were asking for it you're just drawing opaque clouds with semi-transparent edges though. It would work just fine drawing back to front. Or I could just be too sleep deprived to think it through.

I worded it weird - I'm trying to do parallax clouds, and I want the clouds to fade into the background as they get further away, but (ideally) I don't want them to show through each other when they overlap.

# ? Feb 23, 2012 08:47

HiriseSoftware: Dec 3, 2004; Two tips for the wise:
1. Buy an AK-97 assault rifle.
2. If there's someone hanging around your neighborhood you don't know, shoot him.

Lucid Dream posted:

I worded it weird - I'm trying to do parallax clouds, and I want the clouds to fade into the background as they get further away, but (ideally) I don't want them to show through each other when they overlap.

What happens when you turn on alpha blending? I'm confused now as to which direction you're rendering, but this should work back-to-front, to give a smooth blending look to the edges of the clouds. I'm assuming just the edges are semi-transparent and the bulk of the cloud is opaque.

code:

// XNA 4.0
GraphicsDevice.BlendState = BlendState.AlphaBlend;

// XNA 3.5
GraphicsDevice.RenderState.AlphaBlendEnable = true;

# ? Feb 23, 2012 15:35

superh: Oct 10, 2007; Touching every treasure

Lucid Dream posted:

I worded it weird - I'm trying to do parallax clouds, and I want the clouds to fade into the background as they get further away, but (ideally) I don't want them to show through each other when they overlap.

Is there a chance you're overthinking it? You're not really trying to get them to fade away further back, you're trying to tint them to a blue (or a specific color out of a gradient) - just keep the cloud part of the asset opaque, draw them back to front, and use progressively less tint as you get towards the front?

# ? Feb 23, 2012 15:46

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

Lucid Dream posted:

I worded it weird - I'm trying to do parallax clouds, and I want the clouds to fade into the background as they get further away, but (ideally) I don't want them to show through each other when they overlap.

I think you really need to define what it is you need, at this point, because from your descriptions I can't tell what you want to happen with a 70% transparent cloud-edge pixel that overlaps a 70% transparent pixel from another cloud, in front of the 0% transparent background.

The usual option is it looks like 30% cloud-edge-pixel, 21% cloud-from-behind-edge-pixel, 49% background. That's what you'll get with back-to-front rendering and alpha blending.

The next option is it looks like 100% cloud-edge-pixel, which is what you get with front-to-back rendering and alpha testing.

The third option, that sounds more like what you're saying, is that pixel looks like 30% cloud-edge and 70% background, which is what you get if you draw the background first then render front-to-back with alpha testing and alpha blending. But it looks like rear end because your 5% transparent pixels come out looking like big holes in the cloud passing behind.

I'm not sure any of these are what you're hoping to achieve though - if you can't describe what you want for a single pixel, perhaps you could Photoshop up a picture of what it is you're hoping to see, because to me, what you're describing is something that only really works with cartoon clouds and doesn't make any sense with the cloud images you've shown.

# ? Feb 23, 2012 15:52

Lucid Dream: Feb 4, 2003; That boy ain't right.

Its entirely possible that the effect I'm after isn't really practical, I've barely scratched the surface of a lot of this blending/stencil/alpha-test stuff. Alpha blending back to front got me like 90% where I wanted to go and I don't hate the result, but its not ideal.

Let me use ground based parallax junk, its easier to show what I'm trying to get across. I want object A to look like it is 75% away, so I make it 75% transparent, and I want object B to look like it is 85% away, so its smaller and 85% transparent.

On the left, the further away object shows through the closer one, which is absolutely what you would expect from alpha blending, but not really what I want. The one on the right is what I want, but to get it in photoshop I selected the closer object and used the selection to cut a hunk out of the further back object so there isn't anything to show through anymore. I haven't a clue how I'd do that in real time though.

"What you're after isn't really possible/practical" is a totally fine answer and I can work around it if I have to but I was hoping there was some fancy thing I wasn't yet aware of that I could use to get the effect I'm after.

superh posted:

Is there a chance you're overthinking it? You're not really trying to get them to fade away further back, you're trying to tint them to a blue (or a specific color out of a gradient) - just keep the cloud part of the asset opaque, draw them back to front, and use progressively less tint as you get towards the front?

I had considered this, but I want to have to option of using a gradient as a background if possible.

# ? Feb 24, 2012 01:12

Paniolo: Oct 9, 2007; Heads will roll.

Render front to back and use the depth or stencil buffer to avoid overdraw.

Paniolo fucked around with this message at 01:20 on Feb 24, 2012

# ? Feb 24, 2012 01:16

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

Lucid Dream posted:

On the left, the further away object shows through the closer one, which is absolutely what you would expect from alpha blending, but not really what I want. The one on the right is what I want, but to get it in photoshop I selected the closer object and used the selection to cut a hunk out of the further back object so there isn't anything to show through anymore. I haven't a clue how I'd do that in real time though.

"What you're after isn't really possible/practical" is a totally fine answer and I can work around it if I have to but I was hoping there was some fancy thing I wasn't yet aware of that I could use to get the effect I'm after.

I had considered this, but I want to have to option of using a gradient as a background if possible.

What you're doing there is, effectively, lerping between texture color and background color. So just do that.

Per object, sample the texture of the rock, and then sample the texture of the background at the appropriate location. Lerp as you choose to indicate distance. Then render it OPAQUE (or at least stencil-alpha) to the background, with the appropriate Z depth to make it sort properly wrt. other rocks.

EDIT: ^^ Or, yeah, do stencil.

# ? Feb 24, 2012 01:19

Lucid Dream: Feb 4, 2003; That boy ain't right.

Ok great, thanks for the suggestions, I think I understand what I need to do now.

# ? Feb 24, 2012 01:27

HiriseSoftware: Dec 3, 2004; Two tips for the wise:
1. Buy an AK-97 assault rifle.
2. If there's someone hanging around your neighborhood you don't know, shoot him.

How about a shader that first premultiplies the texture RGB by some color attribute (your 75%, 85%, etc), keeps the alpha intact, and then alpha-blends that? Basically prevent the alpha component of your texture from being modified by the "current color" which you could then make (1, 1, 1, 1).

I'm an OpenGL guy, and haven't touched XNA in forever, so not sure how that would work.

Edit: Hmm the more I think about that, it would just make the mountain look black at the farthest away, I think...

Edit: Ok, forget all that. If you want to use the depth buffer, and render front to back, only write to the depth buffer for your opaque pixels, and don't write to the depth buffer for the translucent edge pixels, so then you can get a nice blended edge instead of the jagged stuff. Is there any way to do that in a shader?

HiriseSoftware fucked around with this message at 03:22 on Feb 24, 2012

# ? Feb 24, 2012 03:05

ZombieApostate: Mar 13, 2011; Sorry, I didn't read your post.

I'm too busy replying to what I wish you said

Isn't that still going to end up with weird looking halos where stuff overlaps? It'll be a lot less noticeable than having funky shadows everywhere, but...

# ? Feb 24, 2012 06:00

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

ZombieApostate posted:

Isn't that still going to end up with weird looking halos where stuff overlaps? It'll be a lot less noticeable than having funky shadows everywhere, but...

I think rendered back-to-front, with mostly-opaque clouds, 'tinted' with the background colors so as to fade into the background without impacting transparency, would work. The semi-transparency at the edges would avoid weird halos, the non-transparency in the middle would prevent the clouds getting too thick where they overlap (and thus losing fade-into-background-ness), and the tinting/lighting with background colors (or double texturing if the background is a texture) would fix the fading.

# ? Feb 24, 2012 06:30

ZombieApostate: Mar 13, 2011; Sorry, I didn't read your post.

I'm too busy replying to what I wish you said

Yeah, that's what I would try. I was just thinking about the stencil/depth buffer method Hirise is talking about. Stuff that should be underneath would draw on top of the semi-transparent bits of the stuff that should be on top and it might look weird where they overlap.

# ? Feb 24, 2012 07:54

roomforthetuna: Mar 22, 2005; I don't need to know anything about virii! My CUSTOM PROGRAM keeps me protected! It's not like they'll try to come in through the Internet or something!

The funny thing about that solution is that it doesn't match the spec of the original question with the overlapping semi-transparent rectangles.

# ? Feb 24, 2012 15:51

Shameproof: Mar 23, 2011

Anyone know of a good .NET library, textbook, or guide for music visualization?

# ? Feb 25, 2012 05:03

Contero: Mar 28, 2004

What's the accepted way to handle the mouse for things like first person camera where you can potentially scroll forever? This is in straight win32 if it matters. The way I used to do it was:

* Hide cursor, move cursor to center of screen.

* On each frame, measure distance between cursor position and center of screen, that is my mouse dx,dy for the frame. Then move cursor back to the center.

Are there any potential problems with this? Is there an easier way to do this in windows? I'm trying to avoid direct input if possible.

# ? Feb 25, 2012 11:29

Adbot: ADBOT LOVES YOU

# ? May 26, 2024 05:18

pseudorandom name: May 6, 2007

A quick look at MSDN suggests you probably want to use raw input instead of standard input events.

# ? Feb 26, 2012 02:14

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

«‹›623 »