[XP] XP Ace Tilemap

[KK20]

What's the fix for invalid byte sequence?
Plane should only create children if there's a viewport being passed in. So a check for if !viewport.nil? will be added.
I can make the WEATHER_ADJUSTMENT encompass Game_Screen and RPG::Weather, so they will only be loaded if WEATHER_ADJUSTMENT is true.
shaking? was removed as I no longer need it for Tilemap#update purposes. Was used to check if I had to move the viewport around and redraw tiles during screen shakes, but I resolved that in a different manner.

[Blizzard]

I literally just comment out that line for the byte-sequence. xD

[KK20]

Huh, I guess the deletion of null characters isn't necessary. Duly noted.
One fix I did find online would be to do

title = title.encode("UTF-16be", :invalid=>:replace, :replace=>"?").encode('UTF-8')

before the deletion. Haven't tried yet.

How the heck is your title not even UTF-8

[Blizzard]

You misunderstood, Ruby doesn't recognize "\0" as UTF-8 string. It's not the string in "title" that's messed up. I think.

[KK20]

But if that's the case, why have I never seen this before? I don't know how to reproduce it. :S

[Blizzard]

Try my DLL and EXE. https://www.dropbox.com/s/lwfax836rbbyhtx/cp-bin.rar?dl=0

Other than that it could be possible that the string really isn't UTF-8 for some reason. Is it possible that the DLL call messed it up? Or the string full of null-characters actually isn't treated as UTF-8 encoded initially? IDK.

[KK20]

Still works for me. Our DLLs are the same. Hoping it's not GetPrivateProfileString at this point.
EDIT:
It's the trademark character (™) in your game title
But yeah, removing delete! or the fix I posted both work strangely enough.

[Blizzard]

Then GetPrivateProfileString() is the one messing things up. It probably supports only ASCII or possibly wide-char if there is a W version of the function. Who knows.

[KK20]

I think it has to do with the changes in Ruby 1.9. As I found out, 1.9 defaults to UTF-8 encoding whereas 1.8 did not even know about encoding at the time, so all strings are just stored as literal bytes. This was also an issue with Multiple Inputs where we needed to use String#each_byte. Not sure if there's a one-liner thing that can essentially disable string encoding and just revert back to bytes again.

[Blizzard]

There was String#scan with (/./m) or something like that. I used it in my input module I think.
Ruby 1.8 did support UTF-8, but it would be implicit. That is, it would regard a string as UTF-8 automatically, because it's backwards compatible with ASCII. Other encodings would not work (such as multi-byte string), but using scan it was still possible to specify the "m" option in a regex (multi-byte) which would kinda make it work. But I'm not sure if it would work with multi-byte or UTF-8 strings, I can't remember.

[KK20]

I was kinda hoping for a one-liner fix-all, something like

# encoding: ______

that applied to all scripts in the project.

At least for this script, I found out that the Resolution module can be skipped entirely Since VXA already has its own resizing, it gets overruled. It's really only needed for XP games.

[KK20]

Fixed things up as mentioned, so updated to version 0.31
https://dl.dropboxusercontent.com/u/58874459/XPAT_v0.31.zip

Changes:

 0.31  ... 08 Feb 2017 ... Bug fixes:
                            - Bad logic with border sprites for non-wrapping map
                            - Problem with Plane objects not initialized with a
                              viewport, causing children-creation to crash
                            - Disable Graphics.resize_screen in Hime's script
                              for XP games as this method does not exist nor is
                              the code necessary to "break" the resolution limit
                            - RGSS does not support Array#cover?
                           Changes:
                            - The Resolution module is disabled for XPA
                            - If WEATHER_ADJUSTMENT is false, it will disable
                              all of the RPG::Weather and Game_Screen classes
                              from loading rather than only some methods
                            - Input module for supporting different game window
                              sizes is disabled for XP as this feature does not
                              work in RGSS

[LiTTleDRAgo]

http://i.imgur.com/Id8tk7M.jpg

    wh = -> w, h, off = 0 { [w + off, h + off].pack('l2').scan /.{4}/ }
    w, h = wh.(width, height)

rgss can't handle that kind of syntax, it's irrelevant whether you disable it or not
you should change it to more friendly syntax instead

    wh = lambda {|w,h,off| [w + off, h + off].pack('l2').scan(/.{4}/) }
    w, h = wh.call(width, height,0)

edit : ups I forgot, rmxp also didn't have Graphics.snap_to_bitmap method

here to save your time : http://pastebin.com/pgRdi7Fn

[KK20]

Oh right, I had a feeling I was forgetting something. Especially that snap_to_bitmap.

[LiTTleDRAgo]

another bug detected, the fogs in top left area is thicker than other areas
no other script used, only RTP (pure rmxp) and XPAT

Spoiler: ShowHide

http://i.imgur.com/gbwMGwO.jpg

[KK20]

Does the viewport have some kind of color tint or tone to it? It seems that the children Plane objects aren't getting the same treatment as the parent.

Regarding the whole UTF-8 deal, I found out that if you eval your scripts, it suddenly works? I noticed this while having SUPERCLASS_MISMATCH_HELPER enabled.

start = __FILE__.scan(/\d+/)[0].to_i + 1
for i in start...$RGSS_SCRIPTS.size
  code = $RGSS_SCRIPTS[i][3]
  eval(code, nil, sprintf("{%04d}", i))
end
exit

But it only works if you buffer the string with "\0" * 256, not 0.chr * 256. Just a neat observation.

[LiTTleDRAgo]

Just a normal fog though, not from script call.
Hue is 0 and normal blending, nothing special at all.


http://i.imgur.com/QbISP8y.jpg

[KK20]

mmm there's definitely some screen tint involved. I used the same graphic on a tint-less map and noticed nothing.

[Blizzard]

Try different opacity values for the fog as well.

[LiTTleDRAgo]

Forgot to tell you, yes there are screen tint involved.
Also, I noticed when using weather, the rain didn't fill the whole screen.


http://i.imgur.com/QvvcAZU.jpg