alephmodular-devel Mailing List for AlephModular
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: Alexander S. <ast...@it...> - 2008-04-20 00:54:59
|
On Apr 19, 2008, at 8:07 PM, Timothy Collett wrote: > Can it be? Is this group actually active, after, what, 5 years of > silence? :-D > > So, Alexander, are these changes a signal of changing times for > AlephModular? > > Timothy Collett I dunno, I was just hoping it would build as Universal - I need to see the original main game loop so I can compare it with A1's and see if we can get one that doesn't use 100% CPU all the time. It compiles successfully, but gives me a silly error dialog (Sorry, AlephModular requires a 68040 processor or later!), so I've left it on PPC only. I don't know if all the endian porting was finished, so maybe we just have to fix the call to Gestalt(). By the way, Xcode doesn't care much about backwards compatibility - some of the compiler flags went away when I opened it. They weren't important anyway, but you can see them by searching for "PBXNativeTarget" in: http://alephmodular.cvs.sourceforge.net/alephmodular/alephModular/build/macosx/AlephModular.xcodeproj/project.pbxproj?revision=1.4&view=markup I think the important bits are there, but if someone wants to compile/ run it on 10.2 or earlier and it doesn't work, maybe I can restore it. Also, CVS is awful. How did we use it? It's almost as bad as automake - I should see if I can get rid of some of the files it's got stuck all over the source tree. |
|
From: Timothy C. <da...@ma...> - 2008-04-20 00:08:17
|
Can it be? Is this group actually active, after, what, 5 years of silence? :-D So, Alexander, are these changes a signal of changing times for AlephModular? Timothy Collett -- The only thing you can't trade for your heart's desire is your heart. ~ Miles Naismith Vorkosigan |
|
From: Br'fin <br...@ma...> - 2005-10-21 17:00:31
|
This was originally posted to the AlephOne mailing list. But I want to note it and consider it here in case I ever manage to do something more with AM. I just had a relevant thought. It doesn't exactly apply to the current problem, but seems useful to contemplate. After all the problems of default data, per-level physics data, starting MML, per level MML, Lua and all. I took a moment to think of how I might want to approach this for AM if I ever get around to it. What if the state of the game setup by MML/physics was stack based? You have a cluster of values that makes up the current settings, and when entering a new level you Push the state. The new state is an exact copy of the previous state and until a value is explicitly changed, you look it up in the previous stack frame. When the level is over, we Pop the physics/MML state back to where it was before. Such a repository might also be much more handy for saving/loading in a saved game wad. The only draw back is existing Minf levels that somehow rely on custom physics from the previous level bleeding through... though I would think that was just poor scenario design. I have no clue when such a thing would be implemented in AM. API-wise it might look something like AM's preference mechanism. (That system is modeled after preference API in Java and MacOS X, you ask for an object representing the appropriate preference domain, and then have a hash of values to keys that's strongly reminiscent of a MacOS X CF Dictionary.) Alternative conception of implementation: You have an API to write to every value that can be set/changed. A pushed stack frame is empty, except for it's list of dirty values (When you Push, the saved frame has a list of all dirty values, and the current frame has a clear list of such). But each time you change a previously unchanged value, you mark that value as dirty and note the original value in the dictionary for the previous stack frame. The previous stack frame becomes a list of diffs to restore itself. This way is messier/more error prone, but could allow for faster/less abstracted data reads. Though it might be slower when setting/loading data. It might be easier to streamline the 'lookup previous data if unchanged' methods of the first implementation. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2005-07-13 05:36:08
|
I managed to implement text and bitmap display in CoreGraphics after a little bit of work. Text caches ATSU style information for current font, style, and size, thanks to a CFontSpecRepository class I had concepted to help SDL and OpenGL but which went unused during Carbon code. Bitmaps of 16 or 32 bits in depth are wrapped in a CGImageRef and CGContextDrawImage is used to draw them into the back buffer. For the indexed color bitmaps that are handled all over the HUD, I was able to provide a serial CGDataProvider to return the 16bit/32bit pixel colors for the indexed colors. I suppose bitmaps could be directly blitted by ourselves and a bit more work, but it's unclear if that's the best option, with some notes around that wrapping bitmaps in CGImageRefs and using CGContextDrawImage may result in speed improvements over raw blitting due to optimized paths the OS may be able to setup in the transition from main memory to VRAM. At any rate, AlephModular in CoreGraphics (AM-CG) on my machine runs full screen, and approximately the same FPS as the Quickdraw based version. AM-CG is also really raw whenever dialog boxes are used. They show up and overwrite the main image, and in addition, they may be missing functionality. For instance, pop-up menus are invisible due to the window shielding levels. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2005-07-10 12:39:09
|
On Jul 10, 2005, at 12:18 AM, Alexander Strange wrote: > > On Jul 9, 2005, at 11:58 PM, Br'fin wrote: > > >> Added in basic CDContext_CoreGraphics. So the map display now >> works Still need to add in text and bitmap images. >> >> Text... looks to be a pain. Looks like I need to integrate in some >> ATSUI support and probably a quick hash container to cache the >> relevant ATSUI style info. In other words, it didn't seem like >> there was a quick way to just draw text to a Quartz context. >> > > There is a quick way, but it doesn't support style runs. > > http://developer.apple.com/documentation/GraphicsImaging/Conceptual/ > drawingwithquartz2d/dq_text/chapter_18_section_4.html > Never mind not supporting style runs, it doesn't even look like it supports styles very well to begin with. And then being limited to MacRoman text music. Well... we may be manually handling style runs, but we still need to cue up the styles. :) -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Alexander S. <ast...@it...> - 2005-07-10 04:19:10
|
On Jul 9, 2005, at 11:58 PM, Br'fin wrote: > Added in basic CDContext_CoreGraphics. So the map display now works > Still need to add in text and bitmap images. > > Text... looks to be a pain. Looks like I need to integrate in some > ATSUI support and probably a quick hash container to cache the > relevant ATSUI style info. In other words, it didn't seem like > there was a quick way to just draw text to a Quartz context. There is a quick way, but it doesn't support style runs. http://developer.apple.com/documentation/GraphicsImaging/Conceptual/ drawingwithquartz2d/dq_text/chapter_18_section_4.html > Copying images into the context I expect to be a pain one way or > another. > > And oddly enough I still can't do 256 color support. In this case I > can now push the screen to 256 colors, and have a 256 color back > buffer. But Quartz doesn't support a indexed color bitmap context. > Go figure. > > -Jeremy Parsons > http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2005-07-10 03:57:23
|
Added in basic CDContext_CoreGraphics. So the map display now works Still need to add in text and bitmap images. Text... looks to be a pain. Looks like I need to integrate in some ATSUI support and probably a quick hash container to cache the relevant ATSUI style info. In other words, it didn't seem like there was a quick way to just draw text to a Quartz context. Copying images into the context I expect to be a pain one way or another. And oddly enough I still can't do 256 color support. In this case I can now push the screen to 256 colors, and have a 256 color back buffer. But Quartz doesn't support a indexed color bitmap context. Go figure. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Aaron D. <ag...@co...> - 2005-07-08 19:11:45
|
On Jul 7, 2005, at 8:21 PM, Br'fin wrote:
> On Jul 7, 2005, at 7:17 PM, Timothy Collett wrote:
>
>
>> As far as assuming that someone who will be running AM has a
>> certain version of the OS, I'd say assume they have at least what
>> you have. At least for now. After all, the majority of the
>> people interested in AM are going to be developers for the moment
>> (and I'd venture to say that the majority of running time it's
>> going to get will be on your computer anyway).
>>
>> Thus, whatever makes it simplest and most elegant to code seems
>> like the best solution to me. Backwards compatibility can always
>> be added in later, especially since we're trying to abstract the
>> core away from the OS interfaces as much as possible anyway.
>>
>
> I'm using A1's development group as a basis for target OS versions
> at the moment. Where it is actually unclear as to which developers
> are using which particular OS version and the nightlies themselves
> are still built on a 10.2 machine because that's what Aaron has
> access to.
>
I have access to 10.4 (in fact, it's my main machine), but it's my
laptop. The nightlies are built on my old beige G3/300, for which
Jaguar is the last supported OS, because it's the "stable" box that
is always on and always connected--I can't make the same guarantees
about my laptop. If you need occassional, ad hoc compiles on 10.4, I
can do that.
BTW, I just finished my Master's degree in Computer Science, and am
beginning a job search. If and when I get a good job, I plan to
upgrade my server to a Mini, which will also be the new compile box
for the nightlies.
--
__ __
/ ) / )
/--/ __. .__ ______ / / __. , __o _ _
/ (_(_/|_/ (_(_) / (_ (__/_(_/|_\/ <__</_/_)_
|
|
From: Br'fin <br...@ma...> - 2005-07-08 04:08:50
|
On Jul 7, 2005, at 10:54 PM, Woody Zenfell III wrote: > I think that James Willson and I are on 10.2, Myrd on 10.3, and > Gregory Smith on 10.4, Mac OS wise. For what it's worth. > > Woody And I'm out on 10.4 myself. And APIs are very interesting. I can't readily support 10.1 because Apple didn't sort out weak linking the libraries until 10.2. Under 10.4, a lot of the Quickdraw APIs are all depreciated. Which I read as 'they'll probably work, but not necessarily be optimized for Mac-intel.' And looking at the APIs around what I want to do with CoreGraphics, things have been improving/changing steadily. For instance, in a related area, it appears that it's only with QuickTime 7 that you have Quicktime APIs that speak to Quartz instead of speaking to Quickdraw. Silly little growing pains, sigh. Making compatibility with things such a pain. :) -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Alexander S. <ast...@it...> - 2005-07-08 03:01:55
|
On Jul 7, 2005, at 10:54 PM, Woody Zenfell III wrote: > I think that James Willson and I are on 10.2, Myrd on 10.3, and > Gregory Smith on 10.4, Mac OS wise. For what it's worth. > > Woody > I have access to 10.4 and 10.3. (Also, 8.6) |
|
From: Woody Z. I. <woo...@ve...> - 2005-07-08 02:54:29
|
I think that James Willson and I are on 10.2, Myrd on 10.3, and Gregory Smith on 10.4, Mac OS wise. For what it's worth. Woody On Thursday, July 7, 2005, at 08:21 PM, Br'fin wrote: > > On Jul 7, 2005, at 7:17 PM, Timothy Collett wrote: > >> As far as assuming that someone who will be running AM has a certain >> version of the OS, I'd say assume they have at least what you have. >> At least for now. After all, the majority of the people interested >> in AM are going to be developers for the moment (and I'd venture to >> say that the majority of running time it's going to get will be on >> your computer anyway). >> >> Thus, whatever makes it simplest and most elegant to code seems like >> the best solution to me. Backwards compatibility can always be added >> in later, especially since we're trying to abstract the core away >> from the OS interfaces as much as possible anyway. >> >> Timothy Collett >> Anaris Family > > I'm using A1's development group as a basis for target OS versions at > the moment. Where it is actually unclear as to which developers are > using which particular OS version and the nightlies themselves are > still built on a 10.2 machine because that's what Aaron has access to. > > -Jeremy Parsons > http://alephmodular.sourceforge.net/ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in > dual > core and dual graphics technology at this free one hour event hosted > by HP,AMD, and NVIDIA. To register visit > http://www.hp.com/go/dualwebinar > _______________________________________________ > Alephmodular-devel mailing list > Ale...@li... > https://lists.sourceforge.net/lists/listinfo/alephmodular-devel > |
|
From: Br'fin <br...@ma...> - 2005-07-08 00:20:25
|
On Jul 7, 2005, at 7:17 PM, Timothy Collett wrote: > As far as assuming that someone who will be running AM has a > certain version of the OS, I'd say assume they have at least what > you have. At least for now. After all, the majority of the people > interested in AM are going to be developers for the moment (and I'd > venture to say that the majority of running time it's going to get > will be on your computer anyway). > > Thus, whatever makes it simplest and most elegant to code seems > like the best solution to me. Backwards compatibility can always > be added in later, especially since we're trying to abstract the > core away from the OS interfaces as much as possible anyway. > > Timothy Collett > Anaris Family I'm using A1's development group as a basis for target OS versions at the moment. Where it is actually unclear as to which developers are using which particular OS version and the nightlies themselves are still built on a 10.2 machine because that's what Aaron has access to. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2005-07-08 00:18:13
|
On Jul 7, 2005, at 7:47 PM, Alexei Svitkine wrote: >> especially since we're trying to abstract the core away from the >> OS interfaces as much as possible anyway. >> > > Wouldn't it better to just draw to an in-memory buffer for the > whole screen and then use the minimal OS calls to transfer that as > a whole bitmap (or parts that changed since last frame) to the > screen? It seems integrating it closely with the OS isn't a very > modular thing to do. ;) > > -Myrd I admit that I have a lot of respect for whoever did the corresponding SDL calls in A1. They may have cribbed from SDL drawing methodology, but the full set of code for rasterizing lines and polygons and such is setup in the A1 code base. I have a lot of respect for whoever put them there, and don't begrudge them doing it either. That said, these drawing operations are already split out from the M2 specific code. I'm also kind of curious what some things like the map and terminals might look like with system provided anti-aliasing :) On the flip side, the OS provided calls for transferring the whole bitmap to the screen are extremely minimal indeed. (There seems to be absolutely nothing that is directly comparable to classic copybits for instance.) -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Alexei S. <isv...@sy...> - 2005-07-07 23:51:21
|
> especially since we're trying to abstract the core away from the OS > interfaces as much as possible anyway. Wouldn't it better to just draw to an in-memory buffer for the whole screen and then use the minimal OS calls to transfer that as a whole bitmap (or parts that changed since last frame) to the screen? It seems integrating it closely with the OS isn't a very modular thing to do. ;) -Myrd |
|
From: Timothy C. <da...@ma...> - 2005-07-07 23:17:34
|
As far as assuming that someone who will be running AM has a certain version of the OS, I'd say assume they have at least what you have. At least for now. After all, the majority of the people interested in AM are going to be developers for the moment (and I'd venture to say that the majority of running time it's going to get will be on your computer anyway). Thus, whatever makes it simplest and most elegant to code seems like the best solution to me. Backwards compatibility can always be added in later, especially since we're trying to abstract the core away from the OS interfaces as much as possible anyway. Timothy Collett Anaris Family -- "The only thing you can't trade for your heart's desire is your heart." ~ Miles Naismith Vorkosigan |
|
From: Br'fin <br...@ma...> - 2005-07-07 22:43:20
|
I got the itch to try recoding AM to use CoreGraphics instead of QuickDraw. Mostly to find that CoreGraphics is a pain in the neck, at least when it comes to CGDirectDisplay. And on top of that, it looks like most of the functions that will help add Quartz support so I can do the HUD and Map are things that were added since 10.2. So it's either code to the 10.2 methods and cross fingers that what I compile actually runs on such machines to begin with, or I code to the 10.4 methods. Which should be stable. Some specifics: CDContext_CoreGraphics is a no-op. In similar fashion, some other platform specific modules that relied upon CBuffer_Carbon, like CMovie, aren't enabled in the devel-cg branch. This means no title screen, no chapter screen, no hud, no map, no terminals. CDisplay_CoreGraphics is functional, grabs a screen, and throws it into 640x480 at whatever color mode you had picked out. It then works with a CBuffer_CoreGraphics, copying the bitmap of the buffer to the screen whenever flush_working_buffer() is called. It also tries to float all application dialogs, such as preferences, asserts, and open/ save dialogs over the shield window. It mostly succeeds. However, there's ugly non-drawn space around the dialogs, and pop-up menus work, however I can't promote their window level yet. So they can't be seen. CBuffer_CoreGraphics is half implemented. It operates with a CPictureBitmap as its pixel array. However, it needs to be able to map it's bitmap within a CGBitmapContext and then spawn a DrawingContext that does all the drawing operations on the bitmap via Quartz calls. So what is the end result? Something no where near close to release, but it does let you kill Pfhor full screen, if you don't mind a screen of 640x480. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2005-06-24 04:03:35
|
On Jun 23, 2005, at 3:39 PM, Timothy Collett wrote: > On Jun 22, 2005, at 12:13 PM, Br'fin wrote: >> But in the process I've been hacking apart the functions that used >> to serve as a way for the editor to load a map into the in- >> application viewer. These functions were already corrupted by the >> hosting of serialization information. >> >> From what I can determine, the original editor sat as generally >> separate code and had it's own internal version of process_map_wad >> (). Where that function in game_wad.cpp handles loading a map from >> file to memory. The editor's version would already be working with >> an in memory copy. > > Hmm...I have no idea of the nature of these hooks, so... > > Would it be possible to ditch them now, and rebuild them in a more > elegant fashion later, once things stabilize a bit? Or is the form > they're in the only form they could take? > > If they're becoming a hindrance to what AM is trying to be, then it > might be best to get rid of them. > > I could probably provide more coherent rambling if you could, > perhaps explain something of what form these hooks take? > > Timothy Collett I will first comment that the code I've been adding in this section is hardly better or more elegant. In other words, some of the way I've been managing things I'm unhappy about. It's better perhaps, but isn't necessarily clean or elegant. Also, I only just connected the dots to see how load_points, load_sides, load_polygons and complete_loading_level connected the dots with the unreleased editor code. In the current code all map loading is processed through process_map_wad. Which basically extracts data from tagged elements of the wad file, and then feeds them to other load functions most of the time. Extract map points from the wad, then feed that data to load_points. load_points historically has two arguments, a pointer to an array of points, and a count of points. During serialization, not noticing that most of these load functions are exported to be called from editor code not included, this became somewhat corrupted. It gets those two arguments, then casts them back to a uint8* so that they can be deserialized. It's not pretty, but works for loading the map. But it means load_points doesn't do what it originally promised it would do. Most of these elements might be pretty straightforward in shape. But there are some complex spots. For instance, the requests to scan and add platform data to platform polygons. And especially recalculating all the redundant map data. Also, since there doesn't seem to be an A1 or AM or even M2 specific map editor that works under a current operating system, it seems out of line to further cut off potential ties to an editor. I agree that in the future a better way of splitting things out may very well be in order. But this seems to be an area of overlap between game_wad.cpp and map.h/.cpp that we are better served by repairing in the current code base rather than excising. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Timothy C. <da...@ma...> - 2005-06-23 19:39:47
|
On Jun 22, 2005, at 12:13 PM, Br'fin wrote: > Recently I've been reworking the mechanisms that game_wad.cpp uses > to load/save files. It has definitely needed work to improve > serialization of saved data . > > But in the process I've been hacking apart the functions that used > to serve as a way for the editor to load a map into the in- > application viewer. These functions were already corrupted by the > hosting of serialization information. > > From what I can determine, the original editor sat as generally > separate code and had it's own internal version of process_map_wad > (). Where that function in game_wad.cpp handles loading a map from > file to memory. The editor's version would already be working with > an in memory copy. > > This leads me to wonder if I should back out a number of my recent > (uncommitted) changes. Rework process_map_wad to translate things > into temporary memory and call things like load_point and > load_sides with their original arguments, already translated. > > I'm strongly inclined to do this as removing the editor functions > gets hairier later since aspects here in game_wad are some of the > only ones that guide and can manage things like recalculating > redundant map information. Hmm...I have no idea of the nature of these hooks, so... Would it be possible to ditch them now, and rebuild them in a more elegant fashion later, once things stabilize a bit? Or is the form they're in the only form they could take? If they're becoming a hindrance to what AM is trying to be, then it might be best to get rid of them. I could probably provide more coherent rambling if you could, perhaps explain something of what form these hooks take? Timothy Collett |
|
From: Br'fin <br...@ma...> - 2005-06-22 16:13:34
|
Recently I've been reworking the mechanisms that game_wad.cpp uses to load/save files. It has definitely needed work to improve serialization of saved data . But in the process I've been hacking apart the functions that used to serve as a way for the editor to load a map into the in-application viewer. These functions were already corrupted by the hosting of serialization information. From what I can determine, the original editor sat as generally separate code and had it's own internal version of process_map_wad(). Where that function in game_wad.cpp handles loading a map from file to memory. The editor's version would already be working with an in memory copy. This leads me to wonder if I should back out a number of my recent (uncommitted) changes. Rework process_map_wad to translate things into temporary memory and call things like load_point and load_sides with their original arguments, already translated. I'm strongly inclined to do this as removing the editor functions gets hairier later since aspects here in game_wad are some of the only ones that guide and can manage things like recalculating redundant map information. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2005-06-16 17:52:25
|
On Jun 16, 2005, at 1:17 PM, Jeremy Parsons wrote: > Update of /cvsroot/alephmodular/alephModular/marathon2 > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6535 > > Modified Files: > Tag: devel-loader > weapons.cpp computer_interface.cpp game_wad.cpp > Log Message: > Reworked load/save game paths to use tag_loader_array > Fixed CLoader's CListLoader to find array to load via sub-classed > accessor as opposed to specified at construction (When many arrays > hadn't been referenced at all yet) > With this set of changes, the devel-loader branch now has working serialization for all aspects of the saved game. Attempting to load a saved game from any previous compile results in an assert in the debug code and undefined behavior otherwise. Aside from general cleanup (Such as removing the old tag to global array and size table and code) I'm currently musing on some other aspects. - CListLoader's default _load_count() method should throw a CLoader::failure for the case it currently asserts on in the future this might even lead to meaningful error displays. - Many aspects of map loading are pretty much the same for a map as for a saved game. Appropriate loaders can and should be used there. - Right now the tag-to-loader roll is handled by an array. Should there be code to actually manage this and perform tag lookups? (for instance, the map could might then have loader_for_tag (ENDPOINT_TAG).load_data(data, length) whereas in the nearer future it might just have cl_endpoint_loader.load_data(data_length) instead.) - Certain loader classes could be further developed to detect the case of CLoader::failure due to bad count * unit_size vs length issues and try to fallback to a 'raw' reading method. This option should probably have ifdefs to only be allowed on PPC macs and if the structure still has a particular size. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2005-06-15 19:16:30
|
Loren added WADFILE_HAS_INFINITY_STUFF to the wad format elements of A1. But aside from recognizing that wad version as legitimate, I don't see any other changes for that version of the file. Was there anything else of any note at all? I ask mainly because I'm tweaking AM Wad files to support per-tag versioning. And for me to increment my overall wad file version I need to at least double check and perhaps include some of the Infinity wad stuff before making my version the one after it. On a side note, while looking for general information on serializing I came upon this article with some notes on the tech of Halo2 http://www.gamesfromwithin.com/articles/0412/000059.html Apparently Bungie is still using a tagged format and C. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2005-06-15 06:50:45
|
For the curious wondering what I'm checking in. I've created a new branch in cvs. 'devel-loader' This way I can try and develop the loader in smaller steps while checking the code into CVS for others to comment upon. Once this is done, settled, and clear, I'll merge it back onto the main trunk. -Jeremy Parsons http://alephmodular.sourceforge.net/ |
|
From: Br'fin <br...@ma...> - 2005-06-14 07:29:46
|
On Jun 13, 2005, at 9:09 PM, Br'fin wrote:
> MyFoo.h
> -------
> #include "CLoader.h" // CSerializer?
>
> // CLoader::Result some variable size data run with a count
> class MyFooLoader : public CLoader
> {
> void load_raw_data(char* raw_data, size_t length);
> CLoader::Result get_save_data();
> }
Refinements on a concept
void CLoader::LoadFromStream(AIStream&, bool versioned= TRUE);
CLoader::Result GetSaveData();
The Load routine doesn't really need data* and size, though I suppose
if we wanted to keep a firm separation of outer data and inner
awareness of AIStream/AOStream usage, then it might be better to use
data+size as external arguments, and the interal _LoadFromStream uses
the streams.
Tweak the wad version to say 'supports tag versions' (Likely check A1
for Minf wad version and go with higher then that)
then when all data is written out, it has an int16 at the beginning
of the tag data that encapsulates version info for that tag.
We then have the version flag on LoadFromStream merely to indicate
the older map files where this version information on the tags is not
present. Alternatively, we add more than one byte to the fore of tag
info, with the other new bytes being a unique marker that should only
be likely and present if the version bytes are also set.
Taken from someone's slashdot post: (http://hardware.slashdot.org/
comments.pl?
sid=139404&threshold=0&commentsort=0&tid=198&mode=thread&pid=11676766#11
677336)
> ver = deserialize<int>(stream);
> if (ver==2)
> {
> . // standard deserialization code
> }
> else if (ver==1)
> {
> . // Code that reads an old stream and builds a new object
> . // in a backwards-compatible way.
> }
Sigh, ramblings and incoherencies from way too late at night.
-Jeremy Parsons
http://alephmodular.sourceforge.net/
|
|
From: Jeremy P. <jer...@ve...> - 2005-06-14 01:26:51
|
I really need to think these things through all the way.
This would also be a good time for defining how and when
load_raw_data fails. Does it return something. Does it throw a
CLoader::LoadFailed exception? (This is fine by me. And considering
that one of the ways of failing is to go out of bounds with an
AIStream, it might make sense to try and catch things like this and
translate them to CLoader exceptions).
Nicer still, translating them to a CLoader exception could be handed
by the primary base code, and the sub classes all override and define
the private implementations for their given area of expertise.
On Jun 13, 2005, at 9:09 PM, Br'fin wrote:
> Ok, I've been working on adding more AI/OStreams friends and the
> like to more objects. As well as tweaking the code that iterates
> over the various save game tags and throws the various data out
> into a file.
>
> Specifically, this array:
>
>> struct save_game_data save_data[]=
>> {
>> { ENDPOINT_DATA_TAG, FILE_SIZEOF_endpoint_data, TRUE },
>> { LINE_TAG, FILE_SIZEOF_line_data, TRUE },
>> { SIDE_TAG, FILE_SIZEOF_side_data, TRUE },
>> { POLYGON_TAG, FILE_SIZEOF_polygon_data, TRUE },
>> { LIGHTSOURCE_TAG, FILE_SIZEOF_light_data, FALSE },
>>
>
> Now, in the past, this thing basically helped develop count of data
> per tag, size of data per tag, and array location for data. So,
> especially for those elements not handled by the level loader, it
> could just say, data, size, source/dest, memcpy. With packing,
> things progress with a big switch for determining size, a big
> switch for source, and then packs the data for copying into a wad.
>
> And that doesn't even cover the additional code to unpack it from a
> saved game.
>
> It feels reasonable to me to have some loader classes that
> encapsulate the elements needed to load/save data.
>
> Something along the lines of
>
> MyFoo.h
> -------
> #include "CLoader.h" // CSerializer?
>
> // CLoader::Result some variable size data run with a count
> class MyFooLoader : public CLoader
> {
> void load_raw_data(char* raw_data, size_t length);
> CLoader::Result get_save_data();
> }
>
> Where load_raw_data does an appropriate unpack event. And
> get_save_returns you some stream of data that you need to dispose
> of yourself. This could be an auto_ptr to a vector<char> that is
> self maintaining, or it could be a pair<char*,size_t> that you need
> to explicitly free in some fashion. (AM has 2-3 instances of the
> latter around resource using functions, like sound_handles and
> CResourceFile, not that I'm perfectly happy with them.)
>
> Thoughts? Comments? Examples of similar objects?
>
> I'm undecided on the return format of get_save_data and am
> definitely not happy with the names load_raw_data and get_save_data.
>
|
|
From: Br'fin <br...@ma...> - 2005-06-14 01:08:36
|
Ok, I've been working on adding more AI/OStreams friends and the like
to more objects. As well as tweaking the code that iterates over the
various save game tags and throws the various data out into a file.
Specifically, this array:
> struct save_game_data save_data[]=
> {
> { ENDPOINT_DATA_TAG, FILE_SIZEOF_endpoint_data, TRUE },
> { LINE_TAG, FILE_SIZEOF_line_data, TRUE },
> { SIDE_TAG, FILE_SIZEOF_side_data, TRUE },
> { POLYGON_TAG, FILE_SIZEOF_polygon_data, TRUE },
> { LIGHTSOURCE_TAG, FILE_SIZEOF_light_data, FALSE },
Now, in the past, this thing basically helped develop count of data
per tag, size of data per tag, and array location for data. So,
especially for those elements not handled by the level loader, it
could just say, data, size, source/dest, memcpy. With packing, things
progress with a big switch for determining size, a big switch for
source, and then packs the data for copying into a wad.
And that doesn't even cover the additional code to unpack it from a
saved game.
It feels reasonable to me to have some loader classes that
encapsulate the elements needed to load/save data.
Something along the lines of
MyFoo.h
-------
#include "CLoader.h" // CSerializer?
// CLoader::Result some variable size data run with a count
class MyFooLoader : public CLoader
{
void load_raw_data(char* raw_data, size_t length);
CLoader::Result get_save_data();
}
Where load_raw_data does an appropriate unpack event. And
get_save_returns you some stream of data that you need to dispose of
yourself. This could be an auto_ptr to a vector<char> that is self
maintaining, or it could be a pair<char*,size_t> that you need to
explicitly free in some fashion. (AM has 2-3 instances of the latter
around resource using functions, like sound_handles and
CResourceFile, not that I'm perfectly happy with them.)
Thoughts? Comments? Examples of similar objects?
I'm undecided on the return format of get_save_data and am definitely
not happy with the names load_raw_data and get_save_data.
-Jeremy Parsons
http://alephmodular.sourceforge.net/
|
