|
 A 3D remake of The Amazing Labyrinth, built from scartch (no engine or framework) with C++ and DirectX.
|
#
¿
May 12, 2008 09:18
|
|
|
|
| # ¿ Apr 27, 2024 06:35 |
|
|
 A smoke/fluid simulator I'm working on for a visualization course. Written in GLUT + GLUI.
|
|
#
¿
Sep 14, 2008 11:07
|
|
|
StickGuy posted:Using the rainbow color map in a visualization course is a bit I didn't come up with the rainbow color map (it was already in the framework provided by the course teacher), but what's so strange about it?
|
|
#
¿
Sep 14, 2008 12:56
|
|
.
|
Adhemar posted:You're at TU/e, right? I probably know your professor. Yeah, I am. The professors of the course are Westenberg and Van De Wetering.
|
|
#
¿
Sep 14, 2008 17:28
|
|
|
Squantmuts posted:Dude, I am in your class :-). Wow  Get yourself over to the Dutch thread right now man.
|
|
#
¿
Sep 16, 2008 08:25
|
|
|
clockwork automaton posted:I started using Qt because initially I was told "okay, this is going to be cross platform" -- but then later I was told "okay, actually this is going to just be windows" and Qt runs slow as hell on windows machines (esp. if you have an embedded OpenGL window like I do). Also, I gently caress around with colors in the HSV colorspace and I was irritated that I can't just create a color that way. I have to create a color and then use setHsv. That's not the only thing I ran into that pissed me off. I'm running a Qt application within Windows, and with an embedded OpenGL window, and it's in no way slow as hell. Also, I just checked, and it is possible to directly create a QColor object using HSV parameters, so that's not a valid argument either. Then again, maybe I'm biased, because the other big library I have to work with is VTK, which makes Qt seem like a haven of sense and simplicity by comparison.
|
|
#
¿
Dec 5, 2010 21:02
|
|
|
Fun little weekend project: A simple console application made in C# that determines the highest-scoring move for Scrabble/Wordfeud. It's essentially just a brute-force check of all possible placements of all possible permutations of your rack. (The board in screenshot is of a Dutch game, in case you're confused)
|
|
#
¿
Nov 20, 2011 16:42
|
|
|
Made a proof-of-concept of a semi-realistic lighting engine for a Roguelike over the weekend. Still a long way to go, but simple direct lighting is working rather well already, and creating a new type of light is as easy as drawing a gradient onto a 256*64 image in Photoshop. Some screenshots, all in the same area:  Wall-mounted omnidirectional lights.  Bright ceiling light.  Flashlight. And the pièce de résistance:   Up next: Shadow-casting for non-floor-to-ceiling objects (e.g., characters and low walls), diffuse lighting, and reflections if I feel up to it. From Earth fucked around with this message at 19:46 on Mar 18, 2012 |
|
#
¿
Mar 18, 2012 19:15
|
|
|
gold brick posted:Don't know if you saw this, but Eric Lippert (from the C# compiler team) had a series of posts on this a while back. The code is in C#, but he spends a good deal of time discussing how he went about solving the problem. I went into this without reading up on existing algorithms, because I wanted to figure it out on my own. Scrolling through the article, it seems I do at least one thing the same (dividing the full 360 degree range into eight sections, and solving each independently), but there are some differences. Once I've got all features in, I might do a write-up of how my algorithm works. taqueso posted:Is the basic idea for non-floor-to-ceiling objects that they reduce light by some percentage depending on how big they are? Not quite. Like I said, I might do a full write-up in the future, but the basic idea is that I'll project the shadow of the object onto the 256*64 image that I use to determine the light color for a given set of angles. That way, all points behind the object will sample their light color from the now-shaded area, which will make them darker. The cool thing is that it even allows for neat effects like colored glass, since that'd be as easy as slapping a blue "shade" onto the light map instead of a black one. quote:And you should totally do reflection, I don't think it will be very hard, and it will really push the realism through the roof. Does everything in your world have material types? Not yet, I'll add that once I add diffusion. I hope reflection will be somewhat doable, I haven't really given it much thought yet.
|
|
#
¿
Mar 19, 2012 07:30
|
|
|
Update on the Roguelike lighting engine: Shadowcasting is done! The circles are omnidirectional lights at a height of 3 meters; the blocks labeled '1' and '2' are solid blocks of 1 and 2 meters high, respectively. The 'W' blocks are windows, consisting of (bottom to top) 1 meter of solid material, 1 meter of blue glass, and another meter of solid material. I actually had to redesign a large part of the algorithm, because my original idea made accurate shadowcasting practically impossible. The new approach is a bit more complex than the old one (in terms of number of computations per square), but it's also far more flexible, and there's still plenty of room for optimization. Up next: Diffusion!
|
|
#
¿
Mar 24, 2012 13:37
|
|
|
Wheelchair Stunts posted:I can't help but grin like an idiot at these screenshots. I love it! Imagine how I feel. I spend far too much time just moving lights and objects around and looking at the results. 
|
|
#
¿
Mar 24, 2012 13:49
|
|
|
Jewel posted:You should give us a bit more insight as to how you calculate the shadowing for different heights of materials and whatnot! It'd be nice to see exactly how it works, since the results are great. I'll do a detailed write-up when everything's done, but here's the basics of it. For every point P near a light L, we can compute two angles, A and B (actually theta and phi, but I don't remember their character codes):  To determine the color and brightness of the light at P, we use a 256 x 128 pixel image that describes L, which I call a light map for lack of a better term. The horizontal range represents the angle A (from 0 to 2pi), the vertical range represents B (from -pi/2 to pi/2). To determine the color of a single point, we simply compute its angles, and sample the light map at the corresponding point. I then also divide this color by the distance between L and P (which I don't think is entirely accurate, but it produces the nicest results), and multiply it by a brightness factor, which I think was set to 2.0 in the previous screenshot.  Creating new types of light is as simple as drawing a new light map. For example, here's a blue-red siren and a flashlight.   Casting shadows essentially comes down to projecting the shape of an object onto the light map. For walls, this is easy: We compute the maximum and minimum values of A for the tile containing the wall, and we simply make this entire range of the light map black (from top to bottom). If we later process a point with an angle A within this range, we know that it's behind a wall, and we color it black. Non-wall objects are a bit more difficult since their shadows also have a limited vertical range, but the basic idea is the same: Project the shape onto the light map, and all points lying within this shape will be colored black. For the windows, instead of projecting a black shape onto the light map, I project a small image onto it, with black at the top and bottom (representing the wall) and light-blue in the center (representing the glass). And that's more or less it. The code itself is a bit more involved, as it includes some optimization strategies, but the core ideas are the same.
|
|
#
¿
Mar 24, 2012 14:28
|
|
|
First crack at diffusion. The basic idea: Every time light bounces off a floor, wall, or ceiling, it stores a fraction of the incoming light as diffuse light in the current tile (for floors and ceilings), or in the adjacent tiles (for walls). Then, when all lights have updated, I blur these diffuse light values a number of times. The effect seems really subtle so far. Blurring three times goes a long way to softening shadows near lit walls, which is the desired effect, but on the whole the result might still be a bit too subtle. Maybe I need to tweak the blurring kernel a bit. Also, I'll probably be posting future updates in the Game Development thread, so keep an eye on that thread if you're interested.
|
|
#
¿
Mar 25, 2012 10:44
|
|
|
Bastard posted:That language is that in? Currently in C# with XNA. If I end up building an actual game around it, I'll probably port it to C++ first (using SDL/Allegro/SFML).
|
|
#
¿
Mar 26, 2012 19:06
|
|
|
Screenshot Saturday Progress! 
|
|
#
¿
Feb 15, 2014 20:31
|
|
|
Internet Janitor posted:Is this the beginnings of a Carnage Heart clone? I had to look up Carnage Heart on YouTube, but it looks far more complex than what I'm planning to make. My idea boils down to, program a number of robots using the board shown in the GIF, hit play, watch the robots solve a puzzle and/or walk into the nearest wall. I'm basing it more on SpaceChem than anything else.
|
|
#
¿
Feb 15, 2014 21:07
|
|
|
|
| # ¿ Apr 27, 2024 06:35 |
|
|
kayakyakr posted:Sounds like robo rally. a competitive game mode with a limited set of tiles (that you draw) and use, would be pretty cool. Robo rally was a fun board game (spinnaz gonna spin). I know and love Robo Rally, so, yeah, I guess it'd be like SpaceChem meets RoboRally (and Carnage Heart, apparently). Jewel posted:May I recommend having a tile pool you can also drag from, like SpaceChem? Less clicks and an overview of what you can place is always a good thing. Just thinking in terms of "what made SpaceChem's UI more enjoying than most puzzle games to me" here. I've added it to the list of Things To Look At Once The Basic Stuff Is More Or Less Working.
|
|
#
¿
Feb 16, 2014 09:59
|
|