|
I was getting sick of maintaining three different lighting systems and not being able to do mesh lighting because of architectural limitations, so I devised some clever solutions to some of the quirkier poo poo with photon mapping and started a new general-purpose light tool: Click here for the full 800x450 image. Unlike the old lighting tool, this toy is entirely built around UV-map based lightmaps so it can handle any lightmap projection on any geometry. That means anything that exports to its geometry format could use it for lighting. It's also fully multi-threaded, and uses disk caching extensively so it's disk-bound rather than memory-bound. (And yeah I know the edges are dark, I haven't implemented the feature that will prevent those yet)
|
#
¿
Sep 6, 2010 04:34
|
|
|
|
| # ¿ Apr 28, 2024 00:23 |
|
|
shodanjr_gr posted:That's basically the form-factor between the patches converging to infinity, right? The solution is to determine the area of the geometry contained within the collection sphere. There's a proper way to calculate that but it's kind of annoying, so for now it just uses pi*r^2 for the valid area factor. There are some other side-effects to doing this "properly", like spatially-dense geometry (ridges, spikes) doesn't wind up excessively bright, and photon impacts can be partitioned by smoothing group instead of maintaining one hit catalog for the entire scene or bleeding over "sharp" edges. OneEightHundred fucked around with this message at 21:02 on Sep 7, 2010 |
|
#
¿
Sep 7, 2010 20:33
|
|
|
I'm trying to make an embedded managed runtime with a very thin C++ integration layer and much better performance than interpreted dynamic languages like Lua. It's also thread-safe and lets you serialize pretty much anything (including threads). The compiler supports nearly all of the language features and template types, the low-level IL translator was just finished (pictured), x86 native code output's next up. I can almost taste the pre-alpha release! (Yes I know it optimizes like poo poo, but compared to globally-blocking interpreted languages that hammer the allocator it'll be great) OneEightHundred fucked around with this message at 05:14 on Sep 25, 2011 |
|
#
¿
Sep 25, 2011 05:05
|
|
|
Doesn't ASP.NET's WebMethod feature already do that?
|
|
#
¿
Oct 11, 2011 18:29
|
|
|
Sagacity posted:That's limited to ASP.NET Xml Web Services or something and is only designed to handle stuff like an Ajax call Guess it doesn't do push though.
|
|
#
¿
Oct 12, 2011 15:25
|
|
|
Bob Morales posted:What did font smoothing ever do to you?
|
|
#
¿
Nov 9, 2011 18:02
|
|
|
Let's make threads serializable!  
|
|
#
¿
Nov 11, 2011 04:25
|
|
|
  I hate myself for starting this project. Fortunately, with switch statements working, there's only one language feature I care about left (foreach) and then I'm done with this dumb compiler! And switch was the last one that required adding an opcode. 
OneEightHundred fucked around with this message at 03:30 on May 16, 2012 |
|
#
¿
May 16, 2012 03:17
|
|
|
 IO-less pure .NET MPEG demuxer/decoder library.
|
|
#
¿
Jul 18, 2012 16:26
|
|
|
Tres Burritos posted:What does this even mean? Demuxer = Can handle streams containing both audio and video. IO-less means that it doesn't do any file reads, you just feed it in bytes and it decodes when it thinks it has enough data, so it works in scenarios where you don't want blocking reads. Pure .NET = no unsafe code = You can use it pretty much anywhere you can use .NET.
|
|
#
¿
Jul 18, 2012 23:45
|
|
|
That's the C++ version, the .NET version is on a different project page. It's also probably more readable, a lot of stuff was cleaned up during the port. It's actually more a port of smpeg, which is kind of an "enhanced" port of mpeg_play (video) and splay (audio). The demuxer is new code and a lot of things under the hood changed too, i.e. the audio decoder bitstream IO was overhauled, the audio decoder was changed to use fixed-point integer math, and a lot of things in the video decoder were changed to make it guarantee that it returns within a finite amount of input data. OneEightHundred fucked around with this message at 06:50 on Jul 19, 2012 |
|
#
¿
Jul 19, 2012 06:25
|
|
|
Running out of features to implement on my extension language. Beta draws near:
|
|
#
¿
Aug 28, 2012 00:05
|
|
|
MPEG video decoding using shaders. My first D3D11 app, lol. (Bitstream parse on the CPU, IDCT in a compute shader, rest in pixel shaders) http://i.imgur.com/E7mBIJj.jpg
|
|
#
¿
Apr 19, 2015 03:12
|
|
|
Messing around with procedural world generation: Trying to make something that can generate worlds similar to RTS campaign maps, with clearly-defined navigable area, lots of variation in space openness and chokes. It's a bit unusual in that the basic structure of the playable space (the sand) is generated first and constrains the rest of the generation process. Next up: Figuring out how to do the spatial analysis necessary to place objectives/NPCs in the map, and fix up some pathological cases like tiny strips of unnavigable terrain. I also need to find a way to make the sand dune filter suck less, but I think doing that is going to require a nasty hack. edit: Looks like Unity's real-time GI still requires baking all of the transport in the editor and can't do it at runtime. That's OK. I'll just turn it of and write my own runtime GI solver.  
OneEightHundred fucked around with this message at 10:42 on Jul 5, 2015 |
|
#
¿
Jul 4, 2015 02:57
|
|
|
Let's convert .NET generics into C++ templates. 
OneEightHundred fucked around with this message at 21:16 on Oct 24, 2015 |
|
#
¿
Oct 24, 2015 21:09
|
|
|
Porting an old somewhat popular Mac game. Got to the title screen! (Might seem minor, but getting this far is probably 20%-30% of getting the whole thing working...) 
|
|
#
¿
Dec 21, 2019 23:12
|
|
|
It'll probably be 100% playable a while before it's completely finished. A lot of the remaining work is rolling a window manager to deal with all of the prefs dialogs and editor mode, changing the resolution (ideally while in-game, which I think the existing code doesn't support), enough of a QuickTime subset to get the TVs working, other random things like gamepad support, and purging a few things with questionable IP status. The depot is here if you want to follow it or take it for a whirl: https://github.com/elasota/GlidePort I'm guessing it'll be mostly playable - but with a lot of broken draw functions - by the end of the week, and most of the draw functions fixed by the new year. OneEightHundred fucked around with this message at 08:13 on Dec 25, 2019 |
|
#
¿
Dec 25, 2019 01:12
|
|
|
 Level editor 95% ported. Only thing that doesn't work is the map scroll bars and resizing. Only 3 things left on the alpha release milestone, which I'll probably knock out next weekend.
|
|
#
¿
Mar 9, 2020 06:50
|
|
|
New UI skin to complete the  
|
|
#
¿
May 18, 2020 10:00
|
|
|
Unlike JSON, Lua permits a trailing comma after the last element in a table def, so you should just always put a trailing comma.
|
|
#
¿
Aug 26, 2020 08:36
|
|
|
|
| # ¿ Apr 28, 2024 00:23 |
|
|
 With the Windows port done, the mobile port is under way. Still struggling with a good touchscreen control setup though. Biggest problem is the rubber band and battery inputs are bad if you need to input movement on the same side of the screen, but using screen edge touch for movement feels way better than anything else I've tried. Sigh.
|
|
#
¿
Oct 15, 2020 15:59
|
|