The more helpful thing you can do is video a game with tons of effects that matches the art style of your game, say Nuclear Throne, and look at it frame by frame to see what's happening.
[video=youtube;3CyPDVcaO8k]http://www.youtube.com/watch?v=3CyPDVcaO8k[/video]
Do this for enough games in your target art style and you'll have a lot to pull from when doing it on your game.
Vulkan binding is slowly reaching something usable, though the generated code has now exceeded 10000 lines. Don't think I should be leaking any memory either which is nice, harder to achieve that than I would of liked.
[CODE]using System;
using System.Runtime.InteropServices;
using static Vulkan.Native;
using Vulkan;
namespace vktest
{
class Program
{
static void Main(string[] args)
{
ApplicationInfo appInfo = new ApplicationInfo();
appInfo.Type = VkStructureType.StructureTypeApplicationInfo;
appInfo.Next = IntPtr.Zero;
appInfo.ApplicationName = "test";
appInfo.ApplicationVersion = 1;
appInfo.EngineName = "test";
appInfo.EngineVersion = 1;
appInfo.ApiVersion = ((1 << 22) | (0 << 12) | (3));
InstanceCreateInfo instInfo = new InstanceCreateInfo();
instInfo.Type = VkStructureType.StructureTypeInstanceCreateInfo;
instInfo.Next = IntPtr.Zero;
instInfo.Flags = 0;
instInfo.ApplicationInfo = appInfo;
instInfo.EnabledExtensionCount = 0;
instInfo.EnabledExtensionNames = IntPtr.Zero;
instInfo.EnabledLayerCount = 0;
instInfo.EnabledLayerNames = IntPtr.Zero;
IntPtr instance = IntPtr.Zero;
VkResult res;
res = Vk.CreateInstance(instInfo, null, ref instance);
uint physDevices = 0;
res = Vk.EnumeratePhysicalDevices(instance, ref physDevices, IntPtr.Zero);
IntPtr dev = Marshal.AllocHGlobal(Marshal.SizeOf(instance) * (int)physDevices);
res = Vk.EnumeratePhysicalDevices(instance, ref physDevices, dev);
uint queueCount = 0;
Vk.GetPhysicalDeviceQueueFamilyProperties(Marshal.ReadIntPtr(dev), ref queueCount, null);
IntPtr queueDev = Marshal.AllocHGlobal(Marshal.SizeOf<VkQueueFamilyProperties>());
vkGetPhysicalDeviceQueueFamilyProperties(Marshal.ReadIntPtr(dev), ref queueCount, queueDev);
QueueFamilyProperties queueProp;
for (int i = 0; i < queueCount; i++)
{
queueProp = new QueueFamilyProperties(queueDev + i * Marshal.SizeOf<VkQueueFamilyProperties>());
if (queueProp.QueueFlags.HasFlag(VkQueueFlags.QueueGraphics))
break;
}
PhysicalDeviceMemoryProperties memProp = new PhysicalDeviceMemoryProperties();
Vk.GetPhysicalDeviceMemoryProperties(Marshal.ReadIntPtr(dev), memProp);
PhysicalDeviceProperties devProp = new PhysicalDeviceProperties();
Vk.GetPhysicalDeviceProperties(Marshal.ReadIntPtr(dev), devProp);
DeviceQueueCreateInfo queueInfo = new DeviceQueueCreateInfo();
queueInfo.Type = VkStructureType.StructureTypeDeviceQueueCreateInfo;
queueInfo.Next = IntPtr.Zero;
queueInfo.QueueCount = 1;
IntPtr queuePrio = Marshal.AllocHGlobal(4);
Marshal.WriteInt32(queuePrio, (int)0.0f);
queueInfo.QueuePriorities = queuePrio;
DeviceCreateInfo deviceInfo = new DeviceCreateInfo();
deviceInfo.Type = VkStructureType.StructureTypeDeviceCreateInfo;
deviceInfo.Next = IntPtr.Zero;
deviceInfo.QueueCreateInfoCount = 1;
deviceInfo.QueueCreateInfos = queueInfo;
deviceInfo.EnabledExtensionCount = 0;
deviceInfo.EnabledExtensionNames = IntPtr.Zero;
deviceInfo.EnabledLayerCount = 0;
deviceInfo.EnabledLayerNames = IntPtr.Zero;
deviceInfo.EnabledFeatures = null;
IntPtr device = IntPtr.Zero;
res = Vk.CreateDevice(Marshal.ReadIntPtr(dev), deviceInfo, null, ref device);
return;
}
}
}
[/CODE]
Current minimal example to get a device. Next is to get lists/arrays being dealt with better.
Current wrapper:
[url]https://gist.github.com/benpye/34ecbedf5711e790d684[/url]
[QUOTE=Tamschi;49791321][...]
This should do the trick (though really, integrate that into the service wrapper): [code]class RateLimiter
{
[...]
}[/code]
[...][/QUOTE]
It seems I was a bit too sleepy while I wrote this. Here's a fixed version that doesn't unnecessarily delay returning from the rate-limited actions: [code]class RateLimiter
{
readonly SemaphoreSlim _semaphore;
readonly int _millisecondsChunkLength;
public RateLimiter(int chunkSize, int millisecondsChunkLength)
{
_semaphore = new SemaphoreSlim(chunkSize);
_millisecondsChunkLength = millisecondsChunkLength;
}
async void DelayRelease(Stopwatch stopwatch)
{
var restDelay = stopwatch.ElapsedMilliseconds - _millisecondsChunkLength;
if (restDelay > 0) { await Task.Delay((int)restDelay); }
_semaphore.Release();
}
public void Limit(Action action)
{
_semaphore.Wait();
var stopwatch = Stopwatch.StartNew();
try { action(); }
finally { DelayRelease(stopwatch); }
}
public T Limit<T>(Func<T> func)
{
_semaphore.Wait();
var stopwatch = Stopwatch.StartNew();
T result;
try { result = func(); }
finally { DelayRelease(stopwatch); }
return result;
}
public async Task LimitAsync(Func<Task> asyncAction)
{
await _semaphore.WaitAsync();
var stopwatch = Stopwatch.StartNew();
try { await asyncAction(); }
finally { DelayRelease(stopwatch); }
}
public async Task<T> LimitAsync<T>(Func<Task<T>> asyncFunc)
{
await _semaphore.WaitAsync();
var stopwatch = Stopwatch.StartNew();
T result;
try { result = await asyncFunc(); }
finally { DelayRelease(stopwatch); }
return result;
}
}[/code]
This is also a good example for the use of [I]async void[/I]: You should (only!) use it if you never examine the result.
[URL="https://msdn.microsoft.com/en-us/library/dd997415%28v=vs.110%29.aspx"]Most exceptions from [I]async void[/I] methods bring down the application by default[/URL], so be sure you really don't need any other error handling if you use them.
[QUOTE=Darwin226;49793494]Now you wouldn't. You'd write [code]var t = await DoAsync();[/code] and await would actually start the execution. Basically, the semantics I'm thinking of would fork the async method to another thread (or take a thread from a pool) and yield the current thread back to the scheduler.[/QUOTE]
That was a bad example on my part. It's somewhat common to start [I]Task[/I]s at one point and await them at another, especially if IO is concerned.
(The compiler can't reorder the calls automatically since none of the APIs involved are guaranteed to be pure.)
[QUOTE]Yes, you're right. My bad.
All in all what you're saying is that Task simply isn't the abstraction that I want it to be. In fact I'd say that a simple `Func<T>` is much closer to what I want than `Task<T>` is.
Fair enough.[/QUOTE]
Right, [I]Func<T>[/I] or especially [URL="https://msdn.microsoft.com/en-us/library/dd642331%28v=vs.110%29.aspx"][I]Lazy<T>[/I][/URL] are much better matches for your Haskell construct.
Both [I]Func<Task<T>>[/I] and especially [I]Lazy<Task<T>>[/I] (so the code can't run twice by accident) would be sensible to use here too though, since that way you could rely on network interrupts to update your (presumably) UI instead of blocking a system thread for each network request and dispatching them back to the main thread manually. This is most likely faster especially on slow connections, if the server supports concurrent requests.
[QUOTE=Fourier;49791012]Just do it and let the market/people decide.. if they wish to donate, they will.[/QUOTE]
OK, I added it: [QUOTE=Tamschi;49789434][...]
([editline]edit[/editline] If you enjoyed this post, please consider chipping in a little [URL="paypal.me/Tamme"]over here[/URL].)[/QUOTE]
None of the normal links or buttons have compatible ToS, but the paypal.me links seem to be OK. (Having an uncommon name is pretty nice sometimes.)
Let's hope they don't make a fuss about me setting it to "friends and family". I don't have any products or services to offer, but it's Paypal so you never know what they'll do.
Still, I feel really conflicted about doing this :s:
As someone who really strongly separates work and free-time, mixing the two in any way doesn't sit well with me at all.
very nice, what's it made in?
sometimes the camera movement is a little janky, could use some interpolating.
[QUOTE=Sam Za Nemesis;49795954]I'm using Source, I'll try to interpolate the camera movement a little bit more for lower FPS (It's awful right now), without recording at a vsync speed it's completely jitterless[/QUOTE]
Oh god, for a moment i thought what kind of shitty camera replacement mod for Witcher 3 that was until i noticed it's a totally separate game. You fooled me.
-
-snip-
[QUOTE=jonnopon3000;49797324]stuff[/QUOTE]
I don't know man, I would agree that composing is better than inheriting.
[QUOTE=WTF Nuke;49797437]I don't know man, I would agree that composing is better than inheriting.[/QUOTE]
it really depends on how the Universe class behaved. If it used the Canvas as a tool to do its job then composing is better, but if it was just a "wrapper" around its Canvas object, you should probably inherit.
[CODE]using System;
using System.Runtime.InteropServices;
using Vulkan;
namespace vktest
{
class Program
{
static void Main(string[] args)
{
ApplicationInfo appInfo = new ApplicationInfo();
appInfo.ApplicationName = "test";
appInfo.ApplicationVersion = 1;
appInfo.EngineName = "test";
appInfo.EngineVersion = 1;
appInfo.ApiVersion = ((1 << 22) | (0 << 12) | (3));
InstanceCreateInfo instInfo = new InstanceCreateInfo();
instInfo.Flags = 0;
instInfo.ApplicationInfo = appInfo;
instInfo.EnabledExtensionCount = 0;
instInfo.EnabledExtensionNames = IntPtr.Zero;
instInfo.EnabledLayerCount = 0;
instInfo.EnabledLayerNames = IntPtr.Zero;
Instance instance = new Instance();
Result res;
res = Vk.CreateInstance(instInfo, null, ref instance);
uint noPhysDevices = 0;
res = Vk.EnumeratePhysicalDevices(instance, ref noPhysDevices, null);
PhysicalDevice[] physDevices = new PhysicalDevice[noPhysDevices];
res = Vk.EnumeratePhysicalDevices(instance, ref noPhysDevices, physDevices);
uint queueCount = 0;
Vk.GetPhysicalDeviceQueueFamilyProperties(physDevices[0], ref queueCount, null);
VkQueueFamilyProperties[] queueProps = new VkQueueFamilyProperties[queueCount];
Vk.GetPhysicalDeviceQueueFamilyProperties(physDevices[0], ref queueCount, queueProps);
for(int i = 0; i < queueCount; i++)
{
var queueProp = new QueueFamilyProperties(queueProps[i]);
if (queueProp.QueueFlags.HasFlag(QueueFlags.QueueGraphics))
break;
}
PhysicalDeviceMemoryProperties memProp = new PhysicalDeviceMemoryProperties();
Vk.GetPhysicalDeviceMemoryProperties(physDevices[0], memProp);
PhysicalDeviceProperties devProp = new PhysicalDeviceProperties();
Vk.GetPhysicalDeviceProperties(physDevices[0], devProp);
DeviceQueueCreateInfo queueInfo = new DeviceQueueCreateInfo();
queueInfo.QueueCount = 1;
IntPtr queuePrio = Marshal.AllocHGlobal(4);
Marshal.WriteInt32(queuePrio, (int)0.0f);
queueInfo.QueuePriorities = queuePrio;
DeviceCreateInfo deviceInfo = new DeviceCreateInfo();
deviceInfo.QueueCreateInfoCount = 1;
deviceInfo.QueueCreateInfos = queueInfo;
deviceInfo.EnabledExtensionCount = 0;
deviceInfo.EnabledExtensionNames = IntPtr.Zero;
deviceInfo.EnabledLayerCount = 0;
deviceInfo.EnabledLayerNames = IntPtr.Zero;
deviceInfo.EnabledFeatures = null;
var device = new Device();
res = Vk.CreateDevice(physDevices[0], deviceInfo, null, ref device);
return;
}
}
}
[/CODE]
Almost usable bindings, just need to handle arrays in structs and arrays of structs/unions rather than handles in functions (hence creating the wrapper type myself there). Also should really create wrappers that use the array to get the length, rather than having to pass the length and the array.
Also, don't suppose anyone knows how I could go about solving this, without it being slow: [url]https://gist.github.com/benpye/9fc7b22b3aafae509c40[/url]
[QUOTE=Handsome Matt;49797889]you're allocating memory, filling it and then copying it to another new allocation of memory? why not just allocate once and fill directly to it?
[editline]asdasd[/editline]
you're also leaking memory by not using FreeHGlobal[/QUOTE]
Yeah I am aware, that's just to get that point across. In my actual code all memory should be freed. How would I fill directly to it, if there is a way that interop can do that I am not aware of it?
[QUOTE=ben1066;49798064]Yeah I am aware, that's just to get that point across. In my actual code all memory should be freed. How would I fill directly to it, if there is a way that interop can do that I am not aware of it?[/QUOTE]
You can pin the array and then get its address.
[code]var arr = new Handle[4];
var handle = GCHandle.Alloc(arr, GCHandleType.Pinned);
var ptr = handle.AddrOfPinnedObject();
FillsMemory(ptr);
handle.Free();[/code]
[QUOTE=ben1066;49798064]Yeah I am aware, that's just to get that point across. In my actual code all memory should be freed. How would I fill directly to it, if there is a way that interop can do that I am not aware of it?[/QUOTE]
You can pin the array using a [URL="https://msdn.microsoft.com/en-us/library/f58wzh21.aspx"][I]fixed[/I][/URL] block, which gives you a native pointer to the first element.
This only works with either built-in simple types or [I]struct[/I]s marked with [I][StructLayout(LayoutKind.Sequential)][/I] or [I][StructLayout(LayoutKind.Explicit)][/I], since other types can't be marshalled in-place.
[QUOTE=ThePuska;49798100]You can pin the array and then get its address.
[code]var arr = new Handle[4];
var handle = GCHandle.Alloc(arr, GCHandleType.Pinned);
var ptr = handle.AddrOfPinnedObject();
FillsMemory(ptr);
handle.Free();[/code][/QUOTE]
There's another good option if the memory is only needed inside the current call and you know the size beforehand: [URL="https://msdn.microsoft.com/en-us/library/cx9s2sy4.aspx"][I]stackalloc[/I][/URL]
With this you can directly allocate some memory outside any heap, which makes it pretty much free aside from the space it takes. Just don't make it [I]huge[/I] or the stack will overflow.
[QUOTE=Handsome Matt;49797872]that was very rude..[/QUOTE]
Well i am sorry if that came out rude. I wanted to say i thought it was a mod at first and was pleasantly surprised when i realized it isn't. The "shitty" was because i thought the original camera for Witcher 3 was just fine and basically the same as what he did and i saw no point in replicating it.
[editline]23rd February 2016[/editline]
What i'm trying to say is if you manage to fool somebody into thinking it's a totally different thing, you're doing a hell of a job. I'm shit at words.
[QUOTE=Darwin226;49793494]Now you wouldn't. You'd write [code]var t = await DoAsync();[/code] and await would actually start the execution. Basically, the semantics I'm thinking of would fork the async method to another thread (or take a thread from a pool) and yield the current thread back to the scheduler.
[...][/QUOTE]
I thought about this some more and there's actually a really convenient way to add this behaviour if you really want it: [code]public static TaskAwaiter GetAwaiter(this Lazy<Task> lazyTask) => lazyTask.Value.GetAwaiter();
public static TaskAwaiter<T> GetAwaiter<T>(this Lazy<Task<T>> lazyTask) => lazyTask.Value.GetAwaiter();[/code]
This makes any [I]Lazy<Task>[/I] or [I]Lazy<Task<>>[/I] directly awaitable, so you can write [code]var lazyTask = new Lazy<Task>(() => DoAsync());
var lazyTrueTask = new Lazy<Task<bool>>(() => TrueAsync());
await lazyTask; // Starts execution and then waits for the Task to finish.
var result = await lazyTrueTask; // Starts execution and then awaits the result.[/code].
If you combine it with the rate limiter that turns into [code]images.Select(image => new Lazy<Task>(() => limiterA.LimitAsync(() => limiterB.LimitAsync(() => UploadImageAsync(image)))))[/code], or [code]images.Select(image => new Lazy<Task>(() => UploadImageAsync(image)))[/code] if you integrate the rate limiting into the API. Your problem probably isn't quite the right use case for this though, unless you have it hooked up directly to a paginated GUI showing the results of those requests only as needed.
Wow that is neat! Didn't know you could extend what's awaitable.
[QUOTE=Darwin226;49798586]Wow that is neat! Didn't know you could extend what's awaitable.[/QUOTE]
A few APIs targeted by C# are duck-typed, others are LINQ comprehension syntax queries and [URL="http://stackoverflow.com/questions/6368967/duck-typing-in-the-c-sharp-compiler"]foreach loops[/URL] for example. [URL="http://blogs.msdn.com/b/pfxteam/archive/2011/01/13/10115642.aspx"]Here's a blog post about the awaitable pattern.[/URL]
(Note that both the LINQ and awaitable patterns support extension methods while the foreach pattern doesn't.)
Fully implementing the awaitable pattern ([URL="http://blogs.msdn.com/b/pfxteam/archive/2012/06/15/executioncontext-vs-synchronizationcontext.aspx"]with all the [I]ExecutionContext[/I] and [I]SynchronizationContext[/I] stuff you're supposed to handle[/URL]) is a little complicated, but you can often get away with a partial implementation or simple forwarding like I did above.
[I]async[/I] methods do this automatically as part of their state machine set-up, but since custom endpoints have to (or rather: [I]should[/I]) do this manually you can make awaitables that move your current method elsewhere: [code]async void GuiEventHandler()
{
// Gather input.
await Sync.Background;
// Do long-running calculations.
await Sync.GUI;
// Display results.
}[/code]
[I]SynchronizationContext[/I] actually had an awaitable [I].SwitchTo()[/I] method in the async CTP if I'm not mistaken, though the framework designers thought it was a bad idea and removed it.
You can easily implement a similar API with a custom awaiter that forwards the continuation though: [code]public struct SynchronizationContextAwaiter : ICriticalNotifyCompletion
{
readonly SynchronizationContext _target;
public SynchronizationContextAwaiter(SynchronizationContext target)
{ _target = target; }
public void OnCompleted(Action continuation) { throw new NotSupportedException("This method needs to flow the ExecutionContext manually when called, but with ICriticalNotifyCompletion, UnsafeOnCompleted and a modern compiler consuming the API it's never used."); }
public void UnsafeOnCompleted(Action continuation) => _target.Post(c => ((Action)c)(), continuation);
public void GetResult() { /* Do nothing. */ }
public bool IsCompleted => SynchronizationContext.Current == _target;
}
public static SynchronizationContextAwaiter GetAwaiter(this SynchronizationContext context) => new SynchronizationContextAwaiter(context);[/code]
[QUOTE=chimitos;49793306][IMG]http://i.imgur.com/EM3cOuN.gif[/IMG]
Primitive based thermometer HP bar.
I [I]finally[/I] understand element placement for complicated GUI components :v:[/QUOTE]
[QUOTE=Asgard;49793411]Share your secret, please![/QUOTE]
This was built in Unity, so there are a few geometry assumptions:
- All primitives are unit width and height, (1x1)
- All geometries are centered on the object.
-- To center over a point just place the object at that point's coordinate. To place an object to the right of a point place it at (pX + 0.5, pY)
- Child objects are multiplied by their parent's scale and their translation origin point is the center of the parent object.
[I]What all that means:[/I]
- Make a parent object
-- Define the entire GUI element's size and position by positioning and scaling this object to its pixel size and position.
- Decide which primitives you need to visually make up the GUI element.
-- Make all of these objects children of the parent and pass it their references.
- Position and scale from outside elements to inside elements
-- Use "percent parent" scale to define the size of the children elements.
-- For heights, use parent percent height directly. Half of the parent size is 0.5, a fourth is 0.25, etc.
-- For widths, use either parent percent width or [B]f[/B][B]or the width of elements that need to be scaled to the same pixel width and height, multiply or divide by the ratio (EntireGuiPixelsY/EntireGuiPixelsX) to reverse the parent transform and get the child element back into the same relative scale.[/B] (this is the least obvious part so it's bolded)
-- Use bounding boxes to literally work outside to inside and define the inner elements by using percent scales of outer elements to define inner element sizes and positions.
The main thing to remember is that you aren't using pixels anymore, but centered percents. Left is -0.5, Right is 0.5, Bottom is -0.5, Top is 0.5. You need to logic out which larger element position or size will define the smaller elements properties. It's also handy to remember that you can place something on the left of an element by using that element's Y, then it's X+Width/2
[IMG]http://i.imgur.com/sxrrU3Q.png[/IMG]
In this example:
- Size and position of HpBar is defined by pixels in screenspace.
- Height of the inner bar is a percentage in HpBar, the height of the pull-tab is 1 minus that percentage.
- Inner green highlighted area is the base for the actual bar elements.
- Outer bulb is defined as a percent height of the green area, the width is that percent height multiplied by our scalar.
- Inner bulb size is 80% of the outer bulb size.
- Height of the inner bar is the height of the outer bar minus the difference between the outer bulb height and the inner bulb height
snip
Hello this is nvidia. Yes we know our platform doesn't support 3d image writes, so what we're going to do is define in our opencl compiler that we support image 3d writes, in direct contradiction to the khronos page in 3d image write support
If this seems like madness to you, then we're going to throw a cryptic ptx assembler error message which returns literally 0 results on the internet (invalid image type in sust.) relating to output of the frontend emitting invalid ptx assembly for this platform, and the assembler disliking this. You want line numbers of where this error came from, in your 10k line long opencl file? Ha ha, citizen pick up that can
Thankfully they have the decency to have not defined this in their extension string
On the plus side, my game now works on old platforms.
Here's a man made of tophats for your patience:
[IMG]https://dl.dropboxusercontent.com/u/9317774/tophats.PNG[/IMG]
Maybe I should give up on digital holography and start making visuals for Goa trance parties :v:
[vid]https://dl.dropboxusercontent.com/u/17216535/ShareX/2016/02/2016-02-23_23-20-45.mp4[/vid]
Those corners shouldn't be there, neither the diagonal movement or the satanistic circles in the centre.
This is a continuation off of my last post a few pages ago.
[b]New Dungeon, New Weapon (Chance loot from this Dungeon) & New Artifact:[/b]
[img]http://i.imgur.com/2nU3dPE.png[/img]
[b]Enemy Health Bar & New Artifact[/b]
[img]http://i.imgur.com/2wkdEfW.png[/img]
[b]New Town (Entrance) & New Artifact:[/b]
[img]http://i.imgur.com/whijJ6x.png[/img]
Is anyone prepping for March yet?
[QUOTE=Jazz84;49800891]This is a continuation off of my last post a few pages ago.
[b]New Dungeon, New Weapon (Chance loot from this Dungeon) & New Artifact:[/b]
[img]http://i.imgur.com/2nU3dPE.png[/img]
[b]Enemy Health Bar & New Artifact[/b]
[img]http://i.imgur.com/2wkdEfW.png[/img]
[b]New Town (Entrance) & New Artifact:[/b]
[img]http://i.imgur.com/whijJ6x.png[/img][/QUOTE]
You should post this to Doomworld if you haven't already.
[t]http://i.imgur.com/HdgcN5p.png[/t]
wrote a ui for my game. I totally didn't rip this off minimalist lines theme from something I saw online. nope.
[QUOTE=elevate;49801416]You should post this to Doomworld if you haven't already.[/QUOTE]
I did awhile back but even with updates since people wouldn't play it for awhile people stopped caring so I stopped updating the topic.
So I'm in a bit of a pickle. I'm not sure how to proceed from this point. I really, really like [url=https://doc.rust-lang.org/book/enums.html]Rust's enums[/url], and I want to include that in my language. However, I'm having a bit of difficulty determining the syntax. Essentially, given the following module, how should the elements of the enum be accessed?
[code]
:import Carbon.
defmodule Color.
defenum do
Red;
Green;
Blue;
Other(Integer, Integer, Integer);
end.
[/code]
The way Rust does it is this, so [img]https://facepunch.com/fp/ratings/heart.png[/img] for this syntax:
[code]
Color::Other(1, 2, 3);
[/code]
The problem with this syntax is that Carbon uses the "::" syntax to scope modules (not functions, like Rust). That means that you would not be able to define modules under "Color" (or, at least, modules named "Red", "Green", "Blue", or "Other"). Not sure how I feel about this, since modules should start with an uppercase letter.
I think Swift does something similar to this, so [img]https://facepunch.com/fp/ratings/zing.png[/img] for this syntax:
[code]
Color.Other(1,2,3);
[/code]
The problem with this syntax is that Carbon uses the "." syntax to scope functions. This means that you would not be able to define functions named "Red", "Green", "Blue", or "Other", but most functions are going to start with a lowercase letter. However, it doesn't really make that much sense to begin with - is "Other" a function or a variable?
Also, I'm unsure of how I want to handle accessing struct fields, but that's a topic for a different time.
[QUOTE=PelPix123;49803338]over the past year or so i've been working on a new way to do VR audio. no captured HRTF, no traditional HRTF at all. fuses the fidelity advantages of raw 3d audio stereo mixdown with the positioning advantages of a HRTF. It doesn't have any of the weird drawbacks of HRTF like audible phase distortion and doing weird things to the FR.
Can you listen to this on headphones? I'm trying to get distance down:
[vid]http://www.pelpix.info/distance.mp3[/vid
you should hear still alive DIRECTLY to your left, starting a few feet away from you and getting further away, then getting closer, then really close, then farther
Early reflections aren't required for the technique, but I included them here cuz it sounds nice.
Alternate version that attempts to cancel out sound passing impossibly through the head to the wrong ear:
[vid]http://www.pelpix.info/distance2.mp3[/vid[/QUOTE]
It definitely worked, but I find it hard to orient myself in complete silence other than the song. Can you put in some ambient noise? Maybe a binaural recording if omnidirectional sounds are hard to pull off.
Have you guys seen boost-experimental dependency injector? This shit is basically witchcraft and magic on steroids. Just take a look at the tutorial, like holy hell how does someone go about writing a library like this? [url]http://boost-experimental.github.io/di/tutorial/index.html[/url]
Sorry, you need to Log In to post a reply to this thread.