VOGONS

Common searches


Jill of the Jungle Sound Effects

Topic actions

Reply 80 of 140, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

I never noticed that the lava was supposed to be animated, having used v1.2d as a reference before.

It's definitely something in the original v1.2d executables. I have a distribution that has both v1.2b (as JJFILE1.EXE) and v1.2d (as JJFILE01.EXE) in the same directory. JJFILE1 (v1.2b) has animated lava, JJFILE01 (v1.2d) has not. That version is even more broken than I previously thought. If v1.2b and v1.2c did not have that hideous timer-driven sample playback routine, I would consider making a patch to downgrade from 1.2d to 1.2c.

Oh well, another issue to investigate....

Reply 81 of 140, by K1n9_Duk3

User metadata
Rank Member
Rank
Member

I'll save you some time and tell you what caused the issue:

For some odd reason, the compiler that was used to build version 1.2d did something wierd. Basically, the original code used to be

setboard(x, y, bd[x][y] | ((msg_block(x, y, msg_update)!=0)*mod_screen))

and the compiler decided it was a good idea to read the value from bd[x][y] before calling msg_block(), which updates the value at bd[x][y] with the next frame of the tile's animation cycle. So the tile number is reset to its previous value immediately after it was updated and you never see the animation.

The code in question was "updbkgnd()" in "JMAN.C" (starting at seg022:120F when I open the executable in IDA Freeware 5.0).

I recommend replacing the code with something resembling this:

if (msg_block(x, y, msg_update))
setboard(x, y, bd[x][y] | mod_screen)

I used the names from the Xargon source code and the debugging information from the Jill executable itself. If you don't want to look up the values for msg_update and mod_screen yourself, here you go:

msg_update = 2
mod_screen = 0xC000

There were some other issues in v1.2d that prevented the screen from updating when some tiles were changed by a trigger or a switch. I don't know if you already fixed that. The issue is caused by calling the setboard() function without the "| mod_screen" part. I think the call at seg015:2715 is responsible for this, but it might be hard to add the "| mod_screen" there just by hacking the executable.

Reply 82 of 140, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

Thank-you. That should help a lot.

K1n9_Duk3 wrote:

and the compiler decided it was a good idea to read the value from bd[x][y] before calling msg_block()

As I understand the C standard, the order of evaluation in this case is undefined, so the programmer was wrong to assume a particular order.

K1n9_Duk3 wrote:

and the debugging information from the Jill executable itself

Did you get IDA FW 5.0 to make use of that debugging information?

Reply 83 of 140, by K1n9_Duk3

User metadata
Rank Member
Rank
Member

No, I did not manage to get IDA itself to use the debugging information. I have written a tool that extracts C-style strings from binary files (basically just replacing any 0 bytes with line breaks) and used the resulting text file and the Xargon source code to assign the names of functions and variables in IDA. I should also mention that I used an older freeware version of IDA for the initial analysis of the executable, since that version can detect compiler signatures and will assign the correct names to the runtime library functions.

The Xargon source code does not contain the source files for all parts of the game, though. Some files are only included as .OBJ files in Xargon, like the low-level graphics code in GRL.OBJ and GRASM.OBJ. Opening these in IDA will make use of the names stored in the .OBJ file, but I guess you already know that.

Reply 84 of 140, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie
K1n9_Duk3 wrote:

The issue is caused by calling the setboard() function without the "| mod_screen" part

But how could that part have disappeared when recompiling the game?

I think I have fixed the lava animation and switch-flipping screen update issue in all three executables at the locations that K1n9_Duk3 mentioned, and from what I can tell, they seem to work correctly now. But have not had the time to play through the games again. I am posting this as a "-TEST" patch until someone who has tested it more extensively tells me that I can replace the main patch with it. Install JILLUPD-TEST instead of JILLUPD on an unpatched game distribution, and apply EPICFM on top of it if you wish.

Edit: Patch updated in the latest post.

Last edited by NewRisingSun on 2017-05-21, 06:47. Edited 1 time in total.

Reply 85 of 140, by K1n9_Duk3

User metadata
Rank Member
Rank
Member
NewRisingSun wrote:
K1n9_Duk3 wrote:

The issue is caused by calling the setboard() function without the "| mod_screen" part

But how could that part have disappeared when recompiling the game?

In the Xargon source code, there is a macro definition for setboard():

#define setboard(x,y,n) bd[x][y]=n|mod_screen;

My guess is they replaced the macro with an actual function in v1.2d (the setboard() function checks if x and y are in range, to avoid memory corruption). The older versions probably used this macro since I cannot find a setboard() function in them.

Reply 86 of 140, by SaxxonPike

User metadata
Rank Member
Rank
Member
NewRisingSun wrote:
K1n9_Duk3 wrote:

The issue is caused by calling the setboard() function without the "| mod_screen" part

But how could that part have disappeared when recompiling the game?

I think I have fixed the lava animation and switch-flipping screen update issue in all three executables at the locations that K1n9_Duk3 mentioned, and from what I can tell, they seem to work correctly now. But have not had the time to play through the games again. I am posting this as a "-TEST" patch until someone who has tested it more extensively tells me that I can replace the main patch with it. Install JILLUPD-TEST instead of JILLUPD on an unpatched game distribution, and apply EPICFM on top of it if you wish.

Thank you both so much for your work on this bug. I'll play through them and let you know. It's especially good if this also fixes the issue where using switches for platforms that are within the viewport don't update on screen. The two problems likely have the same cause in the D release of the game. Time to confirm 😀

Sound device guides:
Sound Blaster
Aztech
OPL3-SA

Reply 87 of 140, by James-F

User metadata
Rank Oldbie
Rank
Oldbie

I have tested ver C and there are no bugs with Water/Lava/Switches.
But ver D (episode 1 shareware) has all three animation problems.

I don't have 1.2D trilogy, so I can only attest for 1.2C trilogy.


my important / useful posts are here

Reply 88 of 140, by SaxxonPike

User metadata
Rank Member
Rank
Member

I'm happy to report everything is working great with the latest patch, animations and all.

Sound device guides:
Sound Blaster
Aztech
OPL3-SA

Reply 90 of 140, by SaxxonPike

User metadata
Rank Member
Rank
Member

This version of the game, whichever it is, allows Jill to kill demons in one hit. Wonder if this was the intended behavior?

https://www.youtube.com/watch?v=dJZaSy3hwvk

I know in 1.2d they are SUPER difficult.

Sound device guides:
Sound Blaster
Aztech
OPL3-SA

Reply 91 of 140, by K1n9_Duk3

User metadata
Rank Member
Rank
Member

Probably a hacked version of the game as far as I can tell.

What I can say for sure is that the demon code in version 1.0 of JILL1.EXE differs slightly from the code in v1.2d. In v1.0, any weapon can hurt the demons, not just the spinblade. Also, since the executable is uncompressed and contains debugging information, it's easy to find the code for the demons and modify the amount of hits a demon can take before it dies. Since the demon has 5 hit points and 4 frames of invulerability between hits in both the earliest and the latest version of JILL1.EXE, I doubt that it would be any different in other versions.

Correction: Nope, it's not hacked, just the normal behavior in v1.0 that I didn't notice at the time I wrote this.

Last edited by K1n9_Duk3 on 2018-11-11, 22:53. Edited 1 time in total.

Reply 92 of 140, by SaxxonPike

User metadata
Rank Member
Rank
Member

The one hit kill demon thing happens in whatever version of the game they're using:
http://tasvideos.org/5779S.html

Filesizes and hashes are listed here and they touch on it in the section where they cover Level 9. I'm really curious what exactly is going on here...

Edit: The demo in Level 9 in Jill 2 also makes more sense with demons taking one hit. I don't have a legitimate 1.0 to verify (only original I have is 1.2c from the B&N release which has the difficult demons)

Sound device guides:
Sound Blaster
Aztech
OPL3-SA

Reply 93 of 140, by K1n9_Duk3

User metadata
Rank Member
Rank
Member

After seeing the file size of JILL2.EXE on the page you linked to, I had to compare it to the known versions on the ModdingWiki: http://www.shikadi.net/moddingwiki/Jill_of_the_Jungle

Whatever version was used in the speedrun is definitely not listed on the ModdingWiki page. And as you can see, I was wrong about the executable being uncompressed, at least in the case of the earliest versions of Jill 2. I still think it's a hacked version or perhaps even a beta version, which would explain the weird demo you mentioned. But it could also be possible that the original release of Jill 2 had demon code that differed from the code in Jill 1, and that the modified code was accidently removed when they updated the code for the later versions. Given the animated tile issues that appeared in v1.2d, this wouldn't surprise me at all.

Without access to the JILL2.EXE from version 1.0, there's not much else I can say about this.

Reply 94 of 140, by SaxxonPike

User metadata
Rank Member
Rank
Member

For those of you who have waited for a legal online distributed version of this game, it looks like GOG has just released the whole trilogy for free today:

https://www.gog.com/game/jill_of_the_ju ... te_trilogy

It looks like the game versions are (based on CRCs):
Volume 1 - v1.0
Volume 2 - v1.0 (but they didn't compress it with LZEXE this time)
Volume 3 - v1.2b

Sound device guides:
Sound Blaster
Aztech
OPL3-SA

Reply 95 of 140, by K1n9_Duk3

User metadata
Rank Member
Rank
Member

Yeah, I already had a quick look at JILL2.EXE from the GOG release since the demon can be killed with one hit in that version. The demon code is identical to the code I saw in v1.0 of JILL1.EXE, meaning that it actually needs to take more than 5 points of damage before it dies. I honestly had no idea why it's possible to kill the demons with one hit in this release. I even wrote a program to check of the demon objects are basically pre-damaged in the level files and found out that that's not the case.

But as I was typing this, I had a look at the code for the spinblade weapon. The spindblade is coded to instantly kill any object that has the 0x400 flag set. And sure enough, the demon has the flags 0x400 and 0x80 defined in version 1.0. So even though the demon code expects the demon to be hit 6 times to kill it, the code of the spinblade weapon bypasses that check. In version 1.2(d), the demon has absolutely no flags set, which explains why it takes 6 hits to kill in the later releases. Mystery solved.

Reply 96 of 140, by badmojo

User metadata
Rank l33t
Rank
l33t
SaxxonPike wrote:

For those of you who have waited for a legal online distributed version of this game, it looks like GOG has just released the whole trilogy for free today

Thanks for posting this, I was looking for a legal version a while back and had no luck so am very happy to have picked it up for free!

If it's broke, then fix it!

Reply 98 of 140, by SaxxonPike

User metadata
Rank Member
Rank
Member
K1n9_Duk3 wrote:

Yeah, I already had a quick look at JILL2.EXE from the GOG release since the demon can be killed with one hit in that version. The demon code is identical to the code I saw in v1.0 of JILL1.EXE, meaning that it actually needs to take more than 5 points of damage before it dies. I honestly had no idea why it's possible to kill the demons with one hit in this release. I even wrote a program to check of the demon objects are basically pre-damaged in the level files and found out that that's not the case.

But as I was typing this, I had a look at the code for the spinblade weapon. The spindblade is coded to instantly kill any object that has the 0x400 flag set. And sure enough, the demon has the flags 0x400 and 0x80 defined in version 1.0. So even though the demon code expects the demon to be hit 6 times to kill it, the code of the spinblade weapon bypasses that check. In version 1.2(d), the demon has absolutely no flags set, which explains why it takes 6 hits to kill in the later releases. Mystery solved.

Fascinating! Thank you for investigating this.

I'm really curious what the original intent was. I wonder if we'll ever get to know. I would love to believe that the 1.0 release was the original intent and careless bugfixes just happened to break the demon functionality. But for all I know, instantly killable demons was a bug itself.

EDIT: I asked Tim on Twitter (@TimSweeneyEpic):
https://twitter.com/TimSweeneyEpic/status/106 … 597339625185280

"I don’t remember the balancing tradeoffs, but they arose because I finished tuning episodes 2 and 3 after episode 1 was released."

Sound device guides:
Sound Blaster
Aztech
OPL3-SA

Reply 99 of 140, by NewRisingSun

User metadata
Rank Oldbie
Rank
Oldbie

My interpretation of this statement is that the spinblade should in fact kill demons instantly in Episode 1, but not in Episodes 2 or 3. It is not unheard of in gaming that the same enemies become harder and more powerful as the game progresses.