MrMoo posted:

That's quite pretty, it would be nice to group categories together like Apple. Unfortunately I don't have the imagination to create a unique style set:

Dromio posted:

This is my hobby project, a MPD client for windows mobile. It doesn't actually PLAY music, it just controls the server that does the playing. It also launches a real music player pointed at the shoutcast stream generated by my server. My music is available to me anywhere my phone gets EVDO or wifi access.

The UI gets album art from amazon and has those nifty "kinetic" scrolling lists, where you flick your finger across the screen to make the list fly in that direction. I still want to do more to the UI, like caching album thumbnails and using them within the lists.

Nuke Mexico posted:

This is an implementation I did of the Signed-Distance Field pre-processing and Shading techniques presented in the paper "Improved Alpha-Tested Magnification For Vector-Textures and Special Effects" that Valve put out. It's nothing too spectacular to look at, but the concept is pretty neat (and flexible).

Basically, most game text-rendering systems either (a) render their fonts at a fixed point size to a texture and just scale them up or down as needed, or (b) render each character that is needed at any given point-size, outline/shadow mode, etc, on demand to one of several swap textures which are updated each frame. The problem with the former method is that the text scales horribly, so if you deviate too far from the target point size (either larger or smaller) you end up with a blurry mess; the problem with the second mode is that it requires you to do a lot of work each frame to managed your texture memory usage, often having several versions if the same glyphs in your cache textures because you need them at different point sizes/rendering modes.

The "Signed Distance Field" method basically pre-processes a high resolution version of the characters, then shrinks the sampled data down and stores it in a single, small, compact texture. Essentially, each pixel in the texture corresponds to how "far" (in texels) that given point is from the edge of the character -- that's the 'distance' part. The 'signed' part comes from the fact that you split the range of possible values such that a value < 0.5 is outside the edge, while > 0.5 is inside the edge. You then map and render these characters as you normally would a set of glyphs in an atlas texture, with the only exception that you then need a shader to interpret the values so that you get smooth results.

This has the obvious advantages over prior methods of needing less texture memory; however, it's also superior to both in that, by virtue of the mathematical properties of the signed distance field and bi-linear texture interpolation, it scales up and down far better than simply rendering the character itself to a texture and scaling that. There's also the added bonus of the fact that you now have continuous "distance-from-edge" information in the texture, which allows you to get neat things like outlining and drop shadows essentially for free.

This is all a lot of for a fairly unexciting picture, however it's still a pretty cool technique -- especially considering how simple it is, conceptually. It's part of a larger tech demo I am working on for a job portfolio, so I may post some other elements later on once they get more polished.

Adhemar posted:

Can you explain the advantage of using this technique over a vector based approach (i.e. rendering triangles based on the splines)?

Nuke Mexico posted:

First, you can get smooth anti-aliasing on your font edges (by manipulating the alpha of the texel based on the distance field instead of just having a hard cut-off) as well as being able to include things like outlining and drop shadows with very little additional cost. You can also, in general, generate much higher quality glyphs with a texture-based system than you could with a direct vector-to-geometry approach, unless you wanted to allocate a fairly sizable amount of triangles towards rendering text.

You also have the advantage of dividing the work more effectively between your vertex- and fragment- units, which is important because one has to keep in mind that the graphics hardware is a pipeline, so a bottleneck in one stage means that the other stages are likely just sitting idle. For this system, I'm generating 2 triangles and 4 vertices (indexed) per character, and doing (hopefully) an equal amount of work on the vertex and fragment processing stages; depending on your implementation, a vector-to-geometry system could be anywhere from 8 to 50 triangles per character, and likely doing almost nothing at all on the fragment processors. That's a lot of CPU and memory overhead to composite those triangles together into one render list, and REALLY a lot of overhead if you're issuing a separate draw command for each character. Of course, none of this really matters if text rendering is not a bottleneck for you; I just happen to find this implementation to be fairly flexible, straightforward, and all-around eloquent.

It's also worth noting that this technique has the additional benefit of being able to work with ANY alpha-tested texture that can be converted into a high-resolution binary (white-or-black) image. For example, you can use this method to create HUD elements from source textures that scale nicely and can drop shadows/pulse/glow. It would also be very useful for alpha-tested polygons of, say, a brush/grass/tree system, for example, as a way of creating leaves which have crisp, smooth edges even under close inspection without using a large amount of texture memory for them. It's really just a good all-around solution for solving the problem of aliasing in alpha-testing.

Adhemar posted:

Thanks a lot for the info. I've been slowly developing an engine out of a codebase I've used for a few projects now, adding features as I need them, and I haven't needed a font rendering system so far as I've been running it inside a GUI app. I've been thinking about taking it to the next level and making it into something that can run full-screen, so I've been thinking about a modern font rendering technique to implement. After reading that paper by Valve I might give it a go, it seems clever and pretty straightforward.
There's a chapter by Jim Blinn in GPU Gems 3 (chapter 25), where they render vector art such as text straight from the spline curves, on the GPU. I haven't read it in detail yet, but maybe Valve's technique is more practical.

Nuke Mexico posted:

Every game I know of/worked on uses bitmapped/textured fonts, if an appeal-to-authority is worth anything

Adhemar posted:

I know, but I don't necessarily want to do what every other game is doing.

PlaneGuy posted:

You could use voxel-based fonts. I don't think there are many doing that.

Nuke Mexico posted:

more falafel please posted:

Can someone explain to me the optical illusion reasons why the Lorem ipsum text moves when my eyes move around it, or is it just that my hangover isn't quite as cured as I thought it was?

more falafel please posted:

Can someone explain to me the optical illusion reasons why the Lorem ipsum text moves when my eyes move around it, or is it just that my hangover isn't quite as cured as I thought it was?

Zagrod posted:

A 3d game me and my friend are working on for our degree. Started from scratch, done in C++/DirectX. We're using Ageia PhysX for the physical simulation side of the things.

We're still in the process of begging our friends for textures and models, so far only the Cube we're in is fully done - doors and boxes have the same texture as the walls because we still don't have anything (good) to substitute it with.

Right now the brightness is pumped way up for us to see everything very clearly - The room itself is going to be darker with a little glow shader where the little lamps are. The engine is mostly finished so we're hoping for a smooth sailing up to the presentation.

Stramit posted:

I'm currently rebuilding my 3d engine from scratch. I used it last year for my honors thesis at university, but there were so many things that I wanted to change by the end that I just decided to rebuild it from scratch. Here are some shots of the stuff I have been working on.

General Scene:


Screen Space Ambient Occlusion Pass (still need a bit more work / tweaking):


I'm doing this ill in OpenGL. Currently the engine supports Bullet physics, and a nice configurable render pipeline where I can change how elements plug in and plug out. I have just started working on the game side of the engine so I'll actually be able to use it for something other then pretty tech renders.

tripwire posted:

I'm thinking of using physx bindings through Ogre for a project I'm working on. Have you found physx to be fast on physics? Is there any comparisons you can draw as to speed and ease of use between physx and other physics engines?

quote:

DataSafe v1.0

A desktop encryption application that will encrypt and decrypt files and folders using the latest and greatest encryption algorithm, AES.

Multithreaded with a budding UI, I require feedback and beta testers. If you would like to try this application, please email me at aronweiler@gmail.com

Zagrod posted:

Unfortunately, no as this is my first time working with a physics engine. Also, my simulation is pretty small, there are few objects which aren't terribly complicated in shape - so I can't really say how fast would it be for your project, if you're planning something in a bigger scale.

As far as ease of use goes it's OK. However, at least for me, you have to do a lot of cross-checking in documentation. For example, there's a whole lesson on Springs and Dampers, along with a compiled example, but when you go to another page about it, they tell you its deprecated and you need to use Distance Joints.

Sir Davey posted:

sweet lookin waveform view

If you're wondering, I'm using OpenGL / GLUT for the rendering.

Evil posted:

I am just finishing an encryption application for Windows that is pretty nifty.


http://flickr.com/photos/aweiler/sets/72157605397499044/


Select the file you want to encrypt, and drag it onto the giant 'ENCRYPT' panel.


Type in a strong password; note that my password is extremely strong at 4 characters long.


Watch your data get encrypted via AES!

This also works with folders and multi-file selection. There are a couple settings that can be changed through the app.config file, but it's all pretty simple stuff.

Like the quote says, I would love to get some beta testers to try this out and find any bugs that might exist.

Alex007 posted:

I'm coding a web-based MMO forthe Urban Dead goons who are sick of Urban Dead

I really wanted to clean up the UI, Urban Dead sucks balls on this, there's a dozen forms on-screen and you always have to search when you want to do something.

I decided to go a bit Web 2.0-style and I'm using javascript popup menus. Plyaers can interact with their environment by clicking on elements showing a drop-down arrow, and a menu pops up.

I'm not sure how standard it is, but it makes a really clean UI and is really easy to use, compared to UD.

Main game screen:



Inventory screen, with popup activated:



Thread: http://forums.somethingawful.com/showthread.php?threadid=2819930

Anode posted:

A Web front-end for NodeBox's Colors library, built with Appengine. It's at http://colorpsinner.appspot.com if anybody wants to mess around with it.

duck monster posted:

Seems broken atm

Barrackas posted:

Couple of pics from my Java3D terrain program (done for my dissertation)

Hazy hills...


Stars coming out at night...

Wuen Ping posted:

Yes, we are using Ogre. I was very resistant to using it at first, because when I first looked at it, it did stupid things like reinvent a substantial portion of the STL. Fortunately, those kinds of defects have been remedied, and now I can go on record as saying it is fantastic to work with.

Wuen Ping posted:

Yes, we are using Ogre. I was very resistant to using it at first, because when I first looked at it, it did stupid things like reinvent a substantial portion of the STL.

OneEightHundred posted:

I've heard a good number of horror stories about lovely STL implementations, which is probably why practically every major engine I look at has its own versions of STL-ish classes.

Nuke Mexico posted:

which is kind of hilarious since that usually makes the problem worse, not better

Wuen Ping posted:

This. Also, the usual motivation for reimplementing part of the STL wasn't implementation quality, it was disagreements over the way the STL does things. For instance, Qt reimplements most (all?) of the STL containers, plus a few more, all with Java-style iterators. This is actually billed as a selling point in their marketing docs! Clearly, this is the work of a genius.

Nuke Mexico posted:

NIH syndrome at its worst

MrMoo posted:

I thought the primary goal was to reduce memory consumption for KDE 4, although the root cause seems to be a plethora of STL containers within their widgets.

Nuke Mexico posted:

because it almost certainly never is.