More 1.84 issues: Tiles Not Saving

This is a problem I had with the ORIGINAL example_1st.qst back in 2000 and also with a test quest I made to test another issue:

Apparently the tiles don't read the same as it seems to read the new ZC tileset rather than the one included with the file from 1.84. The 184 Test Quest I made works fine in 1.84.

To try to remedy the problem I ripped the tiles from 1.84, saved them there, and tried to import them into the test quest in 2.53 to see if that would fix the problem. 2.53 didn't read the 1.84 tile format.

For some reason New Quest and Demo kept their tilesets in 1.84 but the new quest didn't. Weird.

The test quest fails on all versions of 2.50.

-James

Quote:

---

Originally Posted by Nightmare

This is a problem I had with the ORIGINAL example_1st.qst back in 2000 and also with a test quest I made to test another issue:

Apparently the tiles don't read the same as it seems to read the new ZC tileset rather than the one included with the file from 1.84. The 184 Test Quest I made works fine in 1.84.

To try to remedy the problem I ripped the tiles from 1.84, saved them there, and tried to import them into the test quest in 2.53 to see if that would fix the problem. 2.53 didn't read the 1.84 tile format.

For some reason New Quest and Demo kept their tilesets in 1.84 but the new quest didn't. Weird.

The test quest fails on all versions of 2.50.

-James

---

Do all of these have the same issue, across the board in all 2.50.x releases; or is only one of these that has this issue in all 2.50.x releases?

James, i do wish that you would be more specific, and detailed. What quest files you tested in each version, and what the result was for each, in each ZC/ZQuest version, linking to the quest files. This level of compatibility is a very marginal concern for most people, and getting it to work properly, or figuring out the causes will take considerable time and effort. As such, it would be extremely useful not to need to duplicate every test from here, that you have already done.

In general, the best way to report this is something like this:

Quest File (made in specify version of ZC)
Test Results for 2.50.0: Quest does this; works right; has these issues.
Test Results for 2.50.1: Quest does this; works right; has these issues.
Test Results for 2.50.2: Quest does this; works right; has these issues.
Test Results for 2.50.3rc1: Quest does this; works right; has these issues.
Test Results for 2.53.0 Beta n: Quest does this; works right; has these issues.

If you also feel like testing it in 2.10, you can provide those results, but they may not be helpful at this stage.

The more detailed your reports are, the easier it will be for us to (1) schedule a series of our own tests, (2) determine a point at which this issue first occurred. (3) examine the issue and search for a root cause, (4) consider a potential fix implementation.

If none of these quest load tiles properly in any 2.50.x version, then it is possible that the tile loading mechanism for them is simply not properly implemented at all. If it only affects some quests, then it is a much stranger issue, and will be harder to diagnose.

Something that is not clear to me is if this is a ZQuest issue (tile editor), or a an issue with Zelda Classic reading combos. ZC does not 'read tiles', it reads combos which store tile data. Where you are encountering the issue, and precise details that explain what is happening (screenshots would be nice) would be quite handy to have.

I can delve into the 1.50 tiles in ZQ, and the 1.50 combo reading in ZC, but it's hard to say how helpful that will be, which is why I asked if you can find a 2.50.x version in which this worked, so that if it broke in recent history, we can find a cause. If it broke in 2.10 or earlier--oh bio--this will be a bastard to correct.

FWIW, the easiest thing might be to quasi-hack the entire 1.50 type loading code into ZQuest, as I had mentioned in the past. I had worked on an early version of this, which I was a bit unhappy about using, as I effectively duplicated a large number of objects that persist in memory at all times, such as maps, the combo tables, and whatnot from 1.5x.

Now I'm not sure where I saved that blasted thing, or if it was overwritten by a git pull. It would not be hard to write again, but the sheer amount of RAM wastage concerns me with that model.

I do not yet know if the 1.50 loading code would suffice, even if this worked, and then converting the data into usable data for 2.50.x would still be a chore. The main issue is the sizes and types of all of the structs, and data objects.

I do have to ask: How much of a chore is it, in relation/contrast to this amount of work needed to make a 1.84 quest loader, to manually fix the combos and the tiles in the quest files after you load them?

The culprits would be:

1.50

Code:

---

if(!pfread(combobuf,sizeof(combo)*512,f)) {
  pack_fclose(f);
  return qe_invalid;
  }

///and


 if(header->data_flags[0])
 {
  if(!pfread(tilebuf,TILEBUF_SIZE,f))
  {
    pack_fclose(f);
    return qe_invalid;
  }
 }
 else
 {
  for(int i=0; i<TILEBUF_SIZE/4; i++)
    ((long*)tilebuf)[i]=((long*)data[TIL_NES].dat)[i];
 }

---

The actual data stored in *combobuf and *tilebug have changed, so ZQuest is likely trying to read values in the wrong data locations; and iit is a miracle that it does not outright crash in the process.

It didn't work in any version of 2.50. I don't know where it started honestly.

The next step on this one is to repeat the test process creating a quest in 1.90 under the same conditions. I'll report if this build issue is limited to 1.84 or extends to all versions possibly pre 2.10.

I think the problem is honestly the way the tiles are bound to 1.84 and earlier, though more isolation testing needs to be done to confirm.

I posted the test files on Discord in the compatibility channel

-James

OK @ZoriaRPG , some more updates:

2.50.x (anything) and 2.53: Basically creates a weird screen and you can't see Link or anything. Checked the file in ZQuest, and certain tiles were missing, almost as if the tiles weren't replaced. The tileset seemed to be the one that defaulted to 2.50. I had this issue running the original example_1st.qst from 1990 as well. It's almost as if the tileset doesn't carry over. Also, importing the 1.84 tileset doesn't work, it just outright fails and won't even load. I fixed the original example_1st problem by uploading the New Quest tileset (which isn't perfect old, but close enough)

2.10.2: Outright crashes. I can't get ZC 2.10 to even work to the right directory. I personally hate 2.10 a lot, it's one of the reasons why I left years ago and didn't even develop for it outside of forum issues.

1.92: No issues. Plays smooth, works fine. All tiles where they're supposed to be.

Same test files as in the Discord channel.

I am having the DOSBox team whip up a 1.90 example quest. I'll check back in a few days on that. I believe this is a 1.84- issue, but want to double-check on it before signing off on that.

-James

The same quest layout built in 1.90 also fails built the same way in the same exact fashion as 1.84 did, and I cannot load 1.90 tile files into the 2.53 beta.

Also fails in all versions of 2.50, plays in 1.92.

Rebuilding test case in 1.92

Test File available on Discord.

-James

If I upload the New Quest tileset to the 184test.qst file in 2.50.2, it works perfectly.

So essentially, this is a problem is you use the DEFAULT tileset without making a change/adding one, etc. So 1.84, 1.90, and 1.92 quests will not function properly if you didn't change a tile.

Test quest going in Discord.

-James