jetsetdanny

Ian, I will make a note of this inadvertent discovery and will try to remember to place such a guardian in some future game project :). However, for the current one (the nature of which will be revealed soon, I know this assertion is probably becoming boring at this point ;) ), the only thing that is important is that the flashing/flickering be as close to the one in JSW128 game engine as possible. The flickering in the JSW128 game engine is regular, there are no changes to it. It happens in the same way all the time, at least that's the impression I have without really analysing it frame by frame. Therefore, a solution that is more regular is closer to what happens in JSW128 than a solution which has more irregularities in the flashing cycle, no matter how attractive, quirky or inventive that other solution may be. And whichever solution is closer to JSW128 has to be chosen for this project. Nevertheless, as I said at the beginning, there will be future opportunities to apply this discovery, hopefully :) .

My replies are in green below:

Thanks for your involvement in this subject, Ian! :) Let's get this question out of the way first: No, it's beyond my scope of interest. I am only interested in being able to insert into my current project a guardian that will flash satisfactorily. Now as a preamble: Thanks. This test file, however, has nothing to do with the project I am working on, it's just a file I created to present the guardian issue outside of the proper project. When I read you saw it cycling through fours colour for most of the time, I thought you were wrong. Then I looked at it and I could see you were right. However, when I looked at the guardian in my proper project, with the values ef 03 00 d0 00 9e d0 7e inserted, I could still see it was, after a short while, flashing in white, cyan and blue only. Definitely no magenta. I thought I was going crazy. I couldn't understand how it was possible, as I saw no difference between the two files in the guardian definition. Why would the same guardian behave differently in two JSW48 files? Then I realised that the guardian in my proper project was using a sprite from page 9f, not 9e. This was adjusted, so its definition was really ef 03 00 d0 00 9f d0 7e. I checked and yes - it makes a difference! Please find attached a file in which the guardian's sprite page has been changed to 9f. Look at the guardian, please. After a few cycles involving magenta, where the flickering seems slower, the guardian starts flashing faster, in white, cyan and blue only. No magenta whatsoever and it's not coming back at any time AFAICT. And please don't tell me you see magenta there, or I'll really go crazy! ;) Here's the file: MC sprite page 9f - 3 colours only!.tap Now, I was really glad about this, because I thought I would swap the sprites around in my proper project and put the flashing one at 9e instead of 9f and I'll have it flashing in four colours. However, I tried it without swapping the sprites (just using the sprite which already sits at 9e), and it doesn't seem to work, I don't see magenta there after the initial few cycles. Weird, weird, weird... :unsure:

The guardian doesn't change animation frames. #FD or #FF are perhaps marginally better, because they seem to make the four-colour flash last longer after entering the room. However, then the guardian reverts to flashing in three colours anyway. The challenge would be to keep it flashing in four colours. It wouldn't actually matter so much if it reversed the cycle or not, flashing in four colours would be better than flashing in three (which is already an improvement over flashing in just two).

Thanks for all your comments, Ian! :thumbsup: They are very helpful in understanding the situation. Taking into account the limitations of the game engine - i.e. the fact that in JSW48 I will not be able to create a guardian flickering exactly like the ones in JSW128, what would be as good as it gets for me is as follows: A guardian at the bottom of the screen (vertical position 208) flashing through a constant cycle of white-cyan-magenta-blue in any order, without reversing the cycle and without any interruptions or changes of the cycle. After much trial and error (mostly error! :lol:) I haven't been able to achieve that yet. The closest I have come to it - or rather, the closest of many close ones which I intuitively like the best (without analysing the way they all flicker in detail) is the guardian found in the attached file "MC guardian - quite good.tap". It has the following definition: ef 03 00 d0 00 9e d0 7e It still isn't perfect - after including magenta in the first couple of flashes, it then flashes in three colours only - white, cyan and blue and it has some irregularities in the way it flashes, sometimes it seems to be flashing more quickly than at other times - but it's probably good enough for the purposes of my current project (the exact nature of which will be revealed soon) if I'm not able to create a guardian which would flash with 4 colours in a totally regular way. Three colours are better than two, that's certain ;). If anyone were able to create a better guardian (flashing through four colours rather than 3, but excluding black - or at least flashing through the three "current" colours but in a perfectly regular way) - I would be happy to use it with all due credit given :). MC guardian - quite good.tap

The colour-changing barrels half way up the West Wall in 'Jet Set Mini' have the following definition: ef fe 00 c0 02 9c 9c 7e They seem to be flashing in the following colours: black, red, green, yellow, BRIGHT red, BRIGHT green and BRIGHT yellow, although I can't establish the exact cycle right now. I will have to experiment, then, since what I'm trying to obtain is something as similar to what JSW128 does - i.e. the cycle of red, magenta, green, cyan and yellow - as possible.

Changing the guardian's colour to red (02) makes it flash in red and yellow. Still only two colours, while I'm looking for five, like in JSW128. The guardian's full definition in this case: 07 02 00 d0 00 9e d0 d0

I am writing this as I'm experimenting with the last (eighth) byte of the guardian's definition: value 00 - first cycles through blue, magenta, cyan and white various times, then flickers irregularly a couple of times and then starts flickering in magenta and white only! value 01 - can't be set in JSWED's GUI. When you set it manually in JSWED's GUI, it reverts to 00. value 02 - flashes in white and magenta only value 03 - can't be set in JSWED's GUI. When you set it manually in JSWED's GUI, it reverts to 02. value 04 - flashes in white and magenta only value 05 - can't be set in JSWED's GUI. When you set it manually in JSWED's GUI, it reverts to 05. value 06 - value 04 - flashes in white and magenta only value 07 (skipping, I'm sure it would revert to 06) value 08 - flashes in white and magenta only value 0a - flashes in white and magenta only value 80 - flashes in white and magenta only I don't think any higher values would yield any different results, especially that the original value #D0 is a multiple of four (208 in decimal) and it doesn't do anything else but flicker in white and magenta. Now: value 01 (inserted in JSWED's Hex Editor, not GUI) - first cycles through blue, magenta, cyan and white various times, then flickers irregularly a couple of times and then starts flickering in magenta and white only! - so it has the same behaviour as value 00. So values 00 or 01 would be best for my purposes if they maintained cycling through the four colours - blue, magenta, cyan and white - but they stop after a while and revert to flashing in white and magenta only! Weird, weird, weird... :unsure:

Thanks for your prompt response, Ian! :) My replies to some of your points are in green below:

John Elliott's JSWED's manual states (starting at the bottom of page 22) that "In JSW48, there are four guardian types - horizontal, vertical, arrow and rope. In JSW128 there are ten; the four mentioned earlier, two diagonal types, and ?ashing versions of all except the arrow and the rope." The "flashing" versions are called "multicolour" in JSWED itself, e.g. in JSW128 games when choosing the guardian type you can choose "Vertical multicolour", "Horizontal multicolour", "NW/SE multicolour" and "NE/SW multicolour" (the latter two being diagonal ones, of course). Judging by the description in SkoolKid's disassembly, it looks to me like bits 0-2 in the first byte of the 8-bit-long definition of each guardian class define what type of guardian it is (please correct me if I'm wrong on this). In practical terms, it looks to me that vertical multicolour guardians have #07 in the first byte of their definition (again, please correct me if this is not entirely accurate). Please find attached two experimental files. The first one, "MC guardian 128K.tap", features a stationary (unmoving) multicolour vertical guardian in a JSW128 game file. The second file, "MC guardian 48K.tap", features the same guardian copied to a JSW48 game file. Even though there are no multicolour guardians in the JSW48 game engine, as per the JSWED manual, this guardian is still multicolour, or, to be precise, bicolour. If flickers in white and magenta only, which makes the way it flickers (glints? glitters? glows? shimmers? - I'm not sure what verb is best here) less elegant than in the case of the same guardian in the JSW128K game file: the flickering is much faster and less colourful in JSW48 than in JSW128; it does not look as good. In the JSW128 game file the same guardian flickers in five colours: red, magenta, green, cyan and yellow. Its flickering is much nicer to the eye than in the JSW48 game engine (although I suspect that if white and blue were added to the cycle, it would be even better). The question I have is this: Would it be possible to tweak the JSW48 game engine easily (like changing a couple of bytes or adding a little bit of some additional code, I'm not talking about any serious rewriting of the engine) to make this stationary bicolour guardian multicolour, i.e. to make it flicker at least in the five colours that it flickers in in the JSW128 game engine? I only need it to flicker in a nicer way, I don't need it to move. Any help on this would be appreciated :). MC guardian 48K.tap MC guardian 128K.tap

Thanks for your reply, guys! :)

A project I am currently working on involves an additional options screen, on which the player has to press either "1" or "2". Other than that, it just uses the regular keys any JSW48 game uses. Is it worth creating a ZXK file to map the Vega control buttons to the ZX Spectrum keys used by the game in this case? Your thoughts and suggestions would be appreciated :).

Yes, thank you for sharing it, Norman, and for describing the development history! :thumbsup: In view of your statement: > Version M is version "K" and Version "L" combined. So in essence it supersedes both of the earlier versions. when I next work on JSW Central (which may be a couple of months from now, as I am engrossed in another project right now, albeit JSW-related), I will delete the pages for JSW 128 VK3 and JSW 128 VL5 and create a new page for JSW 128 VM, with references to the other two former versions - unless you would like me to leave the individual pages already in existence and add a new one, which I can also do. Please let me know what your preference is. I look forward to exploring JSW VM! :)

Thanks for uploading it, Norman Sword! :thumbsup: From your earlier comments, I did not have a feeling that JSWVL was a further development of JSWVK in the sense of improving the former; I understood that it was not *better*, but *different*, an alternate take, so to speak. If JSW128VM is the "final" version, does it mean that it supersedes both JSWVL and JSWVK? Or only one of them, perhaps? (if so, which one?) Please kindly elaborate on the classification of your versions, so that we know how to describe them on JSW Central and elsewhere.

I would "like" this message were it not for the last sentence :o

Thank you for your view on this issue, Andrew.

Could you not post as Kari Krisnikova, perhaps? You used to do it in the past... While we're on the subject of the Yahoo! Group, how would you feel about the Group's content being archived on JSW Central? It's a very tentative question, I am not saying I will definitely do it if you approve, because it might be a very time-consuming task to modify the saved messages to be hosted over there (particularly if I wanted to host each message as an individual page), but your approval would certainly make me consider it very seriously :).

Yes, and now that the Yahoo! Group is sadly not online any more, I hope that even more of its members will move over here. Let

Thank you for your kind words, DM! :) It was a great pleasure to analyse and fix the three parts of your Down and Out Trilogy! :) Also to play them and record them for the RZX Archive! :) The SEs will be very welcome when you find the time to prepare them. If you choose the JSW64 game engine for them, you will certainly be able to enhance the games in various interesting ways (such as switches, for example). I posted about the fixed editions here and on the Yahoo! Group - whose content is sadly not online any more, I've just had a look - but not anywhere else. Would you like to announce the fixes on WoS and Spectrum Computing yourself, perhaps? I was thinking about doing this before the end of the year, but it would be even better if you posted about them yourself :).

OK, after further investigation, I am able to answer, in part, my own question. In Norman Sword's file HeadsJSW.tap the code which he describes as "draw_bottom_att", as per: Both of these LDIR routines are replaced with a call to draw_bottom_att which is new code sitting in ram somewhere. starts at # 944F. draw_bottom_att ld de,ATT16 = 11 00 5A ld ix,bottom_att ------------- This "bottom_att" starts at # 966B ld hl,bottom_translate ----------- This "bottom_translate" starts at #965E Furthermore, ; expander sub expand: --------------- This starts at #94D5 ld (S_M_C_translate),hl (....) jr draw_logo_loop ;======================================================================= ; expander sub routine -------------- This starts at # 94EC indexer ld c,a rrca (....)

For example, the code to optimise ropes, which Norman Sword provided here. How can I convert it to actual code?

I would be very interested in being able to apply the above-mentioned savings, or a part of them, to a JSW48 game file. I am particularly interested in the rope compression and logo draw. It would be perfect for me to be able to just copy a chunk of the new code as a binary file into another file. I would make all other necessary adjustments. However, I can't figure out where all that new code is. Is it in the "HeadsJSW.tap" file attached for download to this thread? If so, where does the code responsible for the rope compression and for the logo draw start there? Any help on this would be appreciated :).

Thanks for this info, Andy! :) I have to state for the record, though, that I don't believe that Anthropogenic Global Warning has been proven scientifically, that an increase in the levels of carbon dioxide is so bad and that all renewable sources of energy are good and the right solution for the future. I believe that an official narrative regarding climate change has been enforced worldwide almost like a totalitarian doctrine or religious dogma. This climate (pun intended) does not allow for real, objective, scientific analysis and discussion of the problem any more. Instead of such a discussion, "solutions" are imposed which are partly a huge scam. A recent quote about the solar power generation* I particularly like (the source - you would have to scroll way down to see it, I don't think it's possible to link to individual comments over there): We need to end government subsidies and mandates for a technology that has no use in large scale energy production. We need real solutions, not a bag full of phony solutions that waste money and lower our standard of living. California and other states are now demanding that new homes have solar panels on their roofs. This will drive up the cost of housing and create even more homeless people. Solar panels often wear out quickly, are horribly energy inefficient, and it is likely that most solar panel installations will NEVER produce more energy than was required to manufacture them in China with coal fired power plants. The chemicals required to produce solar panels are highly toxic. The big problem is that incurably inefficient and unreliable "renewable" but not sustainable energy systems have become a fad and part of a new age religion that worships windmills and tells us we will all burn in the hell of global warming unless we do what Al Gore and Leonardo DiCaprio say. We need a revolution against this new religious hierarchy and a return to honest science that demands critical thinking and a continuous dialogue of ideas, not a monologue of hysteria used for partisan political gain. I just needed to say that, because I am dismayed at how far climate alarmists have managed to sway public opinion. Apparently, in a recent poll in my country 71% of respondents pointed to climate change as the biggest threat they see. I am sorry to say this shows there is something seriously wrong with them. It is understandable that people may be afraid of illness - it can touch anyone and there are kinds we still can't cure. They may be afraid of poverty or of economic crises which will affect the quality of their lives. They may be afraid of armed conflicts, or uncontrolled floods of migration bringing crime and other problems. But climate change - in a relatively cold country where a temperature increase of a few degrees Centigrade would be a blessing? It's just crazy :o * This is seemingly off-topic, but not quite - that's a Manic Miner reference :P .

So here they are. The RZX recordings of the Trilogy can be downloaded from the RZX Archive using the following links: Skint Willy Willy the Rogue Still Stealin' There are also links to YouTube videos over there, so you can watch the walkthroughs without actually downloading the RZX files and playing them back in an emulator :) .

I've corrected the typo. The game is called: Still Stealin' aka Fahrenheit 2002