16
System / Re: limker error when using sf::time operators
« on: November 02, 2014, 11:04:05 am »
If you set incompatible compiler options you want to get an error, because thats much better than silent corruption at runtime.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
17
System / Re: Pass paramater/argument's address to thread's function which is in class in SFML
« on: November 02, 2014, 10:57:31 am »
The thread in codeblocks forum you linked is more than one and a half years old, back then TDM 4.7.1 may have not supported std::thread, but 4.8.1 does: http://tdm-gcc.tdragon.net/ . That also suggests you are still using outdated codeblocks 12.11, when the newer 13.12 is better and can be got with an included TDM 4.8.1.
You should not use the compiler menu for setting build options, because that setting is only for that computer and will be forgotten if you copy your project to another. Open your project instead and rightclick on it and choose build options, to get a similar menu that works for saving the options in the project file, but dont forget to set it for both Debug and Release.
Also they do not add all GCC options to the code::blocks menu and when you have an old version you may need to set the older -std=c++0x instead of -std=c++11 (or type it into Other Options yourself).
Btw., there is an option in the compiler menu/Other Settings to show the full command line, activate it and see for yourself what gets passed to g++!
You should not use the compiler menu for setting build options, because that setting is only for that computer and will be forgotten if you copy your project to another. Open your project instead and rightclick on it and choose build options, to get a similar menu that works for saving the options in the project file, but dont forget to set it for both Debug and Release.
Also they do not add all GCC options to the code::blocks menu and when you have an old version you may need to set the older -std=c++0x instead of -std=c++11 (or type it into Other Options yourself).
Btw., there is an option in the compiler menu/Other Settings to show the full command line, activate it and see for yourself what gets passed to g++!
18
General / Re: making a cross platform program
« on: October 27, 2014, 10:39:23 am »
Actually, I found its really easy to build many kinds of Makefile, Solutions, Projects using Premake: http://industriousone.com/what-premake . Its got simple Lua syntax, that means, no typing in arcane commands that cmake, make, autostuff, ant, ... need; and it lets you create those files even from different OS. Downside is one currently has to use an old 4.4beta, but they are working on 5.0.
19
Window / Re: Where to place Window and Events using xCode?
« on: October 24, 2014, 12:47:47 pm »
Just placing part of your code into a different file does not create another thread. There is no reason to put all code into main, only simple examples do that.
20
Graphics / Re: Text height
« on: October 24, 2014, 12:39:56 pm »
getLocalBounds can be different depending on the text string. If you actually had a "p" in the string it should reach further down to include the bar-part reaching below the o-part. getGlobalBounds is the same, just transformed into a global coordinate system.
getCharactersize should be the maximum allowed height that cant be drawn outside of when using any character, including "ÂÖgq|".
getCharactersize should be the maximum allowed height that cant be drawn outside of when using any character, including "ÂÖgq|".
21
Graphics / Re: Text height
« on: October 22, 2014, 05:01:48 pm »
If you want the maximum height independent of the actual text string it should be same as getCharacterSize/setCharacterSize.
22
General discussions / Re: Insomniac Game Engine Developer Shares Some Thoughts On Engine Design
« on: October 21, 2014, 02:22:13 pm »
It can be simpler to have a structure of arrays instead of an array of classes, because it eliminates the need for that class to access many different systems. Then you are able to keep the physics code for bullets and other things together somewhere and the rendering code together somewhere, without it being intermingled by having bullet code together, code for other single real world object together.
23
General discussions / Re: Insomniac Game Engine Developer Shares Some Thoughts On Engine Design
« on: October 21, 2014, 01:55:58 pm »
That Data Oriented Design reduces cache misses is a nice sideeffect, and sure people advocating it always include telling about it, because it really is nice.
Then people hear that and think "Ahh, its only about optimizing cache misses, I dont need that, therefore its wasting programmer time". The real point they are missing is that it helps if you dont need to look at dozens of layers of trees of overengineered classes (http://en.wikipedia.org/wiki/Lasagna_code) every time you need to find out whats really going on. Instead, if you have the data directly inside several homogenous arrays, a number of simple to understand loops directly operating on it is all thats needed.
For the bullet example, instead of packing everything into one class, it might be better to split it up and have, for example, an array of positions, another with its velocity and other physical data, and shared data for the visual appearance.
Then people hear that and think "Ahh, its only about optimizing cache misses, I dont need that, therefore its wasting programmer time". The real point they are missing is that it helps if you dont need to look at dozens of layers of trees of overengineered classes (http://en.wikipedia.org/wiki/Lasagna_code) every time you need to find out whats really going on. Instead, if you have the data directly inside several homogenous arrays, a number of simple to understand loops directly operating on it is all thats needed.
For the bullet example, instead of packing everything into one class, it might be better to split it up and have, for example, an array of positions, another with its velocity and other physical data, and shared data for the visual appearance.
24
Feature requests / Re: small & stupid api changes: radians, vectors, colors
« on: October 12, 2014, 11:49:11 pm »
Using your new contructor with a hex literal will obviously work like you want.
Doing an unsafe pointercast or using such a union, setting bytes first, then as a misoptimization reading the whole as an Uint32 would reverse it on little endian. And sure one should not do such as it depends on undefined behaviour, it was just a tiny example to demontrate its not needed to willingly use abgr and still get data in reverse order, to show it needs good documentation.
PS: Yes, I should not have shortened the example by replacing the struct I had there first with sf::Color and possibly have tried to compile it beforehand.
Doing an unsafe pointercast or using such a union, setting bytes first, then as a misoptimization reading the whole as an Uint32 would reverse it on little endian. And sure one should not do such as it depends on undefined behaviour, it was just a tiny example to demontrate its not needed to willingly use abgr and still get data in reverse order, to show it needs good documentation.
PS: Yes, I should not have shortened the example by replacing the struct I had there first with sf::Color and possibly have tried to compile it beforehand.
25
General / Re: SFML tests and examples crash with "Process returned -1073741819 (0xC0000005)"
« on: October 12, 2014, 10:41:02 pm »
You can try http://www.realtech-vr.com/glview/ to see which OpenGL version and extensions are supported on your computer.
I would look at the Intel page again to see if you downloaded the wrong package and there is another for your OS (or if not look through older packages if they support it).
I would look at the Intel page again to see if you downloaded the wrong package and there is another for your OS (or if not look through older packages if they support it).
26
Feature requests / Re: small & stupid api changes: radians, vectors, colors
« on: October 12, 2014, 10:14:51 pm »
Even if someone uses r,g,b,a it can still result in a different byte order depending on the endianness:
union {
Uint32 rgba;
sf::Color sfcolor;
} mycolor;
mycolor mc;
mc.sfcolor=sf::Color::Green;
sf::Color color(mycolor.rgba);
if(color==sf::Color::Blue)
std::cout << "argh" << endl;
Uint32 rgba;
sf::Color sfcolor;
} mycolor;
mycolor mc;
mc.sfcolor=sf::Color::Green;
sf::Color color(mycolor.rgba);
if(color==sf::Color::Blue)
std::cout << "argh" << endl;
27
General discussions / Re: Clipboard support on Linux: A few hiccups.
« on: October 12, 2014, 01:50:08 pm »
If I may say so, I think that its natural to have this associated with the window and adding hacks with global variables to avoid that would not be worth it.
Though if you need to have it more complicated, just add a proxy Clipboard class, require the window reference in its constructor and forward method calls to the window.
Though if you need to have it more complicated, just add a proxy Clipboard class, require the window reference in its constructor and forward method calls to the window.
28
Feature requests / Re: small & stupid api changes: radians, vectors, colors
« on: October 12, 2014, 01:29:49 pm »
The problem I see with doing that is: there is no standardized way of packing rgba into an int.
29
Graphics / Re: Changes in RenderTextures/Texts?
« on: October 09, 2014, 10:00:41 pm »
Excuse me, but misread again, the bug is in padded textures and is not from a new change (git blame/log/diff on these didn't help) and is not in the text rendering. 
To clarify it a bit more, when textures are created they are allocated with power of two size if needed (GL_ARB_texture_non_power_of_two not available), but the texture coordinates/matrix are subtly mishandled in bind method in that case and then its made look worse cause the padding is (at least in some cases) not initialized.
To clarify it a bit more, when textures are created they are allocated with power of two size if needed (GL_ARB_texture_non_power_of_two not available), but the texture coordinates/matrix are subtly mishandled in bind method in that case and then its made look worse cause the padding is (at least in some cases) not initialized.
30
Graphics / Re: Changes in RenderTextures/Texts?
« on: October 07, 2014, 03:57:11 pm »
You seem to not have read the thread carefully enough?
TLDR:
- I wrote I'm capable and willing to do the work on finding the causes of the problems myself.
- I politely asked about background information with respect to recent changes (after having traversed the git history for file changes already) and I'd still like to know, for example, if the change to the mirroring is a new glitch or a bugfix as I did not find the commit.
- I put some effort in providing a timely answer, gave as much information as I had at that time, told I'm still working on it and promised the example code for later.
Meanwhile, using the debugger, I found where the root of the problem with showing uninitialized memory and too small text lies. Its a mishandling of padded textures inside SFML that exists for a very long time already and that is mostly invisible, except under rare circumstances. I'll add an issue on the tracker when the test programs are ready.
Changes with the text rendering had only a very minor effect, which I already adapted to.
TLDR:
- I wrote I'm capable and willing to do the work on finding the causes of the problems myself.
- I politely asked about background information with respect to recent changes (after having traversed the git history for file changes already) and I'd still like to know, for example, if the change to the mirroring is a new glitch or a bugfix as I did not find the commit.
- I put some effort in providing a timely answer, gave as much information as I had at that time, told I'm still working on it and promised the example code for later.
Meanwhile, using the debugger, I found where the root of the problem with showing uninitialized memory and too small text lies. Its a mishandling of padded textures inside SFML that exists for a very long time already and that is mostly invisible, except under rare circumstances. I'll add an issue on the tracker when the test programs are ready.
Changes with the text rendering had only a very minor effect, which I already adapted to.