Dogfight Slave....

[killergorilla]

Hi,

I know this is probably going to get a resounding NO, but Is there any chance the dogfight slave could be changed at all?

It currently asks you two questions, both with 4 answers. The first is how much chip ram do you have, and the second is fast ram.

I generally like to include all slave versions in my packs but this means I have to include 16 different versions of this game!

Is there really a need for that many different options? Can they not be reduced? I mean, who has 1.5MB of chipram anyway? And who uses a 0.5MB chip ram amiga with WHDLoad?

Just a thought, if not, don't worry I'll leave it until last

[killergorilla]

Wondering if any of the WHDload guys fancied commenting?

[Galahad/FLT]

commenting? Well I think the situation in Iraq needs to change drastically.

[killergorilla]

Wise words. But let's not comment on why or how the problem can be solved

[BippyM]

why has the author done it this way.. surely memory can be aquired/checked by the slave :/

[Anubis]

Just to make KG's life miserable...

[Galahad/FLT]

Originally Posted by Anubis

Just to make KG's life miserable...

Every waking minute....

[killergorilla]

I'm miserable in my sleep too because I dream WHDLoad now.

[Galahad/FLT]

Originally Posted by killergorilla

I'm miserable in my sleep too because I dream WHDLoad now.

Shit, that is pretty miserable!

[girv]

What does the install script do with the answers to the questions?

[killergorilla]

I don't know off the top of my head, but IIRC there is only one slave file.

I chose a few different options and compared the crc's of the slaves afterwards and they were all different.

[StingRay]

Sounds like the slave author was very lazy if he uses different slaves for different memory configurations.

[killergorilla]

Join the WHDLoad team and write a slave update without osemu.400

[girv]

Originally Posted by killergorilla

I chose a few different options and compared the crc's of the slaves afterwards and they were all different.

I guess the script is patching the selected memory requirements into the slave files, since they're hardcoded into the slave header structure.

The slaves may also be identical apart from that: do a binary compare and see if there are any differences in the slaves after the first few tens of bytes. If not, the script is just messing with the amount of memory each slave is requesting.

Fastram can be made automatically optional to the slave (uses it if its there, still works OK if not) with a bit of binary hacking, which would chop down the number of combinations you need to work with.

Do the different memory setups make a difference to the game anyway? Like do you get extra graphics or sound with 1 or 2Mb chipram ? Or does it run faster with fastram ? What does more fastram get you ?

[StingRay]

Originally Posted by girv

I guess the script is patching the selected memory requirements into the slave files, since they're hardcoded into the slave header structure.

That's exactly what the install script does. It also removes copy protection that way. I don't see any reason why the slave author did it like this...

[girv]

Originally Posted by StingRay

Sounds like the slave author was very lazy if he uses different slaves for different memory configurations.

It's a limitation of WHDLoad, not the slave author. The problem is that the memory requirements are hardcoded into the slave header.

WHDLoad will abort if it can't allocate the memory requested in the slave header, so, for example, if the game is playable on 0.5Mb chip but has extra features for 1Mb chip you need two slaves with these memory configurations coded into their headers. If you do just the 0.5Mb chip slave, 1Mb owners miss out on the extra features. If you do just the 1Mb chip slave, 0.5Mb owners can't run the game.

I had words with Wepl about this many years ago

[StingRay]

Ah ok, thanks for the info. Did not know that so I take back all I said about "lazy slave author". I totally forgot about the slave header and that the memory configuration is done there. Maybe some "update_header" function in whdload would be nice to have, i.e. you call it once you have changed the memory requirements there and whdload should adapt then. But I don't know how whdload handles the information in the header internally so it might not be possible to add something like this. It would be useful though, so go and have a word with wepl again.

[StingRay]

Hmm, another idea would be to enlarge the slave header and have something like dc.w OFFSET_TO_MEMCFG_ROUTINE-BASE and if that one is != 0 (i.e. the slave needs/wants to do some custom memory settings), whdload would execute this routine first. That should be perfectly possible to do I think.

[girv]

No probs

To avoid this problem, I'd suggested a backwards compatible change to the header structure to define a list of different memory configuration options that WHDLoad could try to allocate in turn. Maybe I'll dig up that old (like, 1998 I think?) email and fire it off again

And by the way...

500TH POST! WOOHOO!

[StingRay]

Congrats for the 500th post

I think, it would be more flexible to have whdload execute a custom routine for the memory settings (i use a system like that in my 3d engine and it saved my ass MANY times, specially when I had to add some stuff 5 minutes before a deadline ;D), it's very flexible. I think it might be possible to add that w/o even enlarging the slave header, it would just require some changes in whdload itself. Like, you normally have chipmem_size = $80000 (f.e.) in the header. Now, if that value there is < than the slave size, whd can interprete it as offset to custom routine and execute that one. I don't think, any slave will be 512k in size. :P Anyway, these are just ideas, but flexible memory configuration should be added to whdload in my opinion.