3 bug reports

[yeahimdukenukem]

Hi,

I would just like to report 3 bugs in Raine 0.91.6:

 

1. The romset "bubboblr1" is not loaded correctly. Raine looks for the filename "bubbobr1" instead and it works actually if the file is renamed.

2. The second issue is with "sf2m8". It loads fine, but the romcheck reports a bad size of one rom, although the size is the same as in the -listinfo
rom:yyc-9.8      size:0x00010000 crc32:0x155824a9 -- bad size: 0x00020000

 

3. The -rfc switch reports many BAD crcs although the roms are correct and checking them directly with -rc reports them as OK.

Thanks and best regards.
 

[Tux]

2 hours ago, yeahimdukenukem said:

Hi,

I would just like to report 3 bugs in Raine 0.91.6:

 

1. The romset "bubboblr1" is not loaded correctly. Raine looks for the filename "bubbobr1" instead and it works actually if the file is renamed.

2. The second issue is with "sf2m8". It loads fine, but the romcheck reports a bad size of one rom, although the size is the same as in the -listinfo
rom:yyc-9.8      size:0x00010000 crc32:0x155824a9 -- bad size: 0x00020000

 

3. The -rfc switch reports many BAD crcs although the roms are correct and checking them directly with -rc reports them as OK.

Thanks and best regards.
 

Tsss... can't insert my reply in the middle of this, so it will do here :

1 : Not for me, sorry, I don't know exactly what happens for you, but the rom loads fine here.

2 : Ah ok for this one, the -romcheck command doesn't handle very well the roms loaded with a ROM_CONTINUE, actually these roms are very few, and it's the 1st time this is reported... Anyway what happens is that it says bad size 0x20000 because the rom is loaded by parts of 0x10000 with a ROM_CONTINUE for the 2nd one. It's harmless anyway, but thanks for the info.

3 :Since you didn't give any example I am obliged to guess here, and chances are you stumbled on another game using ROM_CONTINUE, like sonicwi3 for example... !

That means also that nobody seriously used -rcf in the many years it existed, it's from before 2009 (start of git in august 2009, and it was already here).

Wow, it just shows I spent too much time on this already !

I'd say not worth fixing it for now, sorry !

[Tux]

On 2nd thought, the fix is not hard to make, only a few lines. So I'll do it again, there are a few minor fixes already committed to git and I needed a reason to make a new binary.

Plus I need to recompile all the 32 bits windows dlls (oh joy), to get rid of the dependencies to the old gcc, anyway, I'll release this soon...

(already fixed in git)

[yeahimdukenukem]

Sounds great, man. Much appreciated

For the first point:

If the file is named "bubbobr1.zip" I can load and run it fine by typing "raine bubboblr1" despite the "l" is omitted in the filename. But adding the "l" to match the set name it tries to download the files from anywhere on the net (which didn't work as I had no internet connection). It even told me that it is looking for various filenames, as for example "bubbobr1.zip", but not "bubboblr1.zip".

I didn't try loading it from the UI, but I can do on Monday and report back if that helps. Btw my collection consists of split sets and every other set reported OK by testing with -rc via a script (ok, ignoring the bad crc in sf2m8 now ^^)

Thanks for the great work and go on with it 😃

Edited July 4, 2020 by yeahimdukenukem

[Tux]

Typo error on my part : filenames recognized :

    { "bubble_bobble_romstar2", },
    { "bubbobr1", },
   { "bubbolbr1", },

The last one should have been bubboblr1 and not bubbolbr1.
Will fix that for next time, but I had the original archive which still has the short name bubbobr1 and didn't notice it.
This change was from 2015, so it was not a problem for a lot of people. Anyway next time it will recognize the right name then... !

[yeahimdukenukem]

Excellent. Thanks for your great work, very much appreciated.

Longing for the next version then

[yeahimdukenukem]

Hi again. I have just tested the 0.91.7 and can say, that the points 2 and 3 are now working

But sadly I have discovered something new when checking the romset pang3:

rom:pa3_11.11f   size:0x00008000 crc32:0xcb1423a2 -- bad size: 0x00020000 (8000)
rom:pa3_11.11f   size:0x00018000 crc32:0xcb1423a2 -- bad size: 0x00020000 (18000)

It loads fine, but -rc as well as -rcf report the same bad size despite the rom size matches the value in -listinfo. The rom itself contains only FF from offset 5BA8 on, so I guess it is somewhat overdumped and Raine's report is correct. Maybe we just have to find out the correct size and I cut the overdumped stuff from the file then.

Thank you so much again and please don't misinterpret my reportings, I really only want to help and make Raine even better.

[Tux]

Ok, double error here, LOAD_IGNORE wasn't ignored by -rc & -rcf, plus a partial rom load from the driver shouldn't print any error.

All fixed !

(it shows that nobody has been running a serious romcheck for a very long time or at least they didn't report the errors).

[yeahimdukenukem]

That's awesome. You are really fast, thank you so much.

I will recheck everything with the next version and will report back here.

[yeahimdukenukem]

I can confirm that the rcf now works in 0.91.8 as intented. There are no errors anymore and bubboblr1 loads fine.

Sadly I have discovered another issue, which I think is only kind of a forgotten debug flag or something: Every output from the cli is redirected to stdout.txt instead of the real stdout, so I cannot redirect stdout to my own file and append the output. This is how I tested -rc for all files. I guess this is easy to fix, but as everything seems to work fine now, there is no need to hurry

Thank you so much, great work.

[Tux]

58 minutes ago, yeahimdukenukem said:

I can confirm that the rcf now works in 0.91.8 as intented. There are no errors anymore and bubboblr1 loads fine.

Sadly I have discovered another issue, which I think is only kind of a forgotten debug flag or something: Every output from the cli is redirected to stdout.txt instead of the real stdout, so I cannot redirect stdout to my own file and append the output. This is how I tested -rc for all files. I guess this is easy to fix, but as everything seems to work fine now, there is no need to hurry

Thank you so much, great work.

Yeah I know it's super annoying but it's the way sdl1.2 with its default configuration works in windows ! Which means that if I build it automatically from linux like any other package, then you get this !
I knew it was like that, but I wanted to be sure you couldn't work with the stdout.txt in this case...

I'll update the dlls package today then with a sdl.dll which doesn't do that !