So, I've been doing quite a bit of thinking about making a 16x16 tile system, and I'm getting closer to a full theory.
Basically, I can do this, I think, within the limits of the default system. The only problem is, I would have to keep a dev-copy, and a running-copy of the default system. The reason for this, is that the dev-copy and the running-copy would have to have 2 seperate tilesets, the 32x32 one for the editor, and the 16x16 one for the game. Fortunately, there is another way around that.
I could do this in one of two ways, one being impossible without the hidden classes, and one being feasible without the hidden classes.
I could totally scrap the default mapping system, and just create images based on the tileset, loading chunks of the tileset by halving their size using the default sprite value of zoom_x/y, and then blasting them up on an already lowered screen size of 320x240, now, this would be very simple to do using an array of custom created Sprite objects, unfortunately, the only problem with this method is 1: I can't stop the map from blitting a normal viewport anyway, and 2: I'd have to marshal dump about half a dozen objects to discover their methods and/or variables, then stumble around in the dark for a bit...
Now, the second method, that is not possible, is by getting the hidden classes, loading the map reader, and changing the default viewport rendering behaviour. Basically, I have sized-up tiles, and then stretch them to 50% size, and render them at half-interval on a 320x240 viewport. Of course, yes, this would create unneccesary size for image files, and yes, will cause rendering speed to decrease only slightly... Still though, RMXP could use this system. 32x32 tiles can sometimes be a bad thing... especially in the case of a fangame. Personally, I'm a bigger fan of mutable tilesize, and with this, we should have it.
Even method #2 has many things I could change to make more sense, but do you guys see what I'm getting at?
Basically, I can do this, I think, within the limits of the default system. The only problem is, I would have to keep a dev-copy, and a running-copy of the default system. The reason for this, is that the dev-copy and the running-copy would have to have 2 seperate tilesets, the 32x32 one for the editor, and the 16x16 one for the game. Fortunately, there is another way around that.
I could do this in one of two ways, one being impossible without the hidden classes, and one being feasible without the hidden classes.
I could totally scrap the default mapping system, and just create images based on the tileset, loading chunks of the tileset by halving their size using the default sprite value of zoom_x/y, and then blasting them up on an already lowered screen size of 320x240, now, this would be very simple to do using an array of custom created Sprite objects, unfortunately, the only problem with this method is 1: I can't stop the map from blitting a normal viewport anyway, and 2: I'd have to marshal dump about half a dozen objects to discover their methods and/or variables, then stumble around in the dark for a bit...
Now, the second method, that is not possible, is by getting the hidden classes, loading the map reader, and changing the default viewport rendering behaviour. Basically, I have sized-up tiles, and then stretch them to 50% size, and render them at half-interval on a 320x240 viewport. Of course, yes, this would create unneccesary size for image files, and yes, will cause rendering speed to decrease only slightly... Still though, RMXP could use this system. 32x32 tiles can sometimes be a bad thing... especially in the case of a fangame. Personally, I'm a bigger fan of mutable tilesize, and with this, we should have it.
Even method #2 has many things I could change to make more sense, but do you guys see what I'm getting at?