MultiWindowed Adventure Game
in [ASM]
|
From: Frank Kotler on 28 May 2005 22:44 Evenbit wrote: > Ohh shubby-up! Every programmer needs to caress a couple of these > ( )( ) to keep this ; from falling off. ;-) I actually prefer (.)(.)s - they ain't much use without the "."s :) ;s just turn my | into a ~. .... > > only way I can figure out to "push 0" in HLA is to zero a > > register and push that. > > So, the intuitive "push (type byte 0);" doesn't work? It's a bleedin' immediate! What's it need a "type" for? Besides, Randy says "pushd (0);" is more intuitive. The cryptic "push (0);" apparently encounters an unexpected constant - "near << 0 >>", it helpfully points out... > > Yup. Thanks for the chemistry set! > > If you decide to mix up a batch of blue skin dye, I had in mind something either psychoactive or explosive, actually, but if it turns out to be blue skin dye, I'll keep your suggestions in mind. ("... coming home all hours... and colors"). Best, Frank
From: randyhyde on 29 May 2005 11:33 Charles A. Crayne wrote: > On 28 May 2005 14:23:44 -0700 > randyhyde(a)earthlink.net wrote: > > :Naw, just make it multithreaded. That's the easier solution (well, > :assuming you understand the basics of concurrent programming and > :synchronization). > > May we presume that all of the HLA libraries are reentrant? Of course not, they make calls to the LINUX and Win32 API :-) However, reentrancy is not a requirement for multithreaded. That's what synchronization is all about. BTW, most of the "standalone" library routines *are* thread-safe. Certainly not all, but most. Again, though, the fact that calls like "stdout.putc" place output on the console window means that you're not going to be able to call stdlib routines with wild abandon. Then again, a true "multiuser" game like MUD would not require sophisticated multithreaded operation. What you really want is a distributed application. You'd need only two threads on any given machine, the main thread (playing the game for the particular user) and the thread that communicates with the other machines on the network. Synchronizing those two threads in a "very soft real-time" system isn't that difficult. Put one critical section around all access to shared data and you're in business. The "network interface" module wouldn't need to call much in the way of HLA stdlib routines, so whether they are thread-safe or not is really irrelevant. Cheers, Randy Hyde
From: randyhyde on 29 May 2005 11:34 > > > > So, the intuitive "push (type byte 0);" doesn't work? > > It's a bleedin' immediate! What's it need a "type" for? > Besides, Randy says "pushd (0);" is more intuitive. The > cryptic "push (0);" apparently encounters an unexpected > constant - "near << 0 >>", it helpfully points out... I don't know that it's intuitive, but it's what other assemblers use (MASM, in particular), so I just followed suit. Cheers, Randy Hyde
From: Jim Carlock on 29 May 2005 13:51 <randyhyde(a)earthlink.net> wrote: > What you really want is a distributed application. You'd need only > two threads on any given machine, the main thread (playing the > game for the particular user) and the thread that communicates > with the other machines on the network. I only see the need for one thread on the client side. The server will need to be worked in some other way though, one thread per connection? For instance, the MUD exists at http://www.aardmud.org/ . All you need is something like TelNet to connect and get going. The fancy features of true Mudding software, just creates different windows for various things but it operates on one thread, through one winsock. Data in and data out through the winsock control. The server I'm imagining is a map with a thread per connection. Each character exists in one and only one area at any given instant. The only thing that character needs to see are the events in that one area, unless there's some kind of other comm going on, in which case, the communication data might have a header to indicate it goes to a certain window (a thought window, a question window, a help window or whatever). That's pretty much all client side interpretations. Still only one thread on the client because the MUD connecting software is an MDI inter- face. As far as Multi-User Doom goes, only one thread. It processes the events over the WinSock channel as appropriate. It sends and receives based upon user responses. One person sets up a system to connect to and so in that case it might create multiple winsock controls, but I think it'll all happen on the same thread, no? The aardwolf mud seems to get 500 to 600 connections. I've seen some games handle up to 2000 connections, but that was in 1996 and their servers seemed to get a little slow with that many connections (www.simutronics.com pay per connection). They offer a free 30-day connection I believe. They used to have a neat front end written in C++. They used to be FREE through various online services, AOL, Compuserve, but then they started getting over 2000 logins in at one time and their servers slowed down and they decided to go to a pay-per- connection where they charged $10.00 per month per account. The connections dropped to about 1600 at most and last time I looked ( a couple years ago ) they were at about 900 connects at any given time. Aardwolf is a free mudd that seems to be pretty popular. The way I see a server being set up, is to have a map of each area, and each area has some attributes for the NPCs that roam that particular area, meaning you will find only certain creatures in certain areas, that way if you go to the north side of the world where it snows, you won't see an elephant, but might see a wooly mammoth. So I'm thinking that only one thread is needed even on a server, provided the server processor and the network is fast enough to handle all the connections? I can imagine starting a special thread if you wanted to throw an invasion of some sort. Just guessing. -- Jim Carlock Please post replies to newsgroup.
From: Frank Kotler on 30 May 2005 05:20
Frank Kotler wrote: > > "T.M. Sommers" wrote: > > ... > > but playing with the test program > > below it appears that you will get a SIGBUS if the original size > > fo the file is 0, regardless of the size of the mapping. If the > > original size of the file is not zero, > > I see what you mean, after playing some more. If I write > something to the file - say with a text editor - before > running this, it works! Lo and behold, if I write a bunch of > "dummy" data to the file, after opening it (of course), but > before mmapping it - ta da! Just to bring this up-to-date... a file-size of 1 is fine. I ask to mmap 4096 bytes - I guess that's what you'd get anyway - and can write anywhere in that area. SEGFAULT, not SIGBUS if I try to write beyond it. The SIGBUS seems limited to just the zero-length file. The HLA version isn't going to work for me unless I can figure out where to lose the O_TRUNC flag... That's some pretty cryptic code, even looking at the .asm file... Seems to be using a 28-byte structure, 24 bytes of mmap args, and a pointer to "method"? Different for Windows or Linux, I suppose... I caught myself trying to comment out a line in my Nasm code with "//", so I think it's time for me to take a break from HLA :) My Nasm code is working - not quite the way Randy does it - I just print out the alphabet repeatedly and pass it to the other process to be displayed. Works in two "regular" terminals (not on screen at the same time, of course - not something Paul could use) or in two xterms (not really what Paul wants, either). Still, I thought I'd try to set the scrolling area with "ESC [3;25r". That works in a "regular" terminal, but in an xterm, the top two lines (the "infobar" if I had one) stay at the top of the text buffer - I can scroll back up to 'em - but they don't stay on screen. Similar to what Paul was encountering in a Windows console, I think. Anyway, the "communication" part works. PITA to have to have that one-byte file on the drive - can sys_unlink it at the end, I guess... Best, Frank |