I like Promises. I really do. They seem like a smart solution to the callback pyramid.
Q provides some handy utility functions for converting Node.js functions into Promises, and that's awesome, but Node also has an issue with the EMFILE limit.
It seems to be fairly common to hit this limit, and the usual StackOverflow advice is to either bump kern.maxfiles (which seems foolish), or use graceful-fs (which is awesome).
While I love graceful-fs, as far as I can tell it only saves you from the EMFILE limit when using open() or readdir(), and I use other parts of the FS module!
So, here is FSQ; Node.js FS module wrapped in Q.js Promises, and protection from the EMFILE limit.
Very limited function implementation at the moment, I'll add more when I come to need them.
This is where when() steps in.
when() lets you specify a nested suite of tests to run only when a truthy value is passed as the first parameter to when(). This means you can write a truth-test for something like native support of Array.forEach(), and pass the result of this to when().
Inside your nested suite, write your unit-tests for your shimmed version of Array.forEach(). Voila, now your shimmed version is tested only if the browser you are running the tests in needs to use the shim!
Check out my pull request
So I imagine I suffer with the same affliction that many indie game devs suffer from: An inability to release anything.
Games are easy to start and terribly difficult to finish. Talk of a 90% wall is abundant.
To try and ease the pain I’m taking part in One Game a Month. A genius idea, the brainchild of McFunkypants, 1GAM aims to provide some Gamification of the process of making games, pushing game devs towards making… one game a month, the clue is in the name!
So, as if keeping to a blog schedule wasn’t difficult enough, I’m going to try and produce a game every single month in 2013. I might cheat a little and use my 2013 Global Game Jam entry as my January game, and a rewrite/tweak of my 2012 GGJ entry as my February. Hopefully this will give me a little buffer if I fall behind.
In trying to get VBOs to work I had settled on the idea of rendering all possible glyphs in a font down to a combined spritesheet, and then rendering chunks of that spritesheet to the screen in order to form the strings that I wished to display. This probably would have worked fine except I was consistently unable to render only part of a texture to a quad.
No matter how many ways back and forward I went attempting to render just a section of the texture, OpenGL did not want to play ball. Either it would render the texture upside down, mirrored or render the wrong portion. Eventually I refined my code down to the simplest example I could, and found that I couldn’t render less than a 12 pixel wide portion of a texture, as this would show up as strip a single pixel wide on the screen. I still haven’t worked out why this is.
In an effort to Keep It Simple, Stupid, I decided it would be a good idea to investigate if SDL had sped up its 2D rendering at all. Imagine my suprise when I discovered that its 2D rendering was now hardware accelerated (I think it uses DirectX on Windows)! I’ve subsequently thrown out all my OpenGL code and have started using SDL again. My life is so much easier. SDL provides dead-easy functions for rendering textures to the screen, rendering parts of the textures using clipping, and even flipping the textures during rendering to reduce the amount of textures you actually need.
Performance seems to be relatively on-par with immediate-mode OpenGL, and for now I’m happy. I’d love to see some sort of render call batching made available in SDL, but for all I know it might actually be doing this behind the scenes anyway!
I think it’s worth remembering that there always seems to be a simpler way of doing things than you would first think.
I’ve been creating games in some form or other for several years. Due to my own inexperience I’ve never finished one, but I’ve experimented with several languages and frameworks.
Until recently my tools of choice were SDL on C++. My most recent toolset is… SDL on C++, the difference being I’m now layering OpenGL on top (or underneath, depending on how you look at it). I’d never really considered OpenGL before, as I’ve never had a need to use any 3D functionality (the maths for this is far beyond me), however SDL by itself was getting increasingly unwieldy at higher resolutions, and the general advice was to move to OpenGL and lock it into a 2D viewport.
After a week or so of tinkering I had some 2D sprites rendering quite happily, with my framerate locked at 30fps (I had previously tended to write code with a locked framerate so I could ensure I wasn’t dropping below my minimum target), however when I decided to open it up and see how fast my beast of a PC could go, I was barely topping 60fps at 1024x768. Not ideal at all when I am essentially rendering 2D sprites to the screen.
A couple of minutes Googling introduced me to the concept that immediate mode
(the mode that most OpenGL tutorials teach you) is a Bad Thing™ and that my
constant use of
glBindTexture was slowing things to a crawl. This
began my delve into Vertex Buffer Objects, which to me seems like massive
overkill for a 2D spriting engine, but there we go!
Stripping back all my code so that I am only rendering the framerate to the screen brought my back to about 4000fps, however dropping the code for generating the texture to represent the string I was trying to display, as well as the code for actually rendering this texture revealed a fps of about 6000, which was much better (this is now essentially the upper limit framerate for my PC, as I’m rendering absolutely nothing and am just clearing the screen and flipping buffers every frame).
So as an easy first port of call I decided to pre-render all possible characters from the font I was using into one spritesheet, and then use VBOs to render parts of this sheet to the screen in an order that will represent the strings that I want to display (this is a monospaced font, so I don’t have to worry about kerning). Performing the renders and then displaying the full spritesheet to the screen brought me back to about 4K fps, so it appears that any use of immediate mode at all is resulting in a large performance hit.
Time to break out the VBOs!
glGenBuffers to the rescue… oh wait, my
compiler doesn’t know that symbol.. what’s going on? Turns out, the current
stable release of SDL doesn’t let us access newer OpenGL functionality (of
which VBOs is part), so it’s time to upgrade to bleeding edge SDL 2.0!
This was largely painless (although I did spend several hours trying to debug an issue with SDL_ttf not loading my font file, a problem which mysteriously resolved itself after I left my PC alone for an hour or so), and now allows me to pull in GLEW which handles everything to do with loading OpenGL extensions.
So now I have VBO support and it’s time to try and get fonts rendering the way I want. Let’s see how that goes, and I’ll post an update when I succeed.
I blog so infrequently it’s ridiculous. I think perhaps the last time I blogged it was back in 2007 and I was still an undergrad.
More often than not I tend not to blog due to a lack of anything interesting to say! I have no intention of blogging about things relating to my personal life, so I’m essentially limited to blogs regarding technology, or programming or some other related subject.
If I keep it up for more than a month, I might buy myself some cake.