What are you working on? - Developers

[QUOTE=Ac!dL3ak;49746079]I don't know many functional languages :~)[/QUOTE] To be honest, if you want to make a language that people will actually use, you really need to be familiar with what's currently offered.

[QUOTE=jonnopon3000;49746101]Debug mode is the absolute best way for anyone to learn what a particular program is doing, and I'll fight to the death on that. My lecturers propose a lot of long-winded methods; reading precisely line-by-line; decorating code with print statements; halting program execution by returning values where not normally necessary...while these are all good methods of inspecting your program at run-time, I find it infuriating that they're not talking about debugging and breakpoints. In my opinion, all three of the aforementioned methods of understanding are superseded by breaking the code at runtime and zoning in on the areas you really need to "get." This way you can naturally read line-by-line - but in explicit execution order rather than written order to to avoid confusion - and "print" (see) variables and their values in action. I fully understand why a lecturer might encourage their students to go and [I]just read the bloody code[/I] in effort to help them understand it, but it doesn't prepare you at all for the actual requirements of a programmer, nor give you the opportunity to use the tools that every other programmer uses. Probably waffled off-topic, just needed that off my chest. [I]University is seriously disappointing me[/I][/QUOTE] Oh no it's hella useful for that. I meant if you're writing say a game, don't judge the performance by how it does in debug mode. A much better metric is release mode. Like if you're working on your own software, optimizing for debug mode is an awful idea. Sorry I phrased it fully, haven't slept for about a day.

[QUOTE=WTF Nuke;49746122]Oh no it's hella useful for that. I meant if you're writing say a game, don't judge the performance by how it does in debug mode. A much better metric is release mode. Like if you're working on your own software, optimizing for debug mode is an awful idea. Sorry I phrased it fully, haven't slept for about a day.[/QUOTE] You're forgiven, and your point is solid. I'm equally tired; I think your "debug mode bad" connotation just triggered my latent frustration with all things education recently and made me rant. Feels nice to complain all the time like a proper Brit :v:

[QUOTE=jonnopon3000;49746101]Debug mode is the absolute best way for anyone to learn what a particular program is doing, and I'll fight to the death on that. My lecturers propose a lot of long-winded methods; reading precisely line-by-line; decorating code with print statements; halting program execution by returning values where not normally necessary...while these are all good methods of inspecting your program at run-time, I find it infuriating that they're not talking about debugging and breakpoints. In my opinion, all three of the aforementioned methods of understanding are superseded by breaking the code at runtime and zoning in on the areas you really need to "get." This way you can naturally read line-by-line - but in explicit execution order rather than written order to to avoid confusion - and "print" (see) variables and their values in action. I fully understand why a lecturer might encourage their students to go and [I]just read the bloody code[/I] in effort to help them understand it, but it doesn't prepare you at all for the actual requirements of a programmer, nor give you the opportunity to use the tools that every other programmer uses. Probably waffled off-topic, just needed that off my chest. [I]University is seriously disappointing me[/I][/QUOTE] It takes like 30 minutes to learn how to use the debugger yourself. Is this really something you expect professors to teach? Seriously, a lot of these "college doesn't prepare you for the real world" statements are bullshit. When you start working somewhere you'll be a rookie for about a week and after that you know everything college didn't prepare you for. Higher education is supposed to teach you things you wouldn't/couldn't/don't want to learn yourself.

[QUOTE=Darwin226;49746111]To be honest, if you want to make a language that people will actually use, you really need to be familiar with what's currently offered.[/QUOTE] I am familiar with a few programming languages; I've tried my hand at Rust, C#, Elixir, Crystal, Ruby, Perl, C, and PHP.

Isn't C# the only language that forces methods inside classes out of these?

[QUOTE=Darwin226;49746416]Isn't C# the only language that forces methods inside classes out of these?[/QUOTE] You are correct; however idiomatic Ruby says you should use classes for everything (again, see Rails, or Hanami), Crystal is the same as Ruby, PHP is PHP, Perl is Perl, Elixir is somewhat difficult to work with, and Rust and C don't have classes (and Carbon takes inspiration from them).

I swear CUDA is fucking black magic :v: I had a runtime error in some block of code, commented all of it away, then I uncommented each line until I got the runtime error again... but it never happened again. Seriously what the crap. I don't know if I should be even more worried or rather relieved. [editline]15th February 2016[/editline] Oh it seems to crash my display driver now though, at least I'm sure something is happening on the GPU I guess... [editline]15th February 2016[/editline] Fuck yis [IMG]http://i.imgur.com/s4IFMBj.jpg[/IMG] I'm back on working on my master's thesis. What you see here is a hologram recorded (of a dice) with a CCD. It's not yet reconstructed though. My plan is to have a realtime feed from that CCD, reconstruction with CUDA and visualization with openGL. Visualization is thus sort of done, reconstruction was implemented separately and the CCD driver will be supplied by my promotor (thank god, I heard it's a nightmare to get that stuff to work). I get 40 FPS now on a laptop GPU, if I get 20FPS on a meaty pc I'll be happy. I should also fix window resizing because that looks sloppy AF.

Such is GPU programming, you really don't know what the f* is happening unless you display it.

protip: you have to turn off the windows timeout thing (use Nsight) if your kernel will run for more than a few seconds.

The debugger in IAR studio is godsend for embedded programming. Timer acting weird? Pause the program, step though, and look at the individual bits in the control register. Can't tell if your interrupts are working properly? Throw a break point on it, and memory fill the counter register to hit the interrupt on the next step and take a look! Being able to look at the memory makes looking for where a single control bit gets flipped so much easier than any other method I could imagine.

So I was starting to get a little bit afraid of my obvious scope creep, and decided to give myself a small list of a few basic things that I need to get done. For starters, I needed to stop hammering out shaders and totally revamp my model system. Right now I got most of it down, however once upon a time I assumed that all modelers would use a single texture map per model, so I have to rework my system accordingly. And since I haven't posted any media in a while, here's some screenshots showing off my renderer using something other than primitive geometry; It also shows how much ambient occlusion can help a scene: (SSAO off VS on) [t]http://i.imgur.com/LE9uRL7.png[/t][t]http://i.imgur.com/3q9UQrp.png[/t] Once I fix this texturing issue, I will move on to animation.

[QUOTE=Karmah;49747636]So I was starting to get a little bit afraid of my obvious scope creep, and decided to give myself a small list of a few basic things that I need to get done. For starters, I needed to stop hammering out shaders and totally revamp my model system. Once I fix this texturing issue, I will move on to animation.[/QUOTE] Do you have some basic API examples of your engine?

[QUOTE=Asgard;49747754]Do you have some basic API examples of your engine?[/QUOTE] Idk what really to show, its mostly just a hobby project, so I haven't really thought about it. I try to keep it simple enough and compartmentalized though. Right now the engine is still in the "Rendering" Phase, although this phase is pretty closed to finished (excluding the extra niceties that I eventually want to add). The beginning of the rendering chain involves a list of [I]"Scene"[/I] 's. The engine will cycle through this list and call their render function every frame. An example of this would be one modified for rendering a desired level, the [I]SceneMap[/I], which holds my map data type and overrides the render function to perform all the rendering passes that I define within it (like lighting, shadows, hdr, etc). This basic scene class is easy to expand upon and tack onto the rendering list, say if someone wanted to write their own UI. At a more basic level, if new custom level objects are desired, they inherit from a component class. They can override methods for pushing themselves into any geometry pass, or perform any sort of post processing. If I don't die or something and the scope creep doesn't prevent me from reaching a definitive [I]first version[/I], I will eventually put it up online with some sort of documentation I guess. My ultimate goal is to make it flexible at version 1 to be usable for any future projects of mine, at least [I]in theory,[/I] in case I ever want to.

So today I had a rare moment of no homework, work or chores(well I have chores, but fuck that noise). I had a fun celebratory night last night and was left with an idea for a roguelike. I have always been a big fan of the genre and I have attempted to create them in the past without much success, usually due to a loss of interest and none of my previous attempts were built around the console. I started the project and built an immediate key board event manager thing using conio.h and now I am fumbling around how to clear the screen. I know a lot of hate gets directed at system calls, but I can't seem to find any other way to clear the screen on windows. I am looking for suggestions, cross platform solutions would be the best. Also, my @ moves around the console buffer just fine, however there is the occasional flash of an _ at the top left corner of the console. How do I get rid of that?

Evaluating my lighting with a foliage test envo. All art stolen lel [img]http://puu.sh/n9jT4.jpg[/img]

Just doodling some logo animations. [vid]https://zippy.gfycat.com/CompleteScaryElephantbeetle.webm[/vid] [vid]https://fat.gfycat.com/SharpDistortedAnkole.webm[/vid]

An example for good use of vtables (in pseudocode):[code]class Base abstract Do1() abstract Do2() abstract Do3() class ThingA : Base A data override Do1() => DoStuffWithData override Do2() => DoStuffWithData override Do3() => DoStuffWithData abstract class ThingB : Base B data override Do1() => DoStuffWithData override Do2() => DoStuffWithData abstract class ThingBC : ThingB C data override Do3() => DoStuffWithData abstract class ThingBD : ThingB D data override Do3() => DoStuffWithData[/code][code]foreach Base b in mixedCollection b.Do1 b.Do2 b.Do3[/code] This is something that isn't common in scientific computing or data processing, and in game development is [I]usually[/I] limited to exactly one case where it's too flexible for C# (but not C++). (The latter case still benefits a lot from vtables though, if used well.) However, partially shared behaviour in mixed collections is extremely common in application programming and I'd have to add additional fields to store the necessary information here. (If Ac!dL3ak's language doesn't support capturing lambdas or at least delegates I'd in fact have to use void*s, and we all know what a mess that is.) Haskell is in a pretty good position to sidestep this issue for the most part though, because it makes it relatively painless to do the necessary bootstrapping and you can then do OOP in it. On the other hand, procedural languages without inheritance like what Ac!dL3ak seems to be making are a huge pain whenever you want to dynamically routed calls that operate on different data formats.

[QUOTE=Clavus;49748424]Just doodling some logo animations. [vid]https://zippy.gfycat.com/CompleteScaryElephantbeetle.webm[/vid] [vid]https://fat.gfycat.com/SharpDistortedAnkole.webm[/vid][/QUOTE] This is awesome, do you have any resources you can share regarding this technique?

[QUOTE=Darwin226;49746076]Pretty much any vaguely functional language allows this.[/QUOTE] And every vaguely C-style one too (C++, C#, Java to [I]some[/I] extent, JS, Python and Lua if you count them... the list goes on), since they're almost all true feature supersets. The only difference is that you may have to put an extra line and a few brackets for a class where forced (C# and Java), which is a very small price to pay for the added expressiveness of those over C.

[QUOTE=Tamschi;49748521]An example for good use of vtables (in pseudocode):[code]class Base abstract Do1() abstract Do2() abstract Do3() class ThingA : Base A data override Do1() => DoStuffWithData override Do2() => DoStuffWithData override Do3() => DoStuffWithData abstract class ThingB : Base B data override Do1() => DoStuffWithData override Do2() => DoStuffWithData abstract class ThingBC : ThingB C data override Do3() => DoStuffWithData abstract class ThingBD : ThingB D data override Do3() => DoStuffWithData[/code][code]foreach Base b in mixedCollection b.Do1 b.Do2 b.Do3[/code] This is something that isn't common in scientific computing or data processing, and in game development is [I]usually[/I] limited to exactly one case where it's too flexible for C# (but not C++). (The latter case still benefits a lot from vtables though, if used well.) However, partially shared behaviour in mixed collections is extremely common in application programming and I'd have to add additional fields to store the necessary information here. (If Ac!dL3ak's language doesn't support capturing lambdas or at least delegates I'd in fact have to use void*s, and we all know what a mess that is.) Haskell is in a pretty good position to sidestep this issue for the most part though, because it makes it relatively painless to do the necessary bootstrapping and you can then do OOP in it. On the other hand, procedural languages without inheritance like what Ac!dL3ak seems to be making are a huge pain whenever you want to dynamically routed calls that operate on different data formats.[/QUOTE] Without resorting to typeclass tricks, a static version of this would be: [code] data Base = ThingA A | ThingB B Sub data Sub = Default | ThingBC C | ThingBD D do1 :: Base -> Something do1 (ThingA a) = ... do1 (ThingB b _) = ... do2 :: Base -> Something do2 (ThingA a) = ... do2 (ThingB b _) = ... do3 :: Base -> Something do3 (ThingA a) = ... do3 (ThingB b Default) = ... do3 (ThingB b (ThingBC c)) = ... do3 (ThingB b (ThingBD d)) = ... [/code] You, of course, lose the ability to extend the hierarchy outside of the module, but you get exhaustiveness checking. This isn't really a problem if you're making an application instead of a library.

[QUOTE=srobins;49748543]This is awesome, do you have any resources you can share regarding this technique?[/QUOTE] It's basically a load of cubes and tweens.

[QUOTE=Clavus;49748689]It's basically a load of cubes and tweens.[/QUOTE] I'm more confused about how you figured out where to tween them to :v: Did you write a script to map out the number of cubes and their position per-letter or something along those lines?

[QUOTE=Darwin226;49748626]Without resorting to typeclass tricks, a static version of this would be: [code] data Base = ThingA A | ThingB B Sub data Sub = Default | ThingBC C | ThingBD D do1 :: Base -> Something do1 (ThingA a) = ... do1 (ThingB b _) = ... do2 :: Base -> Something do2 (ThingA a) = ... do2 (ThingB b _) = ... do3 :: Base -> Something do3 (ThingA a) = ... do3 (ThingB b Default) = ... do3 (ThingB b (ThingBC c)) = ... do3 (ThingB b (ThingBD d)) = ... [/code] You, of course, lose the ability to extend the hierarchy outside of the module, but you get exhaustiveness checking. This isn't really a problem if you're making an application instead of a library.[/QUOTE] As I said, Haskell is in a somewhat unique position to sidestep the issue entirely (in certain circumstances). Especially the union system is a great inheritance alternative if you can list all cases exhaustively in one(?) place. This (usually) doesn't apply to mostly procedural languages without any virtual function call support and with C-like types though, which is my whole point here.

[QUOTE=srobins;49748736]I'm more confused about how you figured out where to tween them to :v: Did you write a script to map out the number of cubes and their position per-letter or something along those lines?[/QUOTE] Cubes themselves were manually positioned per letter. Then I just reverse tween them from a single point.

[img]https://my.mixtape.moe/ucqods.png[/img] [url]https://www.shadertoy.com/view/4dGGRK[/url] (Uncomment line 11 to get dithering) Added quick and dirty dithering thing after finding out that the 8x8 "noise"texture on shadertoy is in fact a bayer matrix!

[QUOTE=WTF Nuke;49746122]Oh no it's hella useful for that. I meant if you're writing say a game, don't judge the performance by how it does in debug mode. A much better metric is release mode. Like if you're working on your own software, optimizing for debug mode is an awful idea. Sorry I phrased it fully, haven't slept for about a day.[/QUOTE] It can be really awful if your code is completely unusable in debug mode, say for a game you'll likely want your code to still be debuggable. So I can definitely see the problem with code being too slow in debug mode. If your game ends up getting to the point where you literally cannot debug the thing because it's *just that bad* in debug mode, you're in for a bad time :v: Of course, it's no judge for the performance in the end, but it should be *fast enough* to actually debug it without wanting to slash your wrists. (especially as release builds compile times can blow up too) The C++ STL is an especially bad violator of the whole "a million function calls down, you find the actual implementation" thing too.

[QUOTE=johnnyaka;49738955]If you mean this post: Well, hello :v: I'm about to write how to build something like it etc. on [URL="http://blog.johnnycrazy.de/"]blog.johnnycrazy.de[/URL], but I still got no wooden-frame or anything for it (I'm more like the software guy). But I plan to release a "What-To-Buy"-part soon.[/QUOTE] I'm very interested in integrating UI to the real world, such as with this mirror. Unfortunately, I don't actually own any mirrors outside of my bathroom, and I look in one maybe once a day. This would, however, be an awesome project to do for my girlfriend who owns MANY mirrors and loves to look at herself (I don't blame her!)

[QUOTE=Tamschi;49748521]An example for good use of vtables (in pseudocode):[code]class Base abstract Do1() abstract Do2() abstract Do3() class ThingA : Base A data override Do1() => DoStuffWithData override Do2() => DoStuffWithData override Do3() => DoStuffWithData abstract class ThingB : Base B data override Do1() => DoStuffWithData override Do2() => DoStuffWithData abstract class ThingBC : ThingB C data override Do3() => DoStuffWithData abstract class ThingBD : ThingB D data override Do3() => DoStuffWithData[/code][code]foreach Base b in mixedCollection b.Do1 b.Do2 b.Do3[/code] This is something that isn't common in scientific computing or data processing, and in game development is [I]usually[/I] limited to exactly one case where it's too flexible for C# (but not C++). (The latter case still benefits a lot from vtables though, if used well.) However, partially shared behaviour in mixed collections is extremely common in application programming and I'd have to add additional fields to store the necessary information here. (If Ac!dL3ak's language doesn't support capturing lambdas or at least delegates I'd in fact have to use void*s, and we all know what a mess that is.) Haskell is in a pretty good position to sidestep this issue for the most part though, because it makes it relatively painless to do the necessary bootstrapping and you can then do OOP in it. On the other hand, procedural languages without inheritance like what Ac!dL3ak seems to be making are a huge pain whenever you want to dynamically routed calls that operate on different data formats.[/QUOTE] I'm not entirely certain what you're trying to get at; however, you will be able to define behavioral interfaces on modules (e.g. an "interface" in C# terms). In fact, one of the things I'm probably going to steal from Rust is its Trait system, which looks pretty cool. [quote](If Ac!dL3ak's language doesn't support capturing lambdas or at least delegates I'd in fact have to use void*s, and we all know what a mess that is.)[/quote] Not sure what this means, but yeah, I'll probably find a way to pass around lambdas. Unfortunately, figuring out how I'm going to do that is not at the top of my list at the moment.

Here's some chaotic system stuff I've been messing around with. Circle map ([url]https://www.shadertoy.com/view/XsVGDw[/url]) [t]http://i.imgur.com/A4c4NsN.png[/t] Peter de Jong and Clifford attractors ([url]https://www.shadertoy.com/view/Msy3Dm[/url]) Based off the images here by Paul Bourke: [url]http://paulbourke.net/fractals/clifford/[/url] [t]http://i.imgur.com/XW2ZQb9.png[/t][t]http://i.imgur.com/pkY682Y.png[/t] Lorenz attractor divergence ([url]https://www.shadertoy.com/view/Msy3R3[/url]) ([url=https://giant.gfycat.com/JaggedDentalAttwatersprairiechicken.mp4]Video[/url]) Each pixel is a Lorenz attractor with the starting position based off its screen position and the color is the current XYZ position of the attractor. [t]http://i.imgur.com/aQVwObB.png[/t]