Re: Going to ACCU next week
On 10/04/10 18:55, Walter Bright wrote: with Andrei to do a full day D tutorial. I'm not sure how connected I'll be with email and stuff. http://accu.org/index.php/conferences I hope this goes well for you :) I'm looking forward to videos of the day for those of us that can't be there, hopefully there will be some as with previous events!
Going to ACCU next week
with Andrei to do a full day D tutorial. I'm not sure how connected I'll be with email and stuff. http://accu.org/index.php/conferences
Re: Wormhol 1.0 released
On 4/8/2010 5:15 AM, #ponce wrote: Wormhol is a split-screen 3D snake game written in the D programming language. It Needs Windows, OpenGL 2.0. Download link: http://adinpsz.org/data/adinpsz_-_Wormhol.zip Pouet page: http://pouet.net/prod.php?which=54549 I'm very interested in getting bug reports, send me the log file log.htm Known bugs: - won't work on Intel cards - black screen on some ATI - sometimes don't start, depending of the directory Cheers, #ponce Beautiful game. Nice music too, where'd you get it? The only thing I'd change would be the textures in the 3d worlds, maybe an earth texture for the sphere, a dinner plate for the circle (with a kitchen skybox), and maybe make the odd shaped ones look like a snowflake. Just suggestions. My Specs: Athlon 2, 3 cores Ati Radeon 5600 Windows XP
Re: Wormhol 1.0 released
On 4/9/2010 1:03 PM, digited wrote: (why SDL?) I've been asking myself that same question. I realized a few months ago the only thing in Yage I use it for is to create a window and get input, and it's kind of sucky at window creation--you can't have more than one and switcing to/from fullscreen is buggy. NeHe's first tutorials already have code for window creation/input handling on Win/Linux/Mac, so that will probably what I go to.
Re: Wormhol 1.0 released
I'm really glad it works on your ATI! > Beautiful game. Nice music too, where'd you get it? The music is by maF (http://maf464.free.fr/). He has quite a lot of unrealeased tracks, and will probably be happy to help out provided you give proper credits. > > The only thing I'd change would be the textures in the 3d worlds, maybe > an earth texture for the sphere, a dinner plate for the circle (with a > kitchen skybox), and maybe make the odd shaped ones look like a > snowflake. Just suggestions. Arbitrary mesh support was planned but I ran out of time... and ended up with only deformed spheres :|
Re: Wormhol 1.0 released
> Works for me. WinXP sp3, Nvidia 8400M GS > Quite a nice game). > Several small problems found : > 1. It always shows "You win" no matter who dies, even when the last > survived player. Yep, shoiuld be "player X win" and keep track of scores. > 2. On spiky figure those worms sometimes run in empty space outside... It's a bug. > 3. I didn't find out if it does matter the color of apples. It does not matter. Actually the game was totally rushed in the end, i have to polish lots of things as you see ;)
Re: Wormhol 1.0 released
Eric Poggel Wrote: > On 4/9/2010 1:03 PM, digited wrote: > > (why SDL?) Mostly, legacy :) > > I've been asking myself that same question. I realized a few months ago > the only thing in Yage I use it for is to create a window and get input, > and it's kind of sucky at window creation--you can't have more than one > and switcing to/from fullscreen is buggy. > > NeHe's first tutorials already have code for window creation/input > handling on Win/Linux/Mac, so that will probably what I go to. Absolutely. Also it seems like SDL 1.3 will never be released... I would look at dog for clever window and OpenGL context creation. The inability to create 3.x OpenGL context in SDL 1.2 will become a blocker very soon. However, SDL 1.2 lower the bar for someday porting to Mac/Linux and does its job. The fullscreen <=> windowed thing is probably related to the OpenGL context recreation, maybe it work with pure SDL graphics.
Re: dmd 1.058 and 2.043 release
What's the rationale behind this? (I don't like this). The flexibility comes in handy now and then. but isn't that an abstract form of hijacking then? or an sideeffect smelling like that?
Re: dmd 1.058 and 2.043 release
On 09/04/10 23:11, bearophile wrote:
BCS:
For example, having foo_linux.d and foo_win.d both claiming to be foo.
OK.
And I presume you don't want to use a single module with a mega version(linux)
{...} else {...} inside.
Thank you,
bearophile
No need for a huge module, or module names mismatching file names:
module foo;
version (linux) import foo_linux;
version (Windows) import foo_linux;
Sure it adds and extra file, it's a lot cleaner imo than having a huge
module with both implementations or mismatching file/module names.
Re: Wormhol 1.0 released
"#ponce" ÓÏÏÂÝÉÌ/ÓÏÏÂÝÉÌÁ × ÎÏ×ÏÓÔÑÈ ÓÌÅÄÕÀÝÅÅ: news:hpk6rq$fm...@digitalmars.com... > Wormhol is a split-screen 3D snake game written in the D programming > language. > It Needs Windows, OpenGL 2.0. > > Download link: http://adinpsz.org/data/adinpsz_-_Wormhol.zip > Pouet page: http://pouet.net/prod.php?which=54549 > > I'm very interested in getting bug reports, send me the log file log.htm > > > Known bugs: > - won't work on Intel cards > - black screen on some ATI > - sometimes don't start, depending of the directory > > Cheers, > #ponce > Works for me. WinXP sp3, Nvidia 8400M GS Quite a nice game). Several small problems found : 1. It always shows "You win" no matter who dies, even when the last survived player. 2. On spiky figure those worms sometimes run in empty space outside... 3. I didn't find out if it does matter the color of apples.
Re: dmd 1.058 and 2.043 release
Hello bearophile, BCS: IIRC, all that does is make anything that imports you, import that as well. It doesn't do anything to the names. I meant to create a module named "foo" with inside: module foo; version (linux) public import foo_linux; version (Windows) public import foo_win; The module system has numerous holes (that Walter will need to take a look at, because three of them alone cover almost 10% of all bugzilla votes), so this is not going to work perfectly, but now if you import foo you have available all the names inside foo_linux and foo_win. That's exactly what I thought you were suggesting. The problem is that, IIRC and assuming foo_linux and foo_win both contain a bar, the the following still doesn't work: foo.bar(); what works is: foo_linux.bar(); or foo_win.bar(); In the case that just bar() doesn't work (say there is another bar somewhere else), you're sunk. -- ... <
Re: dmd 1.058 and 2.043 release
BCS: > IIRC, all that does is make anything that imports you, import that as well. > It doesn't do anything to the names. I meant to create a module named "foo" with inside: module foo; version (linux) public import foo_linux; version (Windows) public import foo_win; The module system has numerous holes (that Walter will need to take a look at, because three of them alone cover almost 10% of all bugzilla votes), so this is not going to work perfectly, but now if you import foo you have available all the names inside foo_linux and foo_win. Bye, bearophile
Re: dmd 1.058 and 2.043 release
Hello bearophile, BCS: I don't think that works in one case; where you are forced to use fully qualified name. You can probably use a "public import". IIRC, all that does is make anything that imports you, import that as well. It doesn't do anything to the names. -- ... <
Re: dmd 1.058 and 2.043 release
BCS: > I don't think that works in one case; where you are forced to use fully > qualified > name. You can probably use a "public import". Bye, bearophile
Re: dmd 1.058 and 2.043 release
Hello Robert,
No need for a huge module, or module names mismatching file names:
module foo;
version (linux) import foo_linux;
version (Windows) import foo_win;
Sure it adds and extra file, it's a lot cleaner imo than having a huge
module with both implementations or mismatching file/module names.
I don't think that works in one case; where you are forced to use fully qualified
name.
import foo;
import something.else;
bar(); // calls something.else.bar;
foo.bar(); // IIRC this don't work
OTOH, you might be able to get around that with the following:
version (linux) { import foo_linux; alias foo_linux foo; }
version (Windows) { import foo_win; alias foo_win foo; }
(I haven't tested any of that because my systems are being shipped right
now.)
--
... <
Re: dmd 1.058 and 2.043 release
BCS:
> For example, having foo_linux.d and foo_win.d both claiming to be foo.
OK.
And I presume you don't want to use a single module with a mega version(linux)
{...} else {...} inside.
Thank you,
bearophile
Re: dmd 1.058 and 2.043 release
Walter Bright: > The flexibility comes in handy now and then. OK, I have never felt the need of such extra flexibility in my D programs, so I trust your judgement. Every time a a semantic hole is left in a language (and this is a little hole), you have to pay a price, in terms for example of: - less easy to understand error messages (the currently generated error message is not easy to understand and I think it's wrong, because in that program the four names are distinct, there is no duplication); - less simplicity for the D newbies to learn the language, because to learn something faster you need a strict teacher; - possible bugs caused by side effects of the semantic hole (because semantic holes often create semantic loopholes). In Delphi the "main unit" of a program is denoted with for example, at the top: program Project1; Bye, bearophile
Re: dmd 1.058 and 2.043 release
Hello Walter, bearophile wrote: Walter Bright: Thank you for your answer. The error is not a mismatched file name, which is perfectly legitimate in D. Do you mean that in D it is OK to have a file named "foo.d" with inside it at the top written "module bar;" ? Yes. What's the rationale behind this? (I don't like this). The flexibility comes in handy now and then. For example, having foo_linux.d and foo_win.d both claiming to be foo. -- ... <
Re: dmd 1.058 and 2.043 release
bearophile wrote: Walter Bright: Thank you for your answer. The error is not a mismatched file name, which is perfectly legitimate in D. Do you mean that in D it is OK to have a file named "foo.d" with inside it at the top written "module bar;" ? Yes. What's the rationale behind this? (I don't like this). The flexibility comes in handy now and then.
Re: dmd 1.058 and 2.043 release
Walter Bright: Thank you for your answer. > The error is not a mismatched file name, which is perfectly legitimate in D. Do you mean that in D it is OK to have a file named "foo.d" with inside it at the top written "module bar;" ? What's the rationale behind this? (I don't like this). >The error is two different files have the same module name.< Maybe I am missing something, but: - there is a module "bar" in the file named "foo.d" - and there is the module "test" in the file named "spam.d". All four names are distinct, there are no name duplication (and the imports can't change this basic fact). Bye, bearophile
Re: dmd 1.058 and 2.043 release
Don wrote: Please don't clutter the announce newsgroup with bug reports. And in general, do NOT put multiple bugs in one report. In particular, it's worth saying this to everyone: if something causes a compiler segfault or an internal compiler error, ALWAYS put it in its own report. In > 95% of cases it's a different bug, even if it looks the same as something else. Don's right. But it is ok to reply with a link to a bugzilla report.
Re: dmd 1.058 and 2.043 release
bearophile wrote: Now I have tested this release a little better, it seems to work well. I have to say two things: 1) The bug 3911 was a mix of two different bugs, Don has fixed one of them, so I have closed the bug 3911 and I have opened a new cleaned bug report, number 4075: Please don't clutter the announce newsgroup with bug reports. And in general, do NOT put multiple bugs in one report. In particular, it's worth saying this to everyone: if something causes a compiler segfault or an internal compiler error, ALWAYS put it in its own report. In > 95% of cases it's a different bug, even if it looks the same as something else.
