next »

[standardcombo]

Damn you can put "[Multiline(<some integer>)]" before a string property in Unity to make the field larger in the inspector... Happy about this.

Also I discovered this while Gangnam Style was playing.

[Netsu]

My job forced me to learn screen and this in turn convinced me to try tmux.
Why haven't I used it before? It's everything I ever wanted from a terminal emulator and much much more, all printed as beautiful, configurable, colourful ASCII

[Boreal]

Just got my CMake build system up and running.  Before, I was a huge proponent of makefiles but CMake is just so much less hassle and so much cleaner, and will be much more so once I write my library finders.

[barley]

Damn you can put "[Multiline(<some integer>)]" before a string property in Unity to make the field larger in the inspector... Happy about this.

Also I discovered this while Gangnam Style was playing.

WELP. I didn't know this.

[Boreal]

Finally came up with an engine architecture that is both easy to use and develop.

Basically, the engine API exposes objects such as textures and meshes, but nothing to do with actual subsystem initialization.  The implementations of these objects (which can vary for different back-ends) actually signal for the subsystems to be initialized.  This makes the engine extremely modular, as if a subsystem is never used it is never initialized.

The subsystems themselves are written as free functions in namespaces.  They are reference counted so that they are only initialized once, and so that teardown happens safely.  They can also reference each other so that (for example) the rendering system is guaranteed to be initialized after the windowing system.

You can check out what I have so far in my GitHub, the link to which is in my signature.

[Sik]

Just got my CMake build system up and running.  Before, I was a huge proponent of makefiles but CMake is just so much less hassle and so much cleaner, and will be much more so once I write my library finders.

If you ever make a library with CMake please don't do the stupid thing that libpng does when built with CMake (basically: it requires you to define ZLIB_INCLUDE_DIR and ZLIB_LIBRARY explicitly when you invoke CMake or it won't work, despite the fact the whole point of CMake is to avoid stuff like that - oh, also it's not mentioned in the documentation) On the flipside, when a CMake script is set up properly it's a lot easier to crosscompile than stuff using raw makefiles =P

(PS: if somebody says that building libpng with CMake doesn't need that, I guess something was wrong because I had to do it when crosscompiling from Linux to Windows)

[Boreal]

Just got my CMake build system up and running.  Before, I was a huge proponent of makefiles but CMake is just so much less hassle and so much cleaner, and will be much more so once I write my library finders.

If you ever make a library with CMake please don't do the stupid thing that libpng does when built with CMake (basically: it requires you to define ZLIB_INCLUDE_DIR and ZLIB_LIBRARY explicitly when you invoke CMake or it won't work, despite the fact the whole point of CMake is to avoid stuff like that - oh, also it's not mentioned in the documentation) On the flipside, when a CMake script is set up properly it's a lot easier to crosscompile than stuff using raw makefiles =P

(PS: if somebody says that building libpng with CMake doesn't need that, I guess something was wrong because I had to do it when crosscompiling from Linux to Windows)

Absolutely not.  I'll make sure it uses the proper method to find the libraries, which will mean packaging (or writing) the various FindXXX.cmake scripts.

[ThemsAllTook]

I'm surprised I've never done this before, but I just wrote a simple GL test app to learn how render to texture works. Really simple and effective. My head is spinning with all the possibilities it creates...

[Quarry]

Post processing

[Geti]

Can also be used for split screen and for gpu accelerating lots of parallel operations 

[oahda]

Geez. I haven't been able to get much done lately. Last update before yesterday to my codebase was on the 21st of September. On the 6th before that. Granted, mai waifoo has been staying with me for an entire month up until last week, so whenever any programming did come up, we obviously worked on our common project instead of my personal one. We got some stuff done on kitty game!



That's eventually going to be a chandelier with crystals and stuff flying all over the place when it hits the floor. And there's temporary graphics and perspective to figure out somehow. But it's fun to work on something together.

–––

But yeah. No update on my own project since 21st of September before last night, where I finally got a couple of reasonably focused hours put in! It's still in a sort of framework state where I'm setting up a binding to AngelScript (engine is C++) at the moment (whereas kitty game is Unity – it's nice to get to play with both methods simultaneously), and last night I finally got it set up enough so that I could move an image component around on the screen using scripting. The texture was set through scripting too.

Next step is to add the component through scripting, I suppose. And generally just bind lots and lots of remaining methods until the interface is compatible with the engine. Then finish up the input, which is already working somewhat but doesn't have a complete list of key identifiers yet and I got a neat idea on how to portably set up a system for keys and gamepads and mice alike for the way this game is going to be controlled. So woop!

[Photon]

Slowly but surely getting going with Haxe and OpenFL. Despite wanting to move on to some bigger ambitions and projects, I'll probably be experimenting and practicing with small (test) games at least for a little bit while I get more familiar with Haxe and try to build up something of a base entity-component system to work with in future projects. Its been awhile since I've really dove into good solid hard-coding pertaining to a game project, and I like being back in it! 

[Zack Bell]

Probably having more fun than ever (in terms of gamedev  ) while working on iOS stuff.
Tonight I'm mocking up menus and stuff though. Still exciting to mess with touch controls!

[Layl]

Changed the entire basis of my game framework around to have a "Game" object be assembled rather than inherited, using closures as the mechanic binding all the data together. It worked out so great!

[oahda]

Changed the entire basis of my game framework around to have a "Game" object be assembled rather than inherited, using closures as the mechanic binding all the data together. It worked out so great!

Would you care to elaborate on that, with some concrete examples? Sounds interesting.

[Layl]

Would you care to elaborate on that, with some concrete examples? Sounds interesting.

Well for example, at first I would have this:

Code:

public class Client : Game
{
    private readonly Data _data;
    
    public Client()
    {
        _data = new Data();
        
        CreateLoop(Update, TimeSpan.FromSeconds(1.0/120.0));
    }
    
    private void Update()
    {
        _data.Stuff();
    }
}

Which now instead becomes:

Code:

public static class Client
{
    public static Game Create()
    {
        return new Game(Initialize);
    }
    
    private static void Initialize(Game game)
    {
        var data = new Data();
        
        game.CreateLoop(() => Update(data), TimeSpan.FromSeconds(1.0/120.0));
    }
    
    private static void Update(Data data)
    {
        data.Stuff();
    }
}

"data" here is automatically packed together with the lambda that executes Update. However that's just a side effect for the main benefit. My game object here has become more flexible because it can be assembled rather than inherited. I can easily for example write an editor against this code that allows you to assemble such an object from a GUI. As well I can now assemble the object from a configuration script if I wanted to.

[SolarLune]

For my projects in the BGE, I've started and made a lot of different resources over the years, and awhile ago I compiled them into a single Python module package called BGHelper that I've been maintaining and working on. It's got input maps, post processing filters, random level generation, node maps (A* pathfinding, I guess), sprite animation, 3D mesh trails, easy viewport manipulation (already built into the BGE; just an easy way to access it)... I don't think I'm gonna get a chance to really use it all in the current iteration of the BGE, but the stuff I've learned and code I've written will transfer to the next engine, and the next one, and so on.

[oahda]

Oh, I was thinking of something else, I guess, Layl. Can't remember what anymore, tho.

I got my script binding set upp sufficiently enough yesterday to allow me to write the controller code for the vessel in script alone. However, one problem arose, having to do with something in the binding that kept giving a vector an incorrect value, so that I couldn't finish up entirely. After hours of looking around I gave up and just emailed the author of AngelScript to ask him what might be up. I just noticed I've gotten a reply and he has suggested a simple idea that might work. I think I need to update the library, tho. I'll try it when I get back home from work. If it does, then woop!

Also, I just ordered a PS3 controller and a USB cable for it in order to get to work on something I've never done in all my years of gamedev so far: set up joystick controllers for a game object. I am quite excited! Especially since for this game I've figured out a way to write a couple of methods that should enable a portable way to write controllers that automatically work neatly no matter the chosen input method.

EDIT:
So I got home (after two hours of overtime at work, too~) and I managed to fix it! The author's reply wasn't directly helpful altho it might be useful for future things, but I actually managed to figure it out myself after all. He did suggest one thing – an incompatible implementation of my C++ class – and indeed did I figure out that my template stuff in there was a bit shady. So now I'm able to control this vessel entirely through scripting!



It does remain a bit laggy, however. Next up I'll have to try to make the scripts run more efficiently (I'll probably end up coding the sub's stuff, as it is core mechanics of the game, in C++ either way, but it's obviously still necessary for content coming up).

[Geti]

Listening to metalstep, drawing and coding some space game shit for one of my last subjects of uni for the forseeable future So close to able to focus properly on work I can taste it.

[oahda]

A little bird – in case said bird was not a liar – whispered to me, Geti, that you too employ AngelScript. Is this true? If so, have you got any tips for the first timer from experience?