Sorry your browser is not supported!

I noted a bit of chat about this in 2018, but it was for Tier 2 and the thread is now locked.

Issue;
I'm downloading images from a webserver. These will be uploaded from mobile phones (so high megapixel) and resized to 1080p on the web server.
I've a nice state machine to manage the downloading in a thread-safe manner, so this is running as part of my "game loop" (this is more of a gallery app than a game though).
Images slide across/down the screen, when there is room for the next image, it's loaded as a sprite and moved. When it's off screen, the sprite is destroyed etc.

Ok, this work fine, most of the time, it's able to meet 60fps, but loading the jpg from disk takes ages (longer than 60hz frame of 16ms)

I've previously checked out options of saving the raw image (uncompressed BMP) on the web server and decoding that into a memblock, but it didn't actually save any time (but was a pleasant afternoon of coding!)

Others on the FB Group suggested slicing the images into smaller sprites and moving them together. I'd rather not have to do that as it makes the code a lot more complicated, but I guess it's an option.

So, whilst I know AppGameKit doesn't currently offer async options for image (or other loading), I wondering how it could be achieved? I don't know C++ but may be able to get help. Could a plug-in or other command be written in Tier 2 that would allow this? (I'll be targeting iOS/Android)


I did try pre-loading the images, which clearly takes a bit of time, to load possibly 100 images - and may not be possible on some devices and just fade them off and re-load any new ones after a few minutes.

I can't think of a way to help me on pure AppGameKit Studio Tier 1. What I'd love would be a similar interface to the HTTP stuff where I can include that in my state machine - start the image loading an check back later to enable it when it's ready.

Probably the only feasible way to achieve something like that in Tier 1 would be to manage sections of data at a target pace to maintain whatever framerate you are after (or at least close to it). So it would be similar to the 'slicing the images' suggestion that was recommended to you. The performance of doing it that way will vary by device, so you'll likely need to design a system that is timer based, rather than data chunk size based. Run a timer in the background and once it hits say, 10ms or whatever wait delay works best for you, sync a frame to update gamestate, then continue loading data... as much as the device is capable of until the next interval. A lot will depend on the scope of the operations you have to manage and how much data you need to load during runtime. If this is something that only occurs occasionally, it might work pretty well with few hesitations/delays. If not or if performance turns out to be too much of a limiting factor, then the dreaded loading screen might be needed

Only way is to split the image and load it as chunks using memblocks, unfortunately.

in native Android Studio you can stream images/videos etc into a list and it works very very well but the single threaded nature of AGK/OpenGL prevents such behaviour, your upload code would need to make a memblock of the image, upload that and download, push to memory in chunks and load the final image from the memblock.

you can use HTTP to async download raw data, you would still need to rebuild the image and load, if you code a clever HTTP callback, you send in some prefix arguments to your server scripts that you can send back to the callback in the reply with info of the datablock (what image it belongs to, block index etc etc), json is highly recommended for this as you can load it directly into a Type

As for actually loading the image, as stated AppGameKit graphics are single threaded, the image must be loaded in the same thread as the graphical context, there is no plugin or C++ code that can help there I am afraid, only physics/math/logic can be outsourced to another thread, anything that controls loading or drawing anything must be in the main thread.

CreateImageFromPNGMemblock() Will create an image from a memblock created using CreateMemblockFromFile().

Now i would suggest that you don't necessarily need to use CreateMemblockFromFile(). You could use CreateMemBlock() and load the file in in chunks (If in fact that is the bottle neck)

If you try this i would be very interested in the results. I will subscribe!

Thanks all for the replies. I'll try to investigate fuller. I expect the method of creating smaller images will be the only way to do this.
From memory, the bottleneck was not just the actual load, but creating the image, but I was looking into this at least a year ago.

The memblock method I used was to transcode the jpg to bmp (uncompressed) and write a simple decoder on AppGameKit to insert into memblocks, then a state machine to handle sections (lines) at a time so it was threadsafe.
This wouldn't really be ideal as the end user would possibly be on a ceuluar link and so download possibly slow and bandwidth hungry....but I'm not writing a jpg decoder in Tier 1 haha!

I don't actually care how long it takes to actually load the image (1 or 2 seconds would be ok), but don't want it locking the main thread.

But, I'll dig out my code and benchmark the operations. I think I got the memblock stuff pretty optimal but if I have working code, I'll paste/share.

Thanks again,
Jason