Real tile graphics on close-up view

[SineSwiper]

You should really consider actually using the game image data for the maps. Do you know how hard it would be to try to actually construct a tree when all you have is a brown color and frame coordinates?? I was using this XNB Exporter to look at the individual images and frames. You should code the editor to (perhaps at a certain zoom level) use the real frames to render the map, using either the XNB game data directly, or put the PNG data into the editor.

Looks like this may be a revival of issue #20, but that was eons ago, and with the new Frame tag data/research, this should be achievable:

1. Load all PNG files into memory.
2. Run through each tile within view (plus some excess).
3. For each Tile numbered X, look at Tile_X.png in-memory image.
4. If not isFramed, use the whole image.
5. If isFramed, look at Frame X,Y. Divide by 2. Go to X,Y on image. Assume 8x8 pixel tile.
6. Plop tile/image on map location.

[BinaryConstruct]

I planed on doing this eventually, I've just had a lot of other projects come up. I have permission from the dev of Terrafirma to use his code, just haven't had time.

[SineSwiper]

Awesome... Looks like it opens up the XNB data without needing any PNGs.

Understood about the time. I'm working on a bunch of different directions with different Perl modules myself (mostly DBI actually). Maybe if I get a programmers' itch, I'll take a look at this myself. Seems somewhat easy, but everything seems easy on the surface, and that turns into a month-long project :)

[BinaryConstruct]

http://qink.net/page/The-Ultimate-List-of-Freely-Available-Programming-Books.aspx

[SineSwiper]

Haha, don't worry. I've been coding since I was 5, and been doing Perl web design for around 15 years or so. I'll admit I've done some of it the hard way, but what doesn't kill you makes you stronger.

I got a co-worker that raves about C# and .NET, and after seeing some of the code, I can see the appeal.

[BinaryConstruct]

Excellent!

[SineSwiper]

Looking at the Terrafirma code. Seems like a lot of it can just be dropped in. The Texture.cs is the loader file, which can be put somewhere in TEdit. I can do that, editing the namespaces to make sure it's accessible to TEdit and doesn't bump into other things.

Render.cs is the main engine for placing the Textures. Looks like there's a lot of rules around blending objects. Again, most of this should probably be a drop-in. But, these two files should do it.

The last part is figuring out how compatible your map object is to his. You both have zoom levels, so there would be a scale that works out right. Are you using single pixels for tiles, or something closer to 8x8? That would be a big thing to change over.

[SineSwiper]

Oh, and as an added bonus, using the sounds for tile placement. I'll worry about that later, though.

[SineSwiper]

As I'm doing the validation stuff for things like trees, this is becoming more and more important. I think I'm going to try to get SSFrameValidation stable and working up to a point. Then merge it into master when the testing looks sound.

After that, I'm going to switch to getting the textures and stuff loaded. The Texture stuff is pretty easy to port over as their own Texture2D objects (in TileProperty) and Texture objects (in FrameProperty). The harder part is establishing the layers and actually displaying the data, but again, Terrafirma's code should provide some clarity.

As it is now, I think I'm going to run into some major issues trying to confirm the attachesTo tree validation stuff works right when all I'm looking at is a bunch of brown pixels and frame numbers.

[BinaryConstruct]

Defiantly use Terrafirma for rendering textures, it is highly optimized.

[SineSwiper]

Yeah, though I think it actually only uses one layer for everything and just makes sure the drawing order is correct. I'd like to go for a more layered approach (which can be toggleable by the user), but I'll need to see if that drops speed by any measure.

The other issue is the potential size difference between your single pixel maps and the real world 8x8 pixel maps. I was considering to change your sizes times 8, but I think I'm actually going to reduce the real world view divided by 8, so that there isn't a lot of code changes to the drawing and sprite placement and ya-da, ya-da, etc.

[SineSwiper]

Tile loading and conversion to byte[] is in place. Will be working on Render code next.

[SineSwiper]

Slow going and keep hitting roadblocks, but I'm still working on this. Current progress is on new_gfx branch.

[SineSwiper]

Fixed and merged.

[DumbJoe]

...so the feature is in it the latest beta? Because I still can't see ingame texture sprites.....there doesn't appear to be an option in the file menu dropdowns to specify location of images for use of ingame textures....

...would be nice if there was an option to specify the location of the images directory just like how Terrafirma ask for it if you wish to see ingame textures of the world...if you want to use the editor on another computer that doesn't have Terraria installed, for example you have Terraria installed on a windows xp machine but have a spare windows 7 machine lying around you could use but barely use because it's extremely slow(for example which might be why you don't wanna run the game on that), since the program doesnt run on windows xp machine, you could load the editor, copy the images directory and sub contents with the editor and the tell the editor where the images are at so it can use the ingame textures....

EDIT:

http://qink.net/page/The-Ultimate-List-of-Freely-Available-Programming-Books.aspx

I get: https://i.postimg.cc/CKYDqZwh/screenshot-github-com-2018-10-19-22-03-08.png