Given it's nature, newbie/lurker opinions carry double weight. So
stand up and be heard!
Link:
http://files-upload.com/files/633676/Release.zip
Previous Post/Thread (background/preview of what's coming up):
http://groups.google.ca/group/rec.games.roguelike.development/browse_thread/thread/4512e5539c2c5896?hl=en
- Craig
PS. If anybody knows a better @#^! home for the files, please let me
know. I hate these free upload places, but I am rather useless when it
comes to web stuff.
I'd be happy to host it for you on crawl.akrasiac.org if "ad-free hosting
by specific stranger" is a significant upgrade in your mind. You might
also look at Google Pages or something, though I don't know if they'll
let you post just random Word and source files. I flipped through the
first two chapters and they look very promising.
-r.
(Obligatory because I do this for a living: But they're in _Word_! Have
you considered some sort of structured and publishable (HTML, print,
whatever) format like DocBook, LaTeX, or even FrameMaker or Indesign? :)
Omg, they're in WORD? Glad I didn't download them then. Recommend
fixing if you want anyone to.
Thanks for your time, I'll be checking trough the files whenever I get
home.
Well, I didn't wait and I read through your articles. I guess I found
one or two mispelled words, but I can't even remember where I found
them. I will certainly use these articles when making my own
roguelike. Thanks! However, as a few others pointed out. You should
use another format than doc for your articles. :)
Although you lose the images, you can open them in Wordpad.
-- Shanya Almafeta
Thoughts:
"Release"... could you please give it a more descriptive name like
"Craig's Roguelike Tutorial" or something? ^^;
Article two. "Never once do you see the "levels" in these games
spanning a horizontal region larger than the screen size." I can
think of three games off hand that DO have levels like this...
although for simplicity's sake, and for the sake of new programmers,
screen-sized is probably best.
Comments! This is very handy, and (newbie) I've already learned some
things, but I don't use C++. For the sake of those who have to
convert your code into their language of choice, could you add a few
more comments to your code, especially in the snippets we see in the
article?
Thanks!
-- Shanya Almafeta
My wording should be better/cleaner. The statement was intended for
the games I mentioned earlier like ADOM, Rogue, NetHack, etc.
> Comments! This is very handy, and (newbie) I've already learned some
> things, but I don't use C++. For the sake of those who have to
> convert your code into their language of choice, could you add a few
> more comments to your code, especially in the snippets we see in the
> article?
Hmm.. I honestly thought that my comments would be able to do that.
Problem is - and I don't want to seem like I'm blowing my own horn
here - but I know over 9 different programming languages (nearly all
of them low-level) and when you get to that state they start bleeding
into one and the only real difference you start noticing is syntax
primarily.
What I'm trying to get at is I'm not sure I know *how* to comment in a
way that might make sense to programmers who specialize in higher-
level languages (C#, Python or Lua for instance). It's a completely
different world, trust me. (I used to have a hard time with Java, for
pete's sake). Could you possibly give me an example? Like from the
Article One source?
If you happen to be afflicted with Windows, yes.
I was going to say "if you've written an article about roguelike
development post it here, don't make people jump through hoops", but if
they're in some nutjob format that may be a non-starter.
--
David Damerell <dame...@chiark.greenend.org.uk> flcl?
Today is Second Monday, November.
http://www.megafileupload.com/en/file/24960/Beginners-Guide-to-Roguelikes-zip.html
It would be a very significant upgrade. I would appreciate that. And
I'm sure that those who download it would be even more grateful for
the change. Thank you!
Kind of off-topic, but it was your post on Krice's legendary "Tiny
Roguelike Scene" thread (of which I think it was a turning point for
the RL scene as a whole) that convinced me to try my hand at this
guide. So thank you.
> On Nov 22, 8:48 am, "almaf...@gmail.com" <almaf...@gmail.com> wrote:
>>
>> Comments! This is very handy, and (newbie) I've already learned some
>> things, but I don't use C++. For the sake of those who have to
>> convert your code into their language of choice, could you add a few
>> more comments to your code, especially in the snippets we see in the
>> article?
>
> Could you possibly give me an example? Like from the
> Article One source?
I could try my hand at that.
// This is the minimalist console output class I mentioned.
#include "ExtendedWin32Console.h"
// Please tell me what this is for.
#include <conio.h>
int main( void )
{
console.Clear(); // Blank the screen.
int nPlayerX=40, nPlayerY=12; // Set the player's starting position.
while( true )
{
// Output phase: set the write position to the player's position
// then print "@" to represent the player.
console.SetPosition( nPlayerX, nPlayerY );
console << '@';
// Input phase: wait for a key to be typed.
char nKey = getch();
// Erase the character from the previous position
console.SetPosition( nPlayerX, nPlayerY );
console << ' ';
// Processing phase: choose an action based on the key pressed.
switch( nKey )
{
// Move down
case '2':
nPlayerY++;
break;
// Move left
case '4':
nPlayerX--;
break;
// Move right
case '6':
nPlayerX++;
break;
// Move up
case '8':
nPlayerY--;
break;
// Quit
case 'Q':
case 'q':
return 0;
break;
}
}
return 0;
}
I'm thinking it would be nice to insert a note saying what a function or
#include does the first time it is encountered, as well as what variable
names are for, and what a particular technique is doing (like the
console.SetPosition then console << "*" technique, the "read a character
then act on it technique", and so on). I wouldn't bother to cover the
language basics, but as a reader when I come to a case statement labeled
"processing phase" I would like to know in general terms what we plan to
process.
Of course, I'm experienced enough to understand what this code is going to
do, but presumably your main audience isn't.
Thank you!
> I wouldn't bother to cover the language basics, but as a reader when
> I come to a case statement labeled "processing phase" I would like
> to know in general terms what we plan to process.
Good point. I cover the concept in the articles lightly, which means
that those who are "source-surfing" would be lost in the shuffle.
> Of course, I'm experienced enough to understand what this code is going to
> do, but presumably your main audience isn't.
That's my primary fear: that those who actually do understand what
I'm writing are too experienced to find it useful.
I have taken basic classes in C++ and Java. I understand the code
discussion, but the theory on how to create the base of a roguelike is
still interesting. I assume it will get even better once we get into
rudimentary AI (i.e. placing monsters, and having them move). My 2 zm.
I notice some "this isn't the most effective way to do it, but it's
easy", though. A bit jarring for me as a backseat r.g.r.d. follower.
Maybe necessary to make the tutorial both understandable and concise,
though.
Looking forward to the upcoming chapters.
/Hällzon
Don't you have anywhere to put that? Like home page
or something?
> Comments! This is very handy, and (newbie) I've already learned some
> things, but I don't use C++. For the sake of those who have to
> convert your code into their language of choice, could you add a few
> more comments to your code, especially in the snippets we see in the
> article?
The only thing I'd add is that it's a very good introductory tutorial,
but you are not using C++ except for double-slash style comments! I
would describe the code instead as very simple C. (Which is fine, it
is probably far more accessible to its target audience writing in C or
similar languages such as Basic.)
Making the map global is perfectly feasible when coding a simple
roguelike, but it kind of vitiates any notion of using classes for
encapsulation and access control.
- Gerry Quinn
Ha ha, true!
> I would describe the code instead as very simple C. (Which is fine,
> it is probably far more accessible to its target audience writing in C
> or similar languages such as Basic.)
>
> Making the map global is perfectly feasible when coding a simple
> roguelike, but it kind of vitiates any notion of using classes for
> encapsulation and access control.
You are totally right, and I've debated with my self about this at
quite length. I believe that OOP is an inescapable, fundamental tool
if you're making even a half-serious Roguelike. (Not saying it can't
be done without, but why on earth would you handicap yourself?)
However, it requires considerably more design and forethought than
your normal old-school procedural approach. My fear is that in doing
this, I will loose people right off the bat. I'm trying to keep it
simple and straightforward and (especially at the beginning) allowing
people to play and fiddle around with what they've made. I mean back
when I was 14, my first RL design did this. Didn't yours? My whole
goal is to let them "catch the bug" and progressively get more
involved in the intricacies of coding, which will be tolerable (even
interesting) when they see the reason for it.
Anyways, if you have any ideas about when and how to put OOP in action
let me know. I am leaning more towards the NPC articles. I used to
tutor back in my college days, and I would use NPC design in games as
a way to explain OOP to students. It always amazes me to see how many
people cannot understand that design paradigm, but putting it in
application helps infinitely.
But you're right though, and I'm not entirely convinced what I'm doing
is the right way to do it.
*snip*
> But you're right though, and I'm not entirely convinced what I'm doing
> is the right way to do it.
Keep any lesson code that's not related to the lesson as simple as
possible to start, and gradually include the complexities as they
become relevant, I would suggest. Put the bulk of the code (and
comments) in whatever you're working on in that lesson, unless you've
already gone over it, I'd suggest...
Also, re OOP: A lot of people are not just learning object-oriented
languages, but beginning with object oriented languages, such as Java.
> Anyways, if you have any ideas about when and how to put OOP in action
> let me know. I am leaning more towards the NPC articles. I used to
> tutor back in my college days, and I would use NPC design in games as
> a way to explain OOP to students. It always amazes me to see how many
> people cannot understand that design paradigm, but putting it in
> application helps infinitely.
If by NPC design you mean this metaphor:
Class = class;
Object = one NPC;
Class variable = a NPC's stat;
Method = a skill or ability of that class;
When my first Java professor put it that way, that's when I finally
grasped OOP concepts. And considering your target audience, I'd think
that'd be the perfect way to handle it.
-- Shanya Almafeta
You're welcome!
http://crawl.akrasiac.org/craig/ has both articles in HTML as well as
both ZIP files available for download. Go nuts, everyone.
To Craig: We should probably coordinate some way for you to be able to
upgrade it via email; my preference would be to just check out an SVN
repository but I don't know if that's how you manage your documents. :)
(As it gets bigger, I won't have time to unpack things immediately
anytime you change something.)
> Kind of off-topic, but it was your post on Krice's legendary "Tiny
> Roguelike Scene" thread (of which I think it was a turning point for
> the RL scene as a whole) that convinced me to try my hand at this
> guide. So thank you.
Hey, if I can play some small part in making roguelike development easier,
score! If I find the time, I hope to put together a "How To Make Your
New Game Its Own dgamelaunch Server" tutorial at some point in the next
couple of months...
-r.
Thanks Rachel, I've finally been able to look at those articles! Not
that I haven't access to a winblows box with Office but I'm too lazy
to download and unzip the file :P.
Nice job Craig. This makes me wonder if any studies has already been
done on the r.g.r.d audience. What kind of people wanders here ?
Personally, I would not expect anyone but incurable geeks to get
interrest in amazingly hard to code computer programs that produce
only ASCII characters soup, but it seems that roguelikes also attract
beginner programmers. I've only been infected by roguelike recently
(actually, I've only played a bit of nethack and doomrl). Has there
already been polls to know what kind of developpers lives here or the
number of roguelike by language ? Would such statistics be useful ?
--
jice
Good idea, perhaps a poll could be made on Rogue Temple...
Actually I found this tutorial a while ago where you use OOP from the
start to create an ascii-game.
I didn't make this but if you want an example of how it could be done
you should look at this.
Too bad it's not entirely finished just yet though.
> already been polls to know what kind of developpers lives here or the
> number of roguelike by language ? Would such statistics be useful ?
Comparisons of programming languages tend to degenerate quickly into a
"my language has a bigger **** than yours" type of argument - not very
useful.
sherm--
--
WV News, Blogging, and Discussion: http://wv-www.com
Cocoa programming in Perl: http://camelbones.sourceforge.net
Yes, but such stats could be useful for currently active roguelikes :
C++ : x%
java : x%
... : x%
and also something like :
more than 10 years xp developper : x%
more than 5 years xp developper : x%
more than 2 years xp developper : x%
beginner developper : x%
or even a cross view experience/language.
It would show if beginner guides to roguelike are pertinent or not (I
mean guides for people who have almost never programmed) and if they
are, what language the guide should use (not because it has the
biggest ****, but because most of beginner developpers who want to
create a roguelike use this language) .
The thing is, there are lots of discrepancies between articles/
tutorials we see here. Look at dungeon dweller, you have very complex
algorithms (relatively speaking) like recursive shadow casting LOS and
articles for people who don't even know what a loop or a variable is.
Is there an audience for both ? Are there lots of beginner programmers
who want to start learning programming with a roguelike, or rather a
majority of developpers with solid programming foundations ? The
answer is probably both, but it what proportions ? If there are only
5% beginner programmers, then there's no use having so much beginner
guides and the community could accomodate more advanced guides/
articles.
I'm maintaining a blog with roguelike development articles and I'm
always questioning myself about this. Most articles are low level and
maybe most of the readers think "ok, it's obvious, I already knew
that". Or maybe most of the readers think "Damn, it goes too fast, I
would need more in-depth explanations".
--
jice
RogueBasin could work I guess as it can handle both images and files.
With the recent blog mania here at r.g.r.dev knowledge is getting spread
out over many sites (= not good in my opinion).
/Björn
Especially when they will be down in half a year :(
--
Radomir `The Sheep' Dopieralski <http://sheep.art.pl>
() ascii ribbon campaign - against html e-mail
/\ <www.asciiribbon.org> - against proprietary attachments
Okay, finally had a chance to download it. (For those whining
about .doc, it opens just fine in Open Office FYI.)
Very well done. I like your style and I like your pace. I also like
very much the non-OO approach.
I think that Terror in ASCII dungeon linked to else-thread is a
perfect example of why an OO tutorial is bad. It spends how many
pages without even producing a line of code? If I'm learning
something I want something interactive *fast*.
A lot of OO teachers seem to forget that langauges like Java still
have at their heart a simple list of instructions to be executed.
Beginners do not know how to make a list of instructions! All this
talk about object hierarchies is distracting if I can't even put two
statements together in a list.
Anyways, enough of a rant, on to some critique.
1) I still believe the best newbie map representation is
char *map[MAP_HEIGHT] =
{
"#######"
"#.....#"
"#######"
};
It simplifies your screen drawing and also encourages the learner to
edit the map themselves. Using an integer indirection is something
that can be added as a refinement later.
2) You should make it clear that "Adding another NPC to the map" is a
very advanced next step in Article 1 rather than something to be done
on a whim like your other changes. I'd say remove it entirely as you
should really explain that directly.
3) Your concern for repainting the screen at a minimum distracts from
writing a cool video game. It is not necessary. I repaint the entire
map every step in POWDER and it runs on a Gameboy Advance. If flicker
is the concern, fix your graphics library to have a redraw() command
that posts all pending edits. Ie, no changes show up on screen until
one calls redraw(). This effects double buffering which has been how
we've solved the 60hz mismatch problem for the last few decades.
4) I think you are missing a good learning opportunity when you write
stuff like: "playerx--". Especially when you have the "unmove" path
inside the switch statement.
A very important concept that beginners may lack is the idea of dx/
dy. Instead of directly changing X and Y in the switch statement, we
just set dx and dy to +/- 1. This idea of replacing a "change my
position" with "store my intended change in position" is very powerful
when it comes to writing AI - a large part of the AI problem becomes
just selecting (dx,dy) rather than the conceptually larger issue of
updating (x,y). We see this when you add collision detection - a dx/
dy lets you easily remove that from the switch statement so it is only
written once.
Keep up the good work.
--
Jeff Lait
(POWDER: http://www.zincland.com/powder)
Nobody's complaining now; he put up an html version. (Much better
than a 100 mb download for Open Office.)
on to the article:
I really like the simplicity of it. You really seem to have a good
understanding of what the target audience knows (i.e. nothing), you're
not using anything more difficult than what is absolutely necessary to
get something moving around on the screen.
Almost makes me want to write an ascii game. I'm reminded of how
little you actually have to do to get something up and running, none
of this messing about with perspective transformations and vertex
buffers.
For some reason a screen full of .s and #s and @s just looks really
solid and professional to me, more like an 'actual game' than
something just thrown together with a half dozen lines of code. I
guess this is because it's already at the maximum level of
sophistication possible in the medium, and I've spent so many hours in
front of screens that look just like that. With 3d graphics it takes
so much more work to get something looking acceptable, and even then
it's inevitably inferior to the professional efforts.
In conclusion, your tutorial's almost inspired me to switch to writing
a _roguelike_ roguelike. Maybe I'll have to make that my next
project.
Brog
Hear hear!
>
> Anyways, enough of a rant, on to some critique.
>
> 1) I still believe the best newbie map representation is
> char *map[MAP_HEIGHT] =
> {
> "#######"
> "#.....#"
> "#######"
>
> };
>
> It simplifies your screen drawing and also encourages the learner to
> edit the map themselves. Using an integer indirection is something
> that can be added as a refinement later.
That does simplify the editing process, but in my experience I've
found that people have a hard time understanding how C-style strings
are stored and how to use that system. I felt it would be simpler to
grasp the theory this way.
> 2) You should make it clear that "Adding another NPC to the map" is a
> very advanced next step in Article 1 rather than something to be done
> on a whim like your other changes. I'd say remove it entirely as you
> should really explain that directly.
Very good point. I'll do that.
> 3) Your concern for repainting the screen at a minimum distracts from
> writing a cool video game. It is not necessary. I repaint the entire
> map every step in POWDER and it runs on a Gameboy Advance. If flicker
> is the concern, fix your graphics library to have a redraw() command
> that posts all pending edits. Ie, no changes show up on screen until
> one calls redraw(). This effects double buffering which has been how
> we've solved the 60hz mismatch problem for the last few decades.
I agree with you: double buffering is definately the best, if only,
way to handle this flicker. And when given access to the memory map as
the GBA platform lets you, I would use it in a heartbeat. But with
Win32's propensity to abstract hardware resources the "ideal" page
flip is not viable without going heavy into the OS'es theory and SDK's
like DirectDraw. The software approach using a blit from RAM does work
well (it's what I use for most of my projects), but I feel it's a
little distracting and heavy for the first time programmer.
So as I couldn't buffer away my problems, the thought was to do delta
compression on the output. I do see why this is distracting, and can
be a stumbling block for people as they move ahead - this is not the
normal way things are done, especially as you get into more and more
involved development.
This is off-topic, but because I did development on the GB classic:
out of curiosity, do they still have the tile-based graphics system
built into the hardware? I know they have the onboard Z80 co-processor
to do legacy games, but does the ARM7-based system support that type
of graphics intrisically as the classic hardware did?
>
> 4) I think you are missing a good learning opportunity when you write
> stuff like: "playerx--". Especially when you have the "unmove" path
> inside the switch statement.
>
> A very important concept that beginners may lack is the idea of dx/
> dy. Instead of directly changing X and Y in the switch statement, we
> just set dx and dy to +/- 1. This idea of replacing a "change my
> position" with "store my intended change in position" is very powerful
> when it comes to writing AI - a large part of the AI problem becomes
> just selecting (dx,dy) rather than the conceptually larger issue of
> updating (x,y). We see this when you add collision detection - a dx/
> dy lets you easily remove that from the switch statement so it is only
> written once.
I think you're right. It is a huge opportunity. I'll revamp the first
article.
> Keep up the good work.
Thanks. As always, it's good to get your input.
> I really like the simplicity of it. You really seem to have a good
> understanding of what the target audience knows (i.e. nothing), you're
> not using anything more difficult than what is absolutely necessary to
> get something moving around on the screen.
Thank you!
> Almost makes me want to write an ascii game. I'm reminded of how
> little you actually have to do to get something up and running, none
> of this messing about with perspective transformations and vertex
> buffers.
..and pipeline optimization, and matrix math...
..and by the end of it you still don't have a game.
> For some reason a screen full of .s and #s and @s just looks really
> solid and professional to me, more like an 'actual game' than
> something just thrown together with a half dozen lines of code. I
> guess this is because it's already at the maximum level of
> sophistication possible in the medium, and I've spent so many hours in
> front of screens that look just like that. With 3d graphics it takes
> so much more work to get something looking acceptable, and even then
> it's inevitably inferior to the professional efforts.
That's the advantage of the RL genre and ASCII-based games as a whole.
You can combine the imaginative visualization of text-based games,
MUD's, MUSH'es, etc while having the power of a tile-based system.
Graphics are taken care of, so start putting the fun in functionality
and add content. It's beautiful.
> In conclusion, your tutorial's almost inspired me to switch to writing
> a _roguelike_ roguelike. Maybe I'll have to make that my next
> project.
Wow... I'm honored. Thank you!
There will be more to come, but I have just switched jobs and with
Christmas coming I am already on the hunt for presents for my 5
nephews and my niece. I will be incorporating the suggestions from
this thread during my holiday time starting on the 21st, writing
articles three and four and hopefully hearing back from Rachel
Elizabeth Dillon regarding the webspace access so that she isn't stuck
with the job of posting these things. All in all, the next wave of
articles won't be coming much before the new year, probably a week or
two after.
- Craig
I have something bigger than a poll in mind... I just wish I had the
time to put it out together...
--
Slash
> I agree with you: double buffering is definately the best, if only,
> way to handle this flicker. And when given access to the memory map as
> the GBA platform lets you, I would use it in a heartbeat. But with
> Win32's propensity to abstract hardware resources the "ideal" page
> flip is not viable without going heavy into the OS'es theory and SDK's
> like DirectDraw. The software approach using a blit from RAM does work
> well (it's what I use for most of my projects), but I feel it's a
> little distracting and heavy for the first time programmer.
>
> So as I couldn't buffer away my problems, the thought was to do delta
> compression on the output. I do see why this is distracting, and can
> be a stumbling block for people as they move ahead - this is not the
> normal way things are done, especially as you get into more and more
> involved development.
What is so difficult about blitting from RAM? All you need to do is
create a bitmap and device context in memory, draw everything on the
memory bitmap using the memDC, and just BitBlt() to the screen DC when
you're done?
After that you're done - there's no need to concern yourself with any
sort of fancy techniques to minimise flicker.
- Gerry Quinn
Hmm... That is a good point. Mind you, on the same vein, I know 2d
arrays in general get confusing with C. Like, how do you write a
function that takes one of your maps as a parameter? It might be too
confusing to start them off with map[y*WIDTH + x], however.
> > 3) Your concern for repainting the screen at a minimum distracts from
> > writing a cool video game. It is not necessary. I repaint the entire
> > map every step in POWDER and it runs on a Gameboy Advance. If flicker
> > is the concern, fix your graphics library to have a redraw() command
> > that posts all pending edits. Ie, no changes show up on screen until
> > one calls redraw(). This effects double buffering which has been how
> > we've solved the 60hz mismatch problem for the last few decades.
>
> I agree with you: double buffering is definately the best, if only,
> way to handle this flicker. And when given access to the memory map as
> the GBA platform lets you, I would use it in a heartbeat. But with
> Win32's propensity to abstract hardware resources the "ideal" page
> flip is not viable without going heavy into the OS'es theory and SDK's
> like DirectDraw. The software approach using a blit from RAM does work
> well (it's what I use for most of my projects), but I feel it's a
> little distracting and heavy for the first time programmer.
>
> So as I couldn't buffer away my problems, the thought was to do delta
> compression on the output. I do see why this is distracting, and can
> be a stumbling block for people as they move ahead - this is not the
> normal way things are done, especially as you get into more and more
> involved development.
The thing is that you have already made your
ExtendedWindowsConsole.h. I thus don't see any harm in extending that
file with any black magic needed for double buffering - the user of
the tutorial does not need to know what that file is doing, after all.
> This is off-topic, but because I did development on the GB classic:
> out of curiosity, do they still have the tile-based graphics system
> built into the hardware? I know they have the onboard Z80 co-processor
> to do legacy games, but does the ARM7-based system support that type
> of graphics intrisically as the classic hardware did?
Yes, it has a similar 2D engine built in. Four layers plus sprites,
along with the ability to rotate/zoom the sprites and layers. I
actually use the same abstraction in my SDL ports of POWDER - I just
rewrote the 2d core in software rather than change how the game
interfaces to it.
You wouldn't go too wrong in ditching the Extended Console with
something that just exposes a 2d array of characters for the user to
treat as the screen.
> Articles One and Two are complete and ready for critique. I apologize
> for the delay. Feel free to let me know what you think and please
> point out any gramatical errors or stuff that just doesn't make sense
> or rambles. With everything that has gone on, I'm actually finding it
> hard to think straight lately.
>
> Given it's nature, newbie/lurker opinions carry double weight. So
> stand up and be heard!
>
> Link:
> http://files-upload.com/files/633676/Release.zip
>
> Previous Post/Thread (background/preview of what's coming up):
> http://groups.google.ca/group/rec.games.roguelike.development/browse_thread/thread/4512e5539c2c5896?hl=en
> - Craig
>
> PS. If anybody knows a better @#^! home for the files, please let me
> know. I hate these free upload places, but I am rather useless when it
> comes to web stuff.
>
>
>
Very helpful tutorials Craig! It took some effort but I was able to compile and
run the tutorial in Visual C++ 2008. Everything works fine except for the last
article- I copied the main.cpp exactly and the error I am having is that the
text (Which direction?) appears as this:
????????????? f:ddvc
when trying to open or close a door. The command executes correctly but the text
is jibberish as you can see. The error seems to be occuring in
ExtendedWin32Console.h. I did not edit this file at all and rechecked it just in
case.
I think it might have something to do with the way I have the project setup
perhaps or the fact I'm using Visual C++ 2008.
Can anyone recommend a good C++ compiler for windows? I like how Visual C++ 2008
works but it had a few settings I had to tweak just to get the tutorial to run.
Thanks in advance for the help!
> Everything works fine except for the last
> article- I copied the main.cpp exactly and the error I am having is that the
> text (Which direction?) appears as this:
>
> ????????????? f:ddvc
>
> when trying to open or close a door. The command executes correctly but the text
> is jibberish as you can see. The error seems to be occuring in
> ExtendedWin32Console.h. I did not edit this file at all and rechecked it just in
> case.
>
> I think it might have something to do with the way I have the project setup
> perhaps or the fact I'm using Visual C++ 2008.
raydarken , what settings did you tweak? I only needed to change one:
I copied both source files into a new empty Win32 Console project and compiled.
On compile, I got only one error; C2664: 'SetConsoleTitleW' : cannot convert
parameter 1 from 'const char [19]' to 'LPCWSTR'
This error is because the default project settings in VC++ 2008 use the Unicode
character set, while main.cpp is calling SetConsoleTitle( "Article Three Demo" )
with a plain old single byte string. My fix was to change the Character Set from
"Unicode"to "Multi-Byte Character Set".
> Can anyone recommend a good C++ compiler for windows? I like how Visual C++ 2008
> works but it had a few settings I had to tweak just to get the tutorial to run.
You shouldn't need to change compilers just because of this tutorial... It would
actually make more sense if the tutorial was reworked to use VC++ 2008 Express.
To be honest I'm confused as to why the author chose to use an outdated
commercial compiler rather than the freely available VC++ Express compiler (at
the time of the tutorial's writing it was VC++ 2005 Express).
-e
> You shouldn't need to change compilers just because of this tutorial... It would
> actually make more sense if the tutorial was reworked to use VC++ 2008 Express.
> To be honest I'm confused as to why the author chose to use an outdated
> commercial compiler rather than the freely available VC++ Express compiler (at
> the time of the tutorial's writing it was VC++ 2005 Express).
Presumably because the freeware compiler is incomplete.
- Gerry Quinn
Alright, I began a new project from scratch to retrace my steps. I started by
creating a new>Win32Consoleapplication. This defaults to having precompiled
headers on, but I was having trouble with that before so I turned precompiled
headers off. Every other option was left unchanged. At this point I created a
new ExtendedWin32Console.h copying the code word for word. I also renamed the
default .cpp the program generates for you automatically to main.cpp and pasted
the code from article four into it. Then I built the program and it ran fine,
with the aforementioned error.
Thanks for the help so far, I'm somewhat new to programming in C++. I understand
how it works, but I don't have alot of experience.
> You shouldn't need to change compilers just because of this tutorial... It would
> actually make more sense if the tutorial was reworked to use VC++ 2008 Express.
> To be honest I'm confused as to why the author chose to use an outdated
> commercial compiler rather than the freely available VC++ Express compiler (at
> the time of the tutorial's writing it was VC++ 2005 Express).
That's true. I thought perhaps that there might be a 'better' compiler than VC++
2008 express. But I'm fairly certain that the problem is with my lack of
experience rather than a failure on the compilers part. =/ Ah well, nothing
worth having comes easy I guess! =) There's many tutorials on the web, I'm sure
I'll get better over time!
-Ray Darken
And Gerry Quinn Wrote:
> Presumably because the freeware compiler is incomplete.
Ha ha, were it for that reason. I never went beyond the '98 version.
Depending who I talk to, it is either a relic from the stone ages or
the best of a bad lot. VC++ 6 is my preferred development platform, I
learned the language with it, I know every nuance of the compiler/
linker and the work that do doesn't need anything more feature laden.
As well, I was under the belief that VC++ 6.0 is still quite popular
and the source can directly be exported to Bloodshed DevC++. I have no
idea what the majority of those who use C++ in the RL dev scene code
with.
Truthfully, the newer Visual Studio stuff I've never had need of. I'm
a firmware developer/electrical engineer professionally, and I'm more
comfortable manipulating bits than trying to use OOP-encapsulated data
types, .NET's intermediate machine code, database interfacing or MFC.
I use RL development as a way to keep sharp on the x86 platform, OOP
and coding on CISC architectures.
Edwin wrote:
> You shouldn't need to change compilers just because
> of this tutorial...
Damn right you shouldn't.
Edwin continued:
> It would actually make more sense if the tutorial was
> reworked to use VC++ 2008 Express.
Honestly, that's an awesome idea. It seems unfair to newbies to have
to make them port source from an outdated compiler they've never
worked with to a platform they're still learning. However, I cannot
afford the time to learn a new dev environment as well as write
tutorials, do 9-5 contract work and maintain my sanity all at once.
Heck, I have a hard enough time getting these guides out the door in
any reasonable timeframe.
Since this is just a matter of some quick porting by guys who know
what the hell they're doing, if any body has customized source for
different dev platforms they want to share, send them to me and I'll
include them in the guide with my profuse and heartfelt thanks and
recognition for your work.
Well, I would miss the MFC libraries that come with the professional
edition. And there are things like profilers which you can live without
(I very rarely use them) but are handy to have when you want them.
VC6 works for me too. If it ain't broke don't fix it, I say... and
while it may be broken here and there I am used to its quirks, and don;t
need to learn those of the latest version.
- Gerry Quinn