You gotta love that singular dude defending him, too.

And this:

Jesus, you're operating under the GPL.  I thought free software developers were supposed to be against this kind of stuff?

The Prodigy's album drop, underwhelming in some ways but still powerful and raw as hell for the most part.  Especially Ibiza featuring Sleaford Mods, damn that's a sick track.

What happens if you try to run that executable on fewer cores?

It doesn't affect the executable itself, only the Make process.  So for me, it will kick off up to 8 concurrent compilations instead of having to do them all serially.

Today I discovered the -jN flag for Make, which enables a multi-core build (set N to the number of cores + 1).

Since I have an 8-core (FX-8320) my build is lightning fast now 

...I stand corrected （　・・） I wonder who needed it first.

It's invaluable to writing wrappers, or really any time you need to match up a window event with an object.  What I was doing before was doing my own lookup table from window ID -> custom window class, but this is much simpler.

Well apparently I'm dumb and jumped to conclusions because I recently discovered that SDL2 windows do in fact support user pointers.

Code:

SDL_SetWindowData(window, "Data", data);

void *data = SDL_GetWindowData(window, "Data");

I wrote this up for fun, ended up teaching myself the importance of applicative functors in the process  

First you have your components.

Code:

type Position = Float
type Velocity = Float
type Name = String

Now, your systems.

Code:

position :: Position -> Velocity -> Position
position x v = x + v

velocity :: Velocity -> Velocity
velocity v = v - 9.81

draw :: Position -> Name -> String
draw x n = n ++ "@" ++ show x

All pretty basic.  Next we add our entity type as well as a couple of convenience functions.

Code:

data Entity = Entity {
    x :: Maybe Position,
    v :: Maybe Velocity,
    n :: Maybe Name
}

makeStatic :: Position -> Name -> Entity
makeStatic x n = Entity (Just x) Nothing (Just n)

makeDynamic :: Position -> Velocity -> Name -> Entity
makeDynamic x v n = Entity (Just x) (Just v) (Just n)

Hopefully this is still pretty straightforward.  Here's where things start to get a bit hairy.

First, I made a convenience operator that basically works the same as or in Lua.  My Haskell standard library knowledge is very shallow so I may have accidentally used a name that another module defines.  

Code:

(<?>) :: Maybe a -> Maybe a -> Maybe a
Just x <?> _ = Just x
Nothing <?> x = x

I then broke the tick function down into two discrete parts.

Code:

tick :: Entity -> IO Entity
tick e = do
    render e
    return (update e)

The update function is pure and makes the changes to each component out-of-order.  In a real implementation you would probably want to bucket things to reduce latency.

Code:

update :: Entity -> Entity
update e = Entity
    (position <$> (x e) <*> (v e) <?> (x e))
    (velocity <$> (v e) <?> (v e))
    (n e)

Here you can see the usage of the operator I defined.  Let's analyze the calculation of the position.  It basically reads: "If both the position and velocity are Just values, make the new position the result of the position system function.  Otherwise, copy over the old position."  The render function is a bit simpler.

Code:

render :: Entity -> IO ()
render e = maybe (return ()) putStrLn (draw <$> (x e) <*> (n e))

If it has both a position and a name, it prints a line.  If not, it doesn't do anything.

I didn't bother to make an actual game loop, but it should be pretty straightforward.  You would just map the tick function over a list of entities to get the next frame's entity list.



Here's the full, runnable source file if you're interested.

http://hastebin.com/fusenunawa.hs

Yes, I do.  Not for anyone else, for myself.  Well, and in one (non-gamedev) case for my dad, but it's a mutual thing (bit of a long story).

Too many people in my other main game development community are obsessed with getting "good-enough" results with minimal effort.  They even try to ostracize people like me who are much more interested in the process than the outcome.  I think this is a very poor and unhealthy way to live.

If I had the ingredients I'd do this in a heartbeat. Alternatively, you can do shot glasses of water, vodka, and vinegar. It produces an interesting mix of pre-drink expressions that run the spectrum between horror and revulsion. What's really great is you can always tell who got the water immediately afterwards but it is not immediately clear who got vodka and who got vinegar.

Here's a better idea: everyone gets three glasses (about half full), one with water, one with vodka and one with rectified spirit (96% alcohol).

You drink two random glasses one after another.

There's a drinking game I've seen where you have to find the "path" through a "maze" of shot glasses.  Most of the shot glasses contain water, but some have vodka (or some other clear spirit).  You have to make your way from one end of the "field" to the other, obviously trying to avoid drinking as much of the vodka as possible.

Watched a Bloodborne stream for a bit.

Resounding "meh" from me.  Difficulty has been toned down significantly and loading screens are anywhere from 30 seconds to a minute long.

After using SDL2 for a long time I'm realizing that as a windowing API it's actually not very good except for the case of a single window.  I would rather use GLFW but the super simple cross-platform low-level audio API that SDL2 provides is way too valuable to me.

Just seems like a waste to add a dependency to GLFW on top of SDL2 for the sole reason that SDL2 doesn't provide a window user pointer.

<rant>
One of the big reasons I went AMD + AMD for my rig is that I don't want to support either Intel or Nvidia.  Intel makes "better" CPUs for games, but that's only because most games are still confined to 2 threads at most.  Nvidia makes "better" GPUs for games, but that's only because lots of games use their proprietary tech.  In both cases it's a vicious cycle that I really don't want to contribute to.

Meanwhile, AMD is working on pushing open standards that benefit everyone from hardware developers to programmers to consumers, mostly on the graphics side of things.  Just look at the adaptive sync fad - AMD pushes Freesync into a display standard (DP 1.2a), Nvidia pushes G-sync which is more expensive and refuses to support the new standard.  You can argue that it's "just business" but I don't think that's justification to screw over the consumer.
</rant>

AAA developers don't spend time or money making PC ports run well because they can just throw up their hands and say "they'll just buy better hardware".

There are (conspiracy theorist) arguments that say it's a way to enforce parity and to devalue a PC version to sell more consoles but in the vast majority of cases I'd say that can be taken out of the picture.

The oft-parroted stigma against "premature optimization" is another issue.  Hand-optimized assembly is a waste of time, yeah, but that's not the only way to make your game more efficient, dammit.

I can somewhat see turning CIL into SPIR-V, but to GLSL?  That's a bit crazy.

It just werks.  It's incredibly naive and there's no types other than an integer yet, but still.



Updated to reflect adding a pseudo-generic type system.

I tried to read up on this EDSL thing and I tried to parse your post again, but I still don't really get exactly what it is or what the point of it is. Not to have to write both C++ and GLSL but write both program and shader in Lua? Why? What am I not understanding?

The idea stemmed from using compute shaders, and potentially having to support a CPU fallback if the user's GPU did not support OpenGL 4.3.  I figured if I had a DSL, I could write it once and compile it both to GLSL and to some function to be run on the CPU in parallel, and I wouldn't have to maintain multiple copies of the same program in different languages.  Then I got thinking about the other possibilities, like being able to script AI or networking while both abstracting away finicky implementation details and allowing mass parallelization.  As well, I can use the host language as a super powerful implementation-agnostic preprocessor and macro system.

I've always just been the kind of programmer to prefer doing more work up front if it means simplifying and streamlining things later.  As well, I am dedicated to making my game mod-friendly.  While there's a lot to be said for supporting many DSLs individually, I would rather only have to deal with minimally one FFI since it's a huge pain, even with Lua, and put the burden of interfacing with my EDSL on the host language.

Boreal, what you are describing is called "abstract interpretation". It's quite a useful technique. But you've yet not hit upone one of it's major difficulties. How are you going to handle control flow? Hopefully, you don't need it, as nearly all languages don't give you sufficient hooks to do it abstractly. Getting variables to work as expected is also hard.

It's possible to get it going, but most people prefer just to write a simple language parser instead, which also gives you an AST.

The EDSL is pure, so control flow only exists in the form of condition statements (if-then-else).  My first thoughts were just to use another type constructor, a la

Code:

x = Input(0, Boolean)
y = Cond(x, Integer(100), Integer(0))

But you're right, that may end up being a big oversight on my part.

I just had an epiphany about how I am going to design my scripting engine.

For a while now I've been struggling to come up with a solution to the goal using a common language to write CPU kernels, GPU shaders, entity data, AI behaviours, and so on.  I tried writing my own interpreters/compilers for existing languages and even a custom language.

Yesterday I discovered the concept of an embedded domain-specific language (EDSL).  This got me thinking, and I asked myself this: what if I used an existing scripting language as a host for an EDSL?

I'm gonna go ahead and use Lua as the reference implementation, since it has such a great API.  This is an example of a simple kernel that adds 1 to its input.  You would use this specific dialect of the EDSL to write shaders.

Code:

x = Input(0, Integer)

y = x + Integer(1)

Output(0, y)

Using operator overloading and type constructors, I can encode what appear to be imperative instructions as nodes of an abstract syntax tree (AST).  The AST can then be interpreted, compiled to GLSL or SPIR-V, etc.  This paves the way for opaque usage of asynchronous or lazy procedures.  On top of this, the host language now becomes an extremely powerful preprocessor.

The beauty of this is that I could potentially support other scripting languages as hosts.  This is the Scheme equivalent of the example kernel:

Code:

(define x
    (make-input 0 make-integer))

(define y
    (+ x (make-integer 1)))

(make-output 0 y)

I could even write a system to build up an AST in-place using C++ as my host!

Had this on repeat for a while.





Arguably one of, if not the, best Drum & Bass remixes ever produced.