alephmodular-devel Mailing List for AlephModular (Page 2)
Status: Pre-Alpha
Brought to you by:
brefin
Menu
▾
▴
alephmodular-devel — AlephModular Developers Mailing List
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(61) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(193) |
Feb
(61) |
Mar
(55) |
Apr
(5) |
May
(3) |
Jun
(1) |
Jul
(3) |
Aug
(14) |
Sep
(19) |
Oct
(48) |
Nov
(6) |
Dec
(25) |
| 2004 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(6) |
May
(1) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(17) |
Jun
(20) |
Jul
(13) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Br'fin <br...@ma...> - 2005-06-13 15:42:31
|
On Jun 7, 2005, at 1:28 PM, Alexander Strange wrote: > On Jun 7, 2005, at 1:19 PM, Br'fin wrote: >> Note to ourselves. Now is probably a good time to serialize saved >> files since I didn't already do that. (My bad for thinking that >> transferring saved files tween Mac and anything else wouldn't be >> supported and now having it cause future problems transferring >> tween Macs) >> >> Given the lack of foresight, and with the note that existing M2 >> saved games were never supported, just M2 films. When I code new >> serialized saved games, do I... >> 1. ...avoid all support for existing 0.3 saved games >> 2. ...acknowledge and don't run existing 0.3 saved games >> 3. ...acknowledge and support older 0.3 saved games as well as >> the new ones? >> >> I admit the spread of AM is potentially low enough that we could >> get away with 1. > Is there something extremely convenient (like a version field) in > the file format? If there is, 3 would be the best way; otherwise, I > don't think it would be easy enough to justify not going with 1. There is a data_version field in the WAD headers. But right now that's advertising that the basic format of the saved game is that of a Marathon 2 version map. There doesn't seem to be a great spot for a minor version note. In the future, things get interesting though for now I'll just take route 1. No guarantees on not crashing AM when you try to open older saves. And as files go, there the worst kind for andling gracefully, since for the most part they are legitimate. It's only once you hit the dynamic data that things may get undefined. Heck... if the alignment and voodoo is right with no empty spots in the data structures, they may continue to work fine post serialization in a similar way that Terminals were never original serialized on reading in or writing out. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2005-06-13 04:38:03
|
On Jun 9, 2005, at 1:00 PM, Br'fin wrote: > The other aspect of unserialized items is Terminal structure. Now > the funny thing about Terminals is that they are read in from the > original map file. They should be unpacked for internal use to be > proper. (Being a mix of ints and chars, it managed to fit within > PowerPC alignment issues, so never went through the unserialization > process before.) > > Now, save files still have a complete map file in them (The current > level and all states). Should we save memory most of the time by > unpacking the terminals, then repacking them during the save. Or Do > we just use more memory by holding onto the original packed data > and handing that back to the save system when it is asked for? > I ended up going with serializing on reading and writing so as to not consume the memory during prime game time. I adapted some of the serializing from A1. Especially after some of the pitfalls I managed to fall into on my own. This shouldn't break existing save-games on macs. The next change, for serializing all of the stuff in the saved game file may (alignment issues can mean that structures on disk are aligned differently than in memory. This is what lead to the timing of A1 gaining serialization to begin with... 68k based memory structures saved to disk don't line up with PPC native versions of those same structures.) -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2005-06-09 17:00:28
|
I'm looking over serializing those items that need to be serialized. Most of these things are weapon and player state which are completely based off internal structures. Hence writing them out unserialized now and working with serialization later is is a problem. The other aspect of unserialized items is Terminal structure. Now the funny thing about Terminals is that they are read in from the original map file. They should be unpacked for internal use to be proper. (Being a mix of ints and chars, it managed to fit within PowerPC alignment issues, so never went through the unserialization process before.) Now, save files still have a complete map file in them (The current level and all states). Should we save memory most of the time by unpacking the terminals, then repacking them during the save. Or Do we just use more memory by holding onto the original packed data and handing that back to the save system when it is asked for? -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2005-06-07 23:42:52
|
I'm settled on most of the basic changes to settle the XCode project itself. I see some things specifically to target such as some variables that are potentially undefined that I should look into. As to MacIntel support, the obvious spots are things such as saved games, and potentially the order binary data is stored in the preferences plist (keyboard map, file aliases) Also on the order of MacIntel support, AM compiles, but fails during the linking step because libexpat is PPC only. I'm hazy on how to compile a MacIntel version of expat and include that library when dealing with building an arch i386 build of AM. Further out, Quickdraw under Carbon is depreciated under 10.4. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Timothy C. <da...@ma...> - 2005-06-07 18:53:59
|
On Jun 7, 2005, at 2:12 PM, Aaron Davies wrote: > Option 1 is fine with me--this isn't even alpha code yet. The only > stipulation is the obvious one, that AM should do *something* > intelligent if you try to open an obsolete save file--just so long > as it doesn't crash. The most intelligent thing to do is probably just say, "This isn't a save file I recognize," just as if you tried to open a JPG or other non-save-file with AM. Timothy Collett |
|
From: Aaron D. <ag...@co...> - 2005-06-07 18:21:31
|
On Jun 7, 2005, at 1:19 PM, Br'fin wrote:
> Note to ourselves. Now is probably a good time to serialize saved
> files since I didn't already do that. (My bad for thinking that
> transferring saved files tween Mac and anything else wouldn't be
> supported and now having it cause future problems transferring
> tween Macs)
>
> Given the lack of foresight, and with the note that existing M2
> saved games were never supported, just M2 films. When I code new
> serialized saved games, do I...
> 1. ...avoid all support for existing 0.3 saved games
> 2. ...acknowledge and don't run existing 0.3 saved games
> 3. ...acknowledge and support older 0.3 saved games as well as
> the new ones?
>
> I admit the spread of AM is potentially low enough that we could
> get away with 1.
>
>
Option 1 is fine with me--this isn't even alpha code yet. The only
stipulation is the obvious one, that AM should do *something*
intelligent if you try to open an obsolete save file--just so long as
it doesn't crash.
--
__ __
/ ) / )
/--/ __. .__ ______ / / __. , __o _ _
/ (_(_/|_/ (_(_) / (_ (__/_(_/|_\/ <__</_/_)_
|
|
From: Timothy C. <da...@ma...> - 2005-06-07 17:33:22
|
On Jun 7, 2005, at 1:19 PM, Br'fin wrote: > Note to ourselves. Now is probably a good time to serialize saved > files since I didn't already do that. (My bad for thinking that > transferring saved files tween Mac and anything else wouldn't be > supported and now having it cause future problems transferring > tween Macs) > > Given the lack of foresight, and with the note that existing M2 > saved games were never supported, just M2 films. When I code new > serialized saved games, do I... > 1. ...avoid all support for existing 0.3 saved games > 2. ...acknowledge and don't run existing 0.3 saved games > 3. ...acknowledge and support older 0.3 saved games as well as > the new ones? > > I admit the spread of AM is potentially low enough that we could > get away with 1. > I'd say go with option 1. Not only is the spread very low, but it's self-professedly an extremely basic alpha-level version. Anyone who expects any kind of serious forward compatibility from 0.3 isn't thinking too clearly. I'd say that until we have most of the fundamentals in place for AM, don't worry about breaking previous versions of AM. And it might be best not to worry about breaking compatibility with M2, either, until we get things settled down. At least, if it's a kind of compatibility that we can put back in later, after breaking it... Timothy Collett |
|
From: Alexander S. <ast...@it...> - 2005-06-07 17:28:42
|
On Jun 7, 2005, at 1:19 PM, Br'fin wrote: > Note to ourselves. Now is probably a good time to serialize saved > files since I didn't already do that. (My bad for thinking that > transferring saved files tween Mac and anything else wouldn't be > supported and now having it cause future problems transferring > tween Macs) > > Given the lack of foresight, and with the note that existing M2 > saved games were never supported, just M2 films. When I code new > serialized saved games, do I... > 1. ...avoid all support for existing 0.3 saved games > 2. ...acknowledge and don't run existing 0.3 saved games > 3. ...acknowledge and support older 0.3 saved games as well as > the new ones? > > I admit the spread of AM is potentially low enough that we could > get away with 1. > > -Jeremy Parsons > http://alephmodular.sourceforge.net/ Is there something extremely convenient (like a version field) in the file format? If there is, 3 would be the best way; otherwise, I don't think it would be easy enough to justify not going with 1. |
|
From: Br'fin <br...@ma...> - 2005-06-07 17:19:00
|
Note to ourselves. Now is probably a good time to serialize saved
files since I didn't already do that. (My bad for thinking that
transferring saved files tween Mac and anything else wouldn't be
supported and now having it cause future problems transferring tween
Macs)
Given the lack of foresight, and with the note that existing M2 saved
games were never supported, just M2 films. When I code new serialized
saved games, do I...
1. ...avoid all support for existing 0.3 saved games
2. ...acknowledge and don't run existing 0.3 saved games
3. ...acknowledge and support older 0.3 saved games as well as
the new ones?
I admit the spread of AM is potentially low enough that we could get
away with 1.
-Jeremy Parsons
http://alephmodular.sourceforge.net/
|
|
From: Br'fin <br...@ma...> - 2005-06-07 16:52:17
|
Working with AlephModular
Tag .pbjproj with XCODE-2_0
Open AlephModular.pbproj in XCcode 2.1
It prompts me to make a copy to be updated to an .xcodeproj.
I click 'Upgrade a copy'
It prompte me for where to save.
I select same name and directory. AlephModular.xcodeproj
Project file opens.
Project file still has:
the PB Compatible target
the XCode compatible target
no other new targets
(All sub files of project were copied over as well, notably the
project.pbxproj.in file I use for autoconf purposes in AM)
Notable changes:
Comments have been added to sections
All references are now followed by a comment specifying what is
being
referenced
All file references now have their expanded isa information
included in
their defining line (Translation: A file's base set of
information is
now all on one line)
CFlags specifiers are no longer a single quoted list, but an
array with one
quoted element per specified flag. This applies to
OTHER_CFLAGS
WARNING_CFLAGS
GCC_PREPROCESSOR_DEFINITIONS
OTHER_CPLUSPLUSFLAGS
(it does not apply to OTHER_REZFLAGS though)
Working in XCode:
Most elements that used to be in Info on the project file are now
specifally in the build target settings with the general
exception
of base target architecture.
Currently sticking with 'Current' May try 10.4 (universal)
if needed
Removing PB Compatible target
AM had this target so while the native XCode target was the
default,
additions of files could be added to the PB Compatible
target and
then merged into the PB-2_0 version of the project file.
With the changes to the file format, this is no longer
possible, so
we may as well remove it for simplicity. For A1 I
recommend moving
to an XCode native target and removing the PB
compatible one.
XCode now puts built files into a Configuration directory within
the build
directory. So you will need to move support files into the
new location,
for instance, maps and such at AM/A1 complain about if they
don't find.
This should be settable, I can't seem to locate it.
All of the version stuff delegated by configure.ac is either getting
outside the
bounds I can configure it in XCode (for instance, extra c-flags)
or wasn't
present in the project file for native targets (moved to
external file
Info-AlephModular.plist, specifically things like 0.4.0.CVS as an
application version.)
As such configuring the XCode project file for AM will be removed from
configure.ac. Which does make my life easier when adding files
to XCode.
AM is now compiling and running. However I want to normalize some
settings as
compared with a freshly created project and try and locate where the
option of a
universal build is even if I can't actually test the thing. :)
-Jeremy Parsons
http://alephmodular.sourceforge.net/
|
|
From: Br'fin <br...@ma...> - 2005-06-07 11:38:16
|
I finally finished downloading the XCode 2.1 img and am currently =20 installing it. So far the trickiest thing I may need to deal with for =20= AlephModular is the following from the readme: > The project file format is now much more readable and less prone to =20= > SCM conflicts. It also supports the new Build > Configurations feature. Because of the magnitude of the changes, =20 > the project file extension is changed in Xcode 2.1 to > =93.xcodeproj=94. Older versions of Xcode will not read .xcodeproj =20 > files, but Xcode 2.1 can convert older project files to .xcodeproj > format. Updates on the situation as I found out more. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2005-05-29 10:19:17
|
On May 28, 2005, at 10:49 PM, Woody Zenfell III wrote: > This comes off as a bit of a smug "dig" at A1; not sure whether > that was your intention. I'll leave being smug about it until AM actually is in some kind of advanced state and actually has the feature. Right now I feel it's more my usual tiredness with the lack of organization that often occurs in A1. Consider this putting a red flag on a future trouble spot. > In any event, I agree that AM should generally learn from A1's > experience - I guess that's its purpose, right? :) That's precisely it. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Woody Z. I. <woo...@ve...> - 2005-05-29 02:49:42
|
This comes off as a bit of a smug "dig" at A1; not sure whether that was your intention. In any event, I agree that AM should generally learn from A1's experience - I guess that's its purpose, right? :) Woody On Saturday, May 28, 2005, at 10:15 PM, Br'fin wrote: > I admit this is far off in the future if anywhere. > > But if there comes a time for adding expandability to AM in a fashion > like MML and LUA and such accomplish for A1. Remind me to do it in > just one fashion. For instance, piggyback it all on a scripting > system. And let there be specifc entry points for customizing for > scenario and textures and monster AI in a single set of things instead > of having them loose and distributed among a number of different files > types, formats, and even hidden, hard to get to locations. > > -Jeremy Parsons > http://alephmodular.sourceforge.net/ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Yahoo. > Introducing Yahoo! Search Developer Network - Create apps using Yahoo! > Search APIs Find out how you can build Yahoo! directly into your own > Applications - visit > http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 > _______________________________________________ > Alephmodular-devel mailing list > Ale...@li... > https://lists.sourceforge.net/lists/listinfo/alephmodular-devel > |
|
From: Br'fin <br...@ma...> - 2005-05-29 02:14:22
|
I admit this is far off in the future if anywhere. But if there comes a time for adding expandability to AM in a fashion like MML and LUA and such accomplish for A1. Remind me to do it in just one fashion. For instance, piggyback it all on a scripting system. And let there be specifc entry points for customizing for scenario and textures and monster AI in a single set of things instead of having them loose and distributed among a number of different files types, formats, and even hidden, hard to get to locations. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2005-05-19 06:14:20
|
On May 18, 2005, at 11:29 PM, Woody Zenfell III wrote: > On Wednesday, May 18, 2005, at 09:01 PM, Chris Pickel wrote: > > >> I'll of course put in my usual "make it a class!" line, since if >> there's a CActionFlags class, sticking a mutex in at a later date >> would be much easier. >> > > Yes, bringing to bear language features we have now that were not > as available to Bungie when they wrote this stuff seems like > generally good practice. It also seems in line with AM's > character. The speculative nature of the latter part of your > statement sets me on edge a little, but perhaps it's intended as an > example of how proper use of language features and abstractions > smooths development, rather than a suggestion that developers > attempt to predict the future. :) > > I thought in A1 I _had_ made ActionQueues objects, since there are > several different sets of them in A1 . . . but maybe I'm confusing > some things in my memory. It's been years. A1 I think did, but I've not looked into it since I hadn't really considered working on such on AM Yet. I'm not against it, just my focus wasn't there. >> Random side note - glancing through the code, there are plenty of >> #define's still around. Converting them to const's and inlined >> functions might be a good idea for the future. Of course, many are >> things which MML is used to define in A1, so their final >> implementation might not be constants. But this is random and not >> the subject of this email. >> > > Replacing #defines with safer language features also seems like > good practice. So does typedef'ing certain things, like > action_flags. And don't worry about trying to predict the "final > implementation" - it'll evolve and grow up the way it should, if > properly tended along the way. Make things the best way you can > figure out now, for what they need to be now (e.g. by doing exactly > the kinds of things you're talking about) - it'll then be that much > easier to see how the code really wants to be, and that much easier > to adapt it once you do know where it needs to go next. > > Woody In general, I do agree with doing typesafe things with language features and inline functions. I haven't done any specific attacks on excising them all. Though I've looked at a few specific ones and wondered... what the heck and I going to do about this? (Most specifically things like MAX() and NONE where they flex more in the context the number and values being used are expressed in) -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Woody Z. I. <woo...@ve...> - 2005-05-19 03:29:52
|
On Wednesday, May 18, 2005, at 09:01 PM, Chris Pickel wrote: > I'll of course put in my usual "make it a class!" line, since if > there's a CActionFlags class, sticking a mutex in at a later date > would be much easier. Yes, bringing to bear language features we have now that were not as available to Bungie when they wrote this stuff seems like generally good practice. It also seems in line with AM's character. The speculative nature of the latter part of your statement sets me on edge a little, but perhaps it's intended as an example of how proper use of language features and abstractions smooths development, rather than a suggestion that developers attempt to predict the future. :) I thought in A1 I _had_ made ActionQueues objects, since there are several different sets of them in A1 . . . but maybe I'm confusing some things in my memory. It's been years. > Random side note - glancing through the code, there are plenty of > #define's still around. Converting them to const's and inlined > functions might be a good idea for the future. Of course, many are > things which MML is used to define in A1, so their final > implementation might not be constants. But this is random and not the > subject of this email. Replacing #defines with safer language features also seems like good practice. So does typedef'ing certain things, like action_flags. And don't worry about trying to predict the "final implementation" - it'll evolve and grow up the way it should, if properly tended along the way. Make things the best way you can figure out now, for what they need to be now (e.g. by doing exactly the kinds of things you're talking about) - it'll then be that much easier to see how the code really wants to be, and that much easier to adapt it once you do know where it needs to go next. Woody |
|
From: Chris P. <sf...@ma...> - 2005-05-19 01:01:33
|
On May 18, 2005, at 8:36 AM, Woody Zenfell III wrote: > Also a couple notes - I'm pretty sure that in Mac OS 9-land, VBL stuff > (and other "interrupt" sort of routines, like network-packet-received) > run to completion before pretty much any other code can run (certainly > before "main loop" code can run). On the other hand, note that the > main code could be preempted at pretty much any time for interrupt > tasks. (IIRC.) After reading through the document, I think I have a pretty good impression of how it's supposed to work, and my impression is that we don't have to worry about the "run to completion" part of the threads. It seems that the only way for the input_controller thread to interact with other threads is through the action queues, and Marathon's behaviour is well-defined for what to do when varying amounts of data are in the queues; all we would get by running the interrupts to completion would be a "more likely" chance of getting flags on the first poll. The circular queue also makes sense to me now. Upon consideration, I would expect that the loss of cycles due to mutex locking/unlocking would probably be greater than the loss due to false negatives - pretty small, but every bit counts. I'll of course put in my usual "make it a class!" line, since if there's a CActionFlags class, sticking a mutex in at a later date would be much easier. Random side note - glancing through the code, there are plenty of #define's still around. Converting them to const's and inlined functions might be a good idea for the future. Of course, many are things which MML is used to define in A1, so their final implementation might not be constants. But this is random and not the subject of this email. - Chris Pickel |
|
From: Woody Z. I. <woo...@ve...> - 2005-05-18 12:37:08
|
You guys may or may not find any value in this document (and perhaps especially its accompanying diagram): http://source.bungie.org/_enginedevelopment/reference/networking- input.html Also a couple notes - I'm pretty sure that in Mac OS 9-land, VBL stuff (and other "interrupt" sort of routines, like network-packet-received) run to completion before pretty much any other code can run (certainly before "main loop" code can run). On the other hand, note that the main code could be preempted at pretty much any time for interrupt tasks. (IIRC.) As I recall, I was careful to simulate this behavior in the SDL port of the threading stuff when I did IP ring. Though I might have had to protect certain critical sections that didn't need protection before, since I couldn't guarantee that non-main threads would run their stuff to completion. I honestly don't recall at this point. IP star protocol was built from the ground up with the current context in mind, so it might use a somewhat different strategy for threading/locking. The circular buffer/circular queue is a standard way of decoupling producers and consumers, and if implemented properly should not require any locking (part of its appeal). That comparison you were worried about, if the buffer is implemented properly, should only ever return a "false negative" to the question "is there something to read?" - and that's no problem because the consumer will be back around to ask again soon. (There's a similar check for queue full that has a similar rationale behind it.) Try to reason it out if you want, or I'm sure you can find plenty of writeups out there describing it in more detail. Good luck, Woody On Wednesday, May 18, 2005, at 02:12 AM, Chris Pickel wrote: > On May 18, 2005, at 12:00 AM, Br'fin wrote: >> Main Thread (Handles Mac Events) - Also handles updating the world >> and rendering the screen. >> Input Thread (Runs as a VBL API thread) - Polls mouse location and >> keyboard state 30 times a second, updates input queues > > Hmm, I think I see how this is supposed to work. I read through what I > could find of thread use, and I find one thing somewhat curious: there > doesn't seem to be any concept of thread-safety in the code. mytm.h > defines two mutex routines, but they aren't used. It appears to me > that the assumption in the code is that only the input thread is > responsible for write_index and its contents, while only the main > thread is responsible for read_index and its contents. > > This might be a good assumption, but I'm not convinced that it's safe > to do; the input_controller function does a comparison between > read_index and write_index, and I was always taught you're not > supposed to do that without a mutex. |
|
From: Br'fin <br...@ma...> - 2005-05-18 06:42:16
|
On May 18, 2005, at 2:11 AM, Chris Pickel wrote: > On May 18, 2005, at 12:00 AM, Br'fin wrote: > >> Main Thread (Handles Mac Events) - Also handles updating the world >> and rendering the screen. >> Input Thread (Runs as a VBL API thread) - Polls mouse location and >> keyboard state 30 times a second, updates input queues >> > > Hmm, I think I see how this is supposed to work. I read through > what I could find of thread use, and I find one thing somewhat > curious: there doesn't seem to be any concept of thread-safety in > the code. mytm.h defines two mutex routines, but they aren't used. > It appears to me that the assumption in the code is that only the > input thread is responsible for write_index and its contents, while > only the main thread is responsible for read_index and its contents. > > This might be a good assumption, but I'm not convinced that it's > safe to do; the input_controller function does a comparison between > read_index and write_index, and I was always taught you're not > supposed to do that without a mutex. > > The other thing that I notice is that the thread routines are in > plain C that's not easily decipherable. Perhaps this should be > cleaned up and C++-ified? Most likely most of the thread code dates back to the Classic MacOS API. I've no idea if the VBL interrupts for threading even had the concept of a mutex. Having a thread class of some ilk may very well be appropriate, especially as the existing ones rely on a couple different mechanisms. >> The specific problem I ran into when doing mousing in AlephOne was >> that GetMouseLoc in OSX was not updated in the VBL thread. So at >> the very least I want one thread to handle Carbon Events while the >> thread that handles updating the world and rendering is dealt with >> separately so the Carbon Events can get processed in a timely >> fashion for capturing various Mouse Moved events. >> > > It's not? From the looks of it, input_controller() (the thread > function) calls parse_keymap(), which calls mouse_idle(), which > calls get_mouse_location(). Isn't that where the call should be? Or > are you picturing an interrupt-based event system rather than a > polling loop? > > - Chris Pickel With the current layout, the get_mouse_location isn't functioning right under OSX. You can try playing with it. But it didn't seem to be updated all the time in the way that the keyboard polling function was. Meanwhile the advised way of catching mouse movements under OSX is by catching the explicit Mouse Moved events via a Carbon Event Handler. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Chris P. <sf...@ma...> - 2005-05-18 06:12:34
|
On May 18, 2005, at 12:00 AM, Br'fin wrote: > Main Thread (Handles Mac Events) - Also handles updating the world and > rendering the screen. > Input Thread (Runs as a VBL API thread) - Polls mouse location and > keyboard state 30 times a second, updates input queues Hmm, I think I see how this is supposed to work. I read through what I could find of thread use, and I find one thing somewhat curious: there doesn't seem to be any concept of thread-safety in the code. mytm.h defines two mutex routines, but they aren't used. It appears to me that the assumption in the code is that only the input thread is responsible for write_index and its contents, while only the main thread is responsible for read_index and its contents. This might be a good assumption, but I'm not convinced that it's safe to do; the input_controller function does a comparison between read_index and write_index, and I was always taught you're not supposed to do that without a mutex. The other thing that I notice is that the thread routines are in plain C that's not easily decipherable. Perhaps this should be cleaned up and C++-ified? > The specific problem I ran into when doing mousing in AlephOne was > that GetMouseLoc in OSX was not updated in the VBL thread. So at the > very least I want one thread to handle Carbon Events while the thread > that handles updating the world and rendering is dealt with separately > so the Carbon Events can get processed in a timely fashion for > capturing various Mouse Moved events. It's not? From the looks of it, input_controller() (the thread function) calls parse_keymap(), which calls mouse_idle(), which calls get_mouse_location(). Isn't that where the call should be? Or are you picturing an interrupt-based event system rather than a polling loop? - Chris Pickel |
|
From: Br'fin <br...@ma...> - 2005-05-18 04:00:25
|
On May 17, 2005, at 9:54 PM, Chris Pickel wrote: > Oops, thought Reply-to was set to the list. > > On May 17, 2005, at 6:02 PM, Br'fin wrote: > >> In the case of AM, this is, I believe, in shell.cpp. However, as a >> further snarl. I don't think going with a straight up abstraction, >> like I did with some other areas of the code, necessarily gets >> what we need out of it. The process of updating the state of the >> world and rendering it happens in this event loop. So I want to >> add a thread in here. But I don't know enough about threads to get >> my brain too well around them either. >> > > Just to clarify, is the thread you'd like to add would be > responsible for the rendering? i.e. an update to game state would > trigger an update to audio/visual state, and the audio/visual state > would update at the same time as the next game state update. Current thread situation in AM: Main Thread (Handles Mac Events) - Also handles updating the world and rendering the screen. Input Thread (Runs as a VBL API thread) - Polls mouse location and keyboard state 30 times a second, updates input queues Network thread (I don't know details) - Performs network traffic, kind of unimplemented/unused in AM The specific problem I ran into when doing mousing in AlephOne was that GetMouseLoc in OSX was not updated in the VBL thread. So at the very least I want one thread to handle Carbon Events while the thread that handles updating the world and rendering is dealt with separately so the Carbon Events can get processed in a timely fashion for capturing various Mouse Moved events. > I've had some limited dealings with threads before, in the form of > boost::thread (this was on Linux), although I used my own mutexes > since I didn't quite understand their documentation. However, I'm > not sure exactly what the best way to split two event loops apart > would be - after all, I believe that you would need to create a > readable state for the display loop that would be entirely separate > from the writable state of the game loop. For the time being, Updating the world state and rendering the world state need to be kept in the same thread. They're reading off the same global world state. Probably a bad idea to modify this during rendering right now. Currently the update and render world steps happen during a call to idle_game_state() near the end of the main event loop. (I'd love to split this out into a couple levels at a future date, setup the concept of world state in terms of where everything is, and a second animation state that is driven by the world state, but can do bunches of things on its own. And would only be needed by a client and not a server.) > I also find it ironic that the first three people on a thread about > "de-Mac-ifying" have mac.com email addresses :) DeMacifying was the term I decided to use to explain what I was doing with AM. It's the process of taking the Mac-OS 9 specific calls and pushing them out of the main game code via abstractions which hopefully could be implemented on another platform. As opposed to some extensions in A1 where code is duplicated into MacOS and SDL versions of the same file. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Timothy C. <da...@ma...> - 2005-05-18 03:01:53
|
Agh...I forgot about that, too...Br'fin, can you fix this list's reply-to address, by chance? On May 17, 2005, at 6:02 PM, Br'fin wrote: > I was going through and removing direct calls to Mac-specific > things. At the heart of the program is an event loop. Figure out > what the user is doing to the computer, then have the computer > update the state of the game-world. And finally display the result > on the screen with sound. > > In the case of AM, this is, I believe, in shell.cpp. However, as a > further snarl. I don't think going with a straight up abstraction, > like I did with some other areas of the code, necessarily gets what > we need out of it. The process of updating the state of the world > and rendering it happens in this event loop. So I want to add a > thread in here. But I don't know enough about threads to get my > brain too well around them either. > Well, I know something about threads in theory...is the problem you're having with your brain not wrapping more in concept, or code? 'Cause I'm sure I can help with the former, while the latter might be more difficult. I've been looking a bit at the code so far, and I've been able to understand pretty much all of it...haven't really gotten into the main event loop part yet; I'm just working my way through marathon2.cpp and shell.cpp and seeing what I can see. Timothy Collett -- "We are the Rangers. We walk in the dark places others fear to enter. We stand on the bridge, and none may pass. We live for the One. We die for the One!" |
|
From: Chris P. <sf...@ma...> - 2005-05-18 01:54:21
|
Oops, thought Reply-to was set to the list. On May 17, 2005, at 6:02 PM, Br'fin wrote: > In the case of AM, this is, I believe, in shell.cpp. However, as a > further snarl. I don't think going with a straight up abstraction, > like I did with some other areas of the code, necessarily gets what we > need out of it. The process of updating the state of the world and > rendering it happens in this event loop. So I want to add a thread in > here. But I don't know enough about threads to get my brain too well > around them either. Just to clarify, is the thread you'd like to add would be responsible for the rendering? i.e. an update to game state would trigger an update to audio/visual state, and the audio/visual state would update at the same time as the next game state update. I've had some limited dealings with threads before, in the form of boost::thread (this was on Linux), although I used my own mutexes since I didn't quite understand their documentation. However, I'm not sure exactly what the best way to split two event loops apart would be - after all, I believe that you would need to create a readable state for the display loop that would be entirely separate from the writable state of the game loop. For reference, a couple relevant boost classes are: http://www.boost.org/doc/html/thread.html http://www.boost.org/doc/html/barrier.html ...and the Mutex explanation is here: http://www.boost.org/doc/html/threads/concepts.html Using Boost.Threads right out of the bag is an option; so is taking a peek at the source code and reimplementing it for AM. Using boost directly is probably a better option, though, as the boost libraries are likely to get adopted fairly directly into the C++/0x standard, and that would mean that we would have a pretty standard base of support for threads. I also find it ironic that the first three people on a thread about "de-Mac-ifying" have mac.com email addresses :) - Chris Pickel |
|
From: Br'fin <br...@ma...> - 2005-05-17 22:02:01
|
On May 17, 2005, at 4:56 PM, Timothy Collett wrote: > So, having gotten myself into this with a (perhaps ill-advised) > bold declaration of support and checked AM out from CVS again... > > Where should I start? > > Which files should I be looking in for this, and can you give me a > quick rundown of what (if anything) you *have* managed to decipher, > so I don't have to reinvent the wheel? > > Thanks. > > Timothy Collett I was going through and removing direct calls to Mac-specific things. At the heart of the program is an event loop. Figure out what the user is doing to the computer, then have the computer update the state of the game-world. And finally display the result on the screen with sound. In the case of AM, this is, I believe, in shell.cpp. However, as a further snarl. I don't think going with a straight up abstraction, like I did with some other areas of the code, necessarily gets what we need out of it. The process of updating the state of the world and rendering it happens in this event loop. So I want to add a thread in here. But I don't know enough about threads to get my brain too well around them either. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Timothy C. <da...@ma...> - 2005-05-17 20:57:00
|
So, having gotten myself into this with a (perhaps ill-advised) bold declaration of support and checked AM out from CVS again... Where should I start? Which files should I be looking in for this, and can you give me a quick rundown of what (if anything) you *have* managed to decipher, so I don't have to reinvent the wheel? Thanks. Timothy Collett -- "Far better it is to dare mighty things, to win glorious triumphs, even though checkered by failure, than to take rank with those poor spirits who neither enjoy much or suffer much, because they live in the gray twilight that knows not victory nor defeat." -T.R. |
