next »

[s_l_m]

Apparently Unity can't generate random numbers from a second thread, because why wouldn't it have some weird bullshit like that?

Edit: I guess switching my code to use the system random instead of the built in Unity random functions works, it's just such a strange limitation

[Geti]

Probably don't want race conditions for reproducibility (which the system random doesn't offer afaik) - I usually write a simple xorshift random for each thread or context that I need - helps to prevent breaking seeds for generators when you add a new subsystem (of course, sometimes its unavoidable, but it's better than calling some global)

[s_l_m]

Probably don't want race conditions for reproducibility (which the system random doesn't offer afaik) - I usually write a simple xorshift random for each thread or context that I need - helps to prevent breaking seeds for generators when you add a new subsystem (of course, sometimes its unavoidable, but it's better than calling some global)

Mhmm, I think I might just write a simple random generator, I am using System.random for now but I would much rather have this thread be as self contained as possible. Also, System.Random conflicts with the unity random stuff if you don't specify so it is probably for the better I avoid it

[Whiteclaws]

ARGHHHH...

BECAUSE OF ONE SPACE IN MY GLSL SHADER , MY PROGRAM SHOWED A BLACK SCREEN

TRIED RE-WRITING 5 TIMES , AND BEEN SCRATCHING MY HEAD FOR 4 WEEKS AND MY CODE WAS GOOD FROM THE BEGINNING !!!!!

AND COMPILER DIDN'T SAY NOTHING ABOUT THIS ...

//Not Working
#version 330
 
 layout(location = 0) in vec3 Position;
 
 void main()
 {
    gl_Position = vec4(Position, 1);
 }
 
//Working
#version 330
 
layout(location = 0) in vec3 position;
 
void main()
{
    gl_Position = vec4(position,1);
}
 
////////////////////////////////////////////////////////////////////////////////////////////

Edit :
Uh...

My head hurts from me hitting the wall with it

I guess I learnt my lesson ... the hard way ...
C/C++ devs ... I feel your pain...

[Polly]

Whiteclaws, grab AMD's GPU ShaderAnalyzer to standalone compile shaders ( against a whole slew of cards )* Easiest way to catch these kind of mistakes ( and more ).

*Doesn't actually use your GPU, so works fine on NVIDIA / Intel etc. systems too.

[ThemsAllTook]

BECAUSE OF ONE SPACE IN MY GLSL SHADER , MY PROGRAM SHOWED A BLACK SCREEN

Was it the space, or the capitalization of Position? Latter seems more likely to me, but I don't know all the quirks of the GLSL compiler.

[kamac]

I'd guess it was the space before the layout keyword, maybe?

[InfiniteStateMachine]

possibly, does the GLSL even take into account line breaks and carriage returns?

[powly]

It should ignore all white space that doesn't separate actual expressions apart from line breaks for single line comments (and expressions like 'int a' obviously need that space) so I'm very curious about what's going on. Always remember to consult the compilation error log (and recent drivers) since it actually tells you what's wrong - shader development is a big enough pain in the beginning even if you do. ShaderAnalyzer is a good way to check strictness if you're not on AMD hardware. There are also a couple of debug extensions that seem very nice but I haven't touched them myself quite yet so hard to say if I should recommend them

As a side note, neither version is valid GLSL; you're doing an implicit cast. It should be '1.0' in the vec4().

[Saishy]

I frequently run into problems because Unity think it's cool to discard any decimal result of a integer division.

Because logically, if you are dividing integers it should never have decimal results!

AAAAARRRGGG

[ThemsAllTook]

I frequently run into problems because Unity think it's cool to discard any decimal result of a integer division.

Most C-family languages work like that. Integer division is a distinct operation from floating point division. Can be a pain if you don't know/don't remember the exact semantics of the language you're using...

[rosholger]

gaaaaaah!!
somewhere inside a loop that does't touch the this pointer, it's getting fucking corrupted!! 
fuck this!!

[Geti]

Lol potential heap corruption.

You properly sure it's inside the loop?

[Endurion]

If the this-Pointer looks corrupted you usually need to look one stack trace level higher. You probably called a method on an invalid (deleted or not initialised) object.

[rosholger]

Lol potential heap corruption.

You properly sure it's inside the loop?

yup pretty sure, since the this-pointer works before that loop but not after.

If the this-Pointer looks corrupted you usually need to look one stack trace level higher. You probably called a method on an invalid (deleted or not initialised) object.

the strange thing is that the this-pointer looks fine in the stack trace level above, and both are member functions of the same object.

i actually found the problem, it was a buffer overflow that caused it

[gimymblert]

I use to hate programming, but now it's not there I crave it so much more so that getting back into drawing

[Saishy]

All hail unity and monodevelop
http://puu.sh/5DHbF.png
http://puu.sh/5D44Z

Can't program anymore.

[Prads]

Trying to use GL_LINEAR filter for the texture but it's not working. It has no effect and texture looks same as using GL_NEAREST. I have done this in other programs and it has worked before, just can't figure out why it's not working now. Can anyone check it please?

Code:

glGenTextures(1, &frameTexture);
glBindTexture(GL_TEXTURE_2D, frameTexture);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGBA, 1024, 1024, 0, GL_RGBA, GL_UNSIGNED_BYTE, 0);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);

[makerimages]

Cant figure out why the text is not drawing

.h

Code:

#pragma once
#include <string>
#include "GameObject.h"
#include "GameWindow.h"
#include <SFML/Graphics.hpp>
class MessageBox
{
public:
	MessageBox(void);
	MessageBox(std::string title, std::string content,int x, int y,GameObject* gameO,GameWindow* wI);
	~MessageBox(void);
	void draw();
protected:
	sf::Font font;
	sf::Font* boxFont;
	sf::Text* titleT;
	sf::Text contentT;
	int xPos;
	int yPos;
	sf::Sprite* spr;
	GameObject* game;
	GameWindow* windowIn;
};

.cpp

Code:

#include "MessageBox.h"

using namespace std;
MessageBox::MessageBox(string title, string content, int x, int y,GameObject* gameO, GameWindow* wI): xPos(x), yPos(y),game(gameO), windowIn(wI)
{
	
	if(!font.loadFromFile("data/fonts/LCALLIG.ttf"))
	{
		printf("Error loading font! \n");
	}
	boxFont=&font;
	titleT=&sf::Text(title,*boxFont);
	spr=game->getSpriteManager()->getSprite(3);
	spr->setPosition(xPos,yPos);
	
}


MessageBox::~MessageBox(void)
{
}
void MessageBox::draw()
{
	
	windowIn->getWindow()->draw(*spr);
	windowIn->getWindow()->draw(*titleT);


	
}
MessageBox::MessageBox(void)
{
 }

spr draws, on its own, titleT doesnt...

[ThemsAllTook]

Trying to use GL_LINEAR filter for the texture but it's not working. It has no effect and texture looks same as using GL_NEAREST. I have done this in other programs and it has worked before, just can't figure out why it's not working now. Can anyone check it please?

Are you scaling up or down? Given that it's a 1024x1024 texture, I'm guessing you might be scaling down by a lot. GL_LINEAR looks pretty bad with too much downscaling (sometimes similar to GL_NEAREST); you'd get better results with mipmaps.

As an aside, calling glTexParameter before glTexImage2D is supposedly optimized better on some architectures. Probably wouldn't hurt to swap those around.