Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

Deftware Industries

A member registered May 30, 2015 · View creator page →

Creator of

Recent community posts

Hi again Ken,

After more closely examining your logfile I think I may have found the cause of the issue. It was caused by the reasons I stated previously that concerned the variation in hardware vendors' implementations of the OpenGL specification and I believe I have a fix that will properly accommodate the particulars of your system's graphics hardware. I will email you a link to a new version of PixelCNC which you can test out ASAP.

You don't need to worry about sending a new logfile just yet. Expect the link email soon if you haven't received it by the time you're reading this.



Hi Ken,

Thank you for posting your log. Unfortunately I don't see any of the extra debugging info. Did you follow my instructions to enable it beforehand? I'm going to have to ask you to check that it's enabled and then go ahead and run through the process of trying to load an image and posting the resulting log file again (whichever is the newest one in the logfiles folder afterwards).

The 501 error is related to the graphics hardware of your system but your computer does support OpenGL 2.1, which is the minimum supported graphics version that we're targeting for PixelCNC. So you're technically in the clear but with these older versions of OpenGL  (which is the underlying software layer enabling software to interface with the wide range of graphics hardware out there) things can be a little finicky, especially from a software-development standpoint. This usually manifests itself as bugs or errors and is a direct result of the OpenGL specification not being followed exactly by the implementation that is provided by the hardware vendors. Some implementations are better than others and are more forgiving toward sloppy developers while others are missing features that are supposed to be present for the version they claim to support, etc.

It's a bit of a mess, to be honest, and is unfortunately more common than you would think. It is also the reason why most new software simply does not support older graphics hardware in spite of it being capable enough. Or it just doesn't utilize it at all and instead leans entirely on the CPU alone for all of its compute work, which means slower performance. At the end of the day it's the end-users who get burned: with perfectly capable hardware they are forced to upgrade  just to use newer software.

At any rate the solution will probably require making some minor changes to PixelCNC to ensure compatibility with machines running your specific graphics hardware's specific OpenGL implementation. I'd be happy to work with you figuring out what needs to be done to get you up and running. It will also benefit other potential users who would otherwise experience the same issue if they happen to have the same setup. It's going to be a little bit of a process, if you don't mind, where I will simply be sending you new test-versions of PixelCNC to test-drive and you would just report back with the logfile that it spits out. You get to do the easy part!

The first step right now is getting that debugging info into the logfile, which will provide more information and help narrow down the exact situation that needs fixing. We should be able to get you up and running pretty quick and then you'll be CNCing Xmas presents in no time! :D

^^^^ Here's the debug info option you can enable to tell PixelCNC to generate more verbosity about everything it's doing. Get that going and generate a new logfile to copy/paste here and we'll be off to the races :)

Thanks again, and happy holidays!


Hi Ken, this is indeed the place where I will be able to help you :)

Are the example images are not working? Or is it a specific image? If you can post your logfile I should be able to see what is happening.

Start up PixelCNC and in the Config menu enable "Log: Debug Info". Then load an image that causes the problem. You should then be able to find your logfiles folder from the File menu. You will see text files that are named with the year, month, day, - hour, minute, second, and should be able to find the newest logfile in there just by sorting them by name. Open up the log file and copy/paste its contents into a post here. (In notepad you should be able to press CTRL-A to select all, then CTRL-C to 'copy', then in the comment textbox here paste using CTRL-V).

Not bad! Thanks for sharing :D

Thank you for your interest :)

The current version is v1.27a, and the free trial can be downloaded from the main PixelCNC page, toward the bottom where it says "Download demo",  

The older versions are only kept available for users if they encounter problems running the latest version. Otherwise, the latest version  is always the one that should be used.

(1 edit)

The texture mode actually isn't implemented yet. It is implemented in v1.3a, however, and simply allows you to load an image *which is 'projected' onto the loaded model as if there's a slide projector casting the image onto the model from your vantage point, and light pixels in the image translate to creating optics while dark areas are blank. This gives a sort of raw control over how optics are distributed over the surface, instead of relying on how a model's vertices or polygons/edges are situated. I will try to get it all running by the next version ;)

Good to hear! I'll probably hammer out a few more things soon, no telling when, but hopefully within the next few weeks. I'd like to add better multithreading capability to speed up rendering and optic generation - it would be nice if loading bigger models didn't bog it down as much. I'm also thinking about modifying it so that when you are rotating/moving the model around it draws a low-poly proxy so that it's responsive.

More importantly I'd like to add better optic generation, maybe one that is sort of the inverse of the vertex mode - where it plots optics at the centers of polygon faces? I'd like to also make the wireframe optic mode have shading like the vertex mode has now. The big feature I got running a bit in the old version of Holocraft, pre-2.0, with the projected texture optic generation is something I'd like to get going as well, so that you can just have an arbitrary pattern of optics across a model, regardless of its vertices and polygons.

Right now I'm working on a devlog post for this release.

Right now the square that you setup your hologram scene within is what you set the size of via the export dialogs:

The blue arrows are the extent of your hologram, so you want to keep your optics within there if you're doing a square hologram. Otherwise, if you can extend your hologram horizontally further if you wish, and let your optics overlap into the MARGIN areas. The blue rectangle around the 'Inches Scale' CNC export parameter refers to the length of the arrows denoting the hologram's size, in inches.

Since you set the size of the hologram at export time all you need to worry about is keeping things inside the square, but there's not currently a way to specify a size ahead of time: the hologram-area square has no actual size, so there's nothing for rulers to show if they were there. But, if you want to make a non-square hologram that's wider than it is tall, then just keep all your optics within the top/bottom of the window, vertically, and let your optics extend out into the margins a bit, and then the Inches Scale parameter would just be referring solely to the height of your hologram. Keep in mind though that if you're not using 'Origin at Center' that the bottom-left of your hologram will only be for the square area. A rectangular hologram will not start at the actual bottom-left most corner of your hologram's optics. I personally recommend you use the center origin mode, and then measure the center of your material to zero your CNC at.

I've been trying to hack in a bunch of little things real quick into v2.2a before I upload it, while I have the time today. I'm starting to feel like I should expand Holocraft's model-loading capacity, because right now it's limited to very simple models with low vertex/polygon counts - due to the data structures it precalculates from the model to facilitate fast optic generation. I'm also going to separate the optics slider into two sliders: optic count and threshold, so that if you are in Vertex or Wireframe mode you can adjust the number of optics to squeeze onto a edge line while independently adjusting the threshold at which an edge line qualifies for having any optics created along it at all.

Right now I'm switching over to 64-bit compiler to allow Holocraft to allocate more memory and be able to load larger models (~4x more verts/polys), due to 64-bit EXEs being able to access tons more system memory. I've also changed Holocraft to allocate memory dynamically.

There's some weird thing going on where some models have more than two polygons attached to a single edge spanning two vertices. If I can figure out how to resolve these funky situations (or a model having 50+ polygons to one single vertex!) I can expand it pretty easily to allow for much more complicated models.

Your hologram looks pretty good so far, but I do have some pointers. It looks like your light angle doesn't match the actual incident light angle. The light source's angle changes the 'depth' of the hologram, as far as how much straight above the hologram it's shining in from. You can tell if your light is too high and not out in front of the hologram enough because the object rotates much faster/farther than the actual hologram surface itself. You want to match your light position with what you have your Light slider set to. This changes the vertical steepness of the optic grooves themselves to match the light source, and the holographic effect is much more pronounced when the viewer orientation (or hologram angle) matches the apparent orientation of the geometry being depicted.

Also, if you can find some kind of metal polish (I use one called 'Blue Magic') and put a bit onto a rag, and then just buff the whole surface of the hologram real quick after cutting it you can shine up your grooves and double their brightness really easy. You don't need to buff the whole thing to a mirror shine, just going over it with a rag and some metal polish real quick will clean them up and get brighter glints.

For cutting I took some little pyramid carbide engraving bits (they look like a 3-sided pyramid at the tip, but have a tiny trangle facet on the very tip where the 3 sides meet) and diamond-ground it into more of a very slightly rounded point - getting rid of that triangle facet. A rounded point will produce rounded grooves which can catch the light at almost any angle, maximizing your glints. This took me a bit of trial/error to get right, but basically I just ground the carbide to a point by spinning it in my spindle and put the diamond grinding surface on it. Once it was a sharp point then I just barely rounded it by tilting the diamond sharpener up and over to the opposite side once or twice. You want a super duper tiny diameter.

One last thing: you want to figure out what feed rate minimizes any wobbles you get in your optic grooves. A bunch of pressure and moving too fast or slow on a machine that has some flex can induce little speed-wobbles in the tool as it scores the surface, which produces 'blurry' looking holograms that don't have nice sharp defined glints - because the glints will appear all over the optic in multiple spots.

I'll have v2.2a up within a few hours. I almost want to get some more aluminum sheets and start making bigger holograms now! Maybe I'll throw a few bucks at McMaster Carr as a holiday splurge and see what I can make happen over vacation.

I'm glad Holocraft is finding some use!  :)

I'm releasing v2.2 right now to fix an issue with how text is output for both SVG and CNC g-code that causes new-line/carriage-returns to be output wrong at times. I'm also including some example models with the build, so users can start playing with some geometry. I'd like to improve the optic placement/generation, and finally get texture mode in there so that an image can be 'projected' onto a model and used for designating where optics should be across its surface, so that any geometry can be depicted instead of by its vertices or edges - which can sometimes not be very good for generating optics off of with some models.

So now can issue retroactive fees on past payouts to cut into future payouts? Seriously? I'm sure the 3-week total wait between customer payment and actually receiving the payout isn't going to change. That is, of course, unless it gets WORSE.

Jeez. You're slipping itch, slipping.

Also, if you have any requests or ideas for features I'd be glad to hear them! I am pretty busy working on PixelCNC most of the time but I am always willing to see what I can do. If there's a limitation or a bug that you would like me to look at, or a feature or change, just let me know!

(1 edit)

Hi nramco  nracmo, (woops!)

Optic segments overflow means that an optic is being broken up into more than 24 individual occluded/unoccluded segments, where you can think of an entire optic depicting a point in 3D space and the length of the optic is broken into "visible" and "invisible" sections. If you have a model of say a triangle way in the background and then a set of 20 vertical rectangles that make parts of it visible and invisible all along the viewing angle then its optic segments will get broken up too much.

Also, it's recommended that you disable 'Intersection Resolution', which can also cause a segment to be chopped up into too many segments. It was more of an experimental feature but I have yet to get it working as good as I was originally hoping, and it's best to leave it disabled.

Your resulting hologram should be 'opaque' as long as 'Occlusion Detection' is enabled. This will prevent optics from being created for back-facing geometry, and also clip sections of optics that are blocked from view by foreground geometry. If you also want it to appear completely opaque in the view you can enable 'Show Faces' in the View menu.

Also, I don't recall if it's mentioned anywhere, but the 'Light' slider controls the expected/assumed azimuth (pitch angle) of the illumination source, where when the slider is at the top-most position the light source is assumed to be directly above the hologram, shining down on it at a 90 degree angle from the direction the hologram is facing. At the bottom of the Light azimuth slider is 60 degrees, so still from somewhat above the hologram but shining more 'head-on'.

The purpose is to accomodate the use of a ceiling light source in different sized rooms, where a larger room with a lower ceiling would use a Light angle that has the slider closer toward the bottom, and a room with a light more directly above the desired hologram position will have the slider up higher.

Also: what settings are you using on the SVG output settings dialog?

Seems to be working fine:

Holocraft does not "convert" models to SVG, it generates groove optics from a model, which can be output as SVG lines/arcs/curves or as Mach3 CNC G-code, but it's up to the user's discretion how optics are generated: the perspective of the model, which metric to generate optics by, etc.

Are you creating any optics? Are you saving the file to a location that doesn't require administrator privileges? Now that PixelCNC has reached a relatively solid and decently featured state I was going to change gears to start making videos to demonstrate it and show off its capabilities, perhaps it would be a good idea to make a Holocraft tutorial video as well.

I will look into it.

Oh boy. If another program is able to use GL2.1 then it sounds like your drivers are at least installed right, but something is blocking PixelCNC from using them properly and Windows is defaulting to the fallback Microsoft driver.  In all my days of programming and using Windows I have never seen anything like this, that's 20+ years. The closest I've seen is that if one program can't use OpenGL, none of them can.Well, this gives me more hope than ever before that we can get it running for you but it looks like the ball is fully in my court now and you've nothing left to do on your end. I'm going to do some investigating and I'll email you a link in a day or two to one or more new PixelCNC executables you can place in your PixelCNC folder to run  instead, so we can start narrowing down the problem. Good work!

Maybe? But you wouldn't have been able to run the 64-bit driver packages if you were running a 32-bit windows, unless for some reason the driver packages were just 32-bit extractor/installers and you've been installing 64-bit drivers on a 32-bit OS. You can right-click the My Computer icon on the desktop and click Properties, or open System from the Control Panel.

Ah, the chipset drivers may play an important role: they support the underlying system. Considering that your 'GPU' is actually a piece of the CPU I think that maybe it's a good idea to make sure you have all of those drivers up-to-date. I know that you already updated your BIOS to the latest version, and there's a distinct possibility that updating your BIOS without running up-to-date chipset drivers could lead to something like other devices not operating properly (like the integrated GPU). From what I've read a lot of people have had problems getting drivers to work right on older laptops, especially when it comes to getting OpenGL to work, which is something I've never had problems with.

I suppose you could go back to the Dell support page for your laptop and have it auto-detect all the drivers you need, and download/install them. Be sure to reboot between driver installs!

Drivers can be finicky, and they take some finesse. I know that it's possible to get your laptop running properly, it just takes time and persistence.

The GL extensions viewer won't work if you don't have the right OpenGL driver installed - it works by interacting with OpenGL, which in your case will be stuck dealing with the Microsoft GDI/Software rendering driver, and will not show you anything about your Intel GPU.

Visit the Dell website and let the auto-detect tell you everything that you need to install. Install the chipset drivers to make sure that Windows isn't unable to control the low level hardware systems.

Also, yes, the 32-bit drivers will not work because you're running a 64-bit version of Windows. You could install a 32-bit version, and then only be able to run 32-bit drivers/software. Windows 64-bit can run 32-bit software just fine, so there's really no reason to run a 32-bit version unless your CPU is 32-bit, at which point you'd have no recourse anyway.

There's always the option of emailing Dell, and telling them you had Windows 10 but decided to downgrade back to Windows 7 because your OpenGL drivers weren't working, and you still haven't been able to get them working. I don't know if they'd help someone with an older laptop that was bought second-hand, but you never know!

I'm a bit baffled that no driver has managed to make the Microsoft OpenGL driver budge at all. There must be something we are missing, or something that you could be overlooking simply due to being less experienced with PCs. I can't imagine what it could be, but it seems like there must be something. Right now it sounds like there's a very good chance the chipset drivers could be the issue. Be sure to install them and *then* install the graphics driver afterwards. I'd suggest sticking with the newest graphics driver that pops up for your i5-520M CPU on the Intel website.

 According to Dell's specs for the e6410 your CPU is either a i5-520M, i5-540M or i7-620M. You can look up your CPU on Intel's website (or Google it, and the Intel page will show up first) and from there go to the downloads link on the left side of the page. From there I'd try the first Intel Graphics download there is. I suppose you could continue extracting the drivers to a folder and manually installing, just to be safe.

Also, be sure you reboot after each driver install. If you install the right driver but try running PixelCNC without rebooting it will still be using whatever driver was already present - instead of the newly installed one. Windows needs to boot with the new driver installed in order for software to be able to utilize whatever functionality the driver exposes, otherwise it just lies dormant, waiting for the reboot, so it can fully swap in the new drivers in place of the ones already being used.

I think the key is definitely going to be finding the right driver for your CPU's graphics functionality. You should be able to see exactly which CPU you have in the device manager under 'Processors', and google that. It should be something iX-YYYM where 'X' is either 5 or 7 and YYY is a 3-digit number.

All I know for sure is that your machine is plenty new to have at least GL 2.0 hardware built into it, and it's just a matter of hunting down the right driver.

(2 edits)

I would try manually downloading the drivers on Intel's website if their auto-detect just directed you to the Dell website. At first glance it looks like there's a couple viable options, but you're going to want to go back to the oldest Intel version they have (i.e. definitely not 4th gen). The driver that will work is probably also either only Windows 7 or a combo of Windows 7/8.1. You might want to try just downloading a couple of them that look like they might be right, I'd start with the oldest one they offer and work your way forward in time, trying each one.

(1 edit)

Dang! EDIT: I think that your system does not have the GMA, and therefore wasn't going to install the drivers for it. The Intel Turbo Boost is just a CPU feature that's unrelated. You either have an Nvidia 3d gfx built in ontop of your Intel HD, or we need to try drivers straight from Intel.

I did just find this:

It's not the exact same as your laptop, but apparently some people have had better luck installing drivers directly from Intel, instead of from Dell. I also just realized that the Minecraft forum guy also says to download the drivers directly from Intel, and not the Dell website. I wonder if this would've worked for you with Win10 installed still (Win7 is still better).

I suppose you could use the auto-detect utility they have on their site:

You might already have perfectly usable drivers for everything else already, so I'd suggest just manually seeking whatever graphics/video driver is listed by the auto-detect results. Then go ahead and try a manual extract/install like you were doing before with the Have Disk route. This *has* to work.

Fingers are crossed!

1.948 GL_VENDOR: Microsoft Corporation  <--- this should say 'Intel'
1.948 GL_VERSION: 1.1.0

It is still saying that you're running the default Windows driver for OpenGL, which is just a placeholder/last-resort/fallback when either there's no graphics hardware present, or no proper driver for graphics hardware that's present. I suggest trying to install the 'Intel GMA' driver that I mentioned previously instead. It might just do the trick.

Also, I did find a forum post where a guy explained a solution for people with Dell Latitude laptops that couldn't get their Intel HD drivers to install properly to play Minecraft because of OpenGL problems just like you are having. His solution was to manually install the drivers instead of letting the downloaded EXE file install them automatically.

So there's two things I suggest you try. First see if the Intel HD 'GMA' driver solves the OpenGL problem: (

If that still does not work then I believe that this guy's forum thread he started about fixing OpenGL support on Intel HD for Dell laptops might be the key. He said that instead of installing it using the driver download EXE's built-in driver installer, he said to go for the 'extract only' option beneath that - where it simply writes the files out to a user-specified destination (i.e. a folder on your desktop). From there you can go into device-manager and into the Intel HD display adapter properties, and click the 'Update Driver' button (which is visible on the last screenshot you posted). From there you can direct Windows where it should seek for the drivers you want it to install, pointing it to the files extracted from the downloaded driver EXE package. He says that after hours of trying to install drivers to play Minecraft it was the only thing that worked, and several other people replied saying that it worked for them too. I believe this sounds promising.

Similar to PixelCNC, Minecraft also has a minimum OpenGL version that it requires (and so do a lot of other OpenGL programs) so it stands to reason that perhaps the Dell driver installer for your laptop (or the specific Intel HD hardware it includes drivers for) does not work properly when it comes to making sure it sets up an installed OpenGL portion of the driver.

I believe that it's worth trying both installing the GMA driver, to see if that works, and also trying the manual installation of the driver via the 'Driver' tab's "Update Driver" button that I explained above ...and I just remembered, I read that there's also (potentially) an Nvidia GPU in your laptop - which makes Intel HD look amateur by comparison, performance-wise and in its functionality. I assumed that what I read about your laptop meant that there are certain versions of it which either include the Nvidia GPU or the Intel HD, but not both, but maybe your laptop actually has an Nvidia GPU in combination with Intel HD (Intel for 2D, Nvidia for OpenGL/DirectX graphics) and it could be the "Unknown Device" listed in your Device Manager? You could try downloading the Nvidia driver on the Dell drivers page for your laptop. There seems to be two of them, one just named 'Nvidia Graphics Driver' and then another called 'Nvidia Quadro FX .... NVS 3100 ...'  Perhaps they might be worth a shot too. You're definitely going to want to figure out how to get legitimate 3D software running on your machine one way or another, otherwise the laptop as a whole will not be able to run anything but 90's 3D software :(

"Nvidia Graphics Driver"
"Nvidia Quadro FX... NVS 3100M"

The big clue is that it still says 'Microsoft Corporation' as the driver provider, which means that there has yet to be an actual legitimate Intel OpenGL driver installed for the graphics hardware, so to my mind it's a matter of figuring out how to wrestle the proper driver in there. I think that the guy who claimed that manually installing the drivers from the Device Manager might be on to something, because I know for a fact that even the version driver you were running in Windows 10 supports GL 2.1, but it still said you were running a Microsoft OpenGL driver, so perhaps his 'trick' is the only way to get the OpenGL component of the driver to properly install for your system. (Here's the Minecraft forum thread:

Between the GMA driver, the manual driver-update, and the possibility of an Nvidia GPU hiding under your keyboard, I believe that there's a high probability that all of your efforts will pay off and you'll finally be able to use PixelCNC (among other 3D software).  After you try these last ideas I can think of, and it proves unsuccessful, we can discuss what options there are for your compensation or reimbursement - for your purchase that you're unable to use. You could always hold on to your copy until you find a way to get it running, whether on a new machine, or by managing to find a way to get the driver situation figured out. But, I cannot in good conscience keep your money if you're unable to use PixelCNC, not unless you were to otherwise agree to some kind of new terms or conditions, or we come up with another specially-tailored peripheral deal first. I think that one of these ideas has to work, and that you'll be generating toolpaths like it's going out of style soon. My fingers are crossed! :D

Good luck, and godspeed!

Also, are you sure that the driver is installing properly? I'm also wondering if it's the Intel GMA driver you should be installing. The other one was working for people on Windows 10 just to get their system working, but I don't know for a fact that it was also giving them OpenGL 2.1 functionality as well. I suggest trying the GMA driver (, and make sure that it's actually installing by going back into Device Manager and checking out the driver tab on your Intel display adapter's properties dialog box. You should be able to right-click the "My Computer" icon on the desktop and click 'Properties' there to get to a system control panel screen - where there is a 'Device Manager' link on the top left.

It's important that you make sure the driver is actually being used by the graphics hardware, because installing the wrong driver will cause it to automatically revert to one that worked previously.

Oh boy, I can't believe it. The Intel HD in there should be able to run at *least* OpenGL 2.1, even with the driver version you had before. The log file should be in a very similar place: C:\Users\<username>\AppData\Deftware Industries\PixelCNC\

I'm curious to see what it says now, but if the GL version is at 2.0/2.1 then the problem is something I think my workaround will actually fix!

Yes, as long as you can log into with your account (which you seem to be able to do if you can post on this messageboard) then you should still have access to the latest PixelCNC download. I admire your courage and persistence! :)

My apologies! I forgot that on Windows 10 "hidden items" must be enabled via the 'View' menu when looking at the DELL folder's contents - and then the AppData folder will appear. Alternatively you can type the folder name in the address bar and it will still allow you to access it whether or not you have hidden items enabled.

Okay, this right here is pretty funky:

7.573 GL_VENDOR: Microsoft Corporation
7.584 GL_VERSION: 1.1.0

GL v1.1 is the very oldest version of OpenGL. Right now PixelCNC tries to create a v2.0 rendering context, which grants it the functionality it needs to draw everything to the screen quickly, and utilize the graphics hardware for some peripheral calculations. According to some Google searches, your Intel HD driver (v8.15.10.2900) should support up to OpenGL v2.1. The fact that it says Microsoft has me thinking it's not even using your Intel HD hardware at all, and is running an OpenGL driver that is emulating graphics hardware on the CPU (aka 'software'). That's not going to fly.

It looks like your only options are to either install a new driver from the Dell support page, downgrade to Windows 7 if the driver doesn't work, or find a new computer to use. Honestly, this entire situation originated from the fact that Windows 10 should not have been installed on such an old machine. Windows 7/Vista would've been fine. 

There's a good chance the driver will work and you'll be on your way:

The biggest problem people seem to have is their screen becomes 'disabled' after installing the driver. If this happens when you boot your machine back up just let it sit for a minute, and then try pressing Windows Key + P simultaneously to switch through the various Screen/Projector modes and it should bring the screen back up after one or more tries. For some reason the driver will default to outputting on the video port, for a projector or external monitor, which just requires switching it back to the internal display.

Good luck!

(1 edit)

No worries about the delay. Your search did, however, show you exactly the folder path I suggested your PixelCNC log files would be in. Here's the search result that was in your first screenshot which you can click on to see the log files:

You can manually navigate the folders on your harddrive to get to the folder indicated by a filepath, which in this case is 'C:\Users\DELL\AppData\Roaming\Deftware Industries\PixelCNC\'.  Just open each folder successively that is named in the filepath, no need for performing an excessive search. Your computer is just a little machine with some files/folders and configuration options organized hierarchically, like a tree :) It's nothing like a vast world wide web, and as such can be navigated much more succinctly.

Just go to your C: drive and open the 'Users' folder, and then the 'DELL' folder (the name of the Windows user that you are logged in with), then 'AppData' (where programs store peripheral/auxillary information), 'Roaming' (application info that is shared between users of the machine), 'Deftware Industries' (where any of my software would store its stuff) and finally 'PixelCNC' (the specific program in question). The log files will be in there. Easy-peasy :D

On a personal note, I suggest that it wouldn't hurt to sometime go crazy and just surf your machine and all of its options, menus, and folders, just to familiarize yourself with the where-and-how of everything. It's an investment that will pay back in dividends, guaranteed. There are many more folders all over the harddrive, but the important places are really just "C:\Users\", "C:\Program Files\" or "C:\Program Files (x86)\" depending on whether a program is 32-bit or 64-bit, and the "C:\Windows\" folder - which you will probably never need to go into unless you become a total PC expert. The rest of Windows comprises Windows/system configuration stuff, which is not on the harddrive but instead located in Windows' menus and interface.

The big one is the 'Control Panel', which has been around since Win95. You can get to that by right-clicking the start menu button (in Win10) and clicking 'Control Panel'. From there you can work with any and all of your computer's installed devices, hardware, etc.. and their configuration. The other powerful Windows dialog is the 'Task Manager', (around since Win95 too) which is also accessible from a right-click on the start menu, or by pressing Control-Alt-Delete (famously referred to as the 'three-finger-salute') and clicking 'Task Manager' on the options that popup. The task manager will let you see all of the running programs, their resource consumption (CPU/RAM/Harddrive), as well as running background 'services', which are basically programs that operate 'behind the curtain' to make Windows happen. Don't be afraid to get to know your machine! :)

Let me know how I can send a link to you privately. The link will be to a download of a custom version of the PixelCNC executable file, which you can then replace your existing one with to see if my workaround resolves your OpenGL driver issue.

(2 edits)

Okay, I've done some more reading, and I think that you are possibly running a usable driver, but something is off. Could you find your PixelCNC log file and paste it here for me to see? It should be located somewhere such as:

"C:\Users\DELL\AppData\Roaming\Deftware Industries\PixelCNC\"

There will probably be a few log files, one for each time PixelCNC was run, but because you're experiencing the same issue they are probably all pretty much identical. Open the most recent one and paste its contents into a reply and we'll see what we can figure out. I might be able to code a work-around. Your hardware is right on the edge of being compatible so maybe something is tripping it up and causing it to default to an older version of OpenGL where glActiveTexture isn't supported.

EDIT: I think I found a way to work around the problem and get it working. I could still use the log file if you don't mind, but other than that you shouldn't have to worry about doing anything more to your system. I'll have a download link for you to replace your PixelCNC exe with to test out the patch in a few hours from now.

(2 edits)

Hi Macboy, did you determine which  graphics hardware you have in your laptop? I'm still fully confident we can get you up and running but I'm going to have to be up-front in saying that it appears as though you may have downloaded and installed a driver for your laptop other than the one for your graphics hardware. Can you tell me which driver(s) you installed?

EDIT: Before you follow through on the instructions I provided below, the black/console window that you snapped a picture of provides more information about your graphics hardware that it detects, and other useful information that will help me solve the problem. Scroll to the top of the window to the beginning of the output that PixelCNC generates there, and it should mention a GL_VENDOR and GL_VERSION. You don't actually have to take a screenshot, just telling me what it says there would be useful, but it sounds like you'll need to do a bit more work getting your system properly configured.

You mentioned BIOS updates, which are not related to graphics drivers, and should've only installed if you made it a point to install all of the drivers that the Dell page auto-detected that your system needs - which should've included the graphics hardware driver. Otherwise, if you made it a point to manually seek out and install the graphics driver by itself then BIOS updates would've only installed if you had accidentally mistaken a driver with "Intel" in the name as being the graphics driver. There are multiple drivers for your system with 'Intel' in the name which are not actually graphics hardware drivers. The Intel graphics drivers are distinguished from other various Intel drivers by the 'HD' or 'GMA' suffix that follows 'Intel' in their name. This is because your system has an Intel CPU and other Intel components, and therefore uses multiple Intel provided drivers.

Apologies if I am completely underestimating your aptitude, ability, or awareness, and you actually managed to install the proper graphics driver. I cannot stress enough that am not trying to be insulting or condescending by assuming a mistake, I am just going on the clues and evidence I have available to me, and I recognize that there's a distinct possibility that you may have simply installed a motherboard/BIOS Intel driver instead of the graphics driver, purely by mistake. There's also the possibility that because you have Windows 10 installed on an older laptop that is no longer supported by Dell that the automatic driver detector simply did not provide a graphics driver in the list of drivers it displayed to you - because there are no Windows 10 drivers for your laptop. If that's the case then you will simply need to manually install an older  driver, which will work fine regardless. Likely a 32-bit Windows 7 driver, if your system actually is 32-bit as you mentioned before, as Windows 7 was the last OS that Dell supported for that laptop, and thus provided drivers for.

I can assure you that whether your laptop has an Intel 'HD'/'GMA' or an Nvidia graphics processor that it will run PixelCNC - and be able to access long-existing OpenGL functions such as glActiveTexture which have been standard for nearly two decades. So something must be preventing your machine's graphics capabilities from being utilized, and in my experience the wrong drivers (or missing drivers) are the culprit. Also, the link to the glActiveTexture bug page you found was actually a discussion between programmers about writing software that utilizes the function, and erratic behavior one programmer was experiencing, which is unrelated to the problem you're experiencing.  "glActiveTexture" is one of many graphics functions that PixelCNC is unable to utilize from your hardware, and is only the very first one that it attempts to confirm accessibility for. A failure to access the function automatically prevents PixelCNC from attempting to access the rest of the graphics functions that it needs so that users are not bombarded by a barrage of error boxes for all of the missing graphics functions. The fact that PixelCNC errors out with "glActiveTexture" as being what the error specifies is purely incidental, and not specific to the glActiveTexture function itself. The problem lies in the graphics hardware not being properly configured for software to be able to access, which just means we need to make sure it's configured properly ;)

We can get to the bottom of the graphics hardware situation directly by seeing what Windows says about it. To do that you can look for yourself to see what graphics hardware you have, and what driver is currently installed for it - which I imagine is the default "Microsoft" provided driver that only grants very basic minimal functionality. It's provided as a last-resort graphics driver when the correct driver is not found. Without this default fall back driver Windows wouldn't be visible on the screen at all when the proper driver can't be located, so Microsoft provides it for convenience purposes. The problem is that it doesn't implement the advanced graphics features that the hardware offers, or that modern software utilizes, so it causes problems like the one you're experience when running proper hardware-enabled 3D software.

Take a look at what you have installed, and we'll have all the information we need. Start by right-clicking on your start menu button, which will pop up a 'context menu', and go to 'Device Manager', just like in this screenshot:

Device manager in the context menu

Once you're there look under "Display Adapters" by clicking on it to see what graphics hardware your system includes:

 I'd like to know what it says under there. I'd also like to know what driver is installed, so once you see what's listed under Display Adapters go ahead and right-click on whatever display adapter is listed under there and click 'Properties'.

This will pop up a dialog with information about your graphics hardware. There will be a row of tabs across the top: "General", "Driver", "Details", "Events", and "Resources".

Click the "Driver" tab and tell me what it says under "Driver Provider", "Driver Date", and "Driver Version", along with the name of the graphics hardware immediately above that. In this image from my netbook you can see it says "Intel(R) HD Graphics" as the adapter name at the top, next to the screen icon, and then "Intel Corporation" for the provider, "11/10/2016" for the date, and "" for the version.

These pieces of information will tell us for sure whether or not your system's graphics hardware's drivers are properly configured, and point us in the right direction. Lets first make sure that your graphics drivers are properly installed and we'll go from there.

Good luck!

Whoa nellie! It has never taken more than 2 weeks for me, usually somewhere between one and two weeks.

Well looking at your machine's specs it should be plenty capable of running PixelCNC. The OpenGL rendering function error is a red flag to me indicating that something specific to the Windows installation on your machine is not properly configured, or that some kind of software is interfering with normal program operation. The function the error mentions, 'glActiveTexture', is something that 20 year old graphics hardware supports, so it could very well be a driver issue with your system.

The problem with Windows complaining about not knowing how to open a common everyday program EXE file indicates that something has taken the liberty to interfere with your Windows installation. It could be a virus, antivirus, or some adware/malware that tried to work its way into your system, or possibly has worked its way in.

Since it looks like PixelCNC did eventually run, in spite of the "search for an app" problem, and wasn't able to properly initialize OpenGL, I think there's a good chance you can at least get it running if you update your drivers. I suggest you visit the driver page for your machine and have it automatically detect which drivers to download. The important one you're going to want to get PixelCNC running will be a video/graphics driver. Your specific laptop model came in two flavors, apparently, one with Nvidia graphics and one with Intel HD graphics. Either one should be able to run PixelCNC.

The driver page should be able to automatically determine if you need the 32-bit or 64-bit version of the drivers, just click the "Detect Drivers" button:

It should show you a list of drivers specific to your laptop, and you could go ahead and download all of them and get your system properly setup, but if you want to just quickly skip to seeing if you can get it working then download only the graphics driver that it shows you, it will either say Intel HD, Intel GMA, or Nvidia, depending on the actual hardware you have. It will also likely say "graphics" somewhere in the name. Go ahead and download/install that, reboot, and try running PixelCNC again. You will probably encounter the same "search for an app" issue, but once you get through that PixelCNC should startup, if it managed to show you the glActiveTexture error before - which means PixelCNC did actually start at some point.

I did manage to find this, which might help you fix that problem with Windows, but it won't fix the OpenGL/graphics driver problem, which must be fixed in order for PixelCNC to use your graphics hardware for rendering.

Good luck!

Hi Macboy, thanks for taking an interest in PixelCNC. What kind of computer are you trying to run PixelCNC on ?

You can buy Holocraft now, but its development, documentation, and support are low-priority for the moment. It has been released purely to satisfy the curiosity of the most courageous. Thanks for your interest.

You can buy Holocraft now, but its development, documentation, and support are low-priority for the moment. It has been released purely to satisfy the curiosity of the most courageous. Thanks for your interest.

You can buy Holocraft now, but its development, documentation, and support are low-priority for the moment. It has been released purely to satisfy the curiosity of the most courageous. Thanks for your interest.

Thanks for the info. If parallels supports multithreaded applications I could likely just force it to run, or at least give an option to the user to 'force run' if they want to see if things will work anyway. I think I'll do that. It sounds like it's just the implementation of the windows API for checking how many logical cores a machine has is not reflecting the actual machine itself - but surely multithreaded programs are properly utilizing multiple cores on there (Parallels). Also, I suggest moving to v1.18a, otherwise the new big v1.20a update that's in the works will include a better simulation system, tool diagrams depicting the profile of the cutter specified via parameters, and a few other tidbits.

Thanks for checking out PixelCNC! ..and yes, please share your PixelCNC creations :)

(2 edits)
A coarse horizontal milling operation and fine step parallel finishing operation.

(Note: If images are hard to see right-click and open in a new tab for full-resolution)

Intro: This tutorial demonstrates how to go about creating a work with sizable pockets that demand the removal of a relatively significant amount of material. This can be achieved using a single parallel operation with a workable depth of cut that results in multiple passes until a max depth is eventually reached at the bottom of the project - which is determined by it's Z dimension. In this case we're going to employ a larger cutter that can remove material more efficiently and in less time and then come in with a smaller tool to remove the remainder to produce the final product. Just about any operation can be used to perform the rough cut but we're going to use the 'horizontal milling' operation. This operation will remove material with horizontal cuts at fixed cut depths. Afterwards we will come in with a smaller ball nose cutter to remove the remaining material and bring out our desired form and detail in our workpiece.

Simulation Setup: For this project we're going to want to see a fast approximation of what our generated toolpaths are going to cut like, so start out by changing the simulation settings to a depthmap resolution of [1024] and mesh quality of [.90]. You can use larger values if you wish but these values will keep the generation time down in exchange for faster simulated cut preview generation. 

Simulation settings for fast and reasonable quality cut previews.

Project Setup: With a new project at the ready (File->New Project) click the 'Load Image' button and open 'pandemonium.jpg' from the included 'examples' folder in your PixelCNC folder. The image should load and generate a mesh in the 3D view. Click the 'Image Size/Origin' button to reveal the project's current dimensions and origin parameters. Set the project size/origin settings to a width of [12] inches and a depth of [1] inch. The 'Autoscale Contrast' option should be enabled here to ensure that the darkest shade and lightest shade from the image are considered the very bottom and very top of our project, respectively, even if they're not absolute black and absolute white. Set a 'downscale' factor of [1] to use the full resolution of the image. Then we'll use the top center of the project as our machine origin so our offsets should be X-Offset:[50%] Y-Offset:[50%] Z-Offset:[100%]. Once your parameters match the screenshot below press the 'Apply' button and the mesh will adapt its dimensions and position accordingly.

Setting up our project dimensions and machine origin.

Cutting Tools: Next we're going to define our cutting tools. Click the wrench icon button to see the project's list of cutting tool definitions. For our horizontal roughing operation we're going to use a larger flat end mill. Click the first tool slot labeled [tool01]. The number in the brackets '01' is the tool index that the generated G-code will expect the physical tool to be in for CNC machines with automatic tool changing capability. For machines without automatic tool changing we will simply break up our operations into two G-code files at the end of this tutorial, one program for each tool.

Roughing Tool: In the tool definition parameters on the right side of the screen we can set the name of the tool to something more descriptive for readability purposes. I'll be changing it to [1/4" endmill]. Click the 'Type' button to select the [Cylinder] option. This will reveal the tool parameters necessary for defining a cylindrical cutting tool. For this tutorial we'll pretend that our tool has a length of 1.5" from the chuck to tip and as such set 'Total Length' to [1.5]. This is to keep the spindle chuck from crashing into the highest parts of our workpiece when cutting the deepest areas, at least with this project image. Our imaginary tool also has a flute length of [1] inches, a 'Flute Diameter' of [0.25], and since it's a flat endmill we'll set 'Corner Radius' to [0] inches. Now we hit 'Apply' to save these parameters to our tool.

Defining our 1/4" flat end mill for our horizontal roughing operation.

Finishing Tool: At this point we can either create our roughing operation first and then come back and define our second tool and its finishing operation, or we can go ahead and define our finishing tool right now while we're here. This is entirely up to the user and their own preference. For this tutorial we'll just go ahead and create our finishing tool right now while we're here. So, click the second tool slot labeled [tool02] and we'll name this one [1/8" ballnose]. It is also a [Cylinder] type, and we'll say it also has a total length of [1.5] inches, a flute length of [1] inches, a flute diameter of [0.125] inches, and a corner radius of [0.063] inches - which is equal to the radius of the tool (rounded to the nearest thousandth) in order to yield a hemispherically rounded ball-nose tool profile. Press 'Apply' to save our finishing tool's definition.

Defining our 1/8" ball-nosed endmill for our finishing operation.

Operations: Now that we have both of the tools we need for our project we can move on to creating both of our machining operations. Click the line graph icon button to bring up the project operations. Click the first operation slot in the list on the left side of the screen labeled [op01]. This will bring up the operation definition on the right side of the screen, just as with the tool definitions editing mode. For this tutorial we'll change the name of the operation to [horizontal roughing]. Click the 'Tool' button and select our [1/4" endmill] we defined from the list. Click the next button, labeled 'Op' and select [Horizontal]. This will reveal the relevant parameters for defining a horizontal milling operation. We'll set the cutting direction to [Climb], which will create toolpaths that engage the tool with the material so that the clockwise rotation will scoop the material in the opposite direction that the tool is moving. This helps to preserve tool life by causing less rubbing than conventional milling.

Speeds & Feeds: For cutting 'speeds & feeds' you can use a special calculator to calculate these based on the capabilities of your machine. For those more experienced with CNC they will likely have evolved a sense of what speeds and feeds to use based on the material they're cutting, size of their cutter, number of flutes, depth of the cut, and capabilities of the machine they're working with. We'll assume that all the variables in play work out to a cutting feed rate of [60] inches per minute, and a tool rotation speed of [10000] rotations per minute. For a 2-flute cutter this comes out to a chip load of .012" being removed per tool revolution, which is perfectly acceptable for a 1/4" tool cutting most woods. If you have a hobby desktop machine with a router spindle such as the DeWalt DWP611, the minimum RPM is 16000 on the lowest dial speed setting. We can just scale up our feed rate accordingly. Our new feed rate for 16000 RPM is: 60IPM x 16000RPM / 10000RPM = 96IPM

Step & Depth: Since this is our roughing operation we want to save time by moving a lot of material, fast, so we're going to set our 'Step Size' to just over half the diameter of our 1/4" cutter, and use [0.15] inches. We're going to cut the diameter of our cutter deep and use a 'Cut Depth' of [0.25] inches. The operation should be allowed to go as deep as our project image goes - the full 1.0" of our project's Z depth, so we set our 'Max Depth' to [1] inches. 'Min Depth' sets the high cutoff point where any cuts shallower than this depth are culled. For this tutorial we'll set it to [0.001] inches. Both the min/max depth values are relative to the top of the project, not absolute Z coordinate relative to the machine origin.

Safe Z: As long as our raw stock material is sufficiently flat we can allow our tool to move between cuts relatively low to the top surface. This minimizes total operation run time by reducing the amount of time that's spent traveling vertically when retracting from a completed cut and feeding into a new one. I almost always keep the 'Safe Z Height' at [0.1] inches unless I absolutely need to optimize for speed, at which point I'll get as low as ~0.025" but this is only in extremely specific situations. Once we have our horizontal roughing operation specified we can generate our toolpath by hitting 'Apply', just as we do with defining a tool.

Our horizontal roughing operation's toolpath for economical removal of material.

Adjustments: The horizontal operation is one of the slowest operations to generate a toolpath for and this is determined entirely by the depth of cut and step size. We can't really rely on having a larger step size to reduce the number of cut paths without causing some lone island spikes to form in tight corner features, which may or may not pose a problem, depending on the project. We can more realistically fiddle with the cut depth, however, but this depends on the machine and the material being cut. A less rigid machine might flex too much or not have a powerful enough spindle to handle to deep of a cut. These parameters should be tweaked to suit the machine that the code will be run on. Here's an example of changing the cut step size to [0.2] inches and the cut depth to [0.3] inches, you can see the reduced calculation time:

Observing the calculation speedup of using larger step size and cut depth.

...However, this leaves more material for the finishing operation to come in and remove, which may or may not prove problematic, depending on the tool used. If a finishing cutter does not have long enough flutes it may not be able to cut high enough when at the bottom of a pocket to remove the larger remaining stock, or it may just as well overwhelm the machine depending on its rigidity and robustness.

View Repositioning: Once we have a decent looking toolpath we can examine it visually by rotating the view around by click-dragging the left/right mouse buttons and spinning the mouse wheel to zoom in/out or click-dragging it to directly control the zoom. Pressing the home icon button on the view button bar top-center of the screen will return the view back to its default birds-eye vantage.

Taking a closer look at the toolpath generated.

Simulation: We can get an even better idea of the cuts our toolpath will create on a CNC using the simulation preview mode by clicking the film play button. This mode also shows a list of the project's operations which can be clicked on to generate a simulated toolpath cut for users to examine and get a much clearer idea of what their parameters are going to physically produce:

Previewing the simulated cuts of our horizontal roughing operation toolpath

Finishing Operation: Once we're happy with our roughing operation we can go back into our operations mode via the line graph icon button and select the second blank operation slot. Here we can name the operation [parallel finishing]. We'll select our [1/8" ballnose] as the tool used, [Parallel] for our 'Op', and [Mixed] for our cutting 'Dir' so that the tool will cut in both directions in a zig-zag fashion instead of lifting up and rapiding to the opposite side to continue cutting in a single direction.

Speeds and Feeds: With the speeds and feeds it gets a little trickier here than with horizontal cuts being that our tool is going to be taking vertical plunge cuts almost half of the entire time the tool is engaged with the material in order to perform the 3D contouring cuts involved. This means that the center of the tool will be doing quite a bit of cutting. The center of a rotating tool is a very tiny radius that will be rotating. As such the flutes will be moving at a very low speed relative to the cut feed rate and the flutes on the circumference. We'll compensate by using a lower feed rate to give the tool tip a better chance at removing material. For our 1/8" ballnose tool, which we'll imagine has 3 flutes, we'll use a feed rate of [20] IPM and a spindle speed of [10000] RPM. This gives us a chip load of 3(flutes) x 20IPM / 10000RPM = .006" inches per revolution. We could go slower, or turn up our RPM, and the center of the tool will do an even better job of actually cutting. In the case of woods and plastics this isn't as much of a concern as it is with machining metals, so we'll call it good.

Step Size: For a finishing pass we need a tiny step size that will minimize the size of the 'scallops' between each cut pass, the little peaks along the midpoint between each cut path. For this tutorial we'll use just a little under 1/4 the diameter of our finishing tool, and set 'Step Size' to [0.03] inches. We want the tool to be able to travel from the top of the project workpiece to the bottom in one fluid cut so 'Cut Depth' should be the full Z depth of the project which also requires that our tool's flute length is at least this large so we'll set it to [1] inches (this is to prevent an operation from potentially cutting deeper than the tool is capable of but this will be changed in the future).

Confinement: 'Max Depth' obviously should be the full project depth, [1] inches, and we can re-use a 'Min Depth' of [0.001] inches which will leave the very top most surface of the project untouched on the left/right sides bordering the project. We could reduce 'Safe Z Height' but we'll keep that at [0.1] as well. For fun you can play with the 'Angle' value and modify the direction of the cuts, but for this tutorial we'll leave it at [0] degrees. Click 'Apply' and the toolpath will generate and it should complete a bit quicker than the horizontal roughing operation we created due to the simpler nature of the toolpath.

A freshly generated parallel finishing toolpath, and parameters

Once we have a toolpath we can examine it more closely by moving the view around.

Taking a closer look at the toolpaths for our finishing operation.

..and again we can go into simulation preview and click our [parallel finishing] operation to generate a preview that is the culmination of both the roughing pass and finishing pass. Granted in this situation the parallel finishing operation will look identical whether or not the horizontal pass is present but in reality, on a machine, the tool or machine might not be so cooperative removing all that material with the tool making so much vertical plunge cut motions through so much material.

A simulated cut from our parallel finishing toolpath.

Toolpaths can be hidden by clicking the visibility eye icon button on the top center button bar to toggle drawing of any toolpaths, this especially helps with viewing simulations where dense toolpaths are in play:

Revealing the simulated cut by toggling off drawing of toolpaths.

Exporting Separate CNC Programs:

If we go back into operation editing mode by clicking the line graph icon button we have a few buttons for each individual operation. There's four buttons that appear on an operation in the operations list when they are selected for editing.

The eye icon toggles visibility of that operation's toolpath, and only applies if the global toolpath visibility toggle isn't already hiding rendering of all toolpaths The pencil icon toggles whether or not the G-code for the operation will be included in exported G-code as well as a generated simulation preview. The up/down arrows allow re-arranging of the order that operations are in.

If we want to export each operation separately we can start by clicking the pencil icon on our parallel finishing operation to prevent it from being included when we export G-code. Now we can export our roughing pass G-code by clicking the 'File' menu and clicking 'Export G-Code'. A file save dialog lets you navigate where you wish to save your CNC program code, with a name like "".

Toggling off writing of finishing operation's toolpath to exported G-code for a roughing program.

Now we can disable writing of our horizontal roughing operation to G-code and re-enable writing of G-code on our parallel finishing operation and repeat the G-code export steps, being sure to save to a different file name, such as "".

Toggling off roughing operation's inclusion to exported G-code for a finishing pass program.

The End :)

Fantastic, what a relief! I'm going to post a tutorial in the morning, I have some tutorial ideas sketched out for mostly just demonstrating the basics of using individual operations and then also a few things that employ a few operations used in combination. I'm all ears to suggestions if you are curious how to go about doing anything in particular.

Thanks Donnie. I made a new build that uses some different compiling options and a sort of in-between version of SDL that still has SVG loading capability as a sort of last resort before I pull out the big guns. I was hoping you could check it out, it's labeled v1.16a on the downloads section. I'm still not entirely sure what's going on here, other than it sounds like something is severely slowing everything down and not giving very much CPU to the main PixelCNC thread that's running, which is very strange.

Was the toolpath that slowed down rendering very complex? Or was it pretty simple? Did toolpaths of equal complexity cause a slowdown in previous versions? The toolpath visibility button sticking is also extremely strange, as it's constantly refreshing the cursor position (from SDL, so maybe that's the culprit) and doing a simple check to see whether or not the cursor is over each rectangle for each button/editbox/checkbox/menu item on the screen, where it hilights green if it is and otherwise defaults. That information isn't even stored in memory, it's re-generated each frame, so I'm at a bit of a loss other than it being SDL, which could be remedied by completely removing it from PixelCNC entirely and just going with the raw method. I haven't seen problems like this with SDL in the past, but that was also before SDL was as big and complex as it is now, so maybe the devs have become somewhat overburdened with keeping compatibility and reliability up to snuff.

Another thing I'm looking at right now is some better debugging systems I can build into PixelCNC to make it easier to track down and determine issues on end-users' machines without requiring them to get their hands dirty, we'll see what comes of that. Anyway, let me know how v1.16a works out when you get a chance, and thanks for taking the time helping me to figure these issues out.

Actually, if you find that the old DLLs fix all the performance problems then I'll probably just revert back to using those and get SVG support in there another way, which is somewhat roundabout, but it would save a lot of extra work that would otherwise not really be necessary.