Re: [Alephmodular-devel] Display Abstraction Landed?

[Br'fin <br...@ma...>]

On Tuesday, October 7, 2003, at 04:16  PM, Timothy Collett wrote:

>> My own up-to-date version of AM seemed to have no problems loading =20=

>> your
>> save game though.
>
> Hmm...that wasn't exactly the problem, I'm afraid.  I think I can load =
=20
> a game from the main menu.  The sequence of events here was the =20
> following:
> start new game
> save
> die
> attempt to resurrect
> AM quits itself
>
> But this suggests that at least the savefile was good.

Ah, hmmmm, you know, I can't think if I ever tried that or not, hmm.

>> Yes, Networking is currently disabled. It was easier to stub it out
>> then to grok everything and rewrite it in OpenTransport. The most
>> likely thing to occur here is that we graft in A1's networking ;)
>
> Star protocol & all? :-)

Heh ;)

>> With respect to replays, I don't know if there is a better way to do
>> things. There are improvements we can make ... like eliminating the
>> need for the Vidmaster's dance. But beyond that, it's hard storing =
all
>> of the world state umpty times a whatever. On the other hand, even in
>> modern games, I don't recall seeing that many replays in FPS ( and
>> usually they work in a similar fashion when they do... reset =20
>> simulation
>> to x point in time, let run :) )
>
> Yeah, I know.  But...couldn't there be some more robustness in the =20
> format?  One thing that comes to mind is making the RNG a little more =20=

> solid in synchronization, if this is possible/sensible (this would =20
> help net games, too).  Another thing is to put information about the =20=

> environment used into the film.  Ideally, each =20
> Shapes/Sounds/Map/Physics file would have some sort of checksum that =20=

> the films (and savefiles) could reference, and if it's not there, =20
> there should be some sort of warning.

Well, the replays are solid in terms of sync. But if something changes =20=

then the replay is off. And classic OOS errors seem to come from =20
someone's emulation getting off for some unclear reason.

As I recall, the wadfile based files (physics, map) do have this =20
checksum (hence how a replay or, I believe, even a saved game syncs up =20=

with the right map.) The other two files, shapes and images do not and =20=

the game tries to sync up with them (from the preferences) due to =20
modification date :/

Though any sort of checking on the files would help over the existing =20=

code with respect to replays :)

>> We have to deal with resources as long as the file system does and we
>> can run old M2 maps. This should cover a nice long while. It would be
>> nice to mix things up to have a scenario bundle. However, even then
>> this might be resource routines now working with an expanded format
>> (that is hidden from the rest of the code.)
>
> I didn't say that quite right, did I?  What I really mean is that we =20=

> shouldn't have any current file formats=97the ones we output=97using =20=

> resources.  I think that having support for *loading* resource-based =20=

> formats is great, and should remain forever (at least where it makes =20=

> sense to do so, like Map and Images).  But if any current formats (ie, =
=20
> savefiles & films) use resources, the use of them should be abstracted =
=20
> away from the core, so it's easy to plug in a new function to save =20
> them on Windows or Linux systems.

The only resource we save into files currently is a map preview in the =20=

saved game that is supposed to show up in Open/Save dialogs and the =20
finder. What's annoying is this worked fine in OS X 1.0, but under 1.1, =20=

Nav Services still created the preview, but the finder ignored it for =20=

me :/

That preview is currently stored in a very platform specific way, =20
supposedly so that that platform can and should show it elsewhere :/

> Another issue I've been thinking about is the real modularization =20
> part...you know, being able to just take the network bits for a pure =20=

> game server, and the rendering code for Visual Mode of an editor, that =
=20
> kind of thing.  How much is that inherent in what you've been doing, =20=

> and how much must be done separately?  More to the point, how much =20
> remains to be done?

The Real modularization part is yet to come... I should dig up one of =20=

the roadmaps and probably check into into the documentation directory.

Here's probably the closest thing we have ;)
http://sourceforge.net/mailarchive/=20
forum.php?thread_id=3D1453618&forum_id=3D17900

I'm still trying to erase direct knowledge of Mac-isms from these main =20=

game loops and so forth. It seems to be a step towards both modularity =20=

and going cross-platform.

Heh, going by those lists the next to work on would be sound =20
abstraction.

> A rough order might be
>         Modularizing basic file capabilities
>         Modularizing basic display capabilities
>         Modularizing sound handling
>         Modularizing preferences
>         Modularizing gui
>         Modularizing game elements
>         Modularizing networking

-Jeremy Parsons