Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / Big with PNG saving??

Author
Message
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 23rd Feb 2019 22:55 Edited at: 23rd Feb 2019 23:04
Link
So I've being playing around with an atlas image, and discovered something that is very odd with AKG and images.

So I am using tiles of 512*512, with a 3 pixel border, so they are 506x506, then the edges repeated. If I build this is Photoshop, save as a PNG, it works fine, no seams. They tiles are 2*2, so it's a 1024x1024 image.

However, I put code together to do the same thing in AppGameKit using memblocks, then save off the result as an image. Loaded into photoshop it looks identical....but in AppGameKit the seams come back between the images. This applies wether I convert the memblock directly into an image, or save it then load it back.

Here's the odd part....if I then load the image back into photoshop...save the EXACT SAME image back as THE EXACT SAME FILENAME as a PNG....and everything is fine, the seam vanishes again.

So is there something odd going on with AGK's PNG format, or how it converts a memblock to an image?

EDIT: title should say bug, not big. :-p
Back to top
Profile PM
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 23rd Feb 2019 23:16
Link
I've also discovered that MAG filter makes no difference - I'ce attached some screens.

Some sample images

the AppGameKit out put image


and as used int he game - notice the seams?


the photoshop output - this is the AppGameKit output loaded into photoshop, then saved as a PNG


and the photoshop output in game - no seams


Attachments

Login to view attachments
Back to top
Profile PM
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 23rd Feb 2019 23:22 Edited at: 23rd Feb 2019 23:39
Link
DELETED
Back to top
Profile PM
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 23rd Feb 2019 23:39
Link
Last update - now got it working with both JPEG and PNG images, and I think I've isolated the issue (not sure if a bug or not).

It won't work if you just create the image from a memblock, nor will it work if you save the image then load it again using loadimage.....however it DOES work and get no lines with any size or format of image if you make an image from the memblock, save the image, then use loadimageresized with a scale of 1.0 x 1.0.

So whatever is happening when you load an image resized in the GPU - my guess is that isn;t happening when making an image from a memblock, and that's the issue I got.

Not sure if it's a bug, or what else it might affect outside ATLAS images.
Back to top
Profile PM
Golelorn
7
Years of Service
User Offline
Joined: 20th Nov 2016
Location:
Posted: 24th Feb 2019 02:16
Link
Nice job on finding the solution.


Unrelated, to this problem. But is your border just a blank alpha 3 pixel border? I have never understood this, and my google searches never clarified what the "border" is supposed to be made of.

Also, do you find you have a speed increase? The last time I tested using atlas terrain textures my FPS was miserable compared to just using 6 512x512 textures.


Thanks!
Back to top
Profile PM
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 24th Feb 2019 09:23
Link
Not sure it's a solution, but perhaps what we need is a makeimagefrommemblockresized option. This works though.

No, the border needs to be a repetition of the texture So that mip mapping works correctly. So the 3 left most pixels down the side of the texture are repeated on the right hand side of the image for a partial tile. This is repeated for all four sides, and then the corners.

In terms of speed, looking up one texture can be faster than looking up 4, but it depends on the sizes, he shader and how I uses them. And the machine of course. I'm maintaining about 80fps at 4k, but I'm not done optimising yet. You project is top down, isn't it? So won't affect you, but as I covered somewhere else using a full resolution texture and a 16th resolution texture and swapping between them in the shader gives me a great balance of quality against speed.

There's lots Hendricks you can use though......for example scanning all reused objects and combining them to singular objects, using simple collision shapes for raycasting etc.
Back to top
Profile PM
Golelorn
7
Years of Service
User Offline
Joined: 20th Nov 2016
Location:
Posted: 24th Feb 2019 12:21 Edited at: 24th Feb 2019 12:21
Link
Ah, that makes sense, then.
I do combine all meshes that use the same shader. Didn't know collision shapes mattered. Will look into that! Thanks!
Back to top
Profile PM
Santman
12
Years of Service
User Offline
Joined: 15th Sep 2011
Location: Inverness
Posted: 24th Feb 2019 12:54
Link
I've not done much testing on collision shapes, but the collision checking is all triangles as I understand it, I imagine within a proximity of the raycast.

So if you have, for example, a table with 2500 triangles, gaps, holes etc, collision checking it is very difficult. If you create a plain cube with the same extremities, make it invisible, then collision check that, you only need one raycast below it's height and only 12 triangles need checked. And, these can also be combined to one mesh for "static" background checking. I think that why so many games have an almost grid like collision detection.....because they do!! Lol.

You can even see this in games like Metro Exoduss now, where there are complex environments but clear "square" areas where you can walk. I assure you, there not collision checking 150,000 triangles across all those objects every frame.
Back to top
Profile PM
Back to top

Login to post a reply

Server time is: 2024-04-24 14:35:40
Your offset time is: 2024-04-24 14:35:40