The Ian Burton Adventure: It's back!

[KeenRush]

No way to know. A wrongly made patch could accidentally go around the code, causing problems like disturbing the tile data in memory, and so on, without crashing the game (or at least not instantly). So yeah, I think it'd be best to go through the patches patch by patch. Do you have that many of them, anyways?

[Zero X. Diamond]

Not really, no, but the ones that I do have are pretty well important. I couldn't really drop most of them, so I... I dunno, I'd have to get them rewritten or something. I don't know how there'd be mistakes in most of them, seeing as it's mostly all copy and pasting directly from the sources (as I suck at patching).

I'll go over it tomorrow.

[KeenRush]

Alright, till tomorrow... And I didn't mean you have patched something wrong, but that the original patches have something wrong in them... We'll hopefully find out soon.

[VikingBoyBilly]

Zero X., I gotta say, I like your hair style

[Shadow Master]

I wonder if it's his RL hair style as well.

[Zero X. Diamond]

Well, it was at the time... I haven't had a haircut in two years, so it's now too long to style beyond "in my face" or "not in my face," but I want to get a haircut soon and I'll certainly be heading back to the good ol' pomp.

That having been said, still having trouble locating what patch is causing this crap. Thankfully it's not the multiple item/door backgrounds patch, which I'd hate to have to drop, but unfortunately I've still yet to locate it. Still a number more patches to check through. I'm pulling an all nighter, so hopefully I'll find the time between now and class tomorrow to figure it out.

[Zero X. Diamond]

Of all the patches it could be, I did not expect the hashing to be caused by this one:

Code: Select all

#Don't show Press F1 for help sprite 
%patch $97C9 $90

Uh... what? Is there something wrong with this?

EDIT: Yeah, wow. Confirmed with original copy of the game, the one hashing over tiles and not the Game Over graphics. Commenting out this patch fixes the hashing. Can anybody explain why this might be?

[Herry Jerry]

There was actually something about it in this topic - according to SM, inserting a NOP instruction can screw things up. (Like, if you say "don't do anything at the code to show the bitmap", chances are the bitmap's referenced at other places.)

[StupidBunny]

On the subject of ugly errors...

I am currently making a mod which is working all nicely for the most part. But I'm getting that ugly waterfall effect on the opening screen. The bitmap I have replacing the Apogee logo is leaving that wierd stuff as it scrolls up, which I really don't want. Does anybody know what causes this? Because I've never made it happen before.

[ckguy]

On the subject of ugly errors...

I am currently making a mod which is working all nicely for the most part. But I'm getting that ugly waterfall effect on the opening screen. The bitmap I have replacing the Apogee logo is leaving that wierd stuff as it scrolls up, which I really don't want. Does anybody know what causes this? Because I've never made it happen before.

It could have something to do with whether you're using the last row of the 'APOGEE' image or not, or if it is black like the background of that screen. (...this is really worded not so well, and I don't really feel like making it more readable... )

[Herry Jerry]

stuff

I believe that has something to do with the way the bitmap is refreshed - I'm pretty sure it just paints the bitmap again, but up a couple of pixels, so the other bitmaps never really disappear. Try putting the whole logo thing into the *top* of the bitmap, leaving blank space below.

(in other words, don't use the last 3-5 rows in the bitmap)

[KeenRush]

Of all the patches it could be, I did not expect the hashing to be caused by this one:

Code: Select all

#Don't show Press F1 for help sprite 
%patch $97C9 $90

Uh... what? Is there something wrong with this?

EDIT: Yeah, wow. Confirmed with original copy of the game, the one hashing over tiles and not the Game Over graphics. Commenting out this patch fixes the hashing. Can anybody explain why this might be?

This patch changes the x coordinate of the sprite/picture in question. This moves it out of screen. And probably something drawing routine or something doesn't check if the position is "legal", and thus draws the sign's pixels over some other data, which in this case happens to be some tileset data. So, this patch doesn't use NOP instruction anywhere, only that particular value (0x90) as a new value for the x coordinate (or actually only the second byte of the value, but that's irrelevant now). Easiest way to get rid of this problem with no need for patching would be to make that help sign size of 8x8, and change its graphics to the 8x8 piece that is on the title screen on the same coordinates.

And cool, great news that the problem has been found! Woohooo!

[StupidBunny]

It worked!!! Thanks all.

Good to know that you've got the ugliness all worked out with your patching! I'm eager to see the finished product.

[KeenRush]

Indeed, it'll be irresistible! Hope we can see it in few months.

[Zero X. Diamond]

With any luck, I will be releasing a tech demo by either the end of this month or the next. As suggested in the last thread on the old forums, it will be an interior level. It may or may not be a level that makes it to the final version.