Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: nemo on June 29, 2010, 12:16:59 pm
-
i've been debating releasing this for awhile, but here goes. it's a basic tilemapper. im releasing this right now as a beta (if you can call it that) since all i want is feedback.
some limitations:
1) tilemap editor cursor is inaccurate. i'm hoping to fix this by reordering the movement code.
2) you can't export the HEX string of the tilemap. my program won't display it, since it's obnoxiously long to copy anyway.
3) you cannot load/save tiles, even though it gives you an option to load a tilemap. that's for the future.
4) you can only navigate through the program tile editor -> tile mapper, as of right now.
buttons of use in tile editor:
arrows - move cursor
[2nd] - invert pixel
[ + ] - next tile
[ - ] - previous tile
[Alpha] - start tilemapping
buttons of use in tilemap editor:
arrows - move cursor
[2nd] - display next tile in tileset.
[ + ] - display tile number
[Clear] - exit program
this definitely isn't a useful program (yet). some of the things i'm hoping to implement:
1) compression techniques. 1 byte = 1 tile, 1 byte = 2 tiles and RLE. let me know if you want me to support any others.
2) saving/loading tilemaps and their corresponding tilesets.
3) more accurate cursors
4) 16x16 tiles. *maybe* unless i gain enough support, they're out.
TL;DR: download. find some bugs, think of useful features. post 'em.
-
Ok I am trying it atm. The first suggestion would be to use getkey instead of getkey() for moving the cursor around, because otherwise, it's hard to move one spot or swap a pixel color only once. I always end up accidentally moving two spots because there are no key delay on the first keypress when holding down the key.
I would also allow the cursor to move to the opposite side when it reach edges, so we don't need to move all the way back to the other side. Inverting the entire sprite would be a nice addition too, or maybe also filling black/erasing.
For the tilemap editor, same suggestions, plus allowing me to select which tile I want. Half byte will be nice, btw. I tried making a tile editor before and failed.
Maps larger than 12x8 would be nice too
Otherwise, nice so far.
-
the getkey() vs getkey->K thing i will experiment. then again, i could make there be two modes. i've done it before ::)
forgot about that. i just added it, thanks for reminding me. except i only added it for the tilemap editor, not the tileset. since at most, to get to the other edge you only need to move 8 pixels. on a tilemap i'll make it do that, though.
scrolling (maps larger than 12x8) will be implemented too, forgot to add that.
my main problem is tile selection. can anyone let me know how they would like to see a tilemap editor work? DJ, i can think of a few ways:
1) leave as is (with a button that will indicate to delete the tile being added)
2) have 1-9 and A-F be tile keys. so pressing 1 will get first tile, 2 = 2nd tile, 3 = 3rd, etc.
3) drop down menu displaying like so at the left side of the screen:
[tile 0][tile 8]
[tile 1][tile 9]
[tile 2][tile 10]
[tile 3][tile 11]
[tile 4][tile 12]
[tile 5][tile 13]
[tile 6][tile 14]
[tile 7][tile 15]
except the actual tile is visible there.
4) combine all three. 2nd would display the next tile, 1-9 + A-F would give corresponding tile, [Alpha] would open the menu.
thoughts?
also, i've decided copying tiles will be another feature. so you could copy the data from tile 1's memory slot to tile 5's memory and then go to tile 5 and be able to edit a variation of tile 1.
-
Usually, I simply do like in Super Mario 83+, I open the actual sprite sheet and you select the desired tile from there. Otherwise, pressing + select the next tile and - the previous one.
-
i'm going to give myself a challenge and do 2,3 and then +, - for next/previous tiles. DJ, should the tiles loop? like if i'm at my last tile, and i press +, should i stay at the last tile or should i loop back to no tile?
-
Yup, looping would be nice. It would also be cool to show the selected tile AND the tile number (either in HEX or base 10), so you know at which point you are in the tile selection.
-
Yes, they should loop both ways.
I, personally, think the menu should depend on your tiles. If you are using half-byte, you can have at most 16 tiles, so two rows at the right or left edge of the screen. (Depending on where you are placing the tile.)
I also would like cross-linking tiles. Eg. Teleport, or doors.
-
working on looping. atm, there is a cut off limit of 16 tiles per tilemap.
by cross linking tiles, do you mean two different looking tiles with the same value in the tilemap? you'd have to have some tricky program logic to get that to work in your program.
DJ, you mean in like the upper right hand corner of the screen show "tile: [tile picture] tile num: [0-15]"?
edit: i'm having a bit of a fight with the + and - keys. apparently, if you hold down [ - ] and the left arrow key, the hardware/axe/the OS throws a hissy fit and won't let you move. also, the minus key and the up arrow held in conjunction make the cursor move up and right diagonally. not good :-\
-
cross linking tiles are something to code by your own in your program. It cannot be implemented in a tilemap. The trick is to make sure to group teleport tiles together if you have many so if conditions are easier to write.
Nemo: Yeah, kinda, altough make sure it's to the upper left when moving the cursor to the right half, down when moving cursor to the upper half and vice versa, so it won't always hide the first tile in the map
-
DJ, i think i'll have it display upper left if the cursor's in the lower half of the screen, and lower left if the cursor's in the upper half. then again, i'm still working on the menu/+/- keys for getting the correct tiles. i believe i've encountered another getkey() grouping problem. i edited an above post.
-
Yeah I often had issues with the left key x.x
Kinda annoying at times. I think it's the key delay not being long enough or something. You migth want to report this to Quigibo in case
-
due to the obnoxious key problems, [2nd] will increase the tile number and [alpha] will decrease. i got looping to work. it's ridiculously unoptimized (i think i store to the tilemap about 8 different times... it's pretty bad) but i'll optimize it later.
next i'll work on getting the menu selection. i probably won't do the 1-9 + A-F selection for the tiles, since i'm anticipating a similar getkey() problem, but i'll try marginally. after the menu, i think i'll work on getkey() improvement. then better navigation, saving/loading, and another test release. oh, and the tile options DJ was talking about. except i'm just implementing inverting the sprite, and leaving it blank since filling it black can be done with a combination.
-
Sounds like a good deal. Good luck :)
-
i'm waiting for geometry drawing to be in axe for the menu, since that will simplify it greatly. the getkey problem is done, i think. it uses BASIC's now. now onto some menu clean-up and tackling appvars (:
-
aaah ok ^^ Hopefully Quigibo implement geometry drawing soon
-
This sounds neat. Will there be an option for if you want to use 256 tiles instead of 16? :D
-
256 tiles is 2048 bytes.. so no. i think i'm capping it at about 60-65 since L2 will probably store them, and L2 is 531 bytes. also, i think 60 tiles is pretty crazy for one map. the tilesets are unique to each map, though you will be able to load other tilesets into different maps.
-
hey guys, i need your input.
what's the maximum size i should make maps? i'd like to have dimensions that fit in 768 bytes. should i just make an input loop where you can specify height and width, but if the product of the two numbers exceeds 768 the program exits? or is it worth it to figure a way to separate the map into 2 free RAM areas to enable larger map sizes?
-
should i just make an input loop where you can specify height and width, but if the product of the two numbers exceeds 768
I think this would work. And if it was over, then just cancel the last change. :)
-
I think 768 should be enough. The only concern I have is if somebody is doing a RPG world map. Such are usually around 4096-16384 bytes large if uncompressed, since they're generally 64x64 through 128x128 (ROL3 maps were about 40x40, but they looked very tiny and simple)
-
they'll have to use CalcGS then. plus, i don't think editing a tilemap greater than 768 bytes on-calc is the easiest way.
-
If need be you would always check to see if you have the RAM, and then create an Appvar with the needed RAM.
-
I tried openign such data once, when I made a map editor that I couldn't figure out how to get editing to work, I had no issues looking through the data except that i had to archive other things before running my prog x.x
-
the source code attached is not recommended to be ran. i'll repeat. it isn't a good idea. it's for tanner, because he wanted the source code to see just how badly i'm messing up in my appvars ;D
-
I really had serious troubles before reading data from appvars. Idk why but it seems to be a major hassle x.x
-
oddly enough, using copy() seems to work when reading from appvars. however, using copy() when writing to appvars does not. in my program i use a for() loop to loop through all the data and copy it byte by byte. regardless, i got it working. as soon as i make it a bit more user friendly i'm going to release another little beta to comment upon.
-
mhmm Idk if it was intended to use or not in appvars. Could you maybe post this in bug reports?
I can't wait for beta!
-
It works both ways. Don't forget to reinitialize the appvar pointer if you have created any new ones becasue then the data could have been moved around somewhere else.
-
quigibo, aren't
Copy(L3,I,384
Copy(L1,I+384,256
and
For(A,0,383
{L3+A}->{I+A}
End
For(A,0,255
{L1+A}->{384+A+I}
End
equivalent lines of code? only the latter works in my program. however, i'll experiment later today to see if having GetCalc(Str1)->I before the copy statements will make a difference.
edit: using getcalc(str1)->I before the copy statements makes it work, although the data at pointer I isn't modified anywhere in my code. if i have a Lbl I and call it as a subroutine, would this perhaps modify the pointer?
-
No, the labels are completely separate. Maybe send me the source or executable of the one where it doesn't work right and I can do a disassembly to figure out what the problem is. There's definitely a possibility that it's a bug.
-
found out why; i was using I as a tempvar in a for() loop.
also, once axe has geometry drawing i'll implement the menu for selecting tiles. the framework is all there, i literally just need the command to draw a hollow rectangle to select the correct tile. right now i've implemented saving/loading 3 tilemaps and their unique tilesets. if you try to load a tilemap/set that you have not saved to, you will get a RAM clear. i'm fixing this now.
quick question. if i wanted to archive an appvar, which of the following would work
"vMYAPPVAR"->Str1
Archive GetCalc(Str1)->I
"vMYAPPVAR"->Str1
Archive Str1
the way it's worded in the command index, it seems the second would work.
-
The second one would work. Glad you got your program to work ^_^
-
found out why; i was using I as a tempvar in a for() loop.
I hate when I try finding a bug and it takes me so long to discover it's a variable conflict x.x. Glad you got it fixed.
-
alright, so i've managed to get it to work for the most part. loading a map that doesn't exist will not crash your calculator, just returns the program. once or twice i've had the problem where tileset 1 has size 4x4, tileset 2 has size 8x8 and for an odd reason when you load tileset 2, the tiles become 4x4. exiting the program and reloading the tileset fixes this, i'm not sure why since the bytes where the sizes of the tiles are stored aren't modified if you exit the program prematurely.
-
4x4 tiles seems quite interesting. I wonder what could be causing the bug though?
-
new release (:
some new things:
-primitive tile selection menu
-saving and loading!
-better navigation
those are the big improvements, now for describing how to use the program
main menu:
1- create a new tilemap and tileset, asks for size of tiles afterwards, 4-8.
2- load a map. if you try to load a nonexistent map, the program exits.
3- doesn't actually quit. what can i say? i'm lazy on the easy things.
clear- quits.
tileset editor:
arrow keys - move cursor
2nd - invert pixel
+ - go to the next tile, if tile number is not 15.
- - go to previous tile, if tile number is not 1.
mode - invert all pixels of the tile
del - clear the tile.
window/F2 - go to the tilemap editor
tilemap editor:
arrow keys - move cursor
2nd - display the next tile in the tileset. loops to 0 if the current tile is the last in the tileset
alpha - display previous tile in the tileset. loops to the end of the tileset if the current tile is blank.
clear - quit.
0 - clear the tile. (set it to 0 in the tilemap)
math - bring up tileset menu. press 2nd to select a tile in the tileset menu.
y=/F1 - go to tileset editor.
enter - save to the appvar. there are 3 slots to save to.
known bugs:
- sometimes the correct tile size will not be loaded from the appvar. to prevent this, restart the program then create a new tileset with the desired size. restart the program again and loading a tileset will have the desired size.
- in the tilemap editor, tile selection using 2nd and alpha will not work if you didn't exit the tileset editor on the last tile. so say you have five tiles 1 2 3 4 and 5. in order for the program to work, when you exit the tileset editor to the tilemap editor, make sure the tile you're on is tile 5. i *think* this is only a bug for loaded tilesets. it's especially annoying because i need 3 more bytes in the appvar to specify the number of tiles in the tileset so the tilemap editor will loops correctly.
let me know of any bugs... the appvar name is TILEMAP.
-
Wow just tried it and it's nice. However, I have some suggestions to make it easier to use:
It would be nice if we could assign specific tiles to number keys from 1 to 9, allowing us to instantly change to that tile when editing the map.
Another suggestion would be to not limit ourselves to 3 maps, else it would kinda suck if in a game, we only had 3 maps or if we had to split our map data in multiple appvars. Maybe when variable exporting is possible, add a feature to export a map into a string or an option to export the entire map data.
I made a screenshot of it in action, btw :)
-
thanks DJ. i like the assigning specific tiles idea, though i'm not sure how the keypad hardware will cope with it. i'll experiment. also, i plan on not limiting to 3 maps. for now, how many maps do you suggest i permit? 1) later on i'm going to RLE compress all the maps in the appvar so you can have more maps. 2) once you can export maps into strings this program will become MUCH more useful. i'm planning on there being options to have 1 byte = 1 tile in the map, have it half-byte compressed (limit on the tiles though), have it RLE compressed where 1 half byte is the frequency and another half byte is the tile number, and lastly have it RLE compressed where 1 byte is the frequency, and the next byte is the tile number (which would allow for 255 tiles to be fit into two bytes... imagine that.) if anyone has any other preferred compression algorithms i would love to hear them. especially pucrunch. all i need is a commented example of pucrunch and i can hopefully try to implement it.
just so i know where i'm headed, i'm going to make a quick checklist here. they're prioritized:
Tileset.
[] fix looping bug. use the max() command. add some bytes in the appvar.
[] export tiles as hex string
[] load tiles from within the tileset to another tile to make slight variations.
[] set specific tiles as corresponding keys for the tilemap editor
[] allow editing of 16x16 tiles.
*note: allowing more than 15 tiles isn't on here because that's really easy to implement. i'm keeping it basic for now.
Tilemap.
[] export map as hex string
[] compress the hex string in various ways
[] placing tiles via pressing specific keys (such as 1-9, though it may be sin, cos, tan, ",", "(", and ")".)
[] tilemaps greater in size than the screen.
[] 16x16 tile placement.
as soon as 4.0 comes out with BASIC vars, i'll crack away at this. until then, im going to work on my axe contest project (:
-
I think 10 maps would be enough. Maybe let the user decide? (as long as he has enough RAM)
Good luck on this and your Axe entry :)
-
What about grayscale support?
-
in what way? since it's just a tilemap editor, it's really only a list of numbers that it'll output, and some hex strings for the corresponding tiles. adding in grayscale is a programmer's choice, since you represent grayscale through tiles and tilesets, not the actual tilemap. I don't think a grayscale tileset editor is necessary, seeing as you can always user Runer112's sprite editor to much more efficiently make grayscale tiles.
-
Nemo, I think you really need to be careful to how you reply to other people on the forums. Normally your posts are perfectly fine, but since the past 24 hours, I noticed a drastic change of tone in your messages, this one being an example. The way you are replying to graph (the "In what way?" part) sounds like you are jumping on him and are not welcoming any suggestion. If you don't want any suggestion then tell us, but remember that with certain other forum members, especially newbies, you could make people leave that way and then Omnimaga could get a reputation of being rude to new members, something UTI and TIBD got for a while (and killed them for a while too) and that I don't want here.
-
Sorry DJ. i meant "In what way" as an actual opening to suggestions, as i do not know how i might implement grayscale into a tilemap editor. I want to know what exact type of grayscale support graphmastur means, to see if it would be a useful feature to the program.
-
Well, like having grayscale tile support. So I can actually see how it looks within one application.
It's okay, btw, I didn't find it rude, but like Nemo meant it. I don't know how you would implement it.
-
hmm, i see what you mean. i don't think i will though, because then i need to store more information in the appvar. especially with 4-level grayscale. right now with monochrome, each tile is 8 bytes. with 4-level grayscale, each tile is 24 bytes (8 bytes for the black layer, 8 for the light gray layer and 8 for the dark gray layer). so even if you just wanted 15 tiles in a tileset, that's already 360 bytes that has to be stored in the appvar. although i like the feature idea, it'd be more memory efficient to keep the tiles monochrome, and let the programmer add in shades of gray.
-
Actually, the grayscale tiles are only double the size, not quadruple. In 4 level grayscale, you only need 16 bytes because there are 4 combinations you can make with the 2 layers of bits. In 3 level, you can 3 of the combinations be colors and the last combination be a transparency or simply unused.
But I agree, this is just for generating a general idea of how the map is going to be layed out and I think the extra gray layer is an unnecessary complexity just for a preview of the map.
-
Well I guess if it's just to get a small idea of how it will look like, monochrome would do. It might be nice to have a gray tile editor, though (although people could use Runer and manually replace the appropriate data in their program after having imported the maps from Nemo editor.)
-
new release! i basically just added hex exporting.
Str4 will contain your tilemap, Str5 contains your tileset. there's nothing new except a few more self-explanatory menu's, so i won't bother reposting which keys do what. however, it's worth noting the different compressions available.
the first is where 1 byte is equivalent to one tile. the second is half-byte compression, where two tiles are fit into one byte. the next is titled "RLE" and uses my own run length encoding algorithm. the decompression algorithm can be found here (http://ourl.ca/4129/103313). lastly, there's another RLE compression as explained by calcdude84se (http://ourl.ca/4129/104988). the corresponding decompression algorithm for this type of RLE is found here (http://ourl.ca/4129/105267).
and a quick checklist of features i should implement...
Tileset.
[] fix looping bug. use the max() command. add some bytes in the appvar.
[] load tiles from within the tileset to another tile to make slight variations.
[] set specific tiles as corresponding keys for the tilemap editor
[] allow editing of 16x16 tiles.
*note: allowing more than 15 tiles isn't on here because that's really easy to implement. i'm keeping it basic for now.
Tilemap.
[] placing tiles via pressing specific keys (such as 1-9, though it may be sin, cos, tan, ",", "(", and ")".)
[] tilemaps greater in size than the screen.
[] 16x16 tile placement.
edit: as for grayscale, i don't think it's necessary for getting a layout of the tilemap, so i'm going to keep it monochrome.
-
Wow awesome, you implemented RLE compression too. HOpefully this should come in handy in the future, if someone made a game with a lot of levels and wanted to keep it small. Nice to see this still being worked on :)