Sorry your browser is not supported!

I'm using some code so I can use a single texture for all my 3D tile surfaces to create a level with. For some odd reason it stopped working now.

Did any of these commands change in AppGameKit Studio compared to AppGameKit 2 ???

SetObjectMeshUVScale( )
SetObjectMeshUVOffset( )

I'm using a version of the code that allows us to change textures or add texture animations to 3D objects. In this case it's really just a level generator that changes the texture once.

For some weird reason it now doesn't calculate the correct texture anymore, including height and width. The texture is 340 pixels by 384 pixels. And works fine in AGK2.

I guess it's being rendered differently now?? Or any other things that affect the UV mapping now?


the yellow comes from yellow pixels being basically the last tile, you can see the texture used in the AppGameKit Studio view.

Exact same code, but ran in AGK2 :

I am guessing it is Vulcan related?? edit: Or maybe not, #renderer "Basic" doesn't change anything. Because the code still works fine when broadcasting the code to Android device:

Short answer is yes, UV has changed, but more corrected rather than merely altered. Previously, the UV offset state didn't seem to correlate properly with scale. That is, AppGameKit would apply the offset first before handling the scale. It should have been applying the scale first, then the offset. So if you scaled to a particular level and then offset, you'd shift by offset initially rather than account for the scaling first. So in your code, you'll just need to account for this corrected formatting and adjust your offsetting accordingly (you don't need to change your scaling factors). There may also be differences in the default uv wrap setup, but I haven't tested that much yet as I typically specify my own anyway at the beginning of my projects. So that might just be something else to double check:

SetDefaultWrapU(1)
SetDefaultWrapV(1)

But for now when it comes to offsetting, you will need to use your original approach when outputting to Android as that uses the older render path with the older (incorrect) UV offsetting. Then have a variable for a mode switch to compile for the other desktop options as may be needed when building/testing for different platforms. One of the reasons for my request of a 'GetRenderMode' option was to account for differences like this where if a variation was required in either the Andoird-GL, OpenGL, or Vulkan render path, we could detect it and account for it as needed in code with a simple 'if/endif' block. This would also lets us specify shaders, parameters, and anything else that need to be different between different rendering paths. So I'm still hopeful that such an option will be available that better accounts for differences that may be required between rendering options. There are some parameter specific checks you can use currently, but nothing yet as global as would be needed.

From Paul Johnson
"This is due to a UV offset change, previously the offset would get scaled by the UV scale amount, but in the new AppGameKit the UV offset does not get changed by the scale. I think it makes more sense that way. In this project changing these two lines would fix it
inc io, 0.25
if io > 0.75"

In my case i think i had used
inc io,1
if io >3

To iterate through 4 images

So basically now i think it's always a value between 0 and 1. As far as i can see the new approach works for "Basic" renderer as well.

Yikes. I don't think it's very good that we now have to deal with two render paths at all.

Isn't there a way where the same code would result in the proper texturing? Maybe the order of code? I've tried changing the offset before setting the scale, but it doesn't change anything. It almost seems like the particular texture trick won't work in AppGameKit Studio. Maybe I'm missing something here when it comes to your explanation.

edit: Thanks blink0k . From the sound of it, I have to change the offset values then. Hmm. Sounds like I have to change a lot of code for that then.

When it comes to UV scaling and offsetting, I'm hopeful that won't always be the case. Eventually, the OpenGL render paths should be aligned with the new Vulkan format.



For now, you will need to separate the two, but they should all eventually be aligned with the corrected Vulkan render path. Just keep your code adjustable with value checks so it can quickly change and adapt as needed when/if things changed in future updates.

And lastly, you simply need to change the offsetting -values-, not the order of scaling vs offsetting (that's only how AGKS now handles things internally to explain the difference in behavior). If you change the scaling at all, then you need to change your offsetting to accommodate a 1:1 baseline. It's actually a little easier to manage things that way as well.