NoshBar's Dumping Ground






[ view entry ] permalink print article

Ever had one of those folders that doesn't technically belong to you and -even though you've got Administrator rights- you can't delete it?

The usual way is to right-click the folder, select security, click advanced, change the owner of it and all subitems to you, then accept, then right-click and open it again so that you can grant full rights on the folder to you...

Well, say now you want to do this for a bunch of folders, say an existing Windows installation on a drive you're using from within a newer Windows installation... it's a huge pain in the gluteus maximus.

Why not Zoidberg a DOS batch file?
takeown /F %1\* /R /A
icacls %1\*.* /T /grant administrators:F
rmdir /S /Q %1

Example usage: deleteit.bat e:\windows

Note: if icacls is not available, try just cacls which also works, but first prompts you if you're sure.

[ view entry ] permalink print article



Get it here.

What you're getting


A Snake-type game where you are a short-sighted snake trying to find food in an unknown maze.

This prototype is unproudly delivered to you in the form of a thousand different hacks tied together with tape made from hack extract with a sprinkling of the worst "levels" ever "designed".

What I wanted to do


Well, for starters, "Short-sighted Snake" abbreviates beautifully to "SSS".
This is both often the onomatopoeia used for snakes AND an abbreviation for SubSurface Scattering... meaning I would have had the opportunity to go crazy with making 3 beautifully SSS rendered snakes next to each other to display the logo "SSS".

Title-screens aside, of course I wanted there to be a nice user interface for selecting levels, viewing scores, etc., but alas, I've just run out of the opportunity to be able to work on this any longer.

How to play


Upon loading the "game", use SPACE to start the game, then the arrow keys for changing direction of the snake.

As an added bonus hindering feature, you can also press "3" to view the level in pseudo-3D where the food sometimes becomes obscured by walls.

How to make levels


Should you one day lose your senses and decide you'd like to play this "game", you can make your own levels to replace the ones kindly provided in this distribution by Satan himself.
  • Levels are 32-bit PNG image files
  • Walls are defined by painting with a colour whose Alpha value is an even number
  • Upon startup, the game looks for consecutive files named "level1.png", "level2.png" and so on, until "level<N>.png" is not found.



[ view entry ] permalink print article

Or to be quite silly:
Delphi Web Scripting in a Dynamic Link Library for running Object Pascal scripts in C [and other languages]

What it is.


This is a simple Windows DLL (32-bit DLL provided) that enables you to compile and run Object Pascal scripts from within your favourite language (provided it supports loading DLL's with the stdcall calling convention) using the DWScript engine by Eric Grange.

Support for calling functions in the Pascal script is supported, as well as registering functions from e.g., C that the script can call. (A sample C wrapper and example are included in the "c_interface" folder).

Available under the Mozilla Public License 1.1

Why? Who can honestly say they've never wanted to run hand-optimised assembler inlined into Pascal Script from within Visual Basic 6? I know I have.

Features.


  • Run full Object Pascal scripts from within your application
  • Jitter can be enabled for JIT compilation, speeding up code "quite a lot".
    I obtained nearly double the execution performance in some cases e.g, running my smallPT renderer conversion without JIT enabled took 39 seconds, whereas the JIT enabled one only took 25 seconds.
    [*only when compiled with Delphi for now]
  • OLE support can be enabled
    [*only when compiled with Delphi for now]
  • ASM support can be enabled
    [*requires NASM executable in the same path as the DLL]
  • The provided DLL was built using Delphi XE 5 from an SVN checkout of the DWScript sources on the 18th of April 2014.


Using.


A simple C example would be something like this:
HMODULE handle = DWScript_initialise("dwscript.dll");  
//you can make as many contexts as you like, but cannot mix and match contexts as you wish
DWScriptContext context = DWScript_createContext(DWScript_Flags_Ole | DWScript_Flags_Asm);
//add any local C functions into the context with DWScript_addFunction()
//and DWScript_addParameter() before compiling
DWScript_compile(context, "begin end.", DWScript_Flags_Jitter); //only necessary once per context
DWScript_execute(context, DWScript_Flags_None); //call as many times as you like
DWScript_destroyContext(context);
DWScript_finalise(handle);


Ideas / TODO


  • Instead of the horrendous fixed-array of unions parameter nonsense going on, you could optionally make the functions take varargs and make calling them a much-more straight-forward affair.
    My only worry then is that you'd have to change from stdcall to cdecl, thereby losing the ability to use this DLL from within certain languages.
  • Fix Unicode/AnsiString conversions / Implement Unicode support
  • Add the ability to run a script in a non-blocking manner.
  • Add debugger support so that you can set breakpoints in the code, etc.
  • Make error handling and reporting not suck.


Free Pascal Notes.


TL;DR; Only this binary collection of FPC 2.7.1 works for me.

I initially started this project using Free Pascal.

As DWScript uses Generics, I needed a newer version of the Free Pascal compiler than what they provide on their home page (2.6).

Fortunately I had Laz4Android installed, which came with a build of FPC 2.7.1
This also provided me with the Masks unit that some DWScript units needed.
(I found mine in laz4android/components/lazutils)

I initially made some horrible hacks to the DWScript code to just get it compiling (deleting entire classes, casting wide to ansi strings, etc.), a simple proof-of-concept to see if it was worthwhile continuing.

Once I had a working DLL, I decided to update my version of Laz4Android to see if it fared any better at the Generics stuff...
Error: Undefined symbol: VMT_$DWSUTILS_$$_$GENDEF386

Hmm, Google had nothing on it, nothing on GENDEF386, couldn't find mention of this in the sources.
Oh well, no worry, I'll just try:
  • compiling FPC from SVN
  • CrossFPC
  • CodeTyphon
  • A random version of Laz4Android I found
  • Building it all on the command line using FPC, then linking it all manually with verbosity set to "I can show you the world"
...
Error: Undefined symbol: VMT_$DWSUTILS_$$_$GENDEF386
Well screw you too.

I've done some investigation into it, I built a little Python Pascal Parser to detect differentiating Interface/Implementation function descriptions and found some things... but nothing the compiler seems upset about.
So instead, if you want to use Free Pascal to compile this, you can try using the binary dump of FPC2.7.1 I took from my working version of Laz4Android from here.

[ view entry ] permalink print article

I recently discovered the HTML5 Canvas, it's lovely, like the good old days of using $A000:0000!

However, when drawing an image to the canvas it kept coming out all blurry. As it turns out, there are actually quite a few possible reasons for this to happen... here's a short checklist of what I discovered on my quest to fix it.

Setting Canvas dimensions



Most articles I came across mentioned that you should always explicitly specify the dimensions of a canvas, either when creating the element in bland HTML e.g.,
<canvas id="drawable" width="100px" height="100px"></canvas>

or via JavaScript e.g,
canvas        = document.getElementById("drawable");
canvas.width = window.innerWidth;
canvas.height = window.innerHeight;


Setting Canvas style dimensions



The above is actually not enough though, you also need to set the CSS dimensions, changing the above JavaScript to SOMETHING like:
canvas              = document.getElementById("drawable");
canvas.width = window.innerWidth;
canvas.height = window.innerHeight;
canvas.style.width = canvas.width.toString() + "px";
canvas.style.height = canvas.height.toString() + "px";


Catering for different pixel ratios



Testing my code out on my retina iPad, I discovered that window.innerWidth and window.innerHeight were returning half of what they should have.

Turns out there's a variable called window.devicePixelRatio that is present on retina devices, and contains the scale you should use when dealing with dimensions...

...sort of. See the "Drawing Pixels is hard" link below for a much clearer explanation.

CSS image rendering settings



Turns out there's ALSO a CSS variable you can change to affect how things are handled internally, it's called image-rendering

You can use it something like this:
/* applies to GIF and PNG images; avoids blurry edges */

img[src$=".gif"], img[src$=".png"] {
image-rendering: -moz-crisp-edges; /* Firefox */
image-rendering: -o-crisp-edges; /* Opera */
image-rendering: -webkit-optimize-contrast;/* Webkit (non-standard naming) */
image-rendering: crisp-edges;
-ms-interpolation-mode: nearest-neighbor; /* IE (non-standard property) */
}


Pixel offsets



Finally getting to what actually fixed it for me, a silly mistake to make.

I wanted to draw my image centered on the canvas, so ended up doing something like: x = canvas.width / 2 - image.naturalWidth / 2, doing the same thing for y.

This leads to floating point co-ordinates, perhaps starting in the middle of a pixel. Being a JavaScript dunce I simply used parseInt(x) to draw the image, and that seemed to cure it for me.

Oddly enough though, I've seen many mentions of always drawing to x+0.5,y+0.5, but I have no idea why you'd do that... unless you always happened to start at 0.5 in the first place.

References



Drawing pixels is hard

About the image-rendering setting


[ view entry ] permalink print article

<Newer | Older> Last>>