Loader Question

[Renzatic]

Cheers for that Renzatic, another question...simple one, are there difficulty settings in Doom 3 and/or The Dark Mod? if so what are they?

Yeah there are. In D3 you have Recruit, Marine, Veteran, and Nightmare. TDM will eventually have em as well, probably named similar to Thief's easy, medium, hard, expert settings...though what they'll entail still hasn't been decided fully on yet.

[sparhawk]

Different levels of AI states. That's it as far as the toolset goes. Everything else is up to the FM author to define. It's pretty simple really.

[potterr]

That ok then, I don't need to do anything special to support difficulties then.

 

Napalm, it may be useful, without looking into it in much depth at the moment I would assume that the script will be ascii readable?

 

A bit of good news though I will be releaseing the final public beta of GarrettLoader today sometime. The Dark Mod stuff will be disabled though as I only just got Doom 3 yesterday and haven't had a chance to look in depth at the folder and file structures....however I'll send an unrestricted version in a week or so to a few people to have a go with.

Also I "think" that I have got Thief 3 supported fully with it...when I say think, I mean I have got the code set up to run FM's in Thief 3 but don't actually have any thief 3 FM's to test with....however there could be a couple released this week

So although it should work, there is no guarantee it will work and indeed not actually muck up your T3 install, use with caution (however it will backup any files that may be overwritten so if it mucks up somewhere you can still just unzip the backup).

[Springheel]

The Dark Mod stuff will be disabled though as I only just got Doom 3 yesterday and haven't had a chance to look in depth at the folder and file structures...

 

Er, you know there won't be completed FMs for at *least* a year, probably two, right? There's no rush for you to figure out the file structure.

[Napalm]

The scripts used in D3 are ascii readable if they haven't updated the setup (which I'm 93% sure is the case) but I havn't looked into it so I'm not really sure

[potterr]

Er, you know there won't be completed FMs for at *least* a year, probably two, right? There's no rush for you to figure out the file structure.

Springheel, Yeah I know, I just want to be prepared and a though was that people could also use it as a Doom 3 FM loader.

[potterr]

Just thought I would let you guys know (although you probably already do)

GarrettLoader versin 1.01 was released on the 11th at http://www.potterdevelopments.org.uk/fm

 

However the Dark Mod and Doom 3 stuff is disabled at the moment but should be in version 1.51 ....Thief 3 is enabled though and the small mission contest entries are released around the 16th.

[Renzatic]

Hey, if you want to use an icon for TDM besides the default Doom 3 one, you can use this...

 

 

The final icon will probably look a bit different since this one doesn't scale down to 64x64 without looking like absolute ass...but it'll work for a placeholder.

[potterr]

cheers for that, I'll have a go at adding it in tommorrow (not sure how good it will be as I use 32x32, 24x24 and 16x16 icons in GL, but so long as its identifyable it should be ok for the moment).

[Guest KoHaN69]

The files stay in the pk4 file at all times. You can extract them to the disk and use it like this also, but this would not be needed for a FM distribution. In fact performancewise it would be worse to extract it to disk, because disc acess is slower then the small time it takes modern CPUs to decompress the ZIP file.

The major thing a loader would have to do is to backup savegames in our case.

<{POST_SNAPBACK}>

 

I strongly disagree, in my expereince, extracting to disk gave 20~ more Fps and 10 second faster loading times.

 

On system:

athlon XP 2600 @ 2.4

512mb ram at 400mhz ddr

80gb western digital hd

9700pro 128mb

[sparhawk]

I wonder how you measured this. Disk access is definitely slower then decompressing it, because this means that you just need to load a small chunk of data and the rest is done in memory, while loading the data from disk means that the CPU has to wait for the disc to provide the data.

[Guest KoHaN69]

I wonder how you measured this. Disk access is definitely slower then decompressing it, because this means that you just need to load a small chunk of data and the rest is done in memory, while loading the data from disk means that the CPU has to wait for the disc to provide the data.

<{POST_SNAPBACK}>

 

I measured this with fraps and the ingame doom3 fps counter.

if the files are in single archieve, then it is the load on the cpu to get each file form archieve (such as a texture) and send it thru system ram to the vid card

 

and if it isnt in an archieve, but in a folder, it loads faster to ram, hence more fps,

however it does give more load on the harddrive.

[god_is_my_goldfish]

If you have a large game with only a few compressed files to store the whole thing (i.e. Doom 3, the game itself) it makes sense to run everything from decompressed folders, but considering that DarkMod FMs and mod content will not take up nearly the space or be spread across many different pk4's it is better for DM content to be compressed.

[Guest KoHaN69]

If you have a large game with only a few compressed files to store the whole thing (i.e. Doom 3, the game itself) it makes sense to run everything from decompressed folders, but considering that DarkMod FMs and mod content will not take up nearly the space or be spread across many different pk4's it is better for DM content to be compressed.

<{POST_SNAPBACK}>

 

roger

[potterr]

Right, having installed DOOM 3 now and played through some of it, I did a bit of an update to GarrettLoader (version 1.11). I have got the original game loading up fine from it, I am now working on doom 3 FMs, which brought me onto the request I have.

In order for GarrettLoader to determine how the Dark Mod FM's should load up (as a Dark Mode FM or as a Doom 3 FM, although I have yet to see if it is an issue), GarrettLoader will need to have this is the FMs readme file:

Game : The Dark Mod

or the readme to have been created by GarrettLoader in the first place.

 

Unless there is a simpler way to identify teh difference between a Doom 3 FM and a Dark Mod FM from the files NOT contained in the PK4 file?

[sparhawk]

Dark Mod FMs will have the textures from our set. So it certainly will contain a lightgem texture. BUT I don't like the idea of having to redistribute everything in each PK4 file, so we might think of a way to have a base package and the actual FMs seperated.

[potterr]

sparhawk, that sounds like a good way forward. What would probably be best is for me to program it so that both a file check and a readme scan is done to confirm the FM is for the dark mod and not just doom 3.

[potterr]

Right, finaly got GarrettLoader able to load up Doom 3 FMs without going through the in game console (done by adding "+map mapname.map" in the startup command of doom3.exe, e.g. "doom3.exe +map sh3.map").

To do this I extract the pk4 from the zip to the doom3\base folder, then when the user clicks the play button it will open up the pk4 file (seeing as its just a zip file), hunt around for any map files and:

1) if there is only 1 map file found it will launch that.

2) if there are multiple map files it will ask which one to start with (see problem below).

3) if no map files are found it will wimper, look pathetic and hide in a corner.

 

PROBLEM:

The thing with asking what map file to load is that it would work well if there is only a single player map and a multiplayer map, however what about multi-level single player maps? is there a way to determine what is the starting one or will there only ever be 1 map file per FM?

[sparhawk]

One othe thing we could provide would be this. This would be the most reliable thing to do. When you open the PK4 you can check for the existence of the mod dll. If it is there you can load it and call a function Darkmod(). If it doesn't exist it is certainly not a darkmod dll. We can include such a function in the DLL.

[OrbWeaver]

I measured this with fraps and the ingame doom3 fps counter.

if the files are in single archieve, then it is the load on the cpu to get each file form archieve (such as a texture) and send it thru system ram to the vid card

 

It doesn't do this for each frame though, otherwise the FPS would be in low single figures. The resources are loaded at level start (and possibly at other times during the game; I am not sure if D3 does on-demand loading or not), so any change in FPS must be due to something else.

 

It is not just the speed of disk access either - retrieving lots of small files from all over the disk is much slower than unpacking them from a single archive file, due to filesystem overhead.

[sparhawk]

It can also do on-demand loading, but this should be avoided.

[potterr]

One othe thing we could provide would be this. This would be the most reliable thing to do. When you open the PK4 you can check for the existence of the mod dll. If it is there you can load it and call a function Darkmod(). If it doesn't exist it is certainly not a darkmod dll. We can include such a function in the DLL.

 

I can have a go, I have no real idea as to how to bring in a DLL partway through a program running (they all get verified on startup of the program rather than at set points through).

 

I may have to settle for just detecting its there.

[sparhawk]

No they don't. That's why they are called DYNAMIC LINK library.

 

You must call LoadModule() (or something like that, I haven't done this for a long time). Then when you got the handle you do GetProcAddress("DarkmodFkt") or similar. If you get a valid pointer you will have a function that is pointing to a TDM library. We can return a version number with this function, but the pointe ralone tells you that it has to be a TDM library, because in other DLLs you wont find such a function. So it's only two, maximum three function calls to check if a mod is a TDM and which version it is.

[potterr]

No they don't. That's why they are called DYNAMIC LINK library.

 

You must call LoadModule() (or something like that, I haven't done this for a long time). Then when you got the handle you do GetProcAddress("DarkmodFkt") or similar. If you get a valid pointer you will have a function that is pointing to a TDM library. We can return a version number with this function, but the pointe ralone tells you that it has to be a TDM library, because in other DLLs you wont find such a function. So it's only two, maximum three function calls to check if a mod is a TDM and which version it is.

<{POST_SNAPBACK}>

Ah, but is that going to work with VB as a lot of dlls are compiled for C++ which VB has a bit of trouble using without a wrapper of some kind?

 

I will wait on the DLL querys untill I have one to test with, but if you could add the function into teh dll that would be great.

 

I am releasing version 1.11 of GarrettLoader tomorrow at some point, which should be set up enough to try using as a Dark Mod FM installer. I can provide the information on what steps it does if you want to know before trying it on Dark Mod FMs.

[sparhawk]

Can't help you there as I never use VB on principle. All the API calls are covered for VB, but I don't know how you would call the actual function then. I think this is not so hard to do, because I have seen some examples, but this was a long time ago and I don't remember exactly how this was done. A bit of googling should find such sample without problem, though.