From: "Keith M. Lucas" Newsgroups: comp.lang.c++,comp.os.msdos.djgpp,gnu.g++.help,rec.games.programmer,rec.games.design Subject: Re: C++ Real Time Design Issues Date: Wed, 23 Apr 1997 16:22:33 GMT Organization: Excession Message-ID: References: <5jig34$pu9$1 AT alpha DOT hcst DOT com> Lines: 71 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk In article <5jig34$pu9$1 AT alpha DOT hcst DOT com>, Bryan Murphy wrote: > >--------------------------------------------------------------------- > >WARNING, EXTREMELY LONG! :) > >I have a few questions about some Heirarchical design issues I faced >or will face in my current program, and I was wondering if anybody >would be willing to help me out/give me ideas or discuss some >concepts? Please try to respond via e-mail if you post a reply to >UseNet as I don't read the groups to thoroughly and might miss any >replies!! Any help is much appreciated! > >--------------------------------------------------------------------- OK -- I'll give you my experience on this -- we developed our own X11 GUI library ( since none of the others suited our purposes ). Like you we start with a base object but we have a none OO kernel that underlies it -- this is what gets X11 messages from X11 and turns them into our messages ( this bit would be re-written for Windows ). One of the things it does is run timers ( so objects can have a TICK event called, without using system resources ) and examine file descriptors ( so objects can respond to file events. ) -- the sockets arrive as FDs so basically, we have a TSpace in which hang a bundle of TInstance objects which have pointers to a TPolyMesh. So incoming packets from a socket kick an event on a TClient which modifies the data in the TSpace/TInstance. There is also a TCamera which knows where it is in the space and gets TICK events -- on each TICK it renders its current view of the window to a bitmap and then asks the TWindow to display the bitmap. Useful hint here, ripped off from Delphi. Make your base object have a list and able to insert itself into lists and so on. That way your TWindow object simply has a list of all the TWindows and TControls ( TButton etc ) that live inside it.. give the base object a render() method and all of a sudden drawing a window is easy and it saves you constantly using list objects and so on. ( Actually there is a chance that we'll be making the code for out stuff available in the near future.. it should port to Windows very easily ( the X11 code is hidden away ) ) >The SIMULATION object is where most of the program will take place. It >is based off of the APPLICATION object. It's only major difference is >that a U_UPDATE message is placed into the INPUT Queue every x milliseconds. >This U_UPDATE message is what allows it to be a real-time simulation, >instead of a simple event driven application. >So, now the problem is: How do I implement a Client/Server type approach >into this structure, along with 3D Graphics Support that is completely >separate from the GUI (this is fairly important to me, but if it needs to >be integrated into the GUI, I can do that). In our system the TCamera is the only one that knows anything about the graphics. It uses a support object ( a TView ) that works at the level of "a pointer to a bitmap and its size" and methods like "texture_polygon()" and "flat_polygon()" ----------------------------------------------+-------------------------------- "It's not a personality.. it's a bulldozer" | Current project: Computer sillywiz at excession dot demon dot co dot uk | wargaming's next generation... ----------------------------------------------+-------------------------------- IQ test in my email address. Humans can solve it to reply, spambots can't (yet) ----------------------------------------+-------------------------------------- For best results, view this with Linux. | Support death penalty for spammers ! ----------------------------------------+--------------------------------------