glueit works fine for me, it supports png and bmp, doesnt have that many options, but does the trick for me. requires .NET 2.0
http://sysimage.250free.com/
C.M.
Printable View
glueit works fine for me, it supports png and bmp, doesnt have that many options, but does the trick for me. requires .NET 2.0
http://sysimage.250free.com/
C.M.
thx for the link,
used tileExtractor a few times,- nice tool as well:
http://www.allegro.cc/forums/thread/587846/617409
official link:
http://retrospec.sgn.net/game-overview.php?link=tiler
performes various tile cut & glue jobs
Ahhhhhh Chimarg you are officially a lifesaver. For some reason all the other editors overlapped my images (probably because they were panorama style editors), but GlueIt works absolutely perfect. Now, another question for the general public.
What's the best method for pulling these images out of my sprite sheet when I create the map? Right now I'm thinking something along the lines of specific lines for specific things, but I have like 132 sprites of walls, 53 sprites of "clouds", etc etc. After I've created the sprite sheet, would it be easier to just edit the image manuall to create the 1 row/1 type method? Hmm, I guess I'll just pack this post full of questions. Is there anyway to preserve or create a transparency when I copyPixel to create the map? All my png's have a bright purple background (in standard sprite fashion), and I'm wondering how to keep the purple transparent. I suppose if I really really wanted to I could use my transparency macro from Adobe CS and just run through all the files (got it down to 713 sprites yay), and re-create the png with transparency built, but I just wondered if was possible on the code end before I do an hour+ worth of unnecessary work.
Check bitmapdata.threshold method to replace color.Quote:
Originally Posted by ImprisonedPride
Hmmm turns out I was looking at old copies. The new copies I retrieved from the source had the transparency built in, but when I was creating the map, I was still recieving the ugly white background thing. Did a little research and solved it with the BitmapData constructor.
Are you actually loading the entire massive sheet of tiles and then extracting what you need from it?
If that's the case, why not load each tile seperately and construct your own tile sheet using BitmapData. That way you only bring in the resources you need. Load time is a fraction slower bringing it in a piece at a time, but it wouldn't require a gang of ram at runtime.
With regard to your tile setup problem, why not use discreet layers for each tile type? By that I mean create a layer for each tile type, nest behavioral properties of said tile type in the layer itself instead of in the tiles, then draw a batch of tiles in that layer. Because some parts of each layer would be transparent, and all layers would overlap to yield a seamless surface, a hitTest system could be devised to check the layers and not each individual tile. Would that work?
Well in testing, I've found that actually brining the whole sheet at once (27x27 tiles EXACTLY), was about 50-100ms faster on average. At least the way I'm doing it. That's if you're doing it in one massive operation. Instead, I've split it up into frame loading, which may actually take a bit longer via preloader, but puts considerably less strain on the cpu. In fact, what I've actually done is compiled the sheet in a way that tile ranges are used to determine the actual tile properties. At time of run, I simply create an object like "t"+tileNumber, which holds the information of the x & y (not _x and _y), that will be used to later rip the sprite from the single sheet. This way, you never need to create copies of the tiles and apply properties to them. When the map is read, it simply tags the array value to the end of "t" and finds all the information from the object "t"+tileNumber to recieve everything the tile will need. Then I simply cut and paste the bitmap into the newly created mc at runtime and set it's properties from the relative placeholder object.
Thanks to all of you for your help! The ball is really rolling on this project, so I thought I'd be nice and share a little screenshot of the map editor:
http://img.photobucket.com/albums/v3...ty/screen1.png
Only 1 thing wrong with it right now, the Status window text is dynamic, but the box doesn't scroll, is there a scroll option or an update command that I have to set to get it to stay at the bottom?
dynamicTextBoxInstanceName.scroll = dynamicTextBoxInstanceName.maxscroll;
:)
It's not a dynamic textbox, it's a textArea component... that command didn't do anything at all when I implimented it.
Ok so I finally figured it out. Instead of maxscroll, when I send the string to the function and attach it to the stuff that's already in the textArea, I just do:
Why 2 looks better visually than 1, I'm not sure, but thanks for the help.Code:statusWindow.vPosition += 2;
I know I shouldn't make new topics that revolve around the same project, and I think I should stop bumping this topic (it's 1/2 way down front page, OH NO!), but I've run into yet another problem.
For reference, look at the screenshot above. Anyhow, in the map window, obviously I have a grid which users can place a tile on simply by clicking the window. The problem is that my map array is a specific size, and likewise, my grid is built on a scale of the same. However, on the edge of the bitmap if the user clicks the scrollbars, it will place a tile underneath the scrollbar and inadvertantly stretch the bitmap another x pixels, which inevitably allows the user to scroll a bit farther, beyond the reaches of the map. Hopefully you can see the viscious cycle that has formed here.
I notice that the UIscrollbar inherited class has a feature of scroll, which is a listener to see if the scrollbars have been clicked. I figured if I just do the check when I check normally (onMouseDown), but listen for a hit on the scrollbars, all would be well. However, the help file shows me little on how to accomplish that aside from implementing the listener. Anyone have any ideas?
Errr. I resolved that last problem by simply reducing the hitTest area on the mapWindow to just shy of the scroll bars. :p (I really need to stop bumping this thread...)