Sorry your browser is not supported!

So, I've been working on a scene where I draw a textured matrix as terrain and place a few grass and bush models on top. All the objects all draw with a Mipmap flag of "0", transparency as "1", and are textured with .png images supporting transparency. It all renders nice in vanilla DBPro, but when I initiate an RTS Sky System from Extends, the sky seems to "reflect"(is this the right word I'm trying to use to describe this????) the textures and colors from the sky system onto the textured matrix(shown as transparent stars), and the 3D models of grass/bushes(shown as solid objects of color similar to that used in sky objects). Here's an image of side-by-side comparison.

Here is all the relevant rendering-related code. Of course this is a large game project with multiple source files and functions that would be unnecessary to share, so these are just the sections that I believe are relevant to look at. Be aware the project is using a default camera of #0.




And yes, the RTS Sky System loaded is simply a rename of one of the tutorial skies, so it can be considered flawless in construction. Thanks to anyone that can provide me any pointers, ideas, or help with this strange anomaly!

I'm having difficulty relating your description to the second image.

In particular how does this relate to the images shown?



I can't see any textures on the terrain in the second image - and no stars either.



What do you mean? One image shows flat terrain, the other shows hills.

Minor query on your code: why have you used floats for grass object IDs? Seems hazardous to me - they should be integers.

I might just be the transparency mode - I think mode 1 is unsorted, so Zdepth tends to mess with alpha transparency. Experiment with those transparency modes. Alpha transparent foliage can act weird - like I have a test engine I'm working on, and used a simple skysphere which caused the foliage to look horrible, like it was blending with the skysphere instead of the terrain. Strangely, this went away when I added 2 effect cameras for refracted/reflected water, now the foliage looks fine whatever it's in front of, even the water plain blends nicely with it. Perhaps sync masking forces the camera renders to Z sort better.

So, it's maybe best to wait until you add any additional cameras you need before worrying too much about it, then try the different transparency modes.

Thanks for the help everyone! It turned out my problem was actually the fact that the RTS Sky System silently creates 11 objects and 11 corresponding images as textures for the sky system(Starting from ID# 1-11). This conflicted with my texture IDs, causing the objects to look like part of the sky(because they literally were textures of the sky). I've spent the whole morning bashing my head on my desk trying to figure out this problem and when I realized the sky system probably had to declare some form of DB objects/images the realization immediately hit me that it simply conflicted. A simple Object/Image Exist check confirmed that I was a right.

A word of advice for those who use Extends RTS Sky, leave Object/Image slots 1-11 empty for the system!!! -I just wish the technical documentation would have informed me of this before hand.



*And yes Gandalf, It's probably better I use integers rather than floats to prevent the possibility of throwing an error from putting in a number that isn't a whole number. In truth, I'm comfortable with variable types in C++ and C#, but in DarkBasicPro, all I've ever learned is the "float: #" and "string: $" from the basic help HTML that came with the software. How would I go about declaring other variable types? Could you link some documentation if possible? Thanks!

a basic integer is just a basic variable name:

a = 1
a# = 1.0
a$ = "one"

you can also declare a type:

a as integer
a = 1

a as string
a = "one"

the help page regarding this is reached f1(main) -> principals -> data types and variables

there are a number of types available including boolean, byte, doubles and others

It's potentially worse than that. If you happen to use very large values, such as object IDs in excess of 6 digits, you might find that the integer conversion gives a quite different ID because floats use a fixed number of significant digits. Sample snippet - notice how the conversion back to an integer doesn't give the original desired integer value a.