MultiWindowed Adventure Game
in [ASM]
|
From: Betov on 28 May 2005 07:26 Frank Kotler <fbkotler(a)comcast.net> ýcrivait news:429854A3.5EE6E328 @comcast.net: > Thanks a lot for the help! Now, must sleep... You'd better suicide: The sleep time is longer. Betov. < http://rosasm.org >
From: Evenbit on 28 May 2005 14:31 Frank Kotler wrote: > > Have you tried it in C? > > While I'm in the "unintuitive" business? :) Ohh shubby-up! Every programmer needs to caress a couple of these ( )( ) to keep this ; from falling off. ;-) > If that turns out to be true, Paul's game - or, ummm, any > other project that wanted to communicate between processes > in this way - would have a certain "minimum requirement". > Not a problem, but I wouldn't want to do it unknowingly. But isn't that - ummm, other project - an adventure game too? If not, then the glossy brochure needs reprinted. And I don't think anyone can forget that over-the-top TV ad during the SuperBowl game! Annie looked mighty fine in that skimpy Xena Princess Warroir-style outfit ;-) > > ... > > > mov ecx, 2 | 100q | 1000q ; O_DRWR, O_CREAT, O_TRUNC > > > mov edx, 666q > > > > I think this might be a problem: the 666 should be octal, not hex > > (which I assume q implies). And here I thought my version of Elsinore was Satanic! Remember, throw a handful of sand into the bottomless chazm, then you will see why you can take "a leap of faith" into interprocess communication. > > I'm not going to urge you to learn Nasm - much less HLA. The > 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? > > Yup. Thanks for the chemistry set! If you decide to mix up a batch of blue skin dye, I will suggest that you experiment on the various green goblins who tend to scurry around these parts. ;-) Nathan
From: randyhyde on 28 May 2005 17:23 Beth wrote: > > Also, consider, Paul, that for the "multi-player" thing, you're going to have to change the structure of the "engine" a little...basically, swap "line input" for "character input"...accept one character of input at a time and then just "concatenate" them as you go along...this is so the game doesn't "get stuck" - paused - waiting for input...it looks for an input character but if it isn't there, then it doesn't wait and carries on processing the game... Naw, just make it multithreaded. That's the easier solution (well, assuming you understand the basics of concurrent programming and synchronization). > The "multiple windows" things sounds a bit "overly complicated"...and it's not too "transferrable" because some games just wouldn't be appropriate with the interface scattered all over the desktop...though, that said, it does give "GUI windowing" abilities to a console game (you can re-arrange your game windows on the desktop into your "preferred" configuration, exploiting Windows / X itself to do the "hard work" there :)...but all that "file mapping" and sending messages and such? I don't actually think, in practice, it would be "easier" or "more convenient"...dealing with the "scrolling" yourself is, I think, less of a difficult thing to do than trying to avoid the "scrolling" by using multiple console windows...a case of "diminishing returns" or a "pyrrhic victory", so to speak...it's so much effort avoiding the "scrolling" that you really would have been better off _dealing_ with the "scrolling" issues yourself directly than trying to "side-step" them... The shared memory aspect certainly won't scale across multiple CPUs (unless you've got distributed shared memory). Alas, the memory-mapped file scheme that I've used doesn't guarantee coherency across a network. So writes to a mmapped file don't appear in the address spaces of other CPUs (that aren't sharing the same physical memory). > > At least, I'd advise giving my "virtual console" idea a whirl first...it really will be the simpler to begin with...then try out the "multiple windows", if that sounds like a "cool" interface style for your adventure game or whatever...it's like Confucius once uttered: Yes, the "virtual console" approach would be easier to turn into a multiplayer game across the network because you know when people are writing to the virtual console (assuming all writing occurs via procedure calls rather than direct stores into the memory buffer). Therefore, whenever someone calls the procedure to manipulate the buffer, you can write the changes across the network. Of course, there is the coherency problem (what if two players write to the same variable on two different machines simultaneously), but that's easy enough to handle by passing a "write token" around the network and only the machine holding the "write token" is allowed to write to the buffer. > > "A journey of a thousand miles begins with a single step" > [ Confucius ] And usually ends about the 10th step when someone realizes how much farther they have to go :-) > > So, you know, concentrate on taking that "first step"...all the rest that's involved is, well, just repeating that "first step" a few million times until the "thousand miles" is finally covered...the "first step" is always trickiest to take...every step tends to get easier after that one...so, pay attention to the "first step"...worry about the others later ;)... The real issue is not giving up when you realize that you've walked a 100 miles in the wrong direction. IOW, don't be afraid to throw away old code and start over, if doing so produces a better journey. Cheers, Randy Hyde
From: randyhyde on 28 May 2005 17:29 Frank Kotler wrote: > > I'm not going to urge you to learn Nasm - much less HLA. The > only way I can figure out to "push 0" in HLA is to zero a > register and push that. Same as MASM and many other assemblers, you use the "pushd" instruction, e.g., pushd( 0 ); cheers, Randy Hyde
From: Charles A. Crayne on 28 May 2005 19:15
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? -- Chuck |