Chaos Project

Featured Projects => Tasks => Advanced RPG Creator => Finished Tasks => Topic started by: Blizzard on March 27, 2011, 07:39:45 am

Title: [Finished] [RGSS] _dump and _load
Post by: Blizzard on March 27, 2011, 07:39:45 am
_dump and _load




Description

Following classes require a _dump and _load method:



_dump should create a byte stream that is dumped into a Marshal file while _load should read the byte stream. Remember that strings are terminated with \0 characters and that you should be careful not to mix up a string and a byte stream while you still will have to use a Ruby String to represent that byte stream.



Priority

High.



Prerequisites

None.



Assigned

Ryex



Everything else

Refer to this topic (http://forum.chaos-project.com/index.php/topic,9089.0) for more information.
Don't forget the create the interface methods for _load and _dump. Call the C++ versions rb__load and rb__dump.
Title: Re: _dump and _load
Post by: Ryex on April 01, 2011, 07:53:05 pm
Color


 def _dump(d = 0)
    [@red, @green, @blue, @alpha].pack('d4')
 end
 def self._load(s)
    Color.new(*s.unpack('d4'))
 end




Tone



 def _dump(d = 0)
    [@red, @green, @blue, @gray].pack('d4')
 end
 def self._load(s)
    Tone.new(*s.unpack('d4'))
 end




Table



 def _dump(d = 0)
    s = [3].pack('L')
    s += [@xsize].pack('L') + [@ysize].pack('L') + [@zsize].pack('L')
    s += [@xsize * @ysize * @zsize].pack('L')
    for z in 0...@zsize
       for y in 0...@ysize
          for x in 0...@xsize
             s += [@data[x + y * @xsize + z * @xsize * @ysize]].pack('S')
          end
       end
    end
    s
 end
 
 def self._load(s)
    size = s[0, 4].unpack('L')[0]
    nx = s[4, 4].unpack('L')[0]
    ny = s[8, 4].unpack('L')[0]
    nz = s[12, 4].unpack('L')[0]
    data = []
    pointer = 20
    loop do
       data.push(*s[pointer, 2].unpack('S'))
       pointer += 2
       break if pointer > s.size - 1
    end
    t = Table.new(nx, ny, nz)
    n = 0
    for z in 0...nz
       for y in 0...ny
          for x in 0...nx
             t[x, y, z] = data[n]
             n += 1
          end
       end
    end
    t
 end




Rect



 def _dump(d = 0)
    [@x, @y, @width, @height].pack('l4')
 end
 def self._load(s)
    Rect.new(*s.unpack('l4'))
 end




Title: Re: _dump and _load
Post by: Blizzard on April 02, 2011, 04:57:06 am
Tone and color both use float values while Rect uses int values so it might be different. As soon as you have tested it, you can mark this task as finished and move it.
Title: Re: _dump and _load
Post by: Ryex on April 02, 2011, 06:10:32 am
ok I tested it and made some edits to my first post
Title: Re: _dump and _load
Post by: Blizzard on April 02, 2011, 06:16:06 am
Wait, no, lol! This task is for the implementation of those methods, not just their definition. xD
Title: Re: _dump and _load
Post by: Ryex on April 02, 2011, 06:27:25 am
lol, and here you told me to move it. not sure how you would implement the pack method in c++ I'll do some research
Title: Re: _dump and _load
Post by: Blizzard on April 02, 2011, 06:31:35 am
If you can't find a good way, you can always manually call the original Ruby functions.
Title: Re: _dump and _load
Post by: Ryex on April 08, 2011, 12:39:24 am
OH YA! I AM AWESOME! I implemented all of them. tested and fully working. take a look and bow before my awesome skills!  :haha: 8)


sorry for the gloating, I just have too, I feel that accomplished.

oh and I did this all at revision 150, I basically beat one of the original Pokemon games by doing this.
Title: Re: [Finished] _dump and _load
Post by: Blizzard on April 08, 2011, 02:31:52 am
Great work, Ryex. :) Now we can basically load all RMXP data.

EDIT: Did you really write "Ryex is awesome." in the commit log? :V:
Title: Re: [Finished] [RGSS] _dump and _load
Post by: Ryex on September 11, 2011, 06:12:32 pm
I just realized something. the way the table class dumps data is readable by RMXP but it's not always usable. this is because of a completely different method of determining the dimension of the table. the RMXP versions dump the dimension of the table as the first 4 bytes of the string and ENFORCE this when you go to access data so while the ruby version dump 3 as a place holder and doesn't care and the C++ version dumps 2 but still determines the dimension from the x y and z sizes of the table when it loads it completely skipping the 4 byte size when reading the data. so basically when RMXP loads that data even though y and z sizes are 1 and the C++ version would interpret the table as 1D the RMXP version will interpret it as the size that was dumped with it and thus force the use of that many parameters when accessing data.

if we want to mimic this behavior (which I think is stupid) we'll need to do a bit of editing. other wise if the engine dumps tables they won't be properly accessible in RMXP
Title: Re: [Finished] [RGSS] _dump and _load
Post by: Blizzard on September 12, 2011, 02:10:34 am
Wait, I didn't really get that. Yes, I implemented in the C++ version that only x, y and z are read and the last byte containing the whole size is not read because it is equal x * y * z anyway. If I remember right, a one-dimensional table is actually a 3 dimensional table that only takes 1 parameter. Or are you trying to say that if you create a table with (x, 1, 1), RMXP thinks it's handling a 3-dimensional table? It's not a problem to change the implementation if we want to mimic this behavior properly. In that case, how can we determine how many dimensions the table has? I think that I remember that table would dump 5 bytes altogether; x, y, z, number of dimensions and total size.
Title: Re: [Finished] [RGSS] _dump and _load
Post by: Ryex on September 12, 2011, 12:31:35 pm
yes if you use Table.new(x, 1, 1) RMXP treats it as a 3 dimensional table and dumps the dimension as the first 4 bytes in the string. the C++ version I wrote ignores those 4 bytes and dumps a place holder number to fill them. the table needs to set the dimensions from the number of arguments passed to it.
Title: Re: [Finished] [RGSS] _dump and _load
Post by: Blizzard on September 12, 2011, 04:02:00 pm
I remember changing a lot of your C++ implementation, but still. I'll change that.