Spider

That's great, I appreciate the 'before' file too so you get an exact copy to see the same sprites 'in action' I was thinking the other day but I've not tried to look into it, the effects of either ink (or paper!) 8 or 9. 8 being 'transparent' = 'no change' and 9 being 'contrast' so its set to either black or white depending on what the other cell type aka ink or paper is set at. 9 might be more sensible if it works that is as its contrast, but IDK if its likely to work "outside Basic" I've never tried that I can recall. :unsure: :)

:D , I did wonder if it would be something along that line as a single byte change could not usually do a great deal. Note to self: 35897 , 87 , just this way I have "both" to hand. :)

I do note slight differences between emulators but I have always assumed most of the problem here on an emulator vs a real machine is the way the host is limited in how it reads the keyboard and which multiple keys it can cope with at once. I do not think there is any difference between a USB and a PS2 type, I'm assuming the concern is a legacy one in how the IBM-PC "architecture" (if that's the right word?) was designed It would be interesting to find out if there are actually any differences in this between a PC and a Mac too.

I could probably write a large paragraph on my W7 > W8 > W81 > W10 adventures but I'll resist. Safe to say despite owning these versions fully licensed I'm currently on W7 for the time being.

Its a shame in a way that you cannot (as in very easily without work) have two types of fire cells as per MM in JSW. :unsure: Then it would be easy to design a 'cell' to fit the top area perhaps :unsure: Its interesting to note that Matt did place fire cells on the leftmost side to prevent a top exit although it could be said these are more cosmetic placements maybe.

That does look quite reasonable to me, the design of them makes them look like they are meant to be there, sort of 'hanging ornaments'

Yes I could not find a erm 'sensible' solution this way either... :)

I was thinking about this just the other day again. With the exception of the C64 MM Editor (that I cannot get to work properly and its a guest editor rather than PC/Mac host) it is slightly odd there is nothing for the other platforms. I can possibly guess compression may rule it out of some variants but the MSX and CPC range in particular seem to be highly suitable candidates, at least for MM if not JSW1. JSW2 might be more tricky.

It occurred to me that I should check the Amstrad and Commodore versions of the above games at some point to see if they also 'feature' him too, although I'd only expect that to be the case in Kokotoni I think.

Did you manage to find him yet Bob ? :) I do not have any more information unfortunately although I do see a few replies to your same question on WOS so hopefully someone has helped.

I had a vague thought about some kind of hidden fire cell at the top of the screen, something invisible but that would spoil it. I then had a random thought (something I looked at once at least in principle) of moving the 'spears' up a bit in Quirkafleeg but to get this to work properly they have to move up a couple of rows and that then makes the Quirkafleeg screen look odd :huh: , not to mention the rope may need a trim too. A solution but a highly impractical one. I may actually go and try this tomorrow now to see how it (badly) works "in practise" :D

One slightly interesting thing I have only really just noted is the 'sloped roof' in 'Halfway up the East Wall' is not set as an active ramp, he can freely stand and move on it without fear of being thrown off the end.

I think a slightly alternative take on this might assist ? I don't want to derail your topic though :unsure: , a look at the cell patterns 'elsewhere' as such ;) The following is a quickly 'stitched together pic' left to right Amstrad CPC / Acorn BBC Micro / Commodore C64 The other variants (Dragon/MSX/CBM+4/Electron etc etc) are quite similar really. Things to note: 1. These pics are all from JSW1 not 2. I did quickly test JSW2 on the CPC and BBC however saw that as not needed so stopped there. 2. All these variants permit a 'top exit' and they all go to Quirkafleeg, with varying results: 3. The BBC and CBM versions behave as the Spectrum version does, aka an IDS as Willy 'appears' on the spiked fire cells at the bottom of the screen 4. The CPC version is slightly different and he loses a life but returns safely to Dr Jones, the reason being the CPC JSW1 version has the 'safe restart from last' feature, this is the same as JSW2 on the Spectrum, it is different in operation to JSWED's 'safe start' however. If you think of JSW2 on the Spectrum, you'll know exactly how it works on the CPC machine for JSW1 as well.

It does (to me) look better with the changes. :) As an aside I'm still unsure on a 'best fix' for preventing a top exit, apart from either changing a cell to fire to prevent an accidental jump or setting the up exit to be the same screen :unsure:

Hi Bob, welcome. :) I saw your topic on WOS asking the same but did not really have an answer, thinking about it a bit the only immediate suggestion would be to possibly ask the people over at RetroSpec where his JSW and MM remakes are listed ? A few members here are also on the jswmm Yahoo mailing list and although IDK if Andy is on that list I'm sure they won't mind asking there for you if you're not on the listing yourself (I'm not hence posting this)

Its quite easy to remove the 'item in question' from the tap/tzx file leaving the 'permitted/allowed' ones present obviously. :) Partly for the two reasons I mentioned above it sort of why it is possibly worth having them available (allows parts only) but this does destroy the originality of it I know, but if this means a 'fixed version' is available... I suppose another way of doing this without ruining anything would be something like this: 1. Game one (denied) 2. Game two (available) 3. Game three (available) 4. Game four (denied) 5. Game five (denied) Now, this compilation will never be available 'as is' as its contents forbid it. However a solution could be quite simple: The 'allowed' titles, strip these out into their own individual tape files aka "game two.tap" , "game three.tap" and then put these two into the listings for the games 'own individual listing' as a 're-release' as that is in effect what it is. Would a practical and relevant example help to explain this ? :) I think it would. I won't put the links up but anyway JSW1 the re-release on the "Sold A Million" tapes, both of these compilations are not available as they contain denied titles, there's actually two versions / releases of this 'first' compilation too, just to complicate matters but it does not really help to explain as the difference between them is simply both have a denied title present. Both versions of this compilation contain the Speedlock variant of JSW, this is not on the main JSW listing page as a re-release, potentially preventing it being used as its not (AFAIK) listed anywhere else.

Merely interested in any thoughts... A poll is attached and it is anonymous. Various compilations have a 'denied' status due to their content, where the entire or near entire content is built from denied games well that's fair enough. Although from a personal standpoint I am slightly curious by some things being in this state these days, that is a completely different matter and up to the author(s) concerned if they wish to release or not their titles. :) The question or concern (depending on how you want to view it) is about preservation and originality. Let us take two examples to work with as that will easily explain this all. For 'available' I refer to it being downloadable on its own individual page where it was originally a 'stand alone' release. "Games compilation one" 1. Game one (available) 2. Game two (available) 3. Game three (denied) 4. Game four (available) 5.Game five (available) 6. Game six (available) 7. Game seven (denied) 8. Game eight (available) "Games compilation two" 1. Game one (denied) 2. Game two (denied) 3. Game three (available) 4. Game four (denied) 5. Game five (denied) The compilations are not available because they contain a denied titles. I have purposely not included 'real' examples although I could do if required. There are several schools of thought on this however: In order to ensure the files that are available are original and unmodified, the tape file is denied due to its content. This does make perfectly logical sense until you consider the small fact that the 'available' titles inside a denied compilation might be quite different to their 'stand alone' variants. By this I mean: 1. They might contain a completely different type of loader, something that would interest the 'tape loading fans' 2. They might well have bug fixes such as +2A-B / +3A-B compatibility added. Using the examples above, there seems not a mass need to make available the little content on "Games compilation two" unless it really did have something special in the available title, however for "Games compilation one" to my mind at least it would make sense to make this available minus the denied titles. All the above is just my own thoughts, I'm not trying to get anyone anywhere to change their policies. :)

Fixed. :) Thank you. I was looking at the content not the title.

Most welcome. :) Typo ? :unsure:

That is an excellent suggestion. :) I was aware of what it would do but before I saw it "in action" I was not really aware of how much it does improve it. For those who prefer it in decimal it is 62121 , 14 Here is an expanded 'combi' pic of before / after so you can see the Water cells clearly to compare: Out of curiosity I took a quick look at the C64, Amstrad and BBC versions of this screen in JSW1 and all of those also have the same Water cell 'paper' colour as the background which matches this 'new change' :) I was not able to confirm the MSX/Einstein variant however given its cell design I suspect that will have black paper due to the way it was 'built' from the Spectrum version at least as I understand it.

Well it is an editor I guess. :) Game Maker information can be found here Here are the relevant Blog entries pertaining to Manic Miner: Part One , Two , Three , Four , Five

Initially I planned on two topics for this: One called "The final barrier through the ages" or similar and another one for the Central Cavern, after a little thought a single topic seemed a bit better. Anyway here are some comparison screenshots of both the Central Cavern and The Final Barrier from various platforms. :) I do realise I have not covered all platforms here however there are some genuine reasons for this plus these are the relatively popular versions. It is quite interesting to see the differences between them when they are directly placed next to each other. The actual game-playing image sizes do vary quite a bit so I have set them to be (within sensible proportions) similar, but not exactly the same resolutions as that would spoil the comparison effect. The images displayed are in the following order: Amstrad CPC , ZX Spectrum , Oric Atmos , Commodore C16/+4 , BBC Micro , Einstein/MSX , Dragon 32 , Commodore 64 , IBM PC. Central Cavern: Final Barrier:

I never read it that way. :D Not sure on the #10h vs #0A fingers business. ;) I do sort of use it occasionally for some values, for instance C9 = 201 = RET and FF = 255 those have been etched into my mind for many years. I think though if my 'start' was on the BBC or similar machine then I would of used it more frequently, one thing I have just thought of too is there's no inbuilt hex tool in ZX Basic either, that may also explain things maybe :unsure: , mind you there's no ELSE either something I never really was concerned about until I used other dialects of Basic then realised how much use it is, I still sort of half write things then realise I have to change them accommodate this awol function.

Regarding the 'loader space' , there are quite a few things you can do to save a few bytes, and these *do* add up quite well. Let me provide some random examples, there are more but these may help, read them as 'before vs after' PRINT AT 0,0 ; ... PRINT AT NOT PI, NOT PI; LET A = 0 ... LET A = NOT PI LET A = 1 ... LET A = SGN PI CLEAR 28000 ... CLEAR VAL "28000" ...or... CLEAR 28E3 POKE 23659,2 ... POKE VAL "23659" , VAL "2" FOR X = 0 TO 64 : PRINT " TEST " : NEXT X ... FOR X = NOT PI TO VAL "64" : PRINT " TEST " : NEXT X GOTO 50 ... GOTO VAL "50" ...or... GOTO CODE "2" (use CHR$ value to figure this out, CHR$50 = Ascii "2") , obviously only works with some values but it can be a bit of a saver sometimes. Variables seem a fraction faster in upper case, although I've yet to figure out why. There are also some good ways of saving having to type border/paper/ink/bright/over/inverse/flash if you want to simply set the screen colours, it can be done in one or two pokes. EDIT... Added a splash of colour. I'm happy to check out any bit of Basic (or part of) if you wanted me to suggest any 'space saving' , can always PM it or perhaps just copy/paste it rather than attach a tape file, either here or a PM if you only wanted a 'partial' thing. Obviously you lose readability the more you do this and it can be annoying to try to debug issues too, but it does save quite a bit of space potentially. Try saving a tiny bit of Basic (then see how big it is) then save it again once you've 'adjusted' it. CLEAR recommended before save too.

Its not something I can easily get my head around despite trying. I do keep a few 'well used' values in memory obviously :D Can only guess its because I started my computing life on the Spectrum as such although I was also later using BBC and then Amstrad, both of which (the former especially) prefer hex aka CALL &xx Talking of emulators, Zero supports "poke memory" via hex if you remember to prefix them with a $ sign aka $C9 for "201" etc etc. I don't think Spectaculator does (not that I can see at least) although its debugger *always* defaults to hex upon entry. I don't have Fuse installed so I cannot recall how that behaves.