code of the Ninja();

// in search of swift, efficient, and invisible code


Code Formatting and Highlighting on Webpages

Tested inChrome, Firefox
Required softwarePrism

The Problem

Writing a blog about programming means talking about code - a lot. Up to and including whole blocks of example code.

This can actually be quite the nuisance, for three reasons.

1: Formatting

Code is usually best presented in a monospace font with whitespace preserved, both for readability and because of the importance of indentation.

Fortunately, HTML can solve this problem pretty easily out of the box. Using <pre> tags can turn this congested mess

if (foo) { var x = bar(); if (x == 42) { print("found the answer"); } } else { print("Hello World"); }

into this

if (foo)
    var x = bar();
    if (x == 42)
        print("found the answer");
    print("Hello World");

without the need to litter the source code with non-breaking spaces and line break tags.

The <pre> tag only gets you so far, though.

2: Escaping

HTML is pretty bad at talking about itself.

If I want to talk about an HTML tag, as in this very post with <pre>, the reader has seen it wrapped neatly in angled brackets, but I've actually been typing &lt;pre&gt;.

(And in order to make that last sentence, I had to actually type &amp;lt;pre&amp;gt;... and it's just going to keep getting worse if I continue down this rabbit hole.)

And it's not just when talking about HTML. The characters that HTML needs escaped are common in most programming languages, so any code that goes into a post has to be run through an escaping procedure.

This is tedious, as you can imagine.

3: Highlighting

Finally, for optimum readability, code really should be highlighted.

When keywords, numbers, and identifiers are all in colours that make them pop, it sure beats staring at a homogeneous grey soup of letters and numbers.

Doing this in pure HTML would mean manually wrapping these words in spans with styling information, which suddenly makes escaping angled brackets and ampersands look like a fun time. No one wants to have to write <span style="color: darkblue; font-weight: bold;"> (or whatever) each time they write a keyword like "if".

The Solution

When I first started writing this blog, I'm embarrassed to admit that I did code escaping and highlighting manually (when I bothered to do highlighting at all). I didn't want to hunt for a more complex solution, even if it did mean doing a bunch of grunt work.

Now that I'm getting back into blogging here again, though, there's no way I'm going to go back to that.

So now I'm using Prism, and I'll explain how I set it up for my blog.

About Prism

First of all, what is Prism? I'll let their website do the explaining.

Prism is a lightweight, extensible syntax highlighter, built with modern web standards in mind. It’s used in thousands of websites, including some of those you visit daily.

Prism consists of a JavaScript file and a CSS file you can include in your webpage, and works by the following method:

  • The Prism script hunts through the page, looking for <code> elements.
  • For each that it finds, it checks what language that code should be. It can't decide this by magic; you have to put a special class on the element yourself, e.g. class="language-javascript". (Alternatively, you can put that class on an ancestor of the element, so for example you could put it on the <body> element if your entire article was about the same programming language. In the latter case, individual <code> elements can still override the language if you put a class on them.)
  • Once the language is determined, the text contents of the <code> element are parsed, and any words that should be highlighted are automatically wrapped in <span> elements and given classes that correspond to their type, e.g. "keyword" or "variable".
  • And it's done; if you've included the Prism CSS file (or provided your own), the <span> elements will be styled based on their class and you'll have your highlighting.

Downloading Prism

If you want your webpage to load lickety-split, you'll want to keep the number of requests to the server and the amount of data to download at a minimum. Prism knows this, so instead of providing a one-size-fits-all download, they've done something a little more complicated.

On their download page, they let you select just which themes, languages, and plugins you want. Dynamic previews of the JavaScript and CSS files are generated based on your selection. Once you're happy with your build, you can download the files from the buttons at the bottom of the page.

For my purposes, I only selected the languages I'd be talking about on this blog. Things like Lua, JavaScript, AutoHotkey, and so on. They don't already have support for things like GML or the assembly languages used in Sega hacking, but it's easy for a user to add these languages themselves. I'll post about that in the future on Code of the Ninja.

As for plugins, I recommend at least Normalize Whitespace, which can trim those pesky extra line feeds from around code blocks inside <pre> tags.

Including Prism on Blogger

While it's technically possible to include Prism by putting the following code at the start of a post,

I decided to put it in my template because I'll be talking about code in every single post, and there's no reason to go to the extra trouble of pasting that into each one individually.

I went to the control panel of my blog, and then to Template → Edit HTML, and posted the following code at the end of the <head> element:

(The differences in syntax to the version above are to keep it consistent with the Blogger template.)

So now I had Prism working across my entire blog. That's great!

But this hasn't solved all three of the problems I enumerated at the start of this post. I can use <pre> tags to format, and Prism to highlight, but escaping code is still an issue.

Writing Unescaped Code

Prism actually has an Unescaped Markup plugin right there on the download page, designed exactly for this purpose.

It's pretty clever, letting you use either HTML comments or <script> tags to write unescaped markup, since HTML won't bother to interpret the text inside those.

The plugin has some limitations, though. First, it's only for markup languages such as HTML, and doesn't bother to add this functionality on any of the other language classes. Second, it only uses the comment trick for code in <pre> tags.

I wanted to be able to write unescaped code in any language, so I needed a plugin that treated all <code> elements equally. Therefore I decided not to include the Unescaped Markup plugin in my Prism download, and instead heavily edited it for my own purposes and included it as a second script, like so.

I decided that I only cared for the HTML comment method for achieving unescaped code; using <script> tags didn't sit right with me because I felt that all code should be in the same kind of tag.

So here's my edited version of the plugin. It's just a stripped down version of Unescaped Markup plugin that only does the comment method, but for every <code> element it finds, rather than just the ones inside <pre> tags.

Of course this does mean that any code I write about that contains HTML comments or something that looks like them will still cause trouble, but at least over 99% of cases are taken care of which is good enough for me for now.


So if you didn't know about Prism before I hope it helps out. It sure spruced things up around here.

I'm currently making some custom language plugins so that I can write about Sega Genesis hacking here at Code of the Ninja, and you can be sure I'll give the details on that process as well.

Until next time, happy coding!


Disable Undo/Redo in Windows Explorer

Operating Systemmost versions of Windows (tested in 7 and 8.1)
Required softwareAutoHotkey

The Problem

I recently started using Windows again after some months of using Ubuntu exclusively, and I decided to fix something that had always bugged me about its built in file browser, Windows Explorer.

If you press Ctrl+Z while Windows Explorer is in focus (this includes the taskbar and desktop), you will Undo the last file operation such as a delete, rename, move, or copy. The same goes for Ctrl+Y and Redo.

This is, of course, intended behaviour, but the way I work I'm always looking back and forth between open instances of Windows Explorer and e.g. a code editor arranged on multiple displays. If I do something in the Windows Explorer window, look back at the code editor window, and decide to undo an edit to the code, I might press Ctrl+Z without remembering to put the code editor window in focus first. The Windows Explorer window, up as it is on my other display and completely out of mind, would still be in focus and receive the Ctrl+Z hotkey, reversing a file operation I may have done hours ago.

Worse, this happens silently, so I might not even notice that it happened at all, until later when the un-deleted, un-copied, un-moved, or un-renamed file is needed and disaster ensues.

To be fair, this doesn't happen often, but in my opinion it's just a catastrophe waiting to happen. And that's not even considering what might happen if un-renaming a file causes a filename conflict, or if undoing a copy or move involves hundreds of files or very large ones. So a fix would definitely be nice.

The Solution

It would be ideal if Windows Explorer just alerted you that you were attempting to Undo or Redo, with a little prompt explaining exactly what file operation was in question. You could then choose to continue or cancel from there.

But I can't just add features to Windows Explorer. I don't work for Microsoft. (And even if I did, I'd be too busy adding bloated, unnecessary background processes to the latest version of Windows to get around to it either.)

So I did the next best thing, and just prevented Windows Explorer from receiving Ctrl+Z or Ctrl+Y commands altogether, protecting myself from potentional future Undo/Redo mishaps.

I did this with a program called AutoHotkey, which I learned about in a video by the always excellent Tom Scott.

AutoHotkey, or AHK, is useful for about a million other things, some of which I'll very likely blog about in the future, so if you are wary of getting it just for this fix alone, you don't have to be. (You can also use this standalone fix I made if downloading an executable from some git with a blog doesn't squick you out.)

What is AHK, though? I'll let their own site answer that (saves me typing).

AutoHotkey (AHK) is a free, open-source macro-creation and automation software for Windows that allows users to automate repetitive tasks. It is driven by a scripting language that was initially aimed at providing keyboard shortcuts, otherwise known as hotkeys, that over time evolved into a full-fledged scripting language.

I just needed something that could detect when keys were pressed and prevent the focused window from receiving them, and AHK fit the bill.

AHK works by running scripts, which are just text files with an ".ahk" extension that you can edit in the code editor of your choice. With AHK installed, you can easily make a new script by using the context menu in Windows Explorer: New → AutoHotkey Script. If you do it that way, some lines of code setting up the script will be filled in for you automatically. These aren't strictly necessary, but they don't hurt.

AHK associates the ".ahk" extension, so once a script file exists you can launch it by e.g. double-clicking it. A new script doesn't do anything, of course, so I had to write some code to get it to listen for a press of Ctrl+Z. Don't despair, the code for an AHK script is kind of weird and terse, but it's not hard.

The Code

Here's the code I added to the script first. It doesn't do everything yet, but building it up step by step makes it easier to understand.


The caret (^) followed by z is just shorthand for Ctrl+Z. The double colon (::) after it means that this is a hotkey declaration: the following block of code is what will run when that key combination is pressed. (It may help to visualise this as a function declaration like in other languages, something like function OnControlZ() { return; }.)

At the moment, the code consists entirely of a Return statement, which means we don't do anything at all. This actually prevents the default behaviour of Ctrl+Z; no other special commands are needed.

Running the script at this point will prevent Ctrl+Z from doing anything - but it will be applied universally, no matter what program is running or what window is focused. That's progress of a sort, but of course we want this to be restricted to Windows Explorer.

Fortunately AHK allows this. Before my hotkey declaration, I used the #IfWinActive directive followed by the criteria that the focused (i.e. active) window has to satisfy in order for the hotkey to work.

#IfWinActive ahk_exe explorer.exe


In this case I used ahk_exe explorer.exe, which means any window that belongs to the "explorer.exe" process.

(AHK lets you use other criteria, like the window's title or class, but those were inappropriate for my purposes. Windows Explorer windows can have any title, depending on the directory being browsed, and they have a different class from the taskbar and desktop, which also needed to be covered. However all of those windows belong to the "explorer.exe" process, so that's what I went with.)

I wasn't able to just guess that ahk_exe explorer.exe was what I should type by some kind of magic, though. AHK includes a utility for checking info about the active window, called Window Spy. If an AHK script is currently running, you can launch Window Spy by right-clicking the script's icon in the system tray. Otherwise you'll need to find "Active Window Info (Window Spy)" in your Apps list or just hunt for "AU3_Spy.exe" in AHK's program directory.

With Window Spy running, I clicked on a Windows Explorer window to get information about it. In Window Spy's "Window Title, Class and Process" field, I could see the title, class, and process of the window. I then clicked on the taskbar and desktop to be sure they were the same process.

Okay. So if you run the script now, Ctrl+Z will be disabled only in Windows Explorer. That's more like it! But instead of simply silently blocking it, wouldn't it be nice to show a little message saying "Undo has been disabled for your protection" or something?


Even better. Let's have a prompt asking if you really want to Undo or not, with "Yes" and "No" buttons.

#IfWinActive ahk_exe explorer.exe

    MsgBox, 4, Windows Explorer, Do you want to undo the last file operation?

MsgBox is a command that makes AHK show a message box. The parameters I used were

  • Button Type — 4. A constant specifying "Yes" and "No" buttons will be present.
  • Title — Windows Explorer. This is the title of the message box.
  • Text — Do you want to undo the last file operation?. This is the text in the body of the message box.

Of course, this prompt is just for show until we write code to respond to it. If the user says "yes", then Windows Explorer should receive Ctrl+Z.

#IfWinActive ahk_exe explorer.exe

    MsgBox, 4, Windows Explorer, Do you want to undo the last file operation?
    IfMsgBox Yes
        SendInput ^z

The new lines should be pretty self-explanatory.

IfMsgBox Yes is akin to a classic if-statement, conditionally performing the following command. (It doesn't have a # at the beginning like #IfWinActive because it's sublty different; it controls program flow instead of being a directive that affects hotkey declarations.)

SendInput is a command that sends key presses to the system as if the user actually typed them. In this case I used ^z (which means Ctrl+Z just like in the hotkey declaration) so that if the user selects "yes", the system receives Ctrl+Z as if nothing ever happened and the Undo operation can go through.

I wasn't done yet, though, because the prompt isn't modal - it doesn't freeze up Windows Explorer while it waits for the user to answer. It can't, because it doesn't really belong to Windows Explorer, it's just a message box shown by AHK. So it's possible that the user can focus a different window before answering the prompt, at which point (if they say "yes") the input will be sent to the wrong window.

I solved that simply by activating the Windows Explorer window again before sending Ctrl+Z.

#IfWinActive ahk_exe explorer.exe

    MsgBox, 4, Windows Explorer, Do you want to undo the last file operation?
    IfMsgBox Yes
        SendInput ^z

(Now that there are two commands in the conditional block after IfMsgBox Yes, they need to be wrapped in braces.)

WinActivate is a command that can activate a specified window; in this case, used without parameters, it activates the window that received the hotkey in the first place. (This helpfully obviates the need to get and store the ID of the active window manually.)

So that's done it. Testing the script at this point gives the behaviour I wanted for Undo in Windows Explorer. But of course the same needs to be done for Redo as well. So here's the entire script.

#IfWinActive ahk_exe explorer.exe

    MsgBox, 4, Windows Explorer, Do you want to undo the last file operation?
    IfMsgBox Yes
        SendInput ^z

    MsgBox, 4, Windows Explorer, Do you want to redo the last file operation?
    IfMsgBox Yes
        SendInput ^y

Now that the script was complete I added a shortcut to it in my Windows startup folder so that it would run whenever I ran Windows. And with that, I was done. Fix complete!


If you want this fix without installing AutoHotkey, the makers of the program have covered that eventuality. AHK optionally comes with a program that can compile scripts into standalone executables that anyone can use whether the whole program is installed or not.

I've provided download links to the script and its compiled form below if you want to grab them. Use at your own risk, etc.

Until next time, happy coding!


Using Strings as Keys in Maps (Game Maker)

Hello, Code Ninjas. This post will be somewhat brief. I discovered a neat thing about Game Maker's map data structures that wasn't made clear in the help file, although (if you dig deep enough) the new Game Maker Studio documentation mentions it without drawing attention to it. If you don't know about it already, it could be quite useful.

Basically, the neat thing is this: The keys (as well as the values) of key/value pairs in a ds_map can be strings as well as real numbers, e.g. the following is valid:

This gives one a lot of power over merely using reals, so you'd think that the documentation would brag about it; perhaps it was assumed to be obvious. It wasn't obvious to me. I gave it a try on a whim after a bout of Javascript programming which made me think of it, and it just happened to work.

Now if you are wondering how string keys are treated by functions such as ds_map_find_first(), ds_map_find_next(), etc. it's pretty simple - they are considered alphabetically. Where the help file talks about these functions as returning the "smallest" key or the "next largest" key, which makes sense in terms of real numbers, you can substitute "earliest alphabetically" or "next in alphabetical order". For example, "a" would be a "smaller" key than "b".

The alphabetisation is case sensitive and is strict about punctuation and numbers, so it won't always behave intuitively. For example, if you add the keys "1", "2", and "10", then "10" will be considered "smaller" than "2". Uppercase letters are considered "smaller" than lowercase, as well.

Finally, if you have a mix of real keys and string keys, all real keys are considered "smaller" than all string keys. A real key of 4000 is "smaller" than a string key of "0".

Hopefully I'm not just super clueless and this was all totally obvious from the get go, and somebody benefits from me pointing it out. :)

Happy coding!


Constant Coding

Today I'll be talking about an interesting trick involving Game Maker's constants.

Constants are basically just like variables, only you can't change them at runtime; you can only change them using the constants form when developing the game. Having grown up with 16-bit video game consoles, I always visualise constants as being in ROM while variables are in RAM - this is purely an analogy, though, as it hardly describes what's really going on in a modern computer.

The cool thing about Game Maker's constants form is that it is more powerful than it really lets on. The documentation is fairly vague; it says "A value of a constant should be a constant expression. That is, it is either a constant number or a string (with quotes around it) or it is an expression." This hints at, but does not make explicit (especially for beginners), the fact that you can use functions for the value of your constants. Or more accurately, the return values of functions.

There are limitations, of course. You can only use Game Maker's built-in functions, and not your own scripts. But you can do stuff like the following example:

The constant DISPLAY_WIDTH will equal the result of the display_get_width() function (the width in pixels of the user's display at its current setting). Now, I must make it exceedingly clear, because this can confuse beginners (as once it did me), but the constant will be, well, constant. Using DISPLAY_WIDTH in your code will not call display_get_width() and give you a new result each time. Constants are evaluated at the very beginning of the game when it runs, so the only time display_get_width() gets called is then; the return value (and only the return value) is stored in DISPLAY_WIDTH.

(Of course display_get_width() is only used as an example, because it's a simple function to understand. In practice you may never use it, because the user (or the game itself) might change the display settings at some point.)

You can go even further, nesting functions like so:

So this is much like what you might do in code or a script, e.g.

Which begs the question... why bother using a constant at all? Why not just use variables like so?:

There are two advantages to constants in my opinion. First, they are colour coded in Game Maker's code editor, and are also part of the auto-complete feature. This is very helpful when coding. And second, it's often cleaner to put them into the constants form that is already provided rather than writing a script full of globalvar and then calling it somewhere in your code.

So now that the basics of using functions for constants are established, I want to get to the "trick" that is the point of this post. Because Game Maker's data structures are created by calling a function, you can make constant data_structures, like so:

To be fair, the functions that create data structures return a reference, or "handle", for the newly created data structure, to be used with other data structure functions. The constants will only be the handle; the data structure itself can still be manipulated. However, because of the two advantages to constants mentioned above, this might still be something you want to do if you have a data structure which will exist for the entire duration of your game.

If this was all you did, then it would still be up to code or scripts to define the contents of the constant data structures. But you can fill in those constants using the constants form, as well. Observe:

Using a second constant, the ds_list_add() function is called, adding a value to the list pointed to by CONSTANT_LIST. The second constant is named using three underscores; it could be anything, but since we don't care to ever use it (it will only contain the return value of ds_list_add(), which is unimportant) the name should be something that won't cause conflicts.

It so happens that it's not possible to perform multiple functions per constant, e.g. separated by semicolons. You won't get an error if you try, but only the first function will be evaluated. But you can just use multiple constants to do as many functions as you want. And, because constants can be multiply defined, only one name need be used, like so:

Of course this might get rather silly after a while, filling your whole constant form with functions to fill a list. However, the data structure functions for reading and writing to strings will work just fine. So the following has the identical effect as the example above that added three values using separate function calls:

Maybe this trick will come in useful someday for you Code Ninjas. If not I hope it was interesting to those who are as fascinated by Game Maker exploits as I am.

Until next time, happy coding!


Creating Old-School Palette Effects Using Pixel (Fragment) Shaders

Please note that the following only applies to Game Maker 8.0 using this shader extension. However, the principle can be applied to anything else that uses shaders.

Okay, time to get started. Let's say you have an image. It's made of pixels - obviously - and each pixel is a colour. Where things get interesting is how you choose to describe that colour, i.e what bits or bytes you use to signify it.

The simplest way is to use 1 bit per pixel - on or off. But that only gives you a monochrome image. What about colour? A very common way is to use 24 bits per pixel - one byte each for the red, green, and blue channels. This gives you 256 levels of intensity for each channel, allowing over 16 million vibrant colours, and indeed 24-bit colour is sometimes referred to as "true" colour.

The drawback to methods such as 24-bit true colour is that they use a large amount of memory. So, a common practice in old-school games was to use indexed colour: a palette contains the actual colours, while the pixels in an image are only described by a single value - the index (i.e. the address in the palette) of the colour to be used for that pixel. (Read more at Wikipedia.)

The indexing method, in addition to saving memory, has another big advantage. If you change a colour in the palette, any and all pixels that reference the index of that colour will change along with it. An otherwise static image can come to life in this way - lights can flash, water can flow, stars can twinkle - all without true animation of any kind. (See a beautiful example of this in action.)

As memory and CPU power improved, these little tricks largely fell by the wayside. Software such as Game Maker doesn't provide any functionality for palettes by default, which is bad news for anyone who wants to emulate the effects of old-school games.

Fortunately, LSnK has come to the rescue with his shader extension for Game Maker. (Sadly it is only compatible with version 8.0 of GM, but 8.0 is still a sufficient tool for making great games.) It allows one to use shaders in Game Maker with little more effort than setting the fog colour.

Shaders are quite a complicated subject, but for the purposes of palette effects (and this article) we will only be considering pixel shaders (also referred to as fragment shaders). You can think of a pixel shader as a tiny program that runs for each pixel that is drawn. If you activate a pixel shader and then use a drawing function, each pixel to be drawn is input to the shader, the shader runs, manipulating the pixel in some way, and finally the pixel is output to the screen.

There are a great many effects pixel shaders can achieve. A common example is drawing an image in greyscale: the red, green, and blue channels are used to determine the perceived brightness of the colour, and then that brightness value is output to all three channels, making the corresponding shade of grey.

Now, I'm not going to explain every little thing about how to use the shader extension or make a shader - there's plenty of instruction on how to do these things on its own page. Here I'm only concerned with explaining the idea behind emulating palette effects with a pixel shader. I'll also provide an example GMK at the bottom of the article to get you started.

So let's move on. First, we need a palette (any image that's one pixel in height with colours in horizontal sequence will do). Let's use Sonic's palette from Sonic 1 as an example.

We'll also need an image of Sonic.

The above image clearly won't do. It's already in colour; what we need is an image of Sonic where each pixel is an index in a palette. I've made a tool called Palettiser that lets you do exactly that. It'll analyse an image and replace all the pixels with shades of red - shades of red whose intensity corresponds to an index in a palette, for a max of 256 colours. Having completed that process one ends up with an image of Sonic that looks like this (since there are only about 16 colours in the palette, the shades of red are all very dark, almost black):

Now, both the palette image and the funky-looking converted image can be imported into Game Maker as a sprite or background resources.

The next step is to create a custom pixel shader. A shader that, when active, will perform the following operation on every pixel that is drawn:

  1. Get the amount of red in the pixel.
  2. Use that value as a horizontal coordinate, finding the colour at that position in the palette image.
  3. Draw a pixel of that colour instead.

By drawing the converted image with the shader active, the original Sonic image can then be recreated correctly. But this time it will palettised - any change to the palette image colours will be reflected in the Sonic image immediately.

But how to change the palette image colours? It's a background or sprite, right? Well, what's cool is that a shader can also use surfaces. If you make your palette a surface, you can draw anything to it, and in so doing animate the palette.

But talk is cheap. It's much cooler to see this happen and play around with it in real time. To that end, here is an example GMK. (Be sure and install the shader extension first, of course!)

Have fun!


The Phantom Returns

This is a bit of weird - and undocumented - behaviour.

When you write scripts in Game Maker, you can have them return a value by using the return statement, like so:

What value does the script return if you don't have any return statement, though? Does it always return true, or false, or maybe something else? I wanted to know, and I learned something surprising when I looked into it.

At first I thought the answer was that the script would always return false, but this rule didn't always hold. What's more, the return values I was getting were seemingly random and unpredictable.

Finally I discovered what was going on. A script returns the value of the most recent equation.

What does that mean exactly? Well, for example, a script containing only this line:

...will return 10. And, likewise:

...will return 20. Whatever the result of the most recent equation is becomes the return value!

This holds true for math operators like *=, +=, and so on. This:

...will return the square of argument0.

How bizarre! Even if you leave out the return statement, you will still get "phantom" return values... I guess this might be the cause of odd behaviour once in a while, so it's good to know about.

Until next time, happy coding!


Prepare To Be Floored (Correction)

This is a correction of a mistake in my last post.

The last section said this:

This is all very well and good for rounding, but what about flooring or ceiling a number? This trick always rounds up with a fractional part of 0.5 or above, and rounds down below that. In Game Maker, you can use the floor() function to always round down, and the ceil() function to always round up.

You're in luck, because you can do code like this:

These will still be very nearly twice as fast as their function equivalents!

The trouble is that only works if your number actually has a fractional part. If you try to floor or ceil an integer that way, you'll get the integer -1 and the integer +1, respectively.

I can still pull my fat out of the fire, though. Instead of using 0.5 as the value to be subtracted (for flooring) or added (for ceiling), you can use a constant that's just ever so slightly less than 0.5, such as:

Just set this up as a constant (call it something like MATH_CEIL) and then make a second constant that's the negative of it (e.g. MATH_FLOOR = -MATH_CEIL). Then you can do:

And everything I said still holds. You'll still get the job done twice as fast as using the function equivalents. (The use of constants doesn't slow it down at all.)

I suppose you might still technically run into a problem if you're using numbers that require a precision greater than power(2,-43), but for most purposes that'll never happen. Again, this is merely a trick to be used in code that requires optimisation at all costs, not everywhere in your program.