I want to revisit this issue.
Building 64 bit on Linux, release or debug, is fast. However,
building 64 bit release on Windows 10 is super slow. I have a
cross platform app that uses gtk-d. Today, I updated DMD to
2.079.1 and the gtk-d lib to 3.8.0. When I performed a debug
build on Windows 1
On Wednesday, 14 February 2018 at 00:22:25 UTC, flamencofantasy
wrote:
Maybe these work, not sure;
https://github.com/Rikarin/VulkanizeD
Thanks, I'll check this out.
On Wednesday, 14 February 2018 at 02:40:18 UTC, Mike Parker wrote:
What [does] it mean to say they don't work? Have you reported
any issues? I don't see any in the DerelictVulkan repo. If
something's broken, please report it so it can be fixed.
Derelict-vulkan is Windows only ATM.
I wanted to do some experimentation with Vulkan using D. None of
the projects that I found (derelict-vulkan, d-vulkan and erupted)
work.
Are there D bindings to Vulkan that actually work?
Here's how I get started:
- Install DMD.
- Install Visual Studio Code.
- Add Jan Jurzitza's (webfreak) serve-d and Native Debug plugins
to VSC.
- Get busy.
On Sunday, 7 January 2018 at 17:02:02 UTC, visitor wrote:
It seems a simple underscore "_" as a variable name tells
Dscanner exactly that.
Any number of underscores but underscores only apparently.
That works too. Thanks.
On Sunday, 7 January 2018 at 03:41:18 UTC, SimonN wrote:
Another way would be to have the RAII wrapper in a with
statement, but it produces extra indentation, which you might
not like:
with (MyStruct(100, 200)) {
// code that uses the new clip rectangle
}
-- Simon
This works
On Sunday, 7 January 2018 at 08:46:40 UTC, Basile B. wrote:
More simple is to understand D-Scanner limitations and accept
that warnings are only warnings and that a message doesn't
necessarily mean that there's something to do.
If the output is clogged with warnings then it's more difficult
t
While working with SDL, I found that I kept using the same
pattern over and over:
- Get the current clip rectangle.
- Set a new clip rectangle.
- restore the old clip rectangle on scope (exit).
Instead of writing that code again and again, I wrote a simple
function that returns a struct which r
I believe that I should call SDL_Quit before my program
terminates. However, some objects may be holding on to SDL
resources and freeing these resources (particularly truetype
resources) causes crashiness if SDL_Quit is called before. Is
there a way to have SDL_Quit (and TTF_Quit) called after
On Wednesday, 13 December 2017 at 13:54:28 UTC, Martin DraĊĦar
wrote:
Dne 13.12.2017 v 4:03 Ivan Trombley via Digitalmars-d napsal(a):
On Wednesday, 13 December 2017 at 01:44:33 UTC, Dmitry wrote:
On Tuesday, 12 December 2017 at 23:28:23 UTC, Ivan Trombley
wrote:
Here's the code that pro
Here's a page that describes the issue:
http://ssp.impulsetrain.com/gamma-premult.html
On Wednesday, 13 December 2017 at 01:44:33 UTC, Dmitry wrote:
On Tuesday, 12 December 2017 at 23:28:23 UTC, Ivan Trombley
wrote:
Here's the code that produces the correct results (exactly the
same as GIMP):
Share images you used, please.
Background image:
http://a4.pbase.com/o10/09/605909/1/1
GIMP 2.9, that is.
On Tuesday, 12 December 2017 at 07:12:07 UTC, Dmitry wrote:
On Tuesday, 12 December 2017 at 06:27:30 UTC, Ivan Trombley
wrote:
This isn't a scaling problem (which is totally solved by
Scaling is not a prerequisite for this problem.
pre-multiplying the alpha with the colors BTW). This is a gam
On Tuesday, 12 December 2017 at 03:34:51 UTC, Dmitry wrote:
On Tuesday, 12 December 2017 at 03:32:05 UTC, Ivan Trombley
wrote:
It turns out that it's an issue with the color channels being
in sRGB color space and the alpha channel being linear. I
verified this by doing a software blend of the i
It turns out that it's an issue with the color channels being in
sRGB color space and the alpha channel being linear. I verified
this by doing a software blend of the images and then doing
another software blend using gamma corrected values.
There's a setting in opengl to correct for it,
glEn
On Monday, 11 December 2017 at 07:04:19 UTC, Mike Parker wrote:
On Monday, 11 December 2017 at 04:57:44 UTC, Ivan Trombley
wrote:
Any SDL experts out there that can give me a clue?
I've used SDL quite a bit, but can't help with your specific
problem. However, I suggest you try the new(ish)
Experimenting with compositing images in SDL2, I get a dark edge
around my textures. In the image below, you can see the top
example where I composite the cyan image on top of the
blue/magenta image looks correct but the bottom example, which is
done using SDL_RenderCopy is not correct.
http:
There are issues with using "--build-mode=singleFile --parallel".
On Windows I get errors saying that it can't write out some
intermediate files (it looks like the file names may be too long
for Windows) and on Linux, it makes the executable at least 3 MB
larger in release mode. Also, it doesn'
On Saturday, 2 December 2017 at 23:26:20 UTC, Ivan Trombley wrote:
On Saturday, 2 December 2017 at 14:34:58 UTC, Arek wrote:
You can try `dub build --build-mode=single-file --parallel`.
It will execute separate instance of compiler for each source
file. If --parallel is given, dub will launch s
On Saturday, 2 December 2017 at 14:34:58 UTC, Arek wrote:
You can try `dub build --build-mode=single-file --parallel`. It
will execute separate instance of compiler for each source
file. If --parallel is given, dub will launch several instances
of dmd in parallel.
I get the error:
Error pro
On Saturday, 2 December 2017 at 03:08:10 UTC, rjframe wrote:
There is a --parallel flag: `dub build --parallel`.
The help string says it "Runs multiple compiler instances in
parallel, if possible."
Thanks, I'll give that a try. After an hour, I pressed CTRL+C,
shut it down and went home.
When DUB bulds the gtk-d library, it takes a long time. This is
mostly because it's only using one processor. It hasn't been such
a big deal on Linux but I'm building my app on Windows right now
and it been building gtk-d for the last half hour! Is there any
way to make DUB use more processors?
Figured it out. I was initializing some member strings where they
were declared in a class. I just needed to move that
initialization to the constructor.
On Thursday, 30 November 2017 at 00:50:35 UTC, Gerald wrote:
On Tuesday, 28 November 2017 at 07:39:19 UTC, Ivan Trombley
wrote:
On Sunday, 24 January 2016 at 19:18:28 UTC, Gerald wrote:
On Monday, 18 January 2016 at 09:04:48 UTC, Luis wrote:
Please, write a HowTo some where. GtkD lack of docume
On Sunday, 24 January 2016 at 19:18:28 UTC, Gerald wrote:
On Monday, 18 January 2016 at 09:04:48 UTC, Luis wrote:
Please, write a HowTo some where. GtkD lack of documentation
it's very anoying.
I've gotten this going with Terminix and posted some
information what it took to get it going here:
On Sunday, 14 May 2017 at 21:01:37 UTC, Basile B. wrote:
On Sunday, 14 May 2017 at 20:23:17 UTC, Ivan Trombley wrote:
When I build C++ projects using make, I can specify how many
processes I want to use (-j). This keeps the processors full
and happy and greatly reduces the overall build time. D
When I build C++ projects using make, I can specify how many
processes I want to use (-j). This keeps the processors full and
happy and greatly reduces the overall build time. Does DUB have a
similar way of compiling each file in it's own process or thread?
29 matches
Mail list logo
