Dogfight Slave....

[girv]

Originally Posted by StingRay

Congrats for the 500th post

Oh, thanks! How did you know?!

Originally Posted by StingRay

I think, it would be more flexible to have whdload execute a custom routine for the memory settings

I guess the routine would need to be told how much chipram and fastram was in the system, then return how much of each it wanted ?

I thought it might be easier for the slave author to just specify different basemem / expmem size combinations with dc.l in a list , using a similar "special value" as you suggested in the current ws_basemem to reference the start of the list. That way, the logic of memory selection can be contained in WHDLoad itself and also WHDLoad can handle any allocation errors etc. and try the next combination. All you need worry about is which memory combinations you need.

Originally Posted by StingRay

but flexible memory configuration should be added to whdload in my opinion.

Let's go see Wepl then

[BippyM]

Originally Posted by girv

500TH POST! WOOHOO!

you must have NO life to acheive 500 posts

Congrats roll on the 1k

[StingRay]

Originally Posted by girv

Oh, thanks! How did you know?!

Umm, I really don't know. I just guessed.

Originally Posted by girv

I guess the routine would need to be told how much chipram and fastram was in the system, then return how much of each it wanted ?

Yep, that's what I had in mind. Like, in the case of Dogfight, it would check the available memory and then just return the correct values.

Originally Posted by girv

I thought it might be easier for the slave author to just specify different basemem / expmem size combinations with dc.l in a list , using a similar "special value" as you suggested in the current ws_basemem to reference the start of the list. That way, the logic of memory selection can be contained in WHDLoad itself and also WHDLoad can handle any allocation errors etc. and try the next combination. All you need worry about is which memory combinations you need.

Well, of course it's easier for the slave author to have a list where he can choose some memory configurations then. Yet, I totally HATE fixed stuff because sooner or later you will have a game/demo that requires special treatment and that can be easily solved with a custom routine as you are free to do whatever you want then. Like, in my 3d engine I have also pre-defined polyfillers which I use most of the time but often I also need to do something totally different (which I of course didn't plan when I coded the engine) and using my custom routines I can very easily add new polyfillers. That's just an example but I think it's a good one.

Originally Posted by girv

Let's go see Wepl then

Word!

[Wepl]

There could be added something to make it possible for the slave to have different basemem setups.
But at least in this example I see it not worth the effort.

I would make one slave which supports all game features. If this slave requires 1 MB chip, then its ok.
Are there really people which use WHDLoad on a machine with 512 kb Chip only?

[StingRay]

Well, while it might be useless in this case, there may be other cases where it will be useful to have! And I think it shouldn't be too hard to add as you have to parse the header anyway. Also, that you think it's not really needed doesn't mean others think the same. So if it's not an insane amount of work, I'd like to see it added. I might be naive but all you have to do is a check if memory config is set in the header and if not, call the given routine. Shouldn't need much time. I might be totally wrong though.

[Psygore]

Originally Posted by StingRay

Well, while it might be useless in this case, there may be other cases where it will be useful to have! And I think it shouldn't be too hard to add as you have to parse the header anyway. Also, that you think it's not really needed doesn't mean others think the same. So if it's not an insane amount of work, I'd like to see it added. I might be naive but all you have to do is a check if memory config is set in the header and if not, call the given routine. Shouldn't need much time. I might be totally wrong though.

I agree with Wepl, it's not really needed
Btw, this feature will be only for slaves wich use kick/osemu and they need to be recompiled (some slaves have absolute value for base/expmem).

[StingRay]

Originally Posted by Psygore

I agree with Wepl, it's not really needed
Btw, this feature will be only for slaves wich use kick/osemu and they need to be recompiled (some slaves have absolute value for base/expmem).

Assembling the slaves is done in like 2 seconds so I don't see problem here. Also, they don't have to be recompiled as they don't require latest whdload, i.e. new slaves would use the feature, old slaves just wont. And seeing that there are 4 different slaves created for a single game, well, apparently someone could have used the feature of flexible memory allocation. So I am still not convinced that it isn't needed but then again, I won't care much either.

[StingRay]

Originally Posted by Wepl

I would make one slave which supports all game features. If this slave requires 1 MB chip, then its ok.

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!
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.

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

[Galahad/FLT]

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!
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.

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

I think there are so few games that require it as an option, that the effort expended to implement it doesn't warrant the work.

At the moment, the only person inconvenienced at the moment is Killer Gorrilla, and with respect, its not worth the hassle for just one person.

Just my opinion thats all

[StingRay]

While I understand that, I don't think implementing a feature like that is a lot of work, so why not? If I am wrong, Wepl should correct me of course! If I didn't miss anything obvious, my code posted above should be all that has to be added. I like to have features even if I might not use them all the time, I just think it makes coder's life easier (sometimes).

[Galahad/FLT]

Originally Posted by StingRay

While I understand that, I don't think implementing a feature like that is a lot of work, so why not? If I am wrong, Wepl should correct me of course! If I didn't miss anything obvious, my code posted above should be all that has to be added. I like to have features even if I might not use them all the time, I just think it makes coder's life easier (sometimes).

The slaves have reserved space for future options, and I'm guessing Bert doesn't want to use those up if far better ideas come up in the future.

[StingRay]

Hmm, I'm sorry but that doesn't convince me either. ;D As what I suggested would just occupy 4 additional bytes in the slave header. (would be possible to reduce it to 2 bytes if size REALLY matters).

[musashi5150]

What about if the slave header stays the same as it is now - and you fill in the minimum required options for the slave to run. Then there could be a WHDLoad_AllocMem() function which you can use if you need it...

It could be linked to the CUSTOM tooltypes of the slave to turn it ON/OFF if you "didn't want the shitty music" for example

[StingRay]

That approach would of course work but I think that this would require much more effort to implement in whdload. (4 bytes added to the slaveheader + a few lines of code vs. complete allocmem function). And even if I sound as if I couldn't live w/o that feature, I actually can very well. But it's nice to discuss these things!

[Codetapper]

I agree with Wepl, Psygore and Galahad. For the 10 (max?) games that have multiple slaves, it's not worth the added complexity. From memory I have done it twice:

I used 2 slaves in Walker - one for speech and one without. The version with speech requires more chip memory, but you are forced to listen to it before each level and cannot skip it, so I always play without the speech!

Mortal Kombat 2 gains extra stuff with 2Mb chip.

Most other slaves that can have optional extras work with fast memory, which is an optional value. You can tell WHDLoad you want 512k but if there is none, it will still continue.

If including 4 versions or 16 or whatever is such a problem, why not just have 2? One for cut-down machines, and one for kick-arse machines?

Also if the only difference is the slave itself, what is the problem with including multiple icons? Is it really such a problem?

[StingRay]

Well, I always hear "added complexity" and stuff here and all kinds of workaround solutions. Now I'd really like to know, what is complex about 4 lines of code plus one additional (long)word in the slave header? I really don't get that. But that might just be me.

[StingRay]

Originally Posted by Codetapper

For the 10 (max?) games that have multiple slaves, it's not worth the added complexity. From memory I have done it twice:

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.

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!

[DrBong]

Originally Posted by Codetapper

Also if the only difference is the slave itself, what is the problem with including multiple icons? Is it really such a problem?

That would make the most sense for KG's "dilemma" IMHO- just a single Dogfight archive in the pack instead of 16 (which would probably confuse some among the masses). The icons could be clearly labelled to indicate which version is which, and another readme file (if needed) could be appended to the archive to spell it all out for the real WHD novices among the masses. Would also keep the size of the pack down and save bandwidth/download volume too.

What Stingray suggests isn't without merit, but I'm sure Bert has a fair list of yet-to-be-implemented features he'd much rather spend time on. No doubt these features would comparatively have far greater benefit for the user base as a whole too!

[Galahad/FLT]

Originally Posted by StingRay

Well, I always hear "added complexity" and stuff here and all kinds of workaround solutions. Now I'd really like to know, what is complex about 4 lines of code plus one additional (long)word in the slave header? I really don't get that. But that might just be me.

Problem with that is there is limited reserve space in the structure of the slave for Bert to simply add stuff everytime someone suggests it. At the moment, all slave structures are the same, if Bert adds too much, there will come a time when he has to expand the structure size and all of a sudden 4000 installs won't work with WHDLoad but a couple of slaves will.

[StingRay]

Originally Posted by Galahad/FLT

Problem with that is there is limited reserve space in the structure of the slave for Bert to simply add stuff everytime someone suggests it. At the moment, all slave structures are the same, if Bert adds too much, there will come a time when he has to expand the structure size and all of a sudden 4000 installs won't work with WHDLoad but a couple of slaves will.

Well, that sounds to me as there won't ever be any additions at all. I mean, 4 (or 2) bytes are really not that much for something that I for myself consider useful. I see what you mean but even if the slave structure has to be enlarged, that does NOT mean that all existing slaves won't work anymore! The headersize can be checked within WHDLOAD, old header detected -> new features disabled/not used. Not much of a problem imho. But as said, I can live w/o that feature as it somehow looks like there is this "oh new feature? nah, better don't touch anything that runs!" mentality here. Years ago we had cars without airbags and they worked well but then someone invented airbags and even though you (hopefully) won't ever use/see them in action there are certain situations where they can be very helpful!