|
frtplot is a plotting program not entirely unlike gnuplot, but it's a lot more interactive, and it can display real-time data. Got a little more time to develop it lately, since we realized we can use it at work... Here we're using it to compare profiling results before/after modifying the code for an industrial simulator (had to censor the function names because.. the usual):   (Images are from the sourceforge project site... hopefully that doesn't constitute leeching) Also wrote a new SDL GUI toolkit for it from scratch. Wonder if that was a wise thing to do, but it has automatic layouting (a bit like in GTK), and is written in C - looks like all other GUI toolkits for SDL are written in C++ for some reason 
|
#
¿
Mar 27, 2009 22:45
|
|
|
|
| # ¿ Apr 26, 2024 07:51 |
|
|
I'm working on a toolset that's built on fast and simple Unix IPC. The initial piece is a program for easy, interactive, real-time 2D vector graphics generation through an STDIN/STDOUT interface, this is called Animator. Here is a simple example game in less than 600 lines of Python. It writes drawing commands intended for Animator and reads events generated by Animator. The result is somewhat like this choppy animated  gif: Click here for the full 400x400 image. For this, you need to run the programs in a "69" configuration (so first output goes to second input and second output goes to first input); originally I wrote a tool called 69 for this, but today I sat down and wrote a more generalized and powerful version that can pipe multiple programs together in various ways. These utils could be the most useful when you're doing quick/hackish stuff - we're quite into the competition scene (like ICFP and Challenge24), there some quick visualization driven by a 10-line AWK script can save your day.
|
|
#
¿
Dec 11, 2009 22:57
|
|
|
Looks like in this thread the 3D stuff is the most popular, so here's mine   Click here for the full 640x480 image.  Click here for the full 640x480 image. It's a Z-buffered software rendering engine with flat and gouraud shading (with one diffuse light), texture mapping, and frustum culling. The main gimmick is that it isn't a lib, but a standalone (SDL-based) program that reads drawing instructions from STDIN, and optionally dumps mouse/keyboard events, or rendered framebuffers, to STDOUT. There is a description language (parsed with flex/bison) for defining geometry, using some usual basic solids, polygons, or used-defined objects. The scene can be changed between multiple frames (e.g. by changing the transformation matrix on defined objects to move them). This way any program that can write to STDOUT can generate fairly complicated 3D animations. Handy for visualizations, for example. The program is called Projector, is utterly undocumented, and available from svn://repo.hu/projector. Interactive 3D programs can be made by connecting Projector's STDIN/STDOUT to another program with two pipes. You can get Projector to report a position where a ray shot towards the mouse intersects a defined plane - here this is used by a 3K AWK script to display simple objects on a map, movable by the mouse:  Click here for the full 640x480 image. A C program using ODE for bouncing lots of stuff off of each other, dumping the object positions and orientations (as quaternions) to Projector:  Click here for the full 640x480 image. We used Projector in the Challenge 24 programming competition. The competing teams had to control three helicopters in a helicopter simulation (also done using ODE), and could view a real-time video stream from a "camera" on one of their helicopters. The video streams were served by xinetd, that ran a shell script that emitted a few HTTP headers, then called a pipeline something like: netcat (from the simulation server) | AWK (for transforming simulation state to Projector instructions) | Projector | ffmpeg (for encoding into Flash video) It looked like this:  Click here for the full 640x480 image. One interesting tidbit: the terrain engine converted a 16384x16384 heightmap + texture to a bunch of gradient-shaded triangles in a quadtree. To make the block cutoff look nicer, a fog effect was needed. The Z buffer has the depths in floating point, and calculating the fog per pixel in the usual way was rather too slow. In the end, I found a way with direct floating point hackery - using the bits in the Z FP value with a bitmask and some shifts gives a pretty nice alpha (but this way the fog density/distance is not variable in runtime). Sorry for the  (edited for typos) k-zed fucked around with this message at 15:51 on Jul 11, 2010 |
|
#
¿
Jul 8, 2010 16:10
|
|
|
(amazing what you can do in Lua these days) And who writes the absolutely asskick music?
|
|
#
¿
Aug 9, 2010 17:21
|
|