Dogfight Slave....

[Codetapper]

Originally Posted by StingRay

10 games that you KNOW OF, that doesn't mean there are no other games needing it! Also, what about demos? No, I'm sorry, that argument doesn't convince me.

Well I've done approximately 1/4 or 1/5 of installs ever made, and I've done it twice. 2 x 5 = 10 installs, a pretty good guess I would think.

From my experience with hacking 300+ games, they all pretty much test for a block of 512k of extra memory, and if found will run and if not, will bail out. There are sod all that require 1Mb of chip and then an optional extra 512k or whatever. I'm sure all the other WHDLoad slave authors will back me up on this.

And for added complexity again, all that you (the people who find this feature useless) would see is one additional dc.l 0 in the slaveheader, nothing more, nothing less! You don't like it/need it? Just ignore it!

Wepl is the one that knows how difficult this would be, he replied earlier in the thread saying it wasn't worth doing for the few installs that need it. Nobody but him knows how complex the code would be with optional chip memory segments etc...

Anyway since I do not play sims (except F-18 Interceptor!) it sounds to me that the Dogfight slave itself is junk, so why doesn't someone just change/fix that rather than going through all the hassle of WHDLoad changes? Wepl's very busy, I'm sure does not want to risk breaking WHDLoad for this kind of feature unless there really is a lot of installs that will benefit from it, and I don't believer there is!

[StingRay]

Originally Posted by Codetapper

Well I've done approximately 1/4 or 1/5 of installs ever made, and I've done it twice. 2 x 5 = 10 installs, a pretty good guess I would think.

From my experience with hacking 300+ games, they all pretty much test for a block of 512k of extra memory, and if found will run and if not, will bail out. There are sod all that require 1Mb of chip and then an optional extra 512k or whatever. I'm sure all the other WHDLoad slave authors will back me up on this.

Well, said it before and I'll say it again: What about demos? I know you have done a lot of installs, no question, but you can't know every game/demo.

Originally Posted by Codetapper

Wepl is the one that knows how difficult this would be, he replied earlier in the thread saying it wasn't worth doing for the few installs that need it. Nobody but him knows how complex the code would be with optional chip memory segments etc...

I'm sorry, but what is the problem, as said, there is NOTHING complex here! And I posted the code already!

As it is now: chipmem size is defined in the header using dc.l chipmemsize

Flexible allocation: have an additional longword in the header, if it's empty, nothing changes, if it contains a value than that is interpreted as offset to a routine which does nothing more than setting the chipmemsize! So, please, tell me, only Wepl knows how to do this?

Now:
_chipmemsize dc.l $80000 ; fixed, can't be changed at runtime

my approach:
_chipmemsize dc.l 0
_memroutine dc.l offset_to_memcfg_routine ; fills chipmemsize

And that just has to be checked ONCE when the slave is started.

There really is absolutely NOTHING complex here. And even though I am not Wepl I think I can say that as I actually thought about these things before posting them.

[Codetapper]

I'm sure if it was a 1 minute change and was worth doing, Wepl would. I don't believe you have thought it all through though:

- New header files needed
- Extra code to test for WHDLoad 17 specific flags
- Code to handle slaves with bogus values in the new field
- Possible change of tooltypes/prefs file
- Check/adjust all the MMU/memory protection code
- Heavy testing of a selection of slaves to make sure the existing 1000+ slaves still work
- Docs changes for all the languages
- Reissue all the user/dev WHDLoad packages
- Website update (copy into history, other archive into older versions, news item etc)

As you can see, this is no 5 minute fix. And I still think my 10 installs that use it wouldn't be too far off the mark. Demos are just the same as games, they usually want 512k chip, or 512k chip + 512k other mem. In fact I can't think of any demos off hand that even have multiple slaves for different memory configs!

This whole argument is pointless anyway, Wepl is the boss, he said it wasn't worth doing, seems the majority of the WHDLoad guys agree so life goes on.

[StingRay]

Originally Posted by Codetapper

I'm sure if it was a 1 minute change and was worth doing, Wepl would. I don't believe you have thought it all through though:

- New header files needed
- Extra code to test for WHDLoad 17 specific flags
- Code to handle slaves with bogus values in the new field
- Possible change of tooltypes/prefs file
- Check/adjust all the MMU/memory protection code
- Heavy testing of a selection of slaves to make sure the existing 1000+ slaves still work
- Docs changes for all the languages
- Reissue all the user/dev WHDLoad packages
- Website update (copy into history, other archive into older versions, news item etc)

Ok, since you seem to know everything better, here is what I have to say:

- New header files needed
Yes, but that I said right from the beginning!

- Check/adjust all the MMU/memory protection code
Why? Totally NOT needed!

- Possible change of tooltypes/prefs file
Why? Totally NOT needed!

- Docs changes for all the languages
Why? I am sure the developers of the slaves all understand english.
And user documentation is not needed for a feature like that!

- Heavy testing of a selection of slaves to make sure the existing 1000+ slaves still work
- Website update (copy into history, other archive into older versions, news item etc)
- Reissue all the user/dev WHDLoad packages
Would have to be done for other changes too so it's irrelevant!

Originally Posted by Codetapper

And I still think my 10 installs that use it wouldn't be too far off the mark. Demos are just the same as games, they usually want 512k chip, or 512k chip + 512k other mem. In fact I can't think of any demos off hand that even have multiple slaves for different memory configs!

Ok, I take it you have seen every demo, resourced all of them and know how they all work. You have my respect for that!

Originally Posted by Codetapper

This whole argument is pointless anyway, Wepl is the boss, he said it wasn't worth doing, seems the majority of the WHDLoad guys agree so life goes on.

As said, I can live w/o that feature. But your reasons why it's not worth to have are just as pointless as this argument then. Also I DO know that this is not a "high priority" feature and Wepl most probably works on more important fixes/changes. However, that doesn't automatically mean this feature is useless!

[Psygore]

Originally Posted by StingRay

Well, said it before and I'll say it again: What about demos? I know you have done a lot of installs, no question, but you can't know every game/demo.

I've done only 2/3 game' slaves which use extra chipmem. Demo which extra sound/gfx? never seen one

Originally Posted by StingRay

As said, I can live w/o that feature. But your reasons why it's not worth to have are just as pointless as this argument then. Also I DO know that this is not a "high priority" feature and Wepl most probably works on more important fixes/changes. However, that doesn't automatically mean this feature is useless!

No, it automatically means that is useless if none of whd author will include it.

[Wepl]

Originally Posted by StingRay

And this is where I disagree. What about games that are different depending on the available amount of chipram? I remember f.e. one game from back then that had an annoying music if it detected chipram >512k. It didn't have this "feature" with 512k only. Now, if whdload would support flexible memory settings (which I still think is very easy to add), the user could have f.e. a tooltype that sets the chipsize the game will use, one slave, 2 different game versions!

This is already possible using current specs. Just give the Slave the max required chip mem and then use custom tooltype to select if the installed games sees all mem or only 512k. It wastes some memory in the latter case but if its below 1mb its acceptible IMHO.

Originally Posted by StingRay

And imho, all that's needed is something like:
; a0: points to start of slave
move.l CUSTOM_MEM_WANTED(a0),d0
beq.b .nothing_to_be_done
move.l d0,a1
jsr (a1)
.nothing_to_be_done

at the very beginning of whdload.

All inits must be done before the Slave is called. But it doesnt make sense anyway to discuss technical details here. Because I said its possible but not worth the effort in my opinion.

Originally Posted by StingRay

So why not add this for people who might want to use this?

Did you ever wrote a Slave? Sorry, I dont remeber...

[Codetapper]

Even if this feature was added to WHDLoad, I would not modify my existing installs. I think it's easier for the user to double click the correct icon to choose whether they want speech in Walker and Mortal Kombat 2 respectively.

Stingray: If Dogfight is so important as to warrant WHDLoad changes, why don't you make a single slave without the 16 versions or whatever it is? Maybe Dr Zarkov didn't know how much memory the game required exactly so just put all these questions when in reality it's probably a standard 1Mb game.

[killergorilla]

Maybe I should have just kept my mouth shut....

[girv]

Wow, what a lot of discussion!

I guess this is academic as Wepl doesn't think it's worth the effort to implement anyway, but I have to comment. "You are all entitled to my opinion" in other words

Firstly, Stingray and I were proposing different things I think. My suggestion was a way for the slave author to specify a list of choices of base/expmem configurations for WHDLoad to try to get at startup time. Instead of trying just the single config, it would try multiple ones in order of preference and fill in the header base/expmem fields with the first one that was successful. After that WHDLoad would continue as if the slave had been hardcoded with that configuration from the outset, so what's the big scary risk? It wouldn't need an extension to the slave header and I still don't see how it would need recompilation or retesting of existing slaves, alteration of the MMU code etc. Sure, it would need a documentation / web update, but it could have been released along with any WHDLoad point release when these things would have been done anyway.

Secondly, IIRC this was proposed a looong time ago, before the optional expmem allocation was added to WHDLoad (I think that may have resulted from the discussion, but it was a long time ago and I don't recall exactly). But now that optional expmem allocation has been around for a long time, how difficult, risky or non-backwardly-compatible would it be really to add a form of optional basemem allocation as well in a similar manner? That's a rehtorical question really, but I don't understand what everyone is so worried about

[Codetapper]

Girv: What actual benefit will you gain from what you have suggested?

If a game works with 512k chip and 512k other mem, the slave will have that memory config set in the slave anyway. If it needs 1Mb chip, it will have that as the requirement.

Nobody has been able to name any software that will benefit from any of these changes therefore the whole argument is pointless. You could add hundreds of optional features to WHDLoad that will never be used by anyone, but what's the point? It'd be used about as much as a tooltype that forces you to click the left mouse button 50 times between loading each file.

Psygore (the demo master) hasn't noticed any demos that will benefit from this, and the handful of games we have identified work perfectly fine with a couple of icons so why bother? If someone rewrote the Dogfight slave correctly I'm sure it would only need a single slave anyway, rendering this thread useless!

Also I fail to see how you can implement all this multiple memory configs stuff without expanding the header or using up the reserved longword. How would you ask for 512k chip + 1Mb fast, or 1Mb chip and 512k fast mem without further fields?

[girv]

If a game works with 512k chip and 512k other mem, the slave will have that memory config set in the slave anyway. If it needs 1Mb chip, it will have that as the requirement.

...and if it works with 512k chip but is better with 1Mb or 2Mb ? Off the top of my head, Uridium 2 and Paradroid '90 benefit from extra chipram with new graphics and more music, and you have given other examples yourself.

Nobody has been able to name any software that will benefit from any of these changes therefore the whole argument is pointless.

You mean like Walker, MK2, Paradroid'90, Uridium 2 ?

The benefit is to do away with multiple slaves for alternate memory configurations, and the associated build and install script complexities. IMHO it's more elegant and less error prone to have this ability centralised in WHDLoad itself.

the handful of games we have identified work perfectly fine with a couple of icons so why bother?

They work perfectly fine because the author has built two or more almost identical slaves, asked the user which one to use and picked or created the correct version on the fly. A flexible memory config built into the slave would avoid all that, so why bother with all that other stuff? It's an improvement. It makes install packages smaller and easier to create and maintain. That's why bother.

Also I fail to see how you can implement all this multiple memory configs stuff without expanding the header or using up the reserved longword. How would you ask for 512k chip + 1Mb fast, or 1Mb chip and 512k fast mem without further fields?

IIRC I suggested using "special values" for ws_expmem that would be interpreted as an offset to a memory preference table in the slave code => backwards compatible and no change in the header. Remember: IIRC this was before expmem could be specified as optional. It probably isn't compatible with that change, but I still believe it would have been an improvement over the "all or nothing" approach to the optional expmem allocation we have now.

There's also a few obsolete fields in the header as well, aren't there (not sarcasm, I can't look up the headers right now)? The new slave would break on old WHDLoads, but you'd have set the required version to higher than that anyway.

But, working within the current header, what I'd maybe propose is to define some flags as special values for ws_basemem to identify which sizes of basemem the slave can utilise: 0.5, 1.0 or 2.0Mb (are there any others?) WHDLoad would try to allocate the sizes specified in decreasing size order and then store the actual size allocated back into ws_basemem for your slave code (and the rest of WHDLoad) to use.

eg:
WHDLMEM_BASE512: equ 1
WHDLMEM_BASE1024: equ 2
WHDLMEM_BASE2048: equ 4

OR these together as required. 1-7 are not valid basemem sizes so this style of usage can be easily and robustly detected. It's not as flexible as specifying the exact basemem size you require, but do you ever specify anything other than 0.5, 1.0 or 2.0Mb ? And by your own argument this would only be used by a small number of installs in any case.

Another, possibly simpler suggestion is using a negative basemem value to specify the -maximum size the slave can use. WHDLoad would allocate 0.5, 1.0 or 2.0Mb depending on the requested size and the available memory. A problem is you could get the situation where you need 1.0 or 2.0Mb, ask for 2.0Mb-max but only get 0.5Mb. The slave would have to check for this and bug out if it didnt get its minimum requirement, but how hard is that? cmp.l #512k, ble fail ? On a subset of a subset of slaves? Cripes, I need a lie down now.

I can't believe this would be a complex change to WHDLoad either. Check a few flags at startup, calculate and store the basemem value and proceed as normal. What am I missing? As for the slave authors, are you saying that changing a single dc.l in the header is more complex than building, distributing and installing multiple slaves? I know which I'd rather do.

These are hacks and it would be cleaner to bump to v17 and extend the header with an offset to a "ws_memconfig" choice table or something. As you say it's probably not worth bumping just for this, but what's the harm in including it if/when v17 comes anyway ?

I don't think its a useless feature at all. I think it's an improvement, useful and worth the small effort I imagine it would take to implement. The only arguments against I'm hearing is that you don't like the speech in Walker (so code a skip-on-fire!) and mainly "it's too much bother". Well OK fair enough, that's Wepl's call. I respect your opinions, but I disagree. It's not the first time. Doesn't mean we all can't still be friends though

[StingRay]

Originally Posted by Wepl

All inits must be done before the Slave is called. But it doesnt make sense anyway to discuss technical details here. Because I said its possible but not worth the effort in my opinion.

I know that! What I meant was that you read out the chipmemsize value in whdload before the slave is started. So I don't see why it's so hard to read one more variable, i.e. the ptr to the custom routine and execute that. After all, you must have some ptr to the slave header within whdload anyway, that's all I meant!

Originally Posted by Wepl

Did you ever wrote a Slave? Sorry, I dont remeber...

For WHDLoad, no, at least no released one. But I have fixed countless demos and have made my WHDLoad like patching system as well (which I don't use these days anymore though), so if your question was if I know about patching/fixing, yes, I definitely do. And I might do some whd slaves in the future, most probably for demos only. And if it was meant as a "you never coded a slave, you have no clue" well, then I better don't comment that!
Edit: you might want to check out this thread http://eab.abime.net/showthread.php?t=28148 just in case you still think "no slave released, no clue"...

[StingRay]

Originally Posted by Codetapper

Stingray: If Dogfight is so important as to warrant WHDLoad changes, why don't you make a single slave without the 16 versions or whatever it is? Maybe Dr Zarkov didn't know how much memory the game required exactly so just put all these questions when in reality it's probably a standard 1Mb game.

I might have a look! Also please note that I don't consider this feature utterly important (as said), I just thought it would/could be nice to have. I won't die if it won't ever be implemented as that's Bert's decision like you already said.

[StingRay]

Originally Posted by Psygore

I've done only 2/3 game' slaves which use extra chipmem. Demo which extra sound/gfx? never seen one

Then check certain Sanity demos...

Originally Posted by Psygore

No, it automatically means that is useless if none of whd author will include it.

That still doesn't necessarily mean it's useless. It's a non-implemented feature then, nothing more nothing less.

[StingRay]

Originally Posted by girv

The benefit is to do away with multiple slaves for alternate memory configurations, and the associated build and install script complexities. IMHO it's more elegant and less error prone to have this ability centralised in WHDLoad itself.


They work perfectly fine because the author has built two or more almost identical slaves, asked the user which one to use and picked or created the correct version on the fly. A flexible memory config built into the slave would avoid all that, so why bother with all that other stuff? It's an improvement. It makes install packages smaller and easier to create and maintain. That's why bother.

That's exactly what I think and the reason why I suggested to add flexible memory config. At least someone shares my ideas. I thought it, you said it!

[Codetapper]

Originally Posted by girv

You mean like Walker, MK2, Paradroid'90, Uridium 2 ?

I was hassled by Stingray for guessing 10 slaves might benefit out of about 1300, and we have come up with a definite list of 4. 6 if Psygore could remember his 2.

The no-speech version of Walker is much smarter than you are giving credit for anyway, as the no-speech version deliberately sets all the speech files as not needing to be buffered which speeds up loading etc. The slaves are certainly not identical. And as for the complexity of maintaining 2 files, only one source file builds both slaves anyway! Don't tell me you have multiple source files for the 2 games you have identified?

This whole issue is a bit like an install script upgrade. You can put all the extra features in that you wish, but nobody is going to go back and redo existing installs that work perfectly fine in their current form!

[StingRay]

Update: I've disassembled the Dogfight slave now and it seems as if Dr.Zarkov tried to use the "CUSTOM" tooltypes to set basememsize+extmemsize (CUSTOM4/5). At least there are (unused) parts in the code that look very much like he tried to do that. Will resource the game now and check if it makes use of extended mem.

[StingRay]

Originally Posted by Codetapper

I was hassled by Stingray for guessing 10 slaves might benefit out of about 1300, and we have come up with a definite list of 4. 6 if Psygore could remember his 2.

I didn't hassle anyone! I just pointed out what I think, that has nothing to do with hassling. You are always entitled to have your own opinion!

Originally Posted by Codetapper

And as for the complexity of maintaining 2 files, only one source file builds both slaves anyway! Don't tell me you have multiple source files for the 2 games you have identified?

I have to comment on this as you contradict yourself here. You say added complexity to whdload is bad but it's ok to have install scripts that are more complex than they need to be?

[StingRay]

I've updated the slave now, turns out Codetapper was right! As far as I could see the game just needs ~256k chip ram and makes use of extended mem if it's available. The slave now requires $80000 bytes basemem and $80000 bytes extended mem. The slave now also removes the copyprotection so that it won't be necessary to modify the gamefile during installation. I also added that the slave first checks for OSEmu400 in the game datadir and if it's not available there it tries to load C:OSEmu400. This way it's possible to use a special version of OSEmu only for that very game as I heard there are several buggy versions around. Unused code has been removed as well. Slave attached to this post, can you please test it, Killergorilla? If it works, I'll create an updated installer script which can then be uploaded to the whdload site.

[Psygore]

Originally Posted by StingRay

Then check certain Sanity demos...

They didn't.