Yeah btw I scrapped the editor. I'm not really going to use it since I stick with tile based engines anyhow. ;)
Printable View
Yeah btw I scrapped the editor. I'm not really going to use it since I stick with tile based engines anyhow. ;)
to Squize: I think as soon as you CAN do all the things i listed in what you call a tile based engine its essentially not a tilebased engine in the old definition sense anymore :)
Cause some of the core definition elements of tile based engines always were that graphics of same size (or exact multiples of that) are aligned next to each other at equal spacing to form a grid like constrained layout.
Therefore i think there´s a confusion regarding what is a tilebased setup and what is a supertile based setup.
This is probably because there can be quite a difference between the setup in a bitmapdata based solution and an older flash version´s movieclip based solution.
With pre f8 (pre bitmapdata solution possible) flash versions the difference in setup had to be way bigger and therefore the differences were more obvious:
A tilebased setup would be a gotoandstop scroller, all tiles would essentially be the same size in the scroller and be contained in their own mc. you´d scroll the thing and when tiles moved out the screen on one side one would change their frame to the image of tiles coming in on the other map side, move em there and go on. (There were some other sub approach sets but yeah,let´s leave it at that for comparison :) ).
So this setup would be useful if a) you always want to fill the entire screen with tiles and b) your tiles are always the exact same size or the exact multiple of that base size.
In a supertile setup in that flash possibilities generation you´d again have tile images but you´d bundle several into a supertile mc. you could place them at any x/y coordinate on the map and you´d scroll less elements as you´d only scroll the supertiles,not the tiles contained in them each by its own.
This setup was clearly superior if you a) didn´t want to fill the whole screen with tiles but maybe just position some graphics in front of a bg
and b) wanted to have total freedom regarding graphic sizes and positioning.
With a bitmapdata based approach of newer flash versions the implementation of both setups can be way closer ,you normally in either case don´t have more than a single screen bitmap (maybe a buffer bitmap,too) and use copypixels to bring your tile graphics onto that bitmap. There doesn´t have to be a difference in mc count or things like that.
You could also just use copypixels in a tilebased engine to copy some additonal not aligned in the grid constraints images somewhere onto the other drawn tile graphics. So yeah,the line becomes more blurry whether you´re doing a tilebased or supertile based engine or something that maybe is so different that we should actually define a new term than for the old flash 7 engines :)
Since its bitmapdata based your supertile engine side (total freedom in positioning and compositing graphics) or tilebased setup (positioning equal sized stuff on a grid) could also just exist on the editor side and at runtime its still plotted different.
Duh, why do you think I said I wished someone ported it to Windows?? Translation of your comment is: "I don't know how to use it, therefore it sucks". :-DQuote:
Originally Posted by renderhjs
The UI adheres to Deluxe Paint conventions, which are now outdated (in terms of the hotkeys), unless you are a ProMotion user. That tool was used for map editing for Cool Spot, Alladin, Jungle Book, Global Gladiators, MC Kids, RoboCop VS Terminator, Prince of Persia (Gameboy), and a crap-load of other SNES, Genesis/MegaDrive, and Gameboy games.
If it were ported to Windows, and UI updated to modern conventions, it would rock!