On Friday, 24 May 2024 at 19:22:32 UTC, Jonathan Gerlach wrote:
I'm impressed. Are you using DirectX "11 on 12" or standard
DirectX11? Did you need to avoid the GC at all? I imagine the
GC could ruin your framerate if you're not careful. Thanks for
sharing and congrats on finishing (close
Hello! Not sure if it's of interest, but I've been developing a
3D game and engine in D for a few years, and finally have a demo
up on Steam for anyone interested in poking around (Windows only
unfortunately).
- All code (engine and game) written in D. Shaders in HLSL.
External libraries
Okay, I was able to get the VS debugger to catch exceptions in
win64 by adding a hack to deh_win64_posix.d so that it mimics
deh_win32.d.
I added the following code above the definition of _d_throwc():
```
import core.sys.windows.windef : DWORD;
extern(Windows)
{
void
Clearly I don't know how to spell exception :P
I can't seem to catch a D exception on win64 in the Visual Studio
debugger. I'm using:
- DMD compiler (2.094.2)
- VisualD 1.1.0
- Visual Studio 2019
- Building a Win64 executable
- Debugger set to Visual Studio
- All Win32 and D exceptions enabled in the Exception Settings
window in VS
Test
On Monday, 7 July 2014 at 21:32:30 UTC, JD wrote:
I'm using a compile time regex to find some tags in an input
string. Is it possible to capture the offset of the matches in
some way? Otherwise I have to "calculate" the offsets myself by
iterating over the results of matchAll.
Thanks,
Jeroen
On Wednesday, 5 July 2017 at 22:05:53 UTC, Stefan Koch wrote:
On Wednesday, 5 July 2017 at 21:58:45 UTC, Lewis wrote:
I was reading
https://blog.rust-lang.org/2017/07/05/Rust-Roadmap-Update.html, which mentioned that the Rust compiler now has a mode to go through the motions of compiling and
I was reading
https://blog.rust-lang.org/2017/07/05/Rust-Roadmap-Update.html,
which mentioned that the Rust compiler now has a mode to go
through the motions of compiling and show errors, but without
generating any code. This way you can do a much faster build
while iterating until you have
On Saturday, 3 June 2017 at 09:28:03 UTC, rikki cattermole wrote:
A lot of this can be done by simply implementing shared
libraries fully on Windows. There is a reason why TypeInfo
doesn't cross the dll boundary right now. Sadly it isn't a high
priority (and it really really needs to be "just
On Friday, 2 June 2017 at 20:47:31 UTC, Mike B Johnson wrote:
Would you mind, when you get some time, to write up a more
detailed analysis of the problems you had to overcome to get it
to work? Possibly we could get some type of library solution
that just "works" with very little change and
On Friday, 2 June 2017 at 02:06:27 UTC, Mike B Johnson wrote:
I wonder if it is possible to somehow turn D in to a scripting
language that can be run inside D?
On a game project I'm working on at home, I've done:
- Hot reloading via a DLL
- A build script that runs in the background, detects
On Saturday, 13 May 2017 at 19:22:09 UTC, Steven Schveighoffer
wrote:
It's just out of date. Can't remember the version, but this did
use to allocate. It doesn't any more. But only for this case.
In most cases it does allocate.
Okay cool, that's good to hear. For reference the most recent
import std.random;
import std.stdio;
int[4] testfunc(int num) @nogc
{
return [0, 1, num, 3];
}
int main()
{
int[4] arr = testfunc(uniform(0, 15));
writeln(arr);
return 0;
}
I've read a bunch of stuff that seems to indicate that array
literals are always heap-allocated, even
On Friday, 12 May 2017 at 02:43:17 UTC, evilrat wrote:
I use just dub and generated Visual D project.
Well in my case the problem is that engine is built as static
lib, and there is not much i can do with this. I've started
moving things around and turn lib to executable, at least now
build
On Thursday, 11 May 2017 at 03:17:13 UTC, evilrat wrote:
I have played recently with one D game engine and result was
frustrating. My compile time was about 45 sec!
Interesting. What game engine were you using? To me this sounds
like a problem in the build process. DMD isn't a build system
On Wednesday, 10 May 2017 at 12:52:34 UTC, JN wrote:
I wonder, would it be possible for D in the current state to
achieve the same? I imagine iOS isn't possible yet and Android
is just getting there?
I've been developing a small 2D PC-only game in my free time over
the last year or so (10
On Monday, 17 April 2017 at 14:23:50 UTC, Jonathan M Davis wrote:
On Monday, April 17, 2017 13:45:18 Dmitry via
Digitalmars-d-learn wrote:
[...]
Every time there's a new template instantiation, it's
essentially copy-pasting the entire template. So, if you have
the templated function
[...]
On Tuesday, 3 May 2016 at 19:06:30 UTC, cc wrote:
I see, thanks. Double checking the original headers, I see the
function is defined as:
FMOD_RESULT F_API FMOD_System_CreateSound
(FMOD_SYSTEM *system, const char *name_or_data, FMOD_MODE mode,
FMOD_CREATESOUNDEXINFO *exinfo,
On Wednesday, 12 April 2017 at 11:25:09 UTC, Mike Parker wrote:
DIP 1006 is titled "Providing more selective control over
contracts".
https://github.com/dlang/DIPs/blob/master/DIPs/DIP1006.md
All review-related feedback on and discussion of the DIP should
occur in this thread. The review
OFF TOPIC: Regarding 4D games, check out Miegakure
(http://www.miegakure.com) if you haven't already. It's not out
yet, but looks pretty nuts.
On Sunday, 12 March 2017 at 12:09:10 UTC, Rainer Schuetze wrote:
Hi,
I'm glad to finally announce the release of a new version of
Visual D, the Visual Studio extension for the D programming
language.
[...]
This looks awesome, thanks Rainer!
On Monday, 30 January 2017 at 03:29:21 UTC, Chris Wright wrote:
I'd think the compiler would use the module name you supplied
in the imported module as the canonical name. Are you not
supplying module names? Are you changing them between
incremental compilation steps? Is the compiler ignoring
On Monday, 30 January 2017 at 01:56:16 UTC, Walter Bright wrote:
On 1/29/2017 5:50 PM, Lewis wrote:
I agree that's a good general practice. Even so, I'm curious
if there are any
reasons against the compiler catching an error like this.
Seems like it'd only
prevent errors.
Because some
On Sunday, 29 January 2017 at 08:55:24 UTC, Walter Bright wrote:
The best practice recommendation is to use all lower case in
import names. This means you won't get any surprises porting
to/from Windows file systems. Some people insist on using mixed
case import names, and that's their
On Sunday, 29 January 2017 at 07:31:33 UTC, Walter Bright wrote:
https://digitalmars.com/ctg/ctgLinkSwitches.html#ignorecase
But I suggest, for maximal portability, to treat names as case
sensitive.
Ah, cool. Agreed, my preference is just to keep everything
case-sensitive.
I wonder
On Sunday, 29 January 2017 at 07:14:52 UTC, Lewis wrote:
0. Try the following in DMD on Windows (presumably this issue
doesn't exist on Linux, but can't test myself)
1. Create File1.d and File2.d. Do something trivial in each
that won't get compiled out.
2. In File2.d, import File1.d, but
0. Try the following in DMD on Windows (presumably this issue
doesn't exist on Linux, but can't test myself)
1. Create File1.d and File2.d. Do something trivial in each that
won't get compiled out.
2. In File2.d, import File1.d, but change the filename case in
the import statement. For example,
On Wednesday, 7 December 2016 at 02:49:14 UTC, Walter Bright
wrote:
Those files were converted to glue.d, etc., but obviously the
VS build was not updated. Please file a bugzilla issue for it.
Done, thanks!
https://issues.dlang.org/show_bug.cgi?id=16954
I like to build DMD with MSVC because it complies a little faster
than the shipped executable. I downloaded and installed a fresh
copy of DMD 2.072.1, opened dmd2/dmd/vcbuild/dmd.sln, and tried
to build. I got several compilation errors related to missing
files, in particular:
1>c1xx : fatal
It's true that templates are inherently slow, and there isn't a
ton we can do about that. However, almost every time I compile
the project (hundreds of times per day), the overwhelming
majority of the time, the same templates are being
re-instantiated in exactly the same way. I can't help but
I recently went through the process of optimizing the build time
on one of my projects. I started at ~3.08s, and got it down to
~1.6s. The project is around 7000 non-comment-non-whitespace LOC.
I timed the build in a pretty non-rigourous fashion (I just timed
the python script that kicks off a
On Thursday, 16 June 2016 at 19:52:58 UTC, OpenJelly wrote:
I just want to install an IDE that's not prone to crashing and
comes with standard features like D syntax highlighting, code
completion, code folding, side bar with my project's directory,
integrated console, bindable key commands
As someone learning D, I thought I would give my insight in how I
came to D.
My biggest reason for choosing D is the GC. I have come from Java
and don't quite believe that I'm ready to manage my own memory
throughout an entire program, but the ability to disconnect from
the GC is a great way
On Sunday, 12 June 2016 at 19:12:37 UTC, Meta wrote:
I wanted to use OpenSSL from D but I noticed that the Deimos
bindings are for version 1.0.0e, which according to OpenSSL.org
is an out of date version. Are there any bindings for the
latest version, or an alternative that I could use? I know
On Sunday, 12 June 2016 at 03:46:31 UTC, Mike Parker wrote:
On Sunday, 12 June 2016 at 02:16:52 UTC, Peter Lewis wrote:
[...]
Your problem is this line:
glBufferData(GL_ARRAY_BUFFER, verts.sizeof, ,
GL_STATIC_DRAW);
[...]
Thank you very much. You are right, that fixed my issue
Hi all.
I am trying to create a basic OpenGL triangle in a GLFW instance.
The window works, I can change the background colour and
everything but for the life of me I can't get the triangle to
show up. Instead of trying to put everything in the post, I have
put it on github.
On Thursday, 7 April 2016 at 07:44:48 UTC, Nordlöw wrote:
On Tuesday, 5 April 2016 at 22:43:05 UTC, Martin Nowak wrote:
Glad to announce D 2.071.0.
I read somewhere recently about performance regressions in DMD.
Were these related the import and module fixes? Were they
fixed? Do they depend
On Thursday, 18 February 2016 at 23:01:24 UTC, Rainer Schuetze
wrote:
On 18.02.2016 01:36, Lewis wrote:
Test code (in a newly created project):
import std.stdio;
int main(string[] argv)
{
writeln("Hello Blah!");
string[string] testAA = null;
testAA["test1"] = "Hello";
Test code (in a newly created project):
import std.stdio;
int main(string[] argv)
{
writeln("Hello Blah!");
string[string] testAA = null;
testAA["test1"] = "Hello";
testAA["test2"] = "Goodbye";
testAA["blah"] = "string";
testAA["bloop"] = "another string";
I was wondering if there was a way to dump the contents of the
heap to a file.
If the heap is guaranteed to be in one contiguous chunk, then all
I would need is:
- The start address of the heap
- The current size of the heap
If it is not in one contiguous chunk, then it might be a little
40 matches
Mail list logo
