What Are You Working On? September 2015

[brianosaur]

Well, I've been reading Clean Code by Bob Martin, and he lays out three laws for TDD:

1. You may not write production code until you have written a failing unit test.
2. You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
3. You may not write more production code than is sufficient to pass the currently failing test.

When I say doing TDD the right way, following these rules is what I really mean.

[NoRegard]

TDD is only good if you know that your project is going to be big. For small projects it's really overkill.
also no idea how to apply TDD, or just testing in general, when working with Unity projects.

[profan]

[QUOTE=BackwardSpy;48674611]TDD (and agile development in general) is pretty great. As far as I'm concerned, it's the 'right' way to write code now.[/QUOTE]

I'd say TDD has it's place, but to say it's the "right" way is approaching cargo-culting, you should [I]always[/I] try to be critical of the methods you apply.

[Хум]

This is nowhere near the quality of most things I see here, but I've been messing around with JSFML, trying to see what I can do.

This is what I got so far:
[IMG]https://dl.dropboxusercontent.com/u/46283290/screenshot1.png[/IMG]

[ben1066]

[QUOTE=Profanwolf;48674712]I'd say TDD has it's place, but to say it's the "right" way is approaching cargo-culting, you [I]always[/I] try to be critical of the methods you apply.[/QUOTE]

Unless you have perfect tests too, you only know if something is wrong, you can't be certain everything is right. There is always a chance you missed something in your tests.

[icantread49]

[QUOTE=takua108;48674216]

  std::vector<Foo *> foos = std::vector<Foo>();
  foos.push_back(new Foo(0));
  foos.push_back(new Foo(1));
  foos.push_back(new Foo(2));

  Foo::Handle bestFoo = foos[2];

  // swap-n-pop vector item removal
  std::swap(foos[1], foos.back());
  foos.pop_back();

  for (int i = 0; i < foos.size(); ++i)
    foos[i].UpdateHandles(foos[i]);

The point is to make Handles you can pass around that will be valid even if the thing they point at moves (assuming you remember to call UpdateHandles() after moving it!). Also they'll be [I]invalid[/I] after the thing is destroyed (assuming you remember to call InvalidateHandles() when destroying!).
[/QUOTE]

Not sure if this makes any sense. What's wrong with:

  std::vector<Foo *> foos = std::vector<Foo>();
  foos.push_back(new Foo(0));
  foos.push_back(new Foo(1));
  foos.push_back(new Foo(2));

  Foo* bestFoo = foos[2];

  // swap-n-pop vector item removal
  std::swap(foos[1], foos.back());
  foos.pop_back();

  // bestFoo is still the right foo - its position in the vector doesn't matter

  // btw, there's a memory leak here

[backwardspy]

[QUOTE=brianosaur;48674663]Well, I've been reading Clean Code by Bob Martin, and he lays out three laws for TDD:

1. You may not write production code until you have written a failing unit test.
2. You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
3. You may not write more production code than is sufficient to pass the currently failing test.

When I say doing TDD the right way, following these rules is what I really mean.[/QUOTE]
Clean Code and The Clean Coder are both excellent books! I think I've recommended them in here before.
I really can't stress enough the improvement that comes to both your programming ability and your performance as a professional if you read and take in what he has to say in those books.

[editline]13th September 2015[/editline]

[QUOTE=Profanwolf;48674712]I'd say TDD has it's place, but to say it's the "right" way is approaching cargo-culting, you [I]always[/I] try to be critical of the methods you apply.[/QUOTE]
Of course, I don't say it lightly. From my experiences, it is the method that results in me having higher productivity and better code for the jobs I do with it.
What I meant by 'as far as I'm concerned' is that for me personally it is the 'right' way to do it, I'm not saying it's necessarily right for everyone, or every project!

[editline]13th September 2015[/editline]

At the very least, it's worth knowing at least some of how to do these things. Agile methodologies in general are becoming fairly popular in the industry, so if you plan to go into a professional programming job at any point then you may very well end up learning it anyway.

[AntonioR]

I was generating the graph for pathfinding by triangulating the navigation mesh. Every vertex of the mesh was one node, and the edges of the resulting triangles would be used to connect the nodes.

If you remove the nodes on the "convex" vertices of the outer shell of the mesh, and nodes on the "concave" vertices from the holes of the mesh, you can get an optimized graph, since shortest path will never go trough those nodes.

[quote]
Before: 882 nodes, 3522 connections
[img]http://i.imgur.com/3F5tOXQ.png[/img]

After: 439 nodes, 1226 connections
[img]http://i.imgur.com/kFG7QFF.png[/img]
[/quote]

Sorry if you are colorblind.

[Karmah]

Still working on cubemaps. Took me all yesterday and up till now to actually get the engine to successfully build a cubemap texture from a node on command. The rendering part was easy, but actually getting the texture information out of the framebuffer somehow took me around 16 hours to figure out.

Turns out I forgot just how bad cubemaps look when they are taken in a scene and used on large surfaces :v:
It should be alright though when used sensibly and limited to small regions and are used in high numbers.

I just need to optimize my code and fix a few more things, then Ill make a more detailed post about it later.

[Tamschi]

[QUOTE=BackwardSpy;48675120][...] Agile methodologies in general are becoming fairly popular in the industry, so if you plan to go into a professional programming job at any point then you may very well end up learning it anyway.[/QUOTE]

I'd rather get a dictionary that translates all the buzzwords into plain English :v:

In all seriousness though, if these "new methods" just used plain handles for what they do there wouldn't even be a need for an explanation, considering not much of it seems really unheard of.

[Berkin]

[QUOTE=JohanGS;48673149]The former.[/QUOTE]

I'm going to keep updating it until I either run out of ideas or die.

[takua108]

[QUOTE=icantread49;48675066]Not sure if this makes any sense. What's wrong with:

  std::vector<Foo *> foos = std::vector<Foo>();
  foos.push_back(new Foo(0));
  foos.push_back(new Foo(1));
  foos.push_back(new Foo(2));

  Foo* bestFoo = foos[2];

  // swap-n-pop vector item removal
  std::swap(foos[1], foos.back());
  foos.pop_back();

  // bestFoo is still the right foo - its position in the vector doesn't matter

  // btw, there's a memory leak here

[/QUOTE]

That wasn't the greatest example, and yeah, I forgot to call "delete" in it.

The idea is that, because I'm using my own memory manager ([url=https://github.com/adamrezich/InfiniteBonus/blob/master/Kuma/Allocator.h]Allocator.h[/url] | [url=https://github.com/adamrezich/InfiniteBonus/blob/master/Kuma/Allocator.cpp]Allocator.cpp[/url]), stuff isn't always going to stay in the same place. (It does right for now, but it might not later on.) Especially when scripted Components are going to want to store references to Entitys.

(Allocator in use: [url=https://github.com/adamrezich/InfiniteBonus/blob/master/Kuma/Game.cpp#L238]Example A[/url] | [url=https://github.com/adamrezich/InfiniteBonus/blob/master/Kuma/Component.h#L236]Example B[/url])

Like, say I make a scripted Component (again, there's no scripting implemented yet) that, like, instantiates an Entity, and then stores a reference to it for later use. Other than storing its unique id and looking it up every time you want to use it (the id lookup table isn't implemented yet also), there wouldn't be a way to do this without Handles, because like I said, stuff can move around (so plain ol' pointers aren't good enough).

---

Speaking of scripting, I've now [url=https://github.com/adamrezich/InfiniteBonus/blob/master/docs/API.pdf]begun outlining the API docs for the engine[/url]. I still haven't decided on which scripting language to use; any suggestions? Like I mentioned in an earlier post, the team I was on used JavaScript in our last project by interfacing with V8, and it was [url=http://stackoverflow.com/questions/26576312/how-to-link-required-libraries-to-use-google-v8-in-visual-studio-c-project/26578067#26578067]A COMPLETE AND TOTAL NIGHTMARE[/url]. I'm not opposed to giving it another go, potentially with a different engine, but I'm also open to trying out different scripting languages. Maybe Lua? I haven't touched Lua since making Gmod gamemodes like six years ago. [B]Any other suggestions? Especially specific implementations?[/B] Or just rate me dumb I guess? :P

[nixnax123]

Got my raycasting algorithm optimized a little:

[vid]https://my.mixtape.moe/xbgsgu.mp4[/vid]

Now, this used to be a constant 108 hits throughout the scene. But now it factors in only segments that are visible from the light source.

So, in the worst case, I reduced the number of hits in a scene with 8 blocks by 36.
In the best case, I reduced that by 96.

I need to find a way to reduce them even more though... right now, I still calculate 3 intersections per point.

[Darwin226]

[QUOTE=Tamschi;48675259]I'd rather get a dictionary that translates all the buzzwords into plain English :v:

In all seriousness though, if these "new methods" just used plain handles for what they do there wouldn't even be a need for an explanation, considering not much of it seems really unheard of.[/QUOTE]

Don't even get me started on design patterns. Recently I was showing my setters to a coworker and said "the setter function just wraps my object so I can call my methods on it" to which be replies "so, a decorator". Why would something so trivial have a name? Is 'a wrapper' really not descriptive enough? Saying it's a decorator adds NO extra context. The only thing it does is potentially confuse those not familiar with it.

[thatbooisaspy]

[vid]https://dl.dropboxusercontent.com/u/357850863/ShareX/2015/09/2015-09-13_15-20-17.mp4[/vid]
So close but yet so far :suicide:

[Berkin]

[QUOTE=thatbooisaspy;48675581][vid]https://dl.dropboxusercontent.com/u/357850863/ShareX/2015/09/2015-09-13_15-20-17.mp4[/vid]
So close but yet so far :suicide:[/QUOTE]

Is this the world's first fighting game between intersected coplanar surfaces?

[thatbooisaspy]

[QUOTE=Berkin;48675640]Is this the world's first fighting game between intersected coplanar surfaces?[/QUOTE]

I wish, more like a fighting game between textures.

[profan]

[QUOTE=Darwin226;48675580]Don't even get me started on design patterns. Recently I was showing my setters to a coworker and said "the setter function just wraps my object so I can call my methods on it" to which be replies "so, a decorator". Why would something so trivial have a name? Is 'a wrapper' really not descriptive enough? Saying it's a decorator adds NO extra context. The only thing it does is potentially confuse those not familiar with it.[/QUOTE]

snip, I misread :v:

I'll agree that much of the design pattern stuff just feels overly convoluted though, many different names for the same concepts, or just naming things which are sort of silly to name at all.
Just look at the strange articles on OOP design patterns where people say things like "If you're not using dependency injection, you're not a real OOP programmer!" or "IOC Containers!!".

Wee, cargo culting!

[No_0ne]

[img]http://i.imgur.com/M6KcgMa.gif[/img]

delicious chest turkey

[backwardspy]

[QUOTE=Tamschi;48675259]I'd rather get a dictionary that translates all the buzzwords into plain English :v:

In all seriousness though, if these "new methods" just used plain handles for what they do there wouldn't even be a need for an explanation, considering not much of it seems really unheard of.[/QUOTE]
That's fair in some cases, in the context of TDD though I think it makes sense that it has its own name. Like most development methodologies (not that TDD is strictly a methodology, because it's not) the name covers a fairly specific method for working on a project that is different to other processes.
I do agree that there are plenty of things in the field of computer science that are given names for seemingly no reason other than to sound like you know more than everyone else. There's a fine line between useful naming of a process and confusing the situation more than necessary.

[Lenny.]

It adds so much code tho, it's cmake all over again

[NoRegard]

warning, video is 12 mb!
- added mana
- added player colours
- added hammer
- added ability to change weapons
- not pictured, added a simple main menu.
- added kd ratio (topleft)
[vid]https://a.pomf.cat/ogjqov.mp4[/vid]

also in the video, a really strange bug where the player suddenly turns invisible (no sprite).
when respawning, he's visible again.

[backwardspy]

I haven't posted content in here in forever. I can't really post most of what I'm working on at the moment, but I did just hit a little milestone with one of my smaller hobby projects.
A bit late to the party, I know, but I am making an assembler and emulator for the DCPU-16 instruction set and architecture. It's been a pretty interesting project so far, and a few minutes ago I had it successfully run some example code!
[t]http://vgy.me/qW0QLE.png[/t]
The spam on the left shows a small portion of video memory (specifically, the part where the example program pokes its 'Hello, world!' message), as well as the states of all the registers in the CPU. As you can see, it worked! I still have a large portion of the instruction set to implement, but seeing progress like this is highly motivating.

[proboardslol]

[quote]by Markus Persson[/quote]

:what:

[backwardspy]

[QUOTE=proboardslol;48676774]:what:[/QUOTE]
DCPU-16 is a virtual processor used in the game 0x10c, created by Notch. The game was unfortunately abandoned, but the architecture remains an interesting emulation project.

[sidneys1]

It's really sad that that project went down the drain because of his fame. He felt too pressured to succeed to continue. :(

[backwardspy]

[QUOTE=Sidneys1;48676907]It's really sad that that project went down the drain because of his fame. He felt too pressured to succeed to continue. :([/QUOTE]
Yeah. I can't imagine how much it must suck to have the fun taken out of your hobby projects because of something like that.
I would have enjoyed playing a game like 0x10c. There was supposed to be a fan remake going on at some point, I wonder how that's getting on.

[MatheusMCardoso]

[QUOTE=BackwardSpy;48676914]There was supposed to be a fan remake[/QUOTE]

I think you would call it a fan make.

:vs:

[Flyguy]

Here's some stuff I made messing around GLSL shaders over the past few months. (Click the link below them to see the animated/interactive versions)

Ray marched mesh terrain:
[thumb]http://i.imgur.com/1j6DZDw.png[/thumb]
[url]https://www.shadertoy.com/view/ltjSRD[/url]

16-Segment display:
[thumb]http://i.imgur.com/jjn0XGM.png[/thumb]
[url]https://www.shadertoy.com/view/ltfXD2[/url]

Ray marched non-Euclidean geometry:
[thumb]http://i.imgur.com/E3vpTVu.png[/thumb]
[url]https://www.shadertoy.com/view/4llSWf[/url]

Distance field based text:
[thumb]http://i.imgur.com/pCK0zcR.png[/thumb]
[url]https://www.shadertoy.com/view/4lsSzX[/url]

Twisted ring:
[thumb]http://i.imgur.com/gmjYbhV.png[/thumb]
[url]https://www.shadertoy.com/view/Xt23z3[/url]

Ray marching with dithered palette shading:
[thumb]http://i.imgur.com/mrLhSAY.png[/thumb]
[url]https://www.shadertoy.com/view/MtjGRd[/url]

[Berkin]

[QUOTE=Flyguy13;48677079]
Twisted ring:
[thumb]http://i.imgur.com/gmjYbhV.png[/thumb]
[url]https://www.shadertoy.com/view/Xt23z3[/url][/QUOTE]

This one is incredibly satisfying to watch.