1
Graphics / Re: Glyph.Advance = 1093664768? (+ SEHExceptions)
« on: July 28, 2017, 06:12:03 pm »
Thanks, I'm now using CSFML 2.4 with the latest SFML.Net master, seems to work fine 
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.
Pages: [1]
2
Graphics / Re: Glyph.Advance = 1093664768? (+ SEHExceptions)
« on: July 28, 2017, 12:44:19 am »
I think I've identified the issue:
Decimal 1101529088 corresponds to binary 0-10000011-01010000000000000000000, which looks a lot like a 32 bit floating point value...
21.0f to be exact, which would be about the value I'd expect for a font size of 30.
SFML.Net 2.2 declares Advance as int, while SFML 2.2 (and therefore CSFML 2.2) handle it as a float value.
The current state of the git repository already declares it as float, but that won't be of any help until SFML.Net 2.4 is released (https://github.com/SFML/SFML.Net/blob/master/src/Graphics/Glyph.cs).
I guess I'll just change the declaration in my own copy if SFML.Net
Btw, I've been wondering about this: Is there any particular reason SFML.Net comes in separate 32 bit and 64 bit assemblies? AnyCpu works fine for me as long as I load the correct CSFML binary on runtime.
Cheers, Mario
Decimal 1101529088 corresponds to binary 0-10000011-01010000000000000000000, which looks a lot like a 32 bit floating point value...
21.0f to be exact, which would be about the value I'd expect for a font size of 30.
SFML.Net 2.2 declares Advance as int, while SFML 2.2 (and therefore CSFML 2.2) handle it as a float value.
The current state of the git repository already declares it as float, but that won't be of any help until SFML.Net 2.4 is released (https://github.com/SFML/SFML.Net/blob/master/src/Graphics/Glyph.cs).
I guess I'll just change the declaration in my own copy if SFML.Net
Btw, I've been wondering about this: Is there any particular reason SFML.Net comes in separate 32 bit and 64 bit assemblies? AnyCpu works fine for me as long as I load the correct CSFML binary on runtime.
Cheers, Mario
3
Graphics / Re: Glyph.Advance = 1093664768? (+ SEHExceptions)
« on: July 28, 2017, 12:35:25 am »
Okay, quick update:
With CSFML 2.2 it doesn't crash (my fault for mixing versions), however the incorrect glyph measurements persist.
Again, the buffer texture looks fine.
"Hello, world!"
Cheers, Mario
With CSFML 2.2 it doesn't crash (my fault for mixing versions), however the incorrect glyph measurements persist.
Again, the buffer texture looks fine.
"Hello, world!"
Cheers, Mario
4
Graphics / Re: Glyph.Advance = 1093664768? (+ SEHExceptions)
« on: July 28, 2017, 12:07:58 am »
The test was run with a fresh copy of SFML.Net 2.2 and the included "extlib" CSFML libraries from here (All compilers - 32-bit): https://www.sfml-dev.org/download/sfml.net/
For my main program this could indeed be an issue, since I'm using a non-standard SFML setup there.
I've compiled SFML.Net myself for AnyCpu and embedded both the 32bit and 64bit CSFML binaries inside of my assembly using Costura.Fody (https://github.com/Fody/Costura) to avoid having to ship multiple files.
I believe I'm using the CSFML 2.4 binaries with SFML.Net 2.2 there, let me check if I get different results with CSFML 2.2 (everything else works fine as far as I'm concerned).
Cheers, Mario
For my main program this could indeed be an issue, since I'm using a non-standard SFML setup there.
I've compiled SFML.Net myself for AnyCpu and embedded both the 32bit and 64bit CSFML binaries inside of my assembly using Costura.Fody (https://github.com/Fody/Costura) to avoid having to ship multiple files.
I believe I'm using the CSFML 2.4 binaries with SFML.Net 2.2 there, let me check if I get different results with CSFML 2.2 (everything else works fine as far as I'm concerned).
Cheers, Mario
5
Graphics / Glyph.Advance = 1093664768? (+ SEHExceptions)
« on: July 27, 2017, 08:59:19 pm »
Hey there,
a few days ago I started suddenly getting SEHExceptions or AccessViolationExceptions from within the unmanaged SFML assemblies every time I tried to call Font.GetGlyph.
Right before the crash, SFML writes the following error message to the console:
Failed to add a new character to the font: the maximum texture size has been reached.
Keep in mind that this happens on the very first glyph with a font size of 16 and a copy of C:\Windows\Fonts\arial.ttf, so under normal circumstances the buffer texture should be tiny (VRAM certainly isn't an issue).
So I decided to create a clean project with a freshly downloaded copy of SFML. This time it didn't crash, but I noticed something odd: The 'Advance' property of any glyph obtained by Font.GetGlyph is waaay off, somewhere in the single digit billions... I heavily doubt that's the expected behavior.
The generated texture looks normal though.
The issue occurs even if execute the program on another machine.
This is the code I used for the test:
And this is the output I'm getting:
Specs (In case that will be relevant)
Windows 10 Professional 64 bit (version 1703)
Intel Core i7-3820 (3.6 GHz)
32 GB memory
NVIDIA GeForce GTX 970 2-way SLI
Cheers, Mario
a few days ago I started suddenly getting SEHExceptions or AccessViolationExceptions from within the unmanaged SFML assemblies every time I tried to call Font.GetGlyph.
Right before the crash, SFML writes the following error message to the console:
Failed to add a new character to the font: the maximum texture size has been reached.
Keep in mind that this happens on the very first glyph with a font size of 16 and a copy of C:\Windows\Fonts\arial.ttf, so under normal circumstances the buffer texture should be tiny (VRAM certainly isn't an issue).
So I decided to create a clean project with a freshly downloaded copy of SFML. This time it didn't crash, but I noticed something odd: The 'Advance' property of any glyph obtained by Font.GetGlyph is waaay off, somewhere in the single digit billions... I heavily doubt that's the expected behavior.
The generated texture looks normal though.
The issue occurs even if execute the program on another machine.
This is the code I used for the test:
using System;
using SFML.Graphics;
namespace SFMLtests {
class Program {
static void Main(string[] args) {
var font = new Font("arial.ttf");
var a = font.GetGlyph('A', 16, false);
var b = font.GetGlyph('B', 16, false);
var c = font.GetGlyph('C', 16, false);
Console.WriteLine(a.Advance);
Console.WriteLine(b.Advance);
Console.WriteLine(c.Advance);
Console.WriteLine();
Console.WriteLine(a.Bounds);
Console.WriteLine(b.Bounds);
Console.WriteLine(c.Bounds);
Console.WriteLine();
Console.WriteLine(a.TextureRect);
Console.WriteLine(b.TextureRect);
Console.WriteLine(c.TextureRect);
font.GetTexture(16).CopyToImage().SaveToFile("font.png");
Console.ReadLine();
}
}
}
using SFML.Graphics;
namespace SFMLtests {
class Program {
static void Main(string[] args) {
var font = new Font("arial.ttf");
var a = font.GetGlyph('A', 16, false);
var b = font.GetGlyph('B', 16, false);
var c = font.GetGlyph('C', 16, false);
Console.WriteLine(a.Advance);
Console.WriteLine(b.Advance);
Console.WriteLine(c.Advance);
Console.WriteLine();
Console.WriteLine(a.Bounds);
Console.WriteLine(b.Bounds);
Console.WriteLine(c.Bounds);
Console.WriteLine();
Console.WriteLine(a.TextureRect);
Console.WriteLine(b.TextureRect);
Console.WriteLine(c.TextureRect);
font.GetTexture(16).CopyToImage().SaveToFile("font.png");
Console.ReadLine();
}
}
}
And this is the output I'm getting:
1093664768
1092616192
1093664768
[FloatRect] Left(-1) Top(-12) Width(12) Height(12)
[FloatRect] Left(0) Top(-12) Width(10) Height(12)
[FloatRect] Left(0) Top(-12) Width(11) Height(12)
[IntRect] Left(1) Top(4) Width(12) Height(12)
[IntRect] Left(15) Top(4) Width(10) Height(12)
[IntRect] Left(27) Top(4) Width(11) Height(12)
1092616192
1093664768
[FloatRect] Left(-1) Top(-12) Width(12) Height(12)
[FloatRect] Left(0) Top(-12) Width(10) Height(12)
[FloatRect] Left(0) Top(-12) Width(11) Height(12)
[IntRect] Left(1) Top(4) Width(12) Height(12)
[IntRect] Left(15) Top(4) Width(10) Height(12)
[IntRect] Left(27) Top(4) Width(11) Height(12)
Specs (In case that will be relevant)
Windows 10 Professional 64 bit (version 1703)
Intel Core i7-3820 (3.6 GHz)
32 GB memory
NVIDIA GeForce GTX 970 2-way SLI
Cheers, Mario
6
DotNet / Re: RenderWindow initialization delay
« on: July 26, 2017, 11:56:46 pm »
It seems to be about 200 ms slower on average, not exactly what I was hoping for :/
7
DotNet / Re: RenderWindow initialization delay
« on: July 19, 2017, 02:35:55 am »
>Run it through a profiler
I already did that, the result was just that the RenderWindow constructor takes ages to return.
>What framework do you use?
I'm compiling against .NET Framework version 4.5.2
I just updated my graphics drivers and nothing changed :/ (Version 384.76)
Btw: I'm now using a slightly different SFML setup, but the problem still prevails...
I've compiled the SFML.Net sources as AnyCpu and embedded the single managed and all 32 and 64 bit dlls into my executable to reduce clutter in the program directory.
But tbh I don't think this is relevant to the problem since everything is still acting as it was before.
I already did that, the result was just that the RenderWindow constructor takes ages to return.
>What framework do you use?
I'm compiling against .NET Framework version 4.5.2
I just updated my graphics drivers and nothing changed :/ (Version 384.76)
Btw: I'm now using a slightly different SFML setup, but the problem still prevails...
I've compiled the SFML.Net sources as AnyCpu and embedded the single managed and all 32 and 64 bit dlls into my executable to reduce clutter in the program directory.
But tbh I don't think this is relevant to the problem since everything is still acting as it was before.
8
DotNet / RenderWindow initialization delay
« on: July 11, 2017, 11:14:03 pm »
Hey there,
for some reason the SFML.Graphics.RenderWindow constructors behave very inconsistenlty on different setups.
If I run the attached program on my laptop, it only takes about 100 ms to create the window, however on my main machine the constructor doesn't return for about 2.4 seconds.
Both devices run the same build of Windows 10 Professional 64 bit, for more specs see below.
Other users have reported different times between 300 and 3000 ms.
The delay is consistent for each individual setup. E.g. my main machine always takes around 2400 ms.
I'm using SFML.NET 2.2 on top of CSFML 2.4 (also tried 2.2/2.2 and the NuGet configuration).
The problem occurs with both 32 and 64 bit, Debug and Release builds.
- Mario
Specs:
Laptop (~100 ms):
Microsoft Surface Book
Windows 10 Professional 64 bit (version 1703)
Intel Code i7 6600U (2.60 GHz)
8 GB memory
Intel HD Graphics 520 + Unspecified NVIDIA GPU
PC (~2400 ms):
Windows 10 Professional 64 bit (version 1703)
Intel Core i7-3820 (3.6 GHz)
32 GB memory
NVIDIA GeForce GTX 970 2-way SLI + multiple screens (maybe that's an issue?)
for some reason the SFML.Graphics.RenderWindow constructors behave very inconsistenlty on different setups.
If I run the attached program on my laptop, it only takes about 100 ms to create the window, however on my main machine the constructor doesn't return for about 2.4 seconds.
Both devices run the same build of Windows 10 Professional 64 bit, for more specs see below.
Other users have reported different times between 300 and 3000 ms.
The delay is consistent for each individual setup. E.g. my main machine always takes around 2400 ms.
I'm using SFML.NET 2.2 on top of CSFML 2.4 (also tried 2.2/2.2 and the NuGet configuration).
The problem occurs with both 32 and 64 bit, Debug and Release builds.
- Mario
static void Main() {
var sw = new Stopwatch();
sw.Start();
RenderWindow wind = new RenderWindow(new VideoMode(800, 600, 32), "Test");
sw.Stop();
Console.WriteLine($"Time to create window: {sw.Elapsed.Seconds}.{sw.Elapsed.Milliseconds:D3} seconds");
wind.Closed += (s, e) => wind.Close();
while(wind.IsOpen) {
wind.DispatchEvents();
wind.Clear();
wind.Display();
}
}
var sw = new Stopwatch();
sw.Start();
RenderWindow wind = new RenderWindow(new VideoMode(800, 600, 32), "Test");
sw.Stop();
Console.WriteLine($"Time to create window: {sw.Elapsed.Seconds}.{sw.Elapsed.Milliseconds:D3} seconds");
wind.Closed += (s, e) => wind.Close();
while(wind.IsOpen) {
wind.DispatchEvents();
wind.Clear();
wind.Display();
}
}
Specs:
Laptop (~100 ms):
Microsoft Surface Book
Windows 10 Professional 64 bit (version 1703)
Intel Code i7 6600U (2.60 GHz)
8 GB memory
Intel HD Graphics 520 + Unspecified NVIDIA GPU
PC (~2400 ms):
Windows 10 Professional 64 bit (version 1703)
Intel Core i7-3820 (3.6 GHz)
32 GB memory
NVIDIA GeForce GTX 970 2-way SLI + multiple screens (maybe that's an issue?)
Pages: [1]