Re: Programming a Game in D? :D

2014-05-27 Thread David via Digitalmars-d-learn

On Saturday, 24 May 2014 at 08:54:53 UTC, ponce wrote:


Hi David,

Learning programming, learning D and learning 3D are 3 
significant endeavours.
You might want to begin with http://www.basic4gl.net/ which 
will get you going with 3D, quite a topic in itself.

Then learn D regardless :)


So, I'v used Blender for a half year or sth. and I think I can 
make a little area :)
As far as I know, I do now need a graphic and physics engines, 1 
of the graphic APIs and for sure my programming stuff and here 
I'm stuck :D


And I still can't install Mono-D :( if I try I just get a whole 
bunch of errors that any packages couldn't be found, don't know 
if I'm doing sth. wrong

(I probably do :P)


Re: Programming a Game in D? :D

2014-05-27 Thread Szymon Gatner via Digitalmars-d-learn

On Tuesday, 27 May 2014 at 10:03:36 UTC, David wrote:

On Saturday, 24 May 2014 at 08:54:53 UTC, ponce wrote:


Hi David,

Learning programming, learning D and learning 3D are 3 
significant endeavours.
You might want to begin with http://www.basic4gl.net/ which 
will get you going with 3D, quite a topic in itself.

Then learn D regardless :)


So, I'v used Blender for a half year or sth. and I think I can 
make a little area :)
As far as I know, I do now need a graphic and physics engines, 
1 of the graphic APIs and for sure my programming stuff and 
here I'm stuck :D


And I still can't install Mono-D :( if I try I just get a whole 
bunch of errors that any packages couldn't be found, don't know 
if I'm doing sth. wrong

(I probably do :P)


I would STRONGLY advise to go with a ready engine like Unity.

You still have to learn a lot before you  will have just building 
blocks to create a game like loading and rendering 3D models, a 
gameplay framework etc etc.


Start with Unity, lean how to make a game there. Learn how to 
programm gameplay there and after that, when you see what is 
needed before even being able to make a game, only then try to 
make things from scratch. Use C# in Unity too as it is similar to 
D so you will have easier transition when necessary.


What are the best std algo for testing a range implementation ?

2014-05-27 Thread BicMedium via Digitalmars-d-learn
Let's say I have a set of containers, using a 
D-unfriendly-semantic. They rather use a kind of ADA vocabulary 
(according to https://en.wikipedia.org/wiki/Deque). I want to 
make them range-aware.


If the input/output ranges are easy to implement(so it's just 
reading/writing an element, keeping an index for the writer and 
another for the reader, and reseting it, isn't it ? So if 
(isInputRange!MyCont  isOutputRange!MyCont) then it's a 
Deque, right ?).
The bidirectionnal ranges or the forward ranges become more 
difficult to interpret with the idioms I 
use(Insert,Add,Remove)...Is this a kind of 3rd plane (time: 
return to previous state, make a backup: copy/roll-back - 
undo/redo ?)


Could you recommend me the algos from std.algo to test 
efficiently my implementations ? (example, if you want to be sure 
that the input ranges work then you'd use this...if you want to 
be sure that output ranges work then you'd use that ...Some kind 
of reference unit tests ?). At the present time, each time I 
try one I get rejected by the template constraints...


Re: What are the best std algo for testing a range implementation ?

2014-05-27 Thread Chris via Digitalmars-d-learn

On Tuesday, 27 May 2014 at 10:50:54 UTC, BicMedium wrote:
Let's say I have a set of containers, using a 
D-unfriendly-semantic. They rather use a kind of ADA vocabulary 
(according to https://en.wikipedia.org/wiki/Deque). I want to 
make them range-aware.


If the input/output ranges are easy to implement(so it's just 
reading/writing an element, keeping an index for the writer and 
another for the reader, and reseting it, isn't it ? So if 
(isInputRange!MyCont  isOutputRange!MyCont) then it's a 
Deque, right ?).
The bidirectionnal ranges or the forward ranges become more 
difficult to interpret with the idioms I 
use(Insert,Add,Remove)...Is this a kind of 3rd plane (time: 
return to previous state, make a backup: copy/roll-back - 
undo/redo ?)


Could you recommend me the algos from std.algo to test 
efficiently my implementations ? (example, if you want to be 
sure that the input ranges work then you'd use this...if you 
want to be sure that output ranges work then you'd use that 
...Some kind of reference unit tests ?). At the present time, 
each time I try one I get rejected by the template 
constraints...


I'm not sure, if I understand your question correctly, but I 
think what you need are RandomAccessRange's (cf. 
http://ddili.org/ders/d.en/ranges.html). You can save their state 
and access members randomly. However, as far as I know, the range 
itself should not be modified while you iterate over it.


Re: Down the VisualD0.3.38-1.exe ,found virus!

2014-05-27 Thread KarlHeesch via Digitalmars-d-learn

Hi,everyone,
down VisulaD from 
http://rainers.github.io/visuald/visuald/StartPage.html

found the virus:Win32.Troj.Undef.(kcloud)

Why?

Frank


https://www.virustotal.com/en/file/bbd76ddb41a80f0526f6cf1e37a2db2736cfa8f29ed3f5fd7a4336bf4c8bbe43/analysis/

Just 5 of 52. Probably a false alarm.


Kaspersky IS accepts the installer VisualD-v0.3.38-1.exe without
complaint, but after installation removes 'c:\program files
(x86)\visuald\visuald.dll' by claiming it as
'UDS:DangerousObject.Multi.Generic'. I don't know how to prevent
this removal (and whether I should do so).

Version 0.3.37 that was contained in the DMD 2.065 installer
could be installed without problem.

Do you have any hint?


Re: What are the best std algo for testing a range implementation ?

2014-05-27 Thread monarch_dodra via Digitalmars-d-learn

On Tuesday, 27 May 2014 at 10:50:54 UTC, BicMedium wrote:
Let's say I have a set of containers, using a 
D-unfriendly-semantic. They rather use a kind of ADA vocabulary 
(according to https://en.wikipedia.org/wiki/Deque). I want to 
make them range-aware.


If the input/output ranges are easy to implement(so it's just 
reading/writing an element, keeping an index for the writer and 
another for the reader, and reseting it, isn't it ? So if 
(isInputRange!MyCont  isOutputRange!MyCont) then it's a 
Deque, right ?).
The bidirectionnal ranges or the forward ranges become more 
difficult to interpret with the idioms I 
use(Insert,Add,Remove)...Is this a kind of 3rd plane (time: 
return to previous state, make a backup: copy/roll-back - 
undo/redo ?)


Just keep in mind that a container is not a range. A container is 
an object that can hold items, and you can add and remove items 
from said object. The Range is a way to iterate your container.


For example, a range definitely does NOT make insertion, removals 
or duplactes of your items. You can save a range, but that's 
NOT the same thing as making a duplicate of your container that 
you can roll back.


I'd suggest you take a look at std.container.array to see what 
I'm talking about.


Could you recommend me the algos from std.algo to test 
efficiently my implementations ? (example, if you want to be 
sure that the input ranges work then you'd use this...if you 
want to be sure that output ranges work then you'd use that 
...Some kind of reference unit tests ?). At the present time, 
each time I try one I get rejected by the template 
constraints...


If the algos are turning you down, then you must have missed 
something. Check that:

alias Range = YourRangeTypeHere;
static assert(isInputRange!Range);
static assert(isForwardRange!Range);
static assert(isBidirectionalRange!Range);
static assert(hasLength!Range);
static assert(isRandomAccessRange!Range);
static assert(hasSlicing!Range);

At the *very least*, the first 3 should pass for a deque. The 3 
others depend on what primitives you want to offer.


RandomAccessRange / Mobile Elements

2014-05-27 Thread Johann via Digitalmars-d-learn

Hello,
I read in std.range that given a random access range r , 
r.opIndex(n) should return a reference to the nth element. Is 
there a qualifier for a read only random access range? If not, 
why?
I also don't really get the point of Mobile Elements, how is 
destructively reading related to mobility, and what is it good 
for?


Thanks.


Re: What are the best std algo for testing a range implementation ?

2014-05-27 Thread monarch_dodra via Digitalmars-d-learn

On Tuesday, 27 May 2014 at 12:18:15 UTC, BicMedium wrote:

I mean that those tests are just like testing an interface...).


If your interface isn't complete, than it is irrelevant what your 
implementations are, since the algorithms can't use your ranges 
anyways.


BTW the 2nd and the 3rd assertions are exactly what fails when 
I try to test an algo (isInputRange!Range or 
isOutputRange!Range pass but has the test doesn't know about 
the implementation I can't know If it's really working...


Probably you are missing `save`, or you implemented it as a 
non-property function (though arguably, it shouldn't be a 
property, but that's another issue).


Re: What are the best std algo for testing a range implementation ?

2014-05-27 Thread BicMedium via Digitalmars-d-learn

On Tuesday, 27 May 2014 at 14:05:56 UTC, monarch_dodra wrote:

On Tuesday, 27 May 2014 at 12:18:15 UTC, BicMedium wrote:

I mean that those tests are just like testing an interface...).


If your interface isn't complete, than it is irrelevant what 
your implementations are, since the algorithms can't use your 
ranges anyways.


We agree on this point. The template constrains for isInputRange 
or isOutputRange just check, at compile-time, if the methods 
matchings to the prototypes defined in std.ranges (or in 
std.container empty, popFront, etc...) are implemented.


But there could be a templated-unittest for those kind of 
things...Ranges are relatively straightforward in to use, but 
when you want to implement one, it's another thing...So it's just 
about indexes ? And a kind of State machine for indexes 
(push/pop) ?
I hardly get how to make my easy containers range-aware. but I 
want to, because of std.algo.


Re: What are the best std algo for testing a range implementation ?

2014-05-27 Thread monarch_dodra via Digitalmars-d-learn

On Tuesday, 27 May 2014 at 16:49:42 UTC, BicMedium wrote:
But there could be a templated-unittest for those kind of 
things...Ranges are relatively straightforward in to use, but 
when you want to implement one, it's another thing...So it's 
just about indexes ? And a kind of State machine for indexes 
(push/pop) ?


We can't wright a generic unittest to make sure that a range 
works. Indeed, depending on *what* your range iterates, the 
test would be different.


You just have to test that yourself.

I hardly get how to make my easy containers range-aware. but I 
want to, because of std.algo.


The easiest way is to give your container the Range opSlice() 
function, where Range is the range you defined to iterate on your 
container. See std.container.array.


Re: Programming a Game in D? :D

2014-05-27 Thread Ryan Voots via Digitalmars-d-learn

On Tuesday, 27 May 2014 at 10:13:13 UTC, Szymon Gatner wrote:


I would STRONGLY advise to go with a ready engine like Unity.

You still have to learn a lot before you  will have just 
building blocks to create a game like loading and rendering 3D 
models, a gameplay framework etc etc.


Start with Unity, lean how to make a game there. Learn how to 
programm gameplay there and after that, when you see what is 
needed before even being able to make a game, only then try to 
make things from scratch. Use C# in Unity too as it is similar 
to D so you will have easier transition when necessary.


I'd definitely agree.  The things you'll learn there will make 
using something else actually possible.  Starting from scratch 
you'll spend about the first year or so building up the 
boilerplate to let you actually get to the parts you want.  I've 
built up about half a dozen engines to that point to only lose 
interest or run into issues with the story I'm trying to tell and 
stop making progress.


That said I'm hoping to have YAGE[1] up and working again with D2 
soon which would mean that there should be a nice starting point 
for building games with D;  Even if that starting point is some 
basic ideas of what doesn't work well.