-
Posts
2,412 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Downloads
Posts posted by SpiderPig
-
-
Okay thanks!
-
I found the problem to be the world size. Making it bigger allowed the shadows to show up. @Josh I'm curious as to what exactly setting the world size does, because so far my models have been showing up fine, it's just the shadows that was affected.
-
I'd use a class to store the information;
class LoadOut { private: string saveTitle = "Assault Pack"; vector<(type)> weaponsList; public: };
This will work for saving between map loads. If you want to save between games you can use the Leadwerks FileSystem to save the list to a file.
Is your players inventory in LUA though?
-
You could use sin() and cos() to get an xy position based on an angle.
UV.x = sin(angle) UV.y = cos(angle)
-
There seems to be functions under Steamworks in C++. Type Steamworks then :: to see the functions available.
-
1
-
-
What are you trying to access in the steam API?
-
Scripts can still be attached to objects. There should be a visual studio project file in one of the folders of your project, under Project->Windows i think...?
Load that up, and you'll see in App.cpp the code that executes Main.lua. You should just need to recode Main.lua into App.cpp and go from there.
-
Okay, I got it working with the tool you posted thanks.
-
1
-
-
Any idea when this could be fixed?
-
Just curious as to why a normal map should use the later compression mode? Does it preserve detail in a different way than DTX5?
-
I'm not sure why it's needed either. I will be looking into it more as i dont think its just the texture array shader. I have a shader that uses a storage object and it dosnt work with zsort on. I'll see if I can track the problem down.
-
I guess I'll have to leave texture arrays alone then. Don't want to not use MSAA ?
Will turbo be different regarding the depth texture? Can we also have the option to use texture arrays?
-
Quote
So it does not occur when MSAA is disabled.
Correct.
What I noticed with texture arrays is, the material had to have z-sort enabled in order for the textures to show. With z-sort enabled on my terrain, and MSAA enabled I get this issue. Can the resolution of the depth texture be changed to match the context or is this impractical?
-
When changing it from off to 2x it looks like the buildings actually move slightly..
-
Yeah. It's worse at higher levels too. I've tried up to 16x.
-
It was set to 2x.
-
No Nvidia. GTX 980 Ti
-
The arrays don't like working with z-sort off... with z sort off everything is black. With it on I get the sky seeping around the edges of buildings. Same problem as here; https://www.leadwerks.com/community/topic/17428-background-seeps-around-edges/#comment-113247
I can't turn Z-Sort on everything because the tree models don't like it on... EDIT : This happens with multi-sampling on at any level.
-
That did the trick, thanks
-
This code shows a yellow texture;
int _width = 512; int _height = 512; char* buf = new char[ _width * _height * 3]; int index = 0; for (int x = 0; x < _width; x++) { for (int y = 0; y < _height; y++) { buf[index] = 255; buf[index + 1] = 255; buf[index + 2] = 0; index+=3; } } OpenGLShader* shader = (OpenGLShader*)mat->GetShader(); glUseProgram(shader->program); GLuint _buffer; glGenTextures(1, &_buffer); glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D_ARRAY, _buffer); glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MAX_LEVEL, 0); glTexImage3D(GL_TEXTURE_2D_ARRAY, 0, GL_RGB8, _width, _height, 1, 0, GL_RGB, GL_UNSIGNED_BYTE, nullptr); GLenum e5 = glGetError(); glTexSubImage3D(GL_TEXTURE_2D_ARRAY, 0, 0, 0, 0, _width, _height, 1, GL_RGB, GL_UNSIGNED_BYTE, buf); glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MIN_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
However loading a texture with a different size at the beginning (1024 x 1024) causes the crash.
Texture* texture = Texture::Load("Materials\\bluegrid.tex");//1024x1024 int _width = 512;//works if these are made 1024 as well int _height = 512; char* buf = new char[ _width * _height * 3]; int index = 0; for (int x = 0; x < _width; x++) { for (int y = 0; y < _height; y++) { buf[index] = 255; buf[index + 1] = 255; buf[index + 2] = 0; index+=3; } } OpenGLShader* shader = (OpenGLShader*)mat->GetShader(); glUseProgram(shader->program); GLuint _buffer; glGenTextures(1, &_buffer); glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D_ARRAY, _buffer); glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MAX_LEVEL, 0); glTexImage3D(GL_TEXTURE_2D_ARRAY, 0, GL_RGB8, _width, _height, 1, 0, GL_RGB, GL_UNSIGNED_BYTE, nullptr); GLenum e5 = glGetError(); glTexSubImage3D(GL_TEXTURE_2D_ARRAY, 0, 0, 0, 0, _width, _height, 1, GL_RGB, GL_UNSIGNED_BYTE, buf); glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MIN_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
-
With no compression it is, yes. Even if i didn't use the texture that I loaded, and set the pixels for the array manually after loading the texture, the two different sizes would cause the crash. Obviously it's something that's easily avoided now, I'm just more curious as to why it happened.
-
Okay I've solved it. If I use a 4096x4096 texture the crash occurs. Using a 1024x1024 works perfectly. @Josh any ideas why this would happen?
EDIT : Something is being set when loading the texture before assigning it to the array. If I don't load the texture and set my own, any size works. But if I load an image before making my own to assign to the array and the two sizes don't match, it crashes.
-
Finally got it to work in a dedicated project, but not in my game. Here's the code that works;
Model* box = Model::Box(); box->Move(0, 1, 0); Material* mat = Material::Load("Materials\\Test.mat"); box->SetMaterial(mat); Texture* texture = Texture::Load("Materials\\bluegrid.tex"); int _width = texture->GetWidth(); int _height = texture->GetHeight(); int sze = texture->GetMipmapSize(0); char* buf = new char[sze]; texture->GetPixels(buf); OpenGLShader* shader = (OpenGLShader*)mat->GetShader(); glUseProgram(shader->program); GLuint _buffer; glGenTextures(1, &_buffer); glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D_ARRAY, _buffer); glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MAX_LEVEL, 0); glTexImage3D(GL_TEXTURE_2D_ARRAY, 0, GL_RGBA8, _width, _height, 1, 0, GL_RGBA, GL_UNSIGNED_BYTE, nullptr); glTexSubImage3D(GL_TEXTURE_2D_ARRAY, 0, 0, 0, 0, _width, _height, 1, GL_RGBA, GL_UNSIGNED_BYTE, buf); glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MIN_FILTER, GL_LINEAR); glTexParameteri(GL_TEXTURE_2D_ARRAY, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
However the exact same code in my game project fails with an access violation at this line in assembly;
0371FCE9 movzx ebx,byte ptr [esi+2]
I'm using the same material and shader as the testing project, and am setting things up the same and at the begging in the Start() function after setting up the window, context and camera. I'm wondering if it could be something setup wrong in the solution settings? Any ideas?
-
Quote
After talking to @Argent Arts trying to figure out what was happening I managed to reproduce the problem.
I have two screens of the same model both set to a resolution of 1920x1080 (which is their native resolution) in which full screen works fine.
If I set one or both of these to a resolution below their native, the problem happens.
@Argent Arts is using two screens as well, but both are different models and have different native resolutions. By setting the lower native resolution screen to the primary Leadwerks ran in full screen but only on that screen, not the bigger one.
I'm not sure how Leadwerks manages full-screen mode, but from what looks to be happening, it seems Leadwerks is using the correct resolution of the screen for it's window, but is somehow scaling the result down as if the screen was still using it's native resolution.
The scaling options for Windows 10 would also do this because it would scale it up to be different from the native as well.
I'm not positive but with the Issue of the Leadwerks window appearing off screen, probably relates to the difference between native and current resolutions too.
Is anyone else able to reproduce this problem by changing their screen resolution?
QuoteJust had a thought and looked at it again, when Leadwerks runs it is actually changing the screens resolution back to native
EDIT : I changed my primary screen to 1680x1050 and had two black bars on the sides due to the aspect ratio. When Leadwerks ran these bars disappeared.
Did you see my earlier replies Josh? I managed to replicate the problem like this.
-
1
-
Character Controller Adjustments
in Suggestion Box
Posted
Don't mean to bother you @Josh, but do you think getting the character controller to align to the direction it's falling could be in the next update? I'm hoping to release my game early next year...
What I'm doing is adding a force to each character controller in the direction of gravity. I just need the controller to align itself to that direction, and behave like normal.