jetsetdanny

Well done, everyone involved! :)

I'm not sure I understand the question. By "the 128k conversion tool" do you mean using JSWED to upgrade from the JSW48 game engine to the JSW128 game engine? I think there may be some issues there, but it would be hard to discuss them in general terms. Have you run into any particular problems?

Guys, I believe I have just come across a ridiculously easy solution to JSWED 2.3.7 freezing after being launched on W10 (after the Creators Update). It works for me, at least! What you need to do, after launching the program, is to 'grab' the upper part of JSWED's window (the white stripe) with your mouse and move the program's window a little bit. It then starts responding! :D I would be interested to know if it's helped, if anyone else has stumbled upon the same problem.

That's a remarkable achievement, MetalMickey! I've always done what I think is advertised as the best solution, i.e. clean install.

OK, yes, you're right, I failed to spot those. I didn't really look at the content of the tables, so when I saw some "BGB" entries printed on the side of the tables, I assumed this was how the program was showing it had come across a problem ;) .

As for the MM analysis - yes, later on at some point.

I'm not sure if "spotted" is the right word here, but yes, when I said "If I understand the output correctly, SPECSAISIE shows the Cell Graphics Bug (=Block Graphics Bug) occurs in rooms 16, 31, 33, 41, 47, 51, 52, 62 and 63", I was only referring to the rooms where SPECSAISIE prints the initials 'BGB'. I could see there were others bits of information in some rooms which seemed abnormal (in relation to other rooms), but I didn't try to analyse them. But you've done a thorough job of it :).

Yes, but SPECSAISIE's BGB_JSW stil analyses them.

OK, I've done it for you since you've asked about it, Ian :). Attached below are screenshots of results of running the BGB-JSW function in SPECSAISIE on a basically unmodified JSW file (it's got things like the colour code bypassed, but I believe no editing was done regarding graphics). If I understand the output correctly, SPECSAISIE shows the Cell Graphics Bug (=Block Graphics Bug) occurs in rooms 16, 31, 33, 41, 47, 51, 52, 62 and 63. This partly contradicts the common knowledge about the problem, I think, both in omitting some of the rooms where the bug occurs and by pointing to others where (possibly) it does not occur (unless these are instances of its occurring in unused cell types).

Thanks for your explanation, Ian. The reference would indeed have been lost on me without it :lol: . No, I haven't tried out that SPECSAISIE function.

OK, I've checked it and it turns out I was right :D . As mentioned in Andrew Broad's description of his SPECSAISIE 1.2 (SPECSAISIE 1.3 Beta 5 was also made available to the members of the MM & JSW Yahoo! Group), it has the following function: BGB_JSW: Detect occurrences of the block-graphics bug in a JSW game (an experimental implementation) [Later on Andrew started using the term "Cell-Graphics Bug" instead.] Apparently, this functionality has been there since SPECSAISIE v. 1.0. Furthermore, John Elliott once wondered about incorporating this functionality into JSWED (but has not applied it so far, TTBOMK - something for the future, perhaps?).

I don't recall any discussion about it, ever, but, as mentioned before, I am interested in creating new games more than the details of the original. So I may have missed something. It's quite possible, though, that you are the first person to ever bring this up. Which makes me think: is there an automatic tool to list all the occurences of the Cell Graphis Bug in a game? I am wondering if SPECSAISIE doesn't have such a function? I seem to recall something like this vaguely, but it may just be an illusion...

Quirkophobes would, though! :lol:

Well done! :) It's interesting to follow this discussion, even though I am only a passive observer.

I have no problem with JSWED 2.3.7 on a computer with W7, fortunately :).

Great stuff, Norman Sword, thank you! :)

So that would save another byte, wouldn't it?

Now, this is not really a suggestion, it's a bug report, but I thought it might not be worth starting a new thread, especially one suggesting that JSWED doesn't work perfectly. After Windows 10 automatic update earlier this week (I think it was at the beginning of this week, or last weekend perhaps, so around the end of October 2017), JSWED 2.3.7 installled on my computer using Windows 10 stopped working. It launches so that its initial screen can be seen, but when I try to load a game it turns out to be frozen, it doesn't respond at all. I can't close it using its own X sign either. However, it can be closed down without any hassle using the Task Manager. That Windows 10 update was a big one, the computer had to shut down and restart several times before it was over. Interestingly, JSWED 2.2.9 installed on the same computer works just fine. But I've grown used to JSWED 2.3.7 so much by now that going back to 2.2.9 does not seem to be a viable option. Both v. 2.2.9 and v. 2.3.7 had been installed on this computer before the Windows 10 update in question. They had co-existed happily (or, at least, peacefully) before. Now only 2.2.9 works. I tried reinstalling the 2.3.7 version (without de-installing it first), but to no avail. I mean, it gets installed, but still doesn't work after I launch it. I have yet to try de-installing it first, and then re-installing, but somehow I have little hope this will help. Perhaps John Elliott could help out, though? Any assistance with having JSWED 2.3.7 work properly with Windows 10 after this recent update would be much appreciated :). Has anyone else had the same problem?

Yes, it's a really good one, Norman Sword, thank you! Now you will be really impressed by this :lol: : When creating the Sprite Selection Screen in "Jet Set Mixup", Ian set the attributes for the various numbers which are printed on the screen using a sequence of LD HL,&0000 - LD (&0000),HL instructions. So you have e.g. 21 41 41 22 a4 58, to set some attributes to BRIGHT blue. He went through most (or almost all) colours like this. Now, when working on a similar selection screen related to a project which is discussed elsewhere, I introduced the following optimisation: I grouped the colours, I introduced the first one (say, non-BRIGHT red, i.e. 02) using the same instruction, so 21 02 02 41 a4 58, and then I introduced the following colours using INC H and INC L instructions (24 2C), thus saving one byte with the definition of each new colour, with the exception of when I had to "jump" from the last non-BRIGHT colour to the first BRIGHT one, which had to be done using the LD HL,&0000 instruction once again. The total net saving was of 8 bytes, I believe. Not too impressive, but if it should happen that you just need one or two (or five) spare bytes in the vicinity, it could come in quite handy.

My quick take on it would be: if a site wants to respect the available/denied rules, it should not make available for download any "denied" titles. So even if one title within a compilation is denied, the whole compilation should not be available for download. However, for the sake of making available the titles which are not denied, my suggestion would be, if possible technically, to strip the compilation of the "denied" titles and leave only the "non-denied" ones within the file. I know this will be a modified file, but personally I don't care. My interest would be to be able to see / play the "non-denied" titles, not to see an unchanged tape. If such a modification of the compilation were not possible, my second suggestion would be to make available for download only the "non-denied" titles (especially the ones which may be of interest to the members of/ visitors to this forum), by extracting them out of the compilation. Should this be impossible to do, technically, I don't know - I suppose the users would have to look for these compilations elsewhere...

"comparsion" instead of "comparison" ^_^

It's an interesting comparison, Andy, thanks for putting it together :). There's a typo in the topic, you might want to correct it.

Absolutely!

Apparently this happens because frames 1 and 3 of the rightward animation are always used, and in the case of Willy they are exactly the same as far as graphics go (only moved within the 16-per-16-pixels sprite space), while in the case of the flying pig they are visibly different (wings up - wings down). So I guess you're right that Willy's running ability could be improved, although I couldn't suggest an exact solution at this moment.

Good stuff, Ian! Congratulations on creating this solution :) .