Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    122
  • comments
    121
  • views
    69253

About this blog

My not-so daily posts on my current console project

Entries in this blog

 

The Programming Squib

Heh, yeah, I feel like a squib right now.*

I've been feeeling a little, eh... stagnant with my programming lately, mostly because I haven't been able to properly complete a project. ((Yes, I realize many of you haven't either :D)) So I bought the GameTutorials set of tutorials... so far I think I've made a worthwhile investment.

I ran through the early C++ tutorials really fast just to make sure I knew what I needed, and I eventually got to some Win32 console stuff, like what I had been doing with cConsole before. One tutorial that caught my eye was "Color Text"... I glanced over it, and behold, text coloring in the console that was far simpler than what cConsole attempted. I really was floundering back there, ugh.

So I ran through the tutorial code, tweaked it, and got rid of the positioning code; I didn't feel I needed it at that point. What I got worked well enough: two functions, ColorPrint and ColorPrintln, that took a text string and a color value. I found I was passing the same color value repeatedly, and besides that it looked really monotonous and klutzy. So I tried something I haven't tried before: I made an iostream manipulator, to use with std::cout.

At first I had the most basic of manips:

class color
{
private:
ConsoleColor myColor; // This is just an enum of colors I made.
public:
color(ConsoleColor theColor)
: myColor(theColor)
{}

void operator()()
{
HANDLE hOut = GetStdHandle(STD_OUTPUT_HANDLE);
SetConsoleTextAttribute(hOut, myColor);
}
};

ostream& operator{
theColor();
return out;
}




I liked this solution a lot better than the functions I had made before. All you needed to do was creat the manip and pass it to cout. Like most manipulators that I've seen, all you need to do is this:


cout

Easy and intuitive, especially because you're using cout there instead of through a function. A few slight gripes I have are that the manipulator does not actually change the state of cout... it changes the attributes of the console itself. This will be important later! For this reason, the operator() doesn't require any parameters, nor does it return anything. The operator
Well, me being me, that wasn't enough. I took the positioning code from before and made it into its own manip. All it does is set where the console caret is... thus, again, it does nothing to the ostream itself, only the console. Again, this will be important later!

Further, foreground text coloring isn't the only coloring you can do with the console; you can also color the background of the character cells. I thus renamed the color manip into 'forecolor', and created the 'backcolor' manip, which looked exactly like forecolor, but bitshifted the color value
The backcolor manip worked just as well as the forecolor manip did... except that they didn't take eachother into account. Do you see the problem? If the console text attributes already had a foreground, if I called the backcolor manip, it replaced the entire mask with the lone background color. Obviously, that's not good, especially because color values are not the only values held in that mask.

In short (yeah, like anything about this post was short!), I called GetConsoleScreenBufferInfo() for the screen buffer info struct, took the attributes mask out (which is of the WORD type), and did some binary ORs and ANDs. The formula I used to retain the original mask, but replace the value I wanted with the forecolor, is ((theMask & 0xFFF0) | myColor). I AND out the part I want to remove, but retain the rest, and OR in the new value! This fixed my mask problem.

Here's the code for the color manips, with inheritance included. Feel free to use it!

CONCOL.H (CONsole COLor)

#include
#include

enum ConsoleColor { CC_BLACK = 0, CC_BLUE, CC_GREEN, CC_CYAN,
CC_RED, CC_PURPLE, CC_YELLOW, CC_WHITE,
CCI_BLUE = 9, CCI_GREEN, CCI_CYAN, CCI_RED,
CCI_PURPLE, CCI_YELLOW, CCI_WHITE};

class color
{
protected:
ConsoleColor myColor;
public:
color(ConsoleColor theColor);
virtual void operator()() = 0;
};

class forecolor : public color
{
public:
forecolor(ConsoleColor theColor);
void operator()();
};

class backcolor : public color
{
public:
backcolor(ConsoleColor theColor);
void operator()();
};

std::ostream& operator




CONCOL.CPP

#include "concol.h"

color::color(ConsoleColor theColor)
: myColor(theColor)
{}

forecolor::forecolor(ConsoleColor theColor)
: color(theColor)
{}

backcolor::backcolor(ConsoleColor theColor)
: color(theColor)
{}

void forecolor::operator()()
{
HANDLE hOut = GetStdHandle(STD_OUTPUT_HANDLE);

CONSOLE_SCREEN_BUFFER_INFO* csbi = new CONSOLE_SCREEN_BUFFER_INFO;
GetConsoleScreenBufferInfo(hOut, csbi);

SetConsoleTextAttribute(hOut, ((csbi->wAttributes & 0xFFF0) | myColor));
delete csbi;
}

void backcolor::operator()()
{
HANDLE hOut = GetStdHandle(STD_OUTPUT_HANDLE);

CONSOLE_SCREEN_BUFFER_INFO* csbi = new CONSOLE_SCREEN_BUFFER_INFO;
GetConsoleScreenBufferInfo(hOut, csbi);

SetConsoleTextAttribute(hOut, ((csbi->wAttributes & 0xFF0F) | (myColor 4)));
delete csbi;
}

std::ostream& operator{
theColor();
return out;
}




There it is. Now, remember how the manips affect the console, NOT cout? This is important, and I'll explain why. When you use one of the color manips, for example, it sets the state of the console to put characters in that color scheme from that point on. This includes input typed via cin. Wow, who would have guessed? Ah, well, like I said, the color manips don't touch cout anyways. They're not exactly your usual manips. This means that you can have the user enter input in a different color. That's pretty neat, isn't it? It works the same for the position manip, even though I haven't put the code up here. Once you set the caret position, cout and cin work from there.

So... pointers, ideas, criticism, and of course colored input are all welcome!

~Jonathan

EDIT: And of course, I forgot to mention! Because both manips are derived from the virtual class 'color', only one operator>> is needed, because it can take a reference to an object of type color. Handy!



* Oh yeah, about the squib comment. In Harry Potter, Mr. Filch the caretaker is a Squib, meaning a wizard-born who's barely got a drop of magic in their blood. A programmer squib, thus, should be obvious. To take the analogy further, compare GameTutorials to Kwikspell, and there you have it.

Twisol

Twisol

 

Book reading

I finally managed to pick up "OpenGL Game Programming", and it is so great.. the one problem I have with it is the math section, and that's only because I don't understand trigonometry yet... but that will change next semester.

A day or so before this, I attempted quaternions to fix gimbal lock I had in a spinning cube. I'm _never_ going back to those until I understand what's going on in there, cause right now, my head is /still/ pounding!

EDIT: Aww, the Hex and Celestial timecounters at the bottom of the page are gone...

Twisol

Twisol

 

*cackles*

Update soon, not like anyone cares, but I thought I'd post this...


Twisol

Twisol

 

Tactics (and Advice)

Well, after some of the people over at #gamedev looked at my code and pointed out at TON of "design errors" (such as the use of BAD_SUIT, BAD_VALUE cards as sentinels for the end of the deck), they told me to mostly scrap the entirety of CardDeck, and change some of the details of Card.h - Card itself was fine - by tkaing out the BAD_ values in the enums, and JOKER in Suits.

So now I'm rewriting CardDeck as an inheritance tree, with base class Pile and derived classes Deck and Hand - yes, this wasn't my idea, which is why it sounds so good. Honestly, I haven't had much experience at all with inheritance, but if I can pull this off, I'll be able to do my next project much more smoothly. It's a big redesign of cConsole.

I've got a design problem in my plan for cConsole though. I'm going to have a ConsoleBase class that contains the core Console info (like the buffer), but I need a way for both of its derived classes to be able to access the the exact same info in it.

For example, if ConsoleBase has derived classes ConsoleInput and ConsoleOutput (not the names I'll use, just an example), and an ConsoleInput is created, it should initialize the ConsoleBase class if it isn't already. Then, if ConsoleOutput is instatiated, it should just use the ConsoleBase info that's already there, rather then creating another instance.

Could that be solved with static members in ConsoleBase? The members would have to be private to keep the derived classes from inheriting them, though. That would keep the derived classes from using them at all. =| Would it work if I made the derived classes friends of the base class? Is that even allowed?

Please comment and help =|

Twisol

Twisol

 

A new level of geekdom

Look at the bottom of my journal before you read any further. Then proceed to comment on my geekiness.



Done? No? Look again.





Hex and Celestial countdowns from THE LAST MIMZY.






In less interesting news, I'm redoing CardDeck almost completely.

Twisol

Twisol

 

CardDeck

Over the past few days I've been slimming down CardDeck, and trying to fix some inconsistencies I've noticed (like the previously mentioned BAD_SUIT, BAD_VALUE cards when I know there's still more cards). If I clear up some of the clutter, though, maybe I can see what's going wrong.

Well, I don't know why I did it in the first place, but I had a size variable to track the vector size. I think it was because I didn't want to include the "BADCARD" at the end of the vector. I removed the size variable and changed all references to it to "deck.size()-1". Definitely a lot easier than adding and subtracting from the size every time cards are added or drawn.

So right now I'm fairly happy with how CardDeck is looking. The only thing I wish I could improve more is operator=, which I'm told should call the copy constructor so as to keep from repeating code. I'm sort of stumped on that - I was told how on #gamedev, but I forgot.
Here's the current implementation of Card and CardDeck. I don't think Card can get much better, it's too simple of a class. :P

Card.h

namespace Twisol
{
namespace Suits
{
enum Suit
{
BAD_SUIT, DIAMOND,
HEART, CLUB,
SPADE, JOKER
};
}

namespace Values
{
enum Value
{
BAD_VALUE, ACE, TWO, THREE, FOUR,
FIVE, SIX, SEVEN, EIGHT, NINE,
TEN, JACK, QUEEN, KING, JOKER
};
}

class Card
{
private:
Suits::Suit suit;
Values::Value value;

public:
/// Default constructor. Initializes the Card to BAD_SUIT, BAD_VALUE.
Card();

/// Takes a Suit and a Value, and initializes the Card.
/// If _suit or _value are negative or too high, initialized to BAD_SUIT, BAD_VALUE
Card(Suits::Suit _suit, Values::Value _value);

/// Returns the card's Suit
Suits::Suit Suit() const;

/// Returns the card's Value
Values::Value Value() const;

bool operator==(const Card& _card) const
{
if (this->suit == _card.suit && this->value == _card.value)
return true;
else
return false;
}

bool operator!=(const Card& _card) const
{
if (this->suit != _card.suit || this->value == _card.value)
return true;
else
return false;
}
};
}



Card.cpp

#include "Card.h"

namespace Twisol
{

Card::Card(Suits::Suit _suit, Values::Value _value)
{
if (_suit == Suits::BAD_SUIT || _suit > Suits::JOKER)
suit = Suits::BAD_SUIT;
else
suit = _suit;

if (_value == Values::BAD_VALUE || _value > Values::JOKER)
value = Values::BAD_VALUE;
else
value = _value;
}

Card::Card()
{
suit = Suits::BAD_SUIT;
value = Values::BAD_VALUE;
}

Suits::Suit Card::Suit() const
{
return suit;
}

Values::Value Card::Value() const
{
return value;
}

} // end namespace Twisol



CardDeck.h

#pragma once
#include "Card.h"
#include

namespace Twisol
{
class CardDeck
{
private:
std::vector deck;
std::vector::iterator currentCard;
int size;
bool (*comp_func)(Card const& a, Card const& b);

static bool CardDeck::CardCompare(Card const& a, Card const& b);
void Init();
void InitDeck(const std::vector& Deck);
public:

// Pass true for jokers.
CardDeck(bool jokers=false, bool empty=false);

// Pass a vector of Cards to be copied.
// Card(BAD_SUIT, BAD_VALUE) will be pushed back.
CardDeck(std::vector _deck);
CardDeck(const CardDeck& _deck);
~CardDeck();

void SetComp(bool (*comp_func)(Card const& a, Card const& b));

int DeckSize() const;
int TotalSize() const;

void Shuffle();
void Sort();
Card Draw(bool remove=false);
void Empty();

void Add(Card _card);
void Add(std::vector _cards);
void Add(CardDeck _deck);

CardDeck const& operator= (CardDeck const& _deck);
};
}



CardDeck.cpp

#include "CardDeck.h"
#include
#include
#include
#include

namespace Twisol
{
Card BADCARD(Suits::BAD_SUIT, Values::BAD_VALUE);

CardDeck::CardDeck(bool jokers, bool empty)
{
if (!empty)
{
if (jokers)
deck.push_back(Card(Suits::JOKER, Values::JOKER));

for (int x = 1; x 4; x++)
for (int y = 1; y 13; y++)
deck.push_back(Card(Suits::Suit(x), Values::Value(y)));

if (jokers)
deck.push_back(Card(Suits::JOKER, Values::JOKER));
}

Init();
}

CardDeck::CardDeck(std::vector Deck)
{
InitDeck(Deck);
}

CardDeck::CardDeck(const CardDeck& Deck)
{
InitDeck(Deck.deck);

int diff = static_castint>(Deck.currentCard - Deck.deck.begin());
for (; diff > 0; diff--)
currentCard++;
}

void CardDeck::InitDeck(const std::vector& Deck)
{
for (int i = 0; i static_castsigned>(Deck.size()); i++)
{
deck.push_back(deck.at(i));

if (deck.at(i) == BADCARD)
break;
}

Init();
}

void CardDeck::Init()
{
deck.push_back(BADCARD);
currentCard = deck.begin();
comp_func = &CardDeck::CardCompare;

srand(static_castunsigned int>(time(NULL)));
}

CardDeck::~CardDeck()
{}

void CardDeck::SetComp(bool (*comp_func)(Card const& a, Card const& b))
{
if (comp_func != 0)
{
this->comp_func = comp_func;
}
}

int CardDeck::DeckSize() const
{
// Subtracts the number of cards that have been drawn from the total vector size.
return TotalSize() - static_castint>(currentCard - deck.begin());
}

int CardDeck::TotalSize() const
{
// Don't want to count the BADCARD at the end.
return static_castint>(deck.size() - 1);
}

void CardDeck::Shuffle()
{
deck.pop_back();
std::random_shuffle(deck.begin(), deck.end());
currentCard = deck.begin();
deck.push_back(BADCARD);
}

bool CardDeck::CardCompare(Card const& a, Card const& b)
{
if (a.Value() > b.Value() ||
(a.Value() == b.Value() && a.Suit() > b.Suit()))
return true;

return false;
}

void CardDeck::Sort()
{
deck.pop_back();
std::sort(deck.begin(), deck.end(), comp_func);
currentCard = deck.begin();
deck.push_back(BADCARD);
}

Card CardDeck::Draw(bool remove)
{
Card card = *currentCard;

if (card != BADCARD && !remove)
currentCard++;
else if (remove)
currentCard = deck.erase(currentCard);

return card;
}

void CardDeck::Add(Card _card)
{
deck.pop_back();
deck.push_back(_card);
deck.push_back(BADCARD);

if (deck.capacity() 1)
{
deck.reserve(deck.size() + 20);
int diff = static_castint>(currentCard - deck.begin());

for (currentCard = deck.begin(); diff > 0; diff--)
currentCard++;
}
}

void CardDeck::Add(std::vector _cards)
{
deck.pop_back();

for (int i = 0; i static_castsigned>(_cards.size()); i++)
if (_cards.at(i) != BADCARD)
deck.push_back(_cards.at(i));

deck.push_back(BADCARD);
}

void CardDeck::Add(CardDeck _deck)
{
std::vector _cards = _deck.deck;
Add(_cards);
}

void CardDeck::Empty()
{
deck.clear();
deck.push_back(BADCARD);
currentCard = deck.begin();
}

CardDeck const& CardDeck::operator= (CardDeck const& _cardDeck)
{
deck.clear();

for (int i = 0; i static_castsigned>(Deck.size()); i++)
{
deck.push_back(deck.at(i));

if (deck.at(i) == BADCARD)
break;
}

currentCard = deck.begin();

int diff = static_castint>(_cardDeck.currentCard - _cardDeck.deck.begin());
for (; diff > 0; diff--)
currentCard++;

if (deck.at(static_castint>(deck.size())-1) != BADCARD)
deck.push_back(BADCARD);

return _cardDeck;
}

} // end namespace Twisol


Twisol

Twisol

 

cConsole

This is a blast from the past... Apparently, Programmer16 studied my cConsole code to research how to "interface with the console", and wrote his own Console class (without the input capabilities, from what I can tell) for use in his recent Quickies games. That's pretty neat, and quite an ego boost for the amateur 'grammer to have his code used in someone else's program.

I'm definitely considering going back and improving it, since it's apparently a useful resource for Windows console programming. I'll get on it after I'm done with my Card classes. Hey, cConsole (renamed to Console when I do it) will definitely be handy at the very least for the C++ Workshop projects.

Uh.. that's actually why I originally wrote it. Talk about getting sidetracked.

Speaking of the Card classes, I haven't worked on them much lately, but CardDeck needs some reworking, since it's got some very strange bugs, like iterator invalidations which I had thought I'd fixed, and on Draw() getting an invalid card when I know there's cards in there.

Finally... it'd be nice to get a comment or two here? My last few entries garnered zilch.

Twisol

Twisol

 

War!

War is coming along well. I have the basic Card and CardDeck classes, with CardHand on its way. I'm also working on the War class, which will handle most of the details of the gameplay. When it's used, you simply create an instance of War, specifying with a bool whether to include Jokers or not, and then run a while loop that iterates over War::Fight() and War::Draw().

Making the two steps of the game into two functions allows the user to do additional stuff between the draw and the fight, such as wait for user input before doing either. Also, a built-in safeguard prevents more than one draw in a row, as well as more than one fight in a row. As well, Fight() handles the details of the "War round". Draw() returns whether the cards were drawn at all (in case someone's deck is out), and Fight() returns the result of the battle (1 if you won, 2 if the opponent won, and 0 if it was a war).

How does the user figure out whether there will be a War round before it occurs? The GetPCard() and GetOCard() methods return the Card that the Player or the Opponent, respectively, will be playing next turn. They returns BAD_SUIT, BAD_VALUE cards if there was no Draw() after the last Fight(), or if the one player has no cards left. This effectively also lets the user know whether one player has won, as there will never be a winning game with both players having empty decks, nor will there be a case where only one deck is drawn from. (I'm sure I could implement a helper Won() function if I think it's required...)

I'm debating over whether to add GetPSize and GetOSize methods, because that would take away from the value of the Get[X]Card methods being able to tell you if there was a winner, although it would make it easier.

Anyways, thoughts on my progress?

Twisol

Twisol

 

Harbinger Update

Um... Not much to update on actually. I got sidetracked on a more basic project.. the infamous card deck.
Vector iterators stink. If you have two, and you erase at one of them, the other one gets invalidated! -_- I was trying to make a sort for my deck - using my own home-made algorithm - but I kept getting mysterious "iterator out of range" runetime exceptions. Debugging brought me to my deck.erase statement - or at least the area around there. Meh. At least I learned a bit about , cause I'm using std::sort from there instead.

That leads me into the next update-rant. For some freakish reason, std::sort won't accept list begin() and end() iterators. I honestly don't know why, but when I tried to switch to a list - you know.. to see if I could solve my original invalid iterators problem - it threw THAT at me. UGH!

But, all is well. I'm still using a vector, and I'm sticking with std::sort... pity about my algorithm. I've got card types and suits set up, a constructor that lets you specify whether to have jokers or not, a DeckSize() function for the current size of the deck (excluding drawn cards), a TotalSize() function (it gives you the entire decksize, including drawn cards, which aren't actually removed from the vector), and Sort() and Shuffle() functions (which automatically return the deck to its fully un-drawn state, where TotalSize() and DeckSize() would be the same).

I was originally planning on having CardDeck be able to act as a hand too, but it seems a bit too complex for one class, so I'll likely remove Sort() and use it for CardHand. After I finish that, I'll be making a basic War card game. :D

So, summary: War going well, Harbinger on hold.

P.S. Did I mention I got Apache, MediaWiki, mySQL, and PHP5 on my iPod?

Twisol

Twisol

 

Code::Blocks

I got U3 working, and I love it, but I'm working out the kinks on the rest of my thumb drive programs, like Code::Blocks; see next paragraph.

I've installed Code::Blocks on my Cruzer - it's easier to call it by its model name than "USB drive" or "thumb drive", and it sounds cooler - but I can't get it to see the MinGW compiler I installed there too. That means, I can't compile any programs! I tried getting MinGW to work with SciTE - a text editor I only picked up because it has decent Lua highlighting, and it's easy to point it to a lua compiler - but even when I point its C++ compiler setting to the compiler executable, it tosses a gazillion errors at me - all sprouting from me including . -_-

So, now I'm on the GameDev IRC channel, scrounging around for help getting this to work. (Code::Blocks, not SciTE, please) I guess I'll be able to get back to real programming when I come back from vacation... that's in 8 days.

Twisol

Twisol

 

Florida

I've arrived in Florida! I managed to snag a two-gig flash drive from OfficeMax for $30 right before we left, so woot! But it's got some U3 Launchpad thing on it, and I can't do anything to the drive - it's write-protected apparently. And worst of all, U3 Launchpad won't launch, so I can't even delete it. -_-

Help?

Twisol

Twisol

 

Vacation

I'm going on vacation for two weeks in Florida! I'll be staying right by the east coast, and there's a cute girl living right across the street. [gasp] If I'm lucky, I might be able to work on some Lua while I'm there, but C++ is probably not going to happen. I tried to get a USB flash drive (2GB) today, but we didn't have time, so I'll have to grab one tomorrow if possible, but that's when we're leaving. I guess I'll just download lua and luac when I get there.

As for the airplane trip, I bought a magazine, four Dragonlance novels, and a book on applying mathematical concepts to game programming. I'm going to go through it all by the time we arrive in Florida...

Oh, does anyone know if it's possible to get your GDnet username changed?

Twisol

Twisol

 

Real Life

Well, I got cut off before I could properly finish my previous entry, because my father needed to get on the computer. Continuing:

I've been taking classes at my local community college. I just recently finished my Geometry finals - I've been averaging a B- on my test material, so I'm hoping I got a good grade! I'm heading into Intermediate Algebra in the fall. I have to wait for at least next spring or fall to be allowed to take a Java course - I think I have the basics of C++ down, so I won't be taking that class unless it's absolutely nessecary.

Twisol

Twisol

 

The moon

I guess the Portuguese actually don't see the same moon as the rest of us. Seems they just see a big ball of code in the sky.

Ahem.
And for those people who actually comment here, I might just try SDL after I get a handle on the Lua basics. I kind of want to work on a simple text game before I go into graphics.

Twisol

Twisol

 

Graphics

This is mostly just a response to comments in my last entry.

I know graphics is an advanced subject, but I've been doing text for 1-2 years now... I've already made enough text RPGs to make me sick. >_
In other news, I reinstalled World of Warcraft on my new computer; glad to say it works with Vista, unlike Guild Wars (:'(). I'm planning on getting the expansion ASAP.

Did I ever tell anyone I beta tested WoW: Burning Crusade last winter?

Twisol

Twisol

 

OpenGL and Windows

So, I finally got around to downloading the PSDK, and I grabbed my OpenGL Superbible and did some example stuff, read a bit, etc. Unfortunately, their collision-detection on the square-bouncing-off-window-walls example was off (strangely), and the square bounces windowHeight+squareSize too high, and bounced squareSize up off the bottom (like some kind of invisible floor). Well, poo. (Yes, I tried fixing it. No luck.)

I'm trying some Win32 (you heard me) programming with Windows instead, just to get a grasp on windows and event-driven stuffs, using a tutorial at this site.

OpenGL is definitely not a beginner's API. =|

EDIT: Scratch that. I'm done with Win32. Just going to try to dig through some OpenGL code...

Twisol

Twisol

 

Harbinger

Sorry for the lack of updates, I've been doing stuff in Real Life(TM).

I decided to dump the Harbinger code base and start fresh. I think it's going a lot better, especially after reviewing some topics like operator overloading (specifically nonmembers, and operator

Twisol

Twisol

 

Harbinger

So far so good, P16 got the scripting engine going, and I'm working on a TinyXML file parser. Just dropping in for an update.

Twisol

Twisol

 

The Cow jumped over the Moon

About the title: My math teacher was discussing the origins of the name Lua (Portuguese for Moon), and since Lua is Luna minus the N, he said "Well, Moon minus the N is Moo."

Anyways, with Programmer16's help, I found a tutorial that's up to date with Lua 5.1, so YAY, I've got Lua working. Now I've got to experiment with calls between Lua and C++ (making a calculator as a test project), and then I'll try integrating into Harbinger (that's not for a bit though).

To Programmer16: I was away today, wasn't home at 5 EST, sorry.

Twisol

Twisol

 

Lua 5.1.1

Well, Scavenger (on IRC) may/may not be joining Project Harbinger part-time, sinec Programmer16 wants to devote a little more time to Ascension. Meanwhile, I've found a new hobby, which might (read: WILL) make people think I'm crazy, or a loon. Check it out, though, it does make some sense.

On the subject of loons, I'm trying to get into Lua 5.1.1. I'm having MASSIVE trouble getting the luaopen_ functions to work, since they have to be pushed onto the Lua stack, then their arguments, then called from the stack. And apparently, when I call, I'm trying to call a nil value. Here's my code, from memory (since I'm on another computer):


lua_State *L = lua_open();

lua_getfield(L, /**/, "luaopen_io");
lua_pcall(L, 0, 0, 0);



When I check for errors (using a handy function I found on the net), I get a "calling a nil value" or whatever error, so apparently I'm not pushing luaopen_io properly, or using lua_pcall right (but I've tried it every which way). Help would be VERY appreciated... [sad]

Twisol

Twisol

 

Project Harbinger

Me and Programmer16 are working on a text adventure together (codename Project Harbinger), and it's very much like WinMUD, except P16 and I made a design doc for it, and we're using XML for the item, room, and monster files. Gotta get to figuring out TinyXML; I tried it once and got confused.

Twisol

Twisol

 

WinMUD, SVN, and XP, oh my!

Technically WinMUD is not a MUD, but its the name I gave it when I started, so I'm sticking with it.

Anyways, I've decided to change my to-do list to reflect changed to WinMUD instead of Arenamatic, since the only part of Arenamatic I was really looking forward to (and pleased with) was cConsole. Take a look. [grin]

I've finished, for the most part, the Roomset component. It's fairly well-known, or at least I thought it was, that a MUD or similar game is made of three parts: rooms, connections, and entities. And, duh, functionality, but I'm talking about actual parts. So far I have the rooms and connections finished, and I'm working on entities. Now, that doesn't mean I'm almost done; no, I still have the command parser after that, and then I'll have to figure some way of linking (not the compile-and-link sort) them together.

In other news, I got an SVN up. Sooner or later I'll get a link up to it; make it easy for you to look at my progress. I'll be committing my changes every time I get something right, which might be a couple times a day, so when I get the SVN up, watch it. [wink]

Also, I set up a new WinXP account exclusively for my programming stuff. I've named it ProGamer RM, kudos to anyone who can figure out why. (if no-one guesses, or comments, I'll say what it is in the next entry)

Gonna work a bit more tonight then head to bed.

Twisol

Twisol

 

Overdue Update

Holy geez! It took me HOURS last night to debug cConsole after installing the Platform SDK for VC++ EE. I had to mess with casting LPCSTRs and wchar_t's, and I'm still not sure if it's not working properly.

Lately I've been working on a sort of "text adventure", like a MUD, but one player. I have the room system working, and I'm making the commands system, but I thought it'd be neat to use cConsole for some of it, and one SDK installation and many wasted hours later, all I've managed to do is have a cConsole instance up. -_-

Ugh... G'night.
((Written last night))

EDIT: After reading this over in the light of day, I realized I'm technically doing Project 2 of the C++ Workshop. [lol]

Twisol

Twisol

 

cConsole

I've mostly been working on trimming down cConsole, but a new addition to the list of functions is setBG(char color);, which allows you to set an overall background color. Basically, you call setBG before you do anything (unless you want a black BG) and you start with a background of that color. Then, you can call output with either a value with only the foreground (0x0F for white foreground), and it'll OR the background with the foreground, or you can pass a background and foreground value (0xAF) and it'll override the setBG value.

I've also removed the flush boolean paramater from output, and added a flushBuffer() function, to make it easier to use output() properly.

Also, I've uploaded a new version of Arenamatic, complete with cConsole[.h/.cpp]. It's at the same link as usual, just above this post.

EDIT: The 'cyan' colored cConsole entry up top is just a temporary color I added to at least show I've been working on something. [wink]

EDIT2: What's with tags not working?

Twisol

Twisol

 

MSDN

I've been mucking through the MSDN today, and I found a couple useful console-related functions I could use, particularly SetConsoleTextAttribute(). Not too big of a change, but it does allow for setting a "default" color. cConsole::output() now only requires the string to be passed. I'm changing the order of the default variables too, so it starts with the string (a must-be-passed), then takes the flush switch (whether to flush the buffer to the screen or not), then the color, then the row and column integers. Outputting is as easy as "console.output("Yay!");" now. [smile]

EDIT: OK, so if you're a nitpicker, you'll notice that you'd have to make it ("Yay!", true) in order to even SHOW the text, but really. That's just chronic nitpicking, there.

I lied. I botched it. I'll work on it tomorrow... today. Whichever is when I wake up. [flaming]

Twisol

Twisol

Sign in to follow this  
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!