rich_is_bored

This is not as fast as being able to sketch a shape but at least you have the software and don't have to write it yourself...

The thing to keep in mind is that a normal map isn't purple for the sake of being purple. Each color channel represents a different component of a surface normal. They aren't photos. The image posted seems consistent with what you'd expect to find in the green channel of a normal map. You need to identify where the missing components are being stored. Maybe the original file has an alpha channel and data is being stored there?

So apparently there is a 16GB package of commercial quality sound effects made available free of charge here. The license appears to be compatible with TDM and having a look through the tracklist there may be quite a few that are useful to people here. I'll report back on the quality and my impressions should I manage to download it.

If you have a Roku or similar device and a windows 7+ computer with Wifi you can stream to it using Miracast. Win+C > Devices > Project > Destination I canceled my cable subscription a few months back and have been using this to watch sports that I cannot otherwise. I presume it would work fine for full screen games, and you could probably even use it as a second monitor.

If I recall correctly, the game loads files in alphanumerical order with the exception that it makes a distinction between pk4s and folders where folders are loaded last.

I recently read a blog post about how the backgrounds in Homeworld 2 were done using nothing but vertex colors. The article can be read here and a tool to create suitable models can be found here. It doesn't sound immediately applicable however what this example demonstrates is how you can "pack" texture data into a mesh. It's a trick that would cost you additional geometry, but if it isn't shadow casting it might be worth looking into. I don't imagine it carries much if any performance penalty. The tool linked above supports exporting a plane; a shape not too far removed from being a terrain mesh. It shouldn't require much tweaking to yield a model suitable for use in game.

This is the code for the particle effect. !!ARBvp1.0 OPTION ARB_position_invariant; MOV result.texcoord[0], vertex.texcoord[0]; MOV result.texcoord[1], program.local[0]; # scroll rate expression for x and y MOV result.texcoord[2], program.local[1]; # scale MOV result.texcoord[3], vertex.color; END !!ARBfp1.0 OPTION ARB_precision_hint_fastest; # Texture 0 is tiling perlin # Texture 2 is a mask TEMP IMG, UV, TMP; ADD UV, fragment.texcoord[0], fragment.texcoord[1]; TEX IMG, UV, texture[0], 2D; MOV TMP, IMG; MUL UV, fragment.texcoord[0], fragment.texcoord[2]; ADD UV, UV, fragment.texcoord[1]; TEX IMG, UV, texture[0], 2D; MUL TMP, TMP, IMG; ADD TMP, TMP, TMP; TEX IMG, fragment.texcoord[0], texture[1], 2D; MOV IMG.r, IMG.g; # <---- FOR SOME REASON THE THIRD TIME I CALL TEX I GET A CYAN IMAGE. MUL TMP, TMP, IMG; MOV TMP.a, TMP.g; MOV result.color, TMP; END

I stayed up way too late playing with this but the documentation for ARB is garbage ...

I'm not liking how glitchy and imprecise fragment programs are but this is one of the things I'm experimenting with ATM...

Yep. I arrived at the same conclusion although my journey was more trial and error. I can confirm that vertex color works and your explanation improves my understanding a great deal. On a side note, the textures loaded in my fragment program are cyan as if the red channel was missing. I've bypassed the issue for now by copying from a known working channel. EDIT: It looks like the red channel is ignored once I call TEX a third time.

That setting repositions the particles where I only mean to offset the texture applied to them. At any rate I've got an idea I'm going to try later. If that fails I'll post a video or some screenshots so it's more clear what I'm after and why.

I have a material with a scrolling texture. I have a particle effect. At present the texture scrolls across all the particles in unison but I need to offset the texture randomly on a per particle basis. I thought shaderparms would be the solution here but it appears they are only applicable on a per entity basis. I tried looking through the source code to be sure but I don't see anything specific to particles that would help. This experiment also happens to use a vertex/fragment program. I bring this up because if shaderparms are not an option perhaps there is some vertex or fragment properties I can use to derive a static value unique to each particle?

Try setting g_gravity to zero in the console.

I was watching a GDC talk this morning about the vfx in Diablo 3 and one thing mentioned reminded me of this thread. Around 20 minutes in the speaker talks about an additive blend that makes use of an alpha channel and demonstrates the difference. I think we can do this already without any fragment programs. { blend gl_one, gl_one_minus_src_alpha map textures/glowyshit } The whole talk is worth watching but this was the only thing I thought was immediately applicable to TDM.

I've created a demo.pk4 with a few examples. This should help you get up to speed... https://onedrive.live.com/?id=D6625ED3877C9FB4!1149&cid=D6625ED3877C9FB4

I don't see how that effect isn't also a disconnected collection of quads floating in space. The best you can do with our particle system is something like this... However, that's not an arc.

@Epifire: The engine supports animated textures in the form of an image strip, image sequence, or ROQ movie file. You might have noticed while creating the material shader for the moving needle gauge of your electric generator, many of the shader keywords accept expressions. This is how you cycle through an image strip (use the 'scroll' keyword) or image sequence (use the 'if' keyword). @bikerdude: Would the dust you're referring to be those fake volumetric light shafts? That works well because the particles all travel along the same vector. Making a straight line of particles is not an issue.

I used to own an Asus Xonar. You have to manually enable/disable "GX" mode in the Xonar applet to make use of it's "emulated" EAX. It doesn't work if the game requires EAX 3.0 or greater which renders it's virtually useless unless you stick to playing games from the 90s.

The particle system in TDM is as basic as they come. It's best suited for effects represented as collection of points in space like smoke, mist, fire, dust, and debris. An electrical arc is tricky. You don't want to draw a disconnected set of quads floating in space. Instead you want to form a connected chain from one point to the next. The engine doesn't currently support that. I imagine the best solution here is to sidestep the particle system altogether. Maybe use a torus shaped mesh with some deformations applied. Have it rotate in game and use a scrolling texture so only an arc is visible.

There's a checkbox in the light inspector labeled parallel that will do the job.

This isn't bad is it?

Have you tried recreating this shape purely out of brushes? I imagine that would eliminate the artifacts and you wouldn't sacrifice much detail.

Can you guess what happened while I was reading this article? I'll give you a hint. It was naggy and annoying.

Done. Same link as before.

I've got a 3D modeled version I put a little work into around the same time that I did the vector version above. I never bothered to share it previously because I considered it unfinished but I'll add it to the OneDrive above in case it's of use to someone. It needs more greebles and widgets in the background. The font isn't a match. It could use some tick marks on the face and it's completely untextured.