Sprite Layer Drawing Problems in New Project

[h3rb]

I imported Fauxton 3D engine and I've attempted to filter just the Demo4 settings to test out the engine. After calling FAUXTON_START I created a test object. It draws the text object in 3D, but no matter what sprite I assign to it, only the first layer is the actual sprite I pick, everything else is some odd but repeatable cruft. It is different for every object. I also noticed I needed to "image_speed=0" because it was showing a rapid animation of the bottom layer showing the layers from the object.

Anyway I'm not sure what I've done wrong, but I'll include a screen shot. One shot is Fauxton, with the strange orange-redbar thing. The other is the same sprite stacked in a different engine.

Note that these same sprites look fine when I load them directly into the Fauxton project and replace the sprite for ob_cube

Is there some hidden project setting I'm not aware of?

[Gizmo199]

Interesting! It looks like for some reason the texture page is sampling texture coordinates outside of the the actual sprites tex coords generated by GM. I have it set up so that it automatically grabs the texcoords via 'sprite_get_uvs' and 'texture_get_uvs'. Try going into the texture options and turning off automatic texture cropping and let me know if that helps? Also you can try selecting the 'separate texture page' option in the sprite 'texture settings' and see if that helps either. '

[h3rb]

Turning off "automatic crop" solved the issue.

Thanks!

[h3rb]

However, trying another sprite, resulted in a different issue where the wrong layers are selected still.

When you say "make your own texture group" .. is that Per Sprite? or "for all sprites that are layered voxels"

[h3rb]

It appears it only makes sense if the setting is "per sprite" and I assume this means a texture swap for each object.

[h3rb]

This was the result of "try selecting the 'separate texture page' option in the sprite 'texture settings'"

[h3rb]

Looking at the internal function, I'm wondering why you don't just use the TUV values and are dependent on the UV values?

forgive me, I'm not 100% certain how your code works below this area

obviously you are looking for textures that are sprite-strips or equivalent? or assembling an array (matrix) of these coords

[h3rb]

I am going to try turning off Seperate Texture Pages and see if a texture group helps (one per sprite)

[h3rb]

None of these in combination or isolated helped, unfortunately.
So, the latest I'm trying it on is a 65 frame 128x128 sprite, which should fit on a texture (since texture max sizes are huge these days), but turning on/off only results in different wrong layers being shown.

sprite_get_tpe() maybe? I dunno.

[h3rb]

Perhaps it would be good if I could load them as strips instead of individual layers, and "tell" your engine to use it that way instead. I suspect this is due to multiple texture pages... there is also that sprite_prefetch_multi() ...

[Gizmo199]

Hey, yeah that is very strange? What version of GM are you using? And the main reason I have different UV functions is for HTML5 compatibility, since HTML5 doesn't return offset values for some reason in GM. If you are wanting to do it the sprite strip way there is also another engine that is really good for sprite stacking called Stack3D: https://dev-dwarf.itch.io/stack3d

[h3rb]

I'm using the latest GM, 2.3.7.606

I like your engine and I wanted to extend it. The biggest issue with your engine is its support for large worlds, and also there is a performance decrease during the first few frames. Otherwise, it is a very nice engine. I have my own Stacking engine, but it uses a for loop (the gifs above are in a version derived of of https://marketplace.yoyogames.com/assets/9639/sprite-stacked-light-engine doesn't use shaders) .. in my version I use a for loop that iterates through shader draws. This is fine for a small amount of enemies, but if you have > 100 it becomes very slow.

[h3rb]

I'm not really excited about using strips. I am just trying to figure out how to guarantee the UVs are correctly calculated. The problem I've been concerned about writing shaders into my engine is related to the fact that there is a rather low limit of texture inputs (32 usually, sometimes 16), and I'm not sure how to guarantee the sprite will be 100% on the same texture page. Perhaps there's more to this we can try?