# Another Simple Text Question

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

## Recommended Posts

I've got a pretty well developed ORPG going on, and now I'm starting to program the actual game server. The problem is I've been working so long on the client which uses DirectX, and now that I'm writing the server, which will not be using DirectX, I'm finding myself getting confused on some very basic Windows GDI stuff because I've never had to use it up to this point. For the first test server, I just want to start with some simple chat functions which will mean typing lines of text into the window, then having them move upwards as new buffers of text arrive (just like any other chat program). Printing text onto the screen in GDI seems pretty straight forward, but unlike my game client the screen won't be updating and redrawn all the time (every loop), so basically the text stays there until it's erased (right?). So here's the stupid question... What's the best way to erase the window when I need to update the position and/or content of the text? Do I color in the areas I need erased with say "black" using a brushed rectangle? If so won't this just fill the area with unnessary pixels? In other worlds is there a simpler "erase" function where maybe you just feed in a RECT as a parameter and it just clears the area you want cleared? And if I'm only updating on a "as needed" basis, do you think it will still cause unsightly "flicker" and if so is there a simple away around that? Thanks again in advance, you guys have yet to fail me in the past. (Oh, programing in C, no MFC or anything)

##### Share on other sites
Why not just make a console application?

##### Share on other sites
I know watcha mean. But I really,really want to use Asyncronous Sockets, which are are only for Windows, plus I'm going to need menus and buttons and other resources to access various information about server status, player status, and other general statistics. Windows just works best for my particular application I have in mind.

##### Share on other sites
Well console applications are Win32 and there's nothing stopping you using asynchronous sockets, but I can see why you don't want to use a console app: it's ugly and (in my opinion) unprofessional.

Nevertheless, 'console' is still a word to remember, as this describes the text-queue structure you describe. I'm sure Google will produce something useful if you ask it for a GDI console sample.

Anyway, you'll probably want to use double-buffering. Do all your drawing to an off-screen surface created with CreateCompatibleDC, CreateCompatibleBitmap. The surface should be cleared either using BitBlt, passing the BLACKNESS/WHITENESS raster-op or, if you want a coloured background, FillRect with an appropriate brush. The usual GDI functions (TextOut/DrawText) will let you draw on the cleared surface. Once you've drawn everything, BitBlt it over to the window's DC. Throw this in a loop that's called each time something needs updating, and you'll have a flicker-free event-driven render loop.

Regards

Console unprofessional? I log into $1000doller/month Linux servers all the time using ssh... I made my server a console application that excepts no input. I access server through a special client on a different machine witch has full blown 3d GUI on top of regular client – so that i can view game state and alter it and view stats. This way i can manage my server form any place in the world and and have very nice manager only at ½ the cost because the other ½ comes from the client. #### Share this post ##### Link to post ##### Share on other sites Quote:  Original post by eiforallConsole unprofessional? I log into$1000doller/month Linux servers all the time using ssh...I made my server a console application that excepts no input. I access server through a special client on a different machine witch has full blown 3d GUI on top of regular client – so that i can view game state and alter it and view stats. This way i can manage my server form any place in the world and and have very nice manager only at ½ the cost because the other ½ comes from the client.

Well of course, but that's a completely different scenario.
If I paid for an online RPG subscriptions and found that its game console was in a Windows console box, I'm sure I wouldn't be thinking 'How wonderfully professional'. Immersion is a rather different story to functionality.

Regards

##### Share on other sites
Actually, you two's argument is wonderfully coincidental in that it has more to do with what I'm doing then you think. First, thanks for your solutions Admiral, it sounds like exactly what I need to create my TEST chat program, and because I've been using DirectX, your solution sound very similar to using and flipping the surfaces I'm used to with DirectX. As far as what Eiforall said, he's perfectly in the right too! My final goal indeed is to have a server program that displays, well, absolutly nothing! Theory goes; if the game ever out grows a simple home server running on Broadband, then the day may come when I need to rent out one or more of those super powerful servers they have locked in some strange and mysterious building somewhere. And if that's the case the server program will need to be run almost completly by remote access, eliminating it's own need for any kind of display. But for NOOOOOOOW...... While I'm developing it I'd really like to have a nice display so I can see what all my variables and connections and such are up to, and I'd like make it look pretty for the other guy's who will be testing it also. So anyway, I should be well on my way, thanks again!

##### Share on other sites
For a game server, console apps are commonplace, with a HTTP remote access for all but emergency maintainence.

Sorry about not helping with the GDI stuff, I don't know how to do that!

##### Share on other sites
Just adding another vote for a standard console app (or some daemon run which allows http or game client control). Logging and admin features are things that just need to work. Pretty just complicates matters.

##### Share on other sites

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