Sorry your browser is not supported!

Ever since AppGameKit went 64 bit I am getting a new error that I never saw before, a drop out box saying I have insufficient GPU memory and to try using fewer or smaller images. I could accept this if when running my code AKG says (using the command built in) I am using about 1.4 GB of graphics memory......on my 8GB GTX 1080.

So I tried it on my laptop, and the code literally won't run, gives that error every time. In fact, the laptop crashes AppGameKit as soon as it tries to load the 6480x3360 image, but that crash is an actual AppGameKit has stopped responding" crash. The only way I can get it to run at all is to half the size of the image.

The error seems to be when Syncing the screen, and only happens intermittently on the desktop, but every single time on the laptop. The laptop itself is no slouch with a Geforce 720GM with 4GB of graphics memory (3GB shared), running 64bit Windows 10....so it shouldn't struggle either, and never used to.

Again, no images have changed in terms of size for a very long time, and downgrading to an earlier version does not suffer this problem (it worked fine on the laptop a few back actually). It also seems to possibly be linked to memblocks, which I use extensively....the images are converted to memblocks and then scanned - syncing while this is loaded seems to give the error (possibly, it;s really hard to tell).

Paul, any ideas? As it stands, AppGameKit is pretty useless if you need an 8GB graphics card to run my 2D space game.

The GPU memory error is from OpenGL, we used to ignore it but it can cause all sorts of unexplained rendering errors, and bug reports, if we do. Maybe it is memory fragmentation that means the GPU doesn't have 87MB of contiguous memory to load the 6480x3360 image, but I can't be sure.

You mentioned this happened after the change to 64-bit, but are you using the 64-bit version? This has to be done manually since some people may still be on 32-bit. In the "Tier 1\Compiler\interpreters" folder you'll see the Windows.exe file which is the 32-bit version, and the Windows64.exe file which is the 64-bit version. Renamed the Windows64.exe to Windows.exe to use that instead.

Hi Paul, thanks for coming back.

I'll try the 64 bit exe tonight, but why would a previous version load the same image no bother? Why would the 12gb GTX onlg occasionally have that error for no reason (maybe one run in twenty)? Oddly, it's always the sync command in the middle of a module that scans the memblock. Is there anything else I could do to try and track down the exact problem? Could ignoring these errors be optional for us to specify, like extending the error mode command or something?

I don't really want to lose all future updates or be forced to redesign half my game, though I am aware few users will likely suffer the same issue.

EDIT: I had wondered if it was to do with the shared memory, but again this would have to have been a recent (ish) change. Did I read somewhere it changed to a new visual studio?

The error is checked in the Sync command, which is why it is failing there. If you are using the 32-bit version that is almost definitely the cause. It'll be limited to only 2-4GB of memory address space, so 1.4GB usage along with address space randomization found in the latest versions of Windows will cause occasional problems finding space for large blocks of memory.

So I just tried that and the game is now compiling and working, but something else odd is happening.

The main game, both at zoomed in space ship level, and zoomed out space level has it's frame rate dropped to less than 2fps....yet oddly when I move between the two views (which involves scaling and rotating the ship only but with all the exact same elements on screen and drawn the whole time) the frame rate jumps back up to around the 50fps plus mark, but only while zooming. Again, not something that happens on the 32bit compile, but I will try and work out what is happening that is different. Is it possible timer calls are slower on the 64 bit compile?? Other than updating shader values that's about the only thing that doesn't happen while the zoom is active.

Either way many thanks Paul, it may be restricted to 64bit but at least it's working. I'll post again if I find any reason for the slow down that's so drastic.