Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread
 
  • Post
  • Reply
StickGuy
Dec 9, 2000

We are on an expedicion. Find the moon is our mission.

forelle posted:

I am rendering tens of thousands of particles, the results of which need to be correctly composited with the results of all the previous particles. Your method would require swapping on each particle which would slow us to a crawl.
Have you considered presorting your particles?

* # ¿ Dec 8, 2007 01:07
  • Quote
Adbot
ADBOT LOVES YOU

# ¿ Apr 27, 2024 18:55
  • Quote
StickGuy
Dec 9, 2000

We are on an expedicion. Find the moon is our mission.
Some time ago, I wrote an application that renders some 2D polygons. I was lazy about handling complex cases so I used the GLU tesselator to handle drawing them. I'm rewriting the rendering code using DirectX as a learning experience, but I can't find a DirectX equivalent to the tesselator. As a stop gap measure, I've used the tesselator to do the tesselation and then just render the primitives with DirectX. I'm hoping there's a better way though. Does anyone have any experience with this sort of thing in DirectX?

* # ¿ Dec 21, 2007 02:08
  • Quote
StickGuy
Dec 9, 2000

We are on an expedicion. Find the moon is our mission.

biznatchio posted:

MS-RL is like the GPL. If you use any of the source code in a file of another project, that file of the project must be made available under the MS-RL license. It differs from the GPL in that copyrights and attributions in the source code must be left intact, even when incorporated into another project.
Judging from your summary, another difference with the GPL is that, under MS-RL, only the source files making use of MS-RL code must be made open source when redistributing. With the GPL, all source files would need to be made open source.

* # ¿ Jan 14, 2008 12:39
  • Quote
StickGuy
Dec 9, 2000

We are on an expedicion. Find the moon is our mission.

heeen posted:

What is the correct way to compute a depth buffer value from world position, because this gives my slightly wrong values:
code:
	vec4 transformedpos=gl_ModelViewProjectionMatrix*vec4(actualpos,1);
	gl_FragDepth=(transformedpos.z/transformedpos.w
                     -gl_DepthRange.near)/gl_DepthRange.diff;
This is what I have in one of my shaders, but I have no idea why it's like this anymore:
code:
gl_FragDepth = ((transformedpos.z / transformedpos.w) + 1.0) * 0.5;
EDIT: If I recall correctly, transformedpos.z / transformedpos.w produces a value in [-1, 1] that needs to be mapped to [0, 1].

StickGuy fucked around with this message at 12:40 on Apr 23, 2008

* # ¿ Apr 23, 2008 11:51
  • Quote
StickGuy
Dec 9, 2000

We are on an expedicion. Find the moon is our mission.

heeen posted:

Ok, the calculation seems to be correct, yet it seems to be z-culled away, any ideas?
I'm raycasting triangles into triangles that lie in front of the former, if that makes sense.
Here is what it looked like with my (apparently wrong) depth calculation. You can see the pool bleed into the border.

edit:
code:
	vec4 transformedpos=gl_ModelViewMatrix*vec4(actualpos,1);
	float near=1.0;
	float far=2048.0;
	float depthcalc=(far / (far - near) + ((far * near / (near - far)) / transformedpos.z));
	gl_FragDepth =  depthcalc;
According to the OpenGL specification, that depth calculation is not relevant here. According to Section 2.11, we arrive at a point's normalized device coordinates as follows:
code:
    vec4 transformedpos = gl_ModelViewProjectionMatrix * vec4(actualpos,1);
    vec3 devicepos = transformedpos.xyz / transformedpos.w;
According to Section 2.11.1, we compute the z window coordinate like so:
code:
    float zpos = ((f - n) / 2) * devicepos.z + (n + f) / 2;
Note that, according to the same section, n and f are clamped to [0, 1] and specified with a call to glDepthRange. By default, they are 0 and 1 (See the man page for more information). Thus the calculation, in that case, becomes:
code:
    float zpos = 0.5 * devicepos.z + 0.5;
This is all relevant because in Section 3.11.2, under "Shader Outputs", it specifies that "The final fragment depth written by a
fragment shader is first clamped to [0, 1] and then converted to fixed-point as if it were a window z value (see section 2.11.1)."

Enjoy.

EDIT: Swapped gl_ModelViewMatrix with gl_ModelViewProjectionMatrix.

StickGuy fucked around with this message at 06:42 on Apr 24, 2008

* # ¿ Apr 23, 2008 22:21
  • Quote
StickGuy
Dec 9, 2000

We are on an expedicion. Find the moon is our mission.
Sorry about the typo. The video looks pretty nice.

* # ¿ Apr 24, 2008 09:45
  • Quote
StickGuy
Dec 9, 2000

We are on an expedicion. Find the moon is our mission.

TSDK posted:

Neither. You should have a Renderer class that renders (or adds to a deferred render list) Sprite objects passed in. The Player class then has a pointer to a Sprite object.
I'm not sure how scalable this approach is when you have, for example, many different types of objects that require special rendering techniques. It would get a bit messy to have all of that in one place.

* # ¿ Jul 1, 2008 12:38
  • Quote
StickGuy
Dec 9, 2000

We are on an expedicion. Find the moon is our mission.

Paradoxish posted:

In a general sense you could keep that information in the actual Sprite (or RenderableObject or whatever the hell) structure. That would allow you to sort your sprites by rendering technique and still basically localize things in the way TSDK is suggesting. It'd actually be pretty trivial to do something like this if you're using programmable shaders.
If you're following this approach, then I'd suggest it's better to have the Renderer be more of something that knows about sets of properties (e.g. shaders, textures, etc.) associated with graphics objects. It would then sort these objects somehow based on the graphics state and render they require, but still request that they render themselves. That way the renderer wouldn't have to care about whether some objects use display lists, VBOs, or other special techniques.

* # ¿ Jul 1, 2008 13:35
  • Quote
StickGuy
Dec 9, 2000

We are on an expedicion. Find the moon is our mission.
It sounds almost like you're using a single-buffered mode.

* # ¿ Jul 21, 2008 09:48
  • Quote
StickGuy
Dec 9, 2000

We are on an expedicion. Find the moon is our mission.

more falafel please posted:

I have some Python code that prints "hello world" 10 times but it's really slow, Python must be really slow.
code:
for i in range(1,10):
    print "hello world"
    for j in range(1,1000000000):
        pass
It's only 4 lines, it can't be the code.

I think this is a lot of the reason why people tend to think languages like Python and Ruby are so slow -- when complicated algorithms (regular expression matching, any string processing crap, etc) are hidden behind a really nice layer of abstraction, you don't realize when you're doing (for instance) n^2 operations n^2 times.

Here's a data point: the vast majority of gameplay code for Gears of War is either written in UnrealScript, expressed as data, or in Kismet, which is UE3's graphical scripting environment. You don't write AI in savagely optimized C.
I think you missed some of the point. Your example has terrible performance because scripting languages just can't handle huge numbers of operations that are actually in the scripting language. If they are hidden away in "savagely optimized C", you won't notice it that much. Python et al. are good for games because you can let them deal with a number of game objects as individual objects and let the hidden C/C++ deal with the hundreds of thousands of individual triangles and vertices.

* # ¿ Jul 22, 2008 07:40
  • Quote
StickGuy
Dec 9, 2000

We are on an expedicion. Find the moon is our mission.
To get the OpenGL libraries and headers for windows you have to download and install the platform SDK from Microsoft. It's free, but it's a big install.

more falafel please posted:

No, my example has terrible performance because it's algorithmically horrible. My point was that a lot of times perceived performance issues in languages like Python come from the language/library obscuring the algorithmic complexity of what it's doing under an awesome interface. This was in reference to someone saying that PyGame was taking a huge and noticeable amount of time to draw each frame. It wasn't PyGame that was the problem, it was that he was essentially reinitializing the entire surface every frame.
I guess my point is subtly different. What you say is true, but the limit at which algorithmic complexity becomes a bottleneck depends on whether it's in wrapped C/C++ code or if it's pure scripting language that can't be passed off to the underlying C/C++ code. Take the example of image processing. There's plenty of image processing libraries for Python, but most of them rely on some wrapped code to handle the actual iteration over the image pixels. To have such iterations in pure Python code would make things much slower.

StickGuy fucked around with this message at 07:53 on Jul 23, 2008

* # ¿ Jul 23, 2008 07:48
  • Quote
StickGuy
Dec 9, 2000

We are on an expedicion. Find the moon is our mission.
The Windows API provides functions to "capture" the mouse so that a window receives all mouse events, even if they're generated outside of it.

* # ¿ Aug 3, 2008 11:22
  • Quote
StickGuy
Dec 9, 2000

We are on an expedicion. Find the moon is our mission.

Null Pointer posted:

Order-independent transparency is interesting for having fluid and aerosol simulations on the GPU, not because of a problem a BSP already solves.
It will also be helpful for rendering intersecting transparent geometry without having to resort to tesselation to get the right result.

* # ¿ Aug 13, 2008 16:44
  • Quote
StickGuy
Dec 9, 2000

We are on an expedicion. Find the moon is our mission.

captain_g posted:

I didn't know GLUT is part of OpenGl? Surely you mean GLU, which no one uses anyway.
GLU is pretty handy actually. It's good for setting up some camera views and who wants to write stuff to tesselate polygons? Furthermore, I refer you to:
http://www.opengl.org/documentation/specs/
where they also list the GLUT specification.

* # ¿ Sep 10, 2008 21:09
  • Quote
Adbot
ADBOT LOVES YOU

# ¿ Apr 27, 2024 18:55
  • Quote
StickGuy
Dec 9, 2000

We are on an expedicion. Find the moon is our mission.
The mouse interaction for me was a bit awkward, but the rest worked OK.

* # ¿ Sep 14, 2008 23:13
  • Quote
  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply
The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Game Development Megathread