Jump to content
  • Advertisement
Sign in to follow this  
Albatross3

Game Console

This topic is 4165 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'd like to include a console in my game - at the moment I'm just using cout. The game is 3d, and I'm using SDL (although the question isn't SDL specific). My current thoughts are to implement a console like this:
class Console{
private:
	//Display the console?
	bool isVisible;
	//The width in chars of text to be rendered
	int viewWidth;
	//The number of visible lines of text
	int viewHeight;
	//Number of pages of text the buffer holds
	int numPages;
	//All the text currently in the console
	char* buffer;
	//The location on screen to write to (in char's, not pixels)
	int x, y;

public:
	//Write a char to the console
	void putch(char c);
	//Write a string to the console
	void print(char* s);
	//Scroll 'num' lines
	void scrollUp(int num);
	void scrollDown(int num);
	/*Render the console to screen.  Will basically draw a background image
	  over the top chunk of the screen, then render using SDL_ttf the data
	  which is in view, according to the buffer.
	*/
	void render();
	//Show and hide the console
	void show(){isVisible = true};
	void hide()(isVisible = false};

	Console(int p_viewWidth, int p_viewHeight, int p_numPages){
		viewWidth = p_viewWidth;
		viewHeight = p_viewHeight;
		numPages = p_numPages;
		buffer = new char[p_viewWidth * p_viewHeight * p_numPages];
	}
	~Console(){
		delete [] buffer;
	}
};
Any feedback on this design? Or even better a library to do all this for me, which is reasonably sized (I don't like huge libraries I'm afraid :)) Thanks in advance :)

Share this post


Link to post
Share on other sites
Advertisement
You are using C++, so always, always, always use std::vector and std::string. They will make your life 1000 times easier. If you let them use std::string, they will have a much easier time printing stuff to your console. If you use std::vector, you can keep your buffer appropriately sized and never worry about running out of room. Third, you should use source tags for easy viewing of your code.

Here is my version of your code:


class Console
{
private:

bool isVisible;
int cursorX;
int cursorY;

// all the text currently in the buffer
std::vector<std::string> lines;

// i am leaving these in because you probably need them to calculate
// where to draw your text
int viewWidth;
int viewHeight;

public:

// one universal write function
void Print( std::string text );

void ScrollUp(int num);
void ScrollDown(int num);

void Render();
void Show() { isVisible = true };
void Hide() ( isVisible = false };

Console( int viewWidth, int viewHeight )
{
this->viewWidth = viewWidth;
this->viewHeight = viewHeight;
}
};

Share this post


Link to post
Share on other sites
It doesn't make any difference for a console, but probably a list is better than a vector in theory - you probably only ever iterate through the elements or look at the most recent one, so the random-access functionality of a vector isn't required.

I'd quite likely do it as a vector myself though, unless it was a coding test!

Share this post


Link to post
Share on other sites
Does std::string have a method setup so you can give it a string of text plus args like printf("text and stuff %i, %f",myint,myfloat)? I always find myself having to write custom functions with <stdarg> to do this and it never occurred to me it might already be present in std::string.

Share this post


Link to post
Share on other sites
Quote:

Original post by My_Mind_Is_Going
Does std::string have a method setup so you can give it a string of text plus args like printf("text and stuff %i, %f",myint,myfloat)? I always find myself having to write custom functions with <stdarg> to do this and it never occurred to me it might already be present in std::string.


Look for information on string streams.

Share this post


Link to post
Share on other sites
Quote:
Original post by d000hg
It doesn't make any difference for a console, but probably a list is better than a vector in theory - you probably only ever iterate through the elements or look at the most recent one, so the random-access functionality of a vector isn't required.

I still think a vector would be more appropriate than a list in this situation, because you're not reordering the elements at all. But it's not like this is a critical situation with thousands of elements being accessed hundreds of times per pass, lawds :D

Back on topic, my only gripe with the design would be that the Console is inherently coupled with the rendering API, but I guess it gets the job done nonetheless.

It looks like you're planning on scrolling the text whole lines at a time. I think smooth scrolling would look a lot nicer, but you'll have to tinker around with SDL's clipping regions (or play with the dest rects) to make it scroll well at the edges.

With the print function, consider using a const char* or a const std::string& (depending on which one you decide). You might also want a function which toggles the show/hide state of the console, and possibly some additional const accessor functions to retrieve the console's state.

za warudo etc.

Quote:
Original post by Gage64
Quote:

Original post by My_Mind_Is_Going
Does std::string have a method setup so you can give it a string of text plus args like printf("text and stuff %i, %f",myint,myfloat)? I always find myself having to write custom functions with <stdarg> to do this and it never occurred to me it might already be present in std::string.


Look for information on string streams.

Or boost::lexical_cast [wink]

Share this post


Link to post
Share on other sites
Quote:
Original post by Mike.Popoloski
You are using C++, so always, always, always use std::vector and std::string. They will make your life 1000 times easier. If you let them use std::string, they will have a much easier time printing stuff to your console. If you use std::vector, you can keep your buffer appropriately sized and never worry about running out of room. Third, you should use source tags for easy viewing of your code.

Here is my version of your code:

*** Source Snippet Removed ***


If you want your game servers to run very long with no memory fragmentation, I suggest you use static Arrays that you "new" at start. And never touch the memory again.

std::string are fun, but lot of new is done in there. Else you allocate bunch of std::string with fixed size at start. <- That would work.

That's my only concern, memory fragmentation. Can slow down your servers if you run the game for like a week. For the client it's not really a concern.. it can be if the player is very serious and competitive.

Share this post


Link to post
Share on other sites
Quote:
Original post by Daivuk
If you want your game servers to run very long with no memory fragmentation, I suggest you use static Arrays that you "new" at start. And never touch the memory again.

std::string are fun, but lot of new is done in there. Else you allocate bunch of std::string with fixed size at start. <- That would work.

That's my only concern, memory fragmentation. Can slow down your servers if you run the game for like a week. For the client it's not really a concern.. it can be if the player is very serious and competitive.
This is not an issue. I worked for 3 years on a C++ system which had a server running about 40 apps and ~10 clients running around the same number, on Windows. It was quite impressive but anyway the point is we used STL containers a lot, and we had a LOT of string manipulation all over the place. Our system could run for several months without a restart, and we never say memory issues, at least not connected with STL. Any memory issues we found were always due to failing to delete dynamic memory or release COM objects.

You do NOT need to worry about this just because it's a game. And even if you did, your console is not processing thousands of lines a minute so it would be insignificant.

STL is designed for serious applications, not as a toy library until you get round to writing your own version.

Share this post


Link to post
Share on other sites
That's correct.

But I wasn't talking about RAM corruption, but Fragmentation. The OS needs more time to process a alloc if the RAM is fragmented.

But, maybe OS are bright and handle that very well anyway... That I can't tell!

But I've noticed performance hit because of 'new'. For a game, I think the usual thing is to do is to load all the level in Ram, all the entities, and not reallocate them in real time.

Share this post


Link to post
Share on other sites
Quote:
Original post by Daivuk
That's correct.

But I wasn't talking about RAM corruption, but Fragmentation. The OS needs more time to process a alloc if the RAM is fragmented.

But, maybe OS are bright and handle that very well anyway... That I can't tell!

But I've noticed performance hit because of 'new'. For a game, I think the usual thing is to do is to load all the level in Ram, all the entities, and not reallocate them in real time.


Why are you so worried about fragmentation? I don't think there are too many games that are allocating and loading things in just the right way as to make them contiguous in memory. Besides, doesn't the OS give you a slice of RAM that you can mess with anyways? When you're done, it will just clean it all up for you.

Anyways, the benefits of using std::string and std::vector over the conventional C counterparts clearly outweigh any possible performance benefit, if there is any at all.

Share this post


Link to post
Share on other sites
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!