0 Members and 2 Guests are viewing this topic.
No, I have more than 77 tiles. I see a "r1<229" in the code, and even if there are some blanks somewhere, I think it is still over 127 For the trainer, there are two kinds of them: the ones that you must beat (they are blocking the road) and that can beat only once, and the ones that you don't have to beat, but you can beat them as many times as you want. For the ones blocking the road, yeah, you have to beat them in order.
For the compression, wow, that is very compressed What could be possible, instead of having it divided in parts, would be to have it in one compressed part but uncompressing small parts, this way, there would only be one map file and not too much slowness (only when going from one part to another)
No, you don't walk on top of a trainer to battle them, you walk on the dots right in front of them And yeah, my only variable (that I called TrainerNumber in this explanation but that is not called like that in the code ) handles all the trainers for now.But what I was worried about was that adding a table of coordinates would be stupid because it would be saving data by adding data, but now, seeing how Deeph compressed my map, I think that the table of coordinates won't be over 9000 so it would still save space, so it is a good idea
Quote from: Hayleia on March 16, 2013, 03:13:27 amNo, I have more than 77 tiles. I see a "r1<229" in the code, and even if there are some blanks somewhere, I think it is still over 127 For the trainer, there are two kinds of them: the ones that you must beat (they are blocking the road) and that can beat only once, and the ones that you don't have to beat, but you can beat them as many times as you want. For the ones blocking the road, yeah, you have to beat them in order.Why do you have so much tiles ? To handle events ("teleportations" etc...) ? This said, the datas I posted earlier may not be usable : I haven't check if the tile ID was under 127 before changing its 7th bit, but without doing it the map is still compressed to 80% (2220 bytes) :Spoiler For compressed map only using horizontal RLE: <snipped again >
Quote from: Hayleia on March 16, 2013, 03:13:27 amFor the compression, wow, that is very compressed What could be possible, instead of having it divided in parts, would be to have it in one compressed part but uncompressing small parts, this way, there would only be one map file and not too much slowness (only when going from one part to another) Yeah I guess you can do it before teleporting the player, you'll just have to define the small areas before.
Quote from: Hayleia on March 16, 2013, 03:13:27 amNo, you don't walk on top of a trainer to battle them, you walk on the dots right in front of them And yeah, my only variable (that I called TrainerNumber in this explanation but that is not called like that in the code ) handles all the trainers for now.But what I was worried about was that adding a table of coordinates would be stupid because it would be saving data by adding data, but now, seeing how Deeph compressed my map, I think that the table of coordinates won't be over 9000 so it would still save space, so it is a good idea If you don't plan to complexify your current system there's no need to add tables, but to my part I think I'm going to handle trainers as events (every step the players does, I'll check if it's in the sight of some trainers, this way I could even handle moving trainers).
Yeah, teleporting carpets and doors for example, all have their own number.
What could be done for them would be a stupid thing like ".db 1,door". That would of course waste one byte since that won't use the 7th bit trick, but they are not so many. And carpets usually go by two so that would be ".db 2,carpet" which doesn't waste anything And the 7th bit trick would be reserved to more usual tiles like trees and such, with numbers under 127
I think that they would not be very complicated, like squares, all with the same dimension and all A separation could be right in the middle of a town but I don't think uncompressing will be too slow since nothing happens during that process. I recall the true Pokemon Yellow having small latencies at the border of towns (where the color of the environnment changes) and I guess it is because they must use this kind of uncompression.
But how will you handle the fact that trainers can have different range of view ?
Quote from: Hayleia on March 16, 2013, 12:34:56 pmYeah, teleporting carpets and doors for example, all have their own number.You mean each one, right ? Cause I think you can easily guess which door (with the same tile for all, if that's not the case) the player have crossed by comparing its coordinates (x*y*map width) with a list like that : ".dw door_01_coordinate,pointer_to_teleporting_handler_01,etc...".Don't know if you can do this in Axe, though.
Quote from: Hayleia on March 16, 2013, 12:34:56 pmWhat could be done for them would be a stupid thing like ".db 1,door". That would of course waste one byte since that won't use the 7th bit trick, but they are not so many. And carpets usually go by two so that would be ".db 2,carpet" which doesn't waste anything And the 7th bit trick would be reserved to more usual tiles like trees and such, with numbers under 127 Yeah but take care not to have the same tiles repeated horizontaly more than 127 times, else it will mess up the decompression (for example, you can't differenciate 143 tiles with the tile #15 alone, in both cases that'll give %10001111).
Quote from: Hayleia on March 16, 2013, 12:34:56 pmI think that they would not be very complicated, like squares, all with the same dimension and all A separation could be right in the middle of a town but I don't think uncompressing will be too slow since nothing happens during that process. I recall the true Pokemon Yellow having small latencies at the border of towns (where the color of the environnment changes) and I guess it is because they must use this kind of uncompression.Uncompressing the beginning of the datas is fast, but not the end, that's why it would be more convinient to do it while teleporting the player.
Also, you wrote x*y*map_width, but I assume that the first "*" is meant to be a "+" right ?
And I thought about something that could work too, since usually, doors are coupled by pairs, one leading to another, so this would be possible, where 2n is the number of doors:-having a list like that door(1)coordinates,door(2)coordinates,...door(n)coordinates,door(n+1)coordinates,door(n+2)coordinates,...door(2n)coordinates-then, when you hit the door k, it teleports you to the door k+n or k-n (basically the door k+n modulo 2n I guess)
Well, It will be slower for the "end" of the map but I think it will be still bearable for users to have a little map change sometimes, if that is not too often, that should not take more than 2 seconds Else, there could be 2 decompression routines, one uncompressing "from left to right", the other one "from right to left', this way, it will be slower in the middle but still quite fast everywhere
Quote from: Hayleia on March 16, 2013, 02:13:52 pmAnd I thought about something that could work too, since usually, doors are coupled by pairs, one leading to another, so this would be possible, where 2n is the number of doors:-having a list like that door(1)coordinates,door(2)coordinates,...door(n)coordinates,door(n+1)coordinates,door(n+2)coordinates,...door(2n)coordinates-then, when you hit the door k, it teleports you to the door k+n or k-n (basically the door k+n modulo 2n I guess) Yes it would work, but in my case I'll need to know the map ID too.
Plus I was thinking of placing teleporters to the same pokecenter (to win space) through the whole game, so it won't work whithout some more datas (where was the player before enter...). Currently you have as many pokecenters as towns, right ?
Erf, I've just found a bug in my compression program, which caused to misread hex numbers... Looks like the compressed map using horizontal RLE+7th bit trick+more than 127 tiles will finaly takes 4712 bytes (57%, and RLE only will take much more) Though, that's not that bad Spoiler For Compressed map using horizontal RLE+7th bit trick+more than 127 tiles: <hey, what did you expect >
Quote from: Hayleia on March 16, 2013, 02:13:52 pmWell, It will be slower for the "end" of the map but I think it will be still bearable for users to have a little map change sometimes, if that is not too often, that should not take more than 2 seconds Else, there could be 2 decompression routines, one uncompressing "from left to right", the other one "from right to left', this way, it will be slower in the middle but still quite fast everywhere Yeah it would work, but you'll have to know when to use which one.
I still think that using small maps instead of a big one can allow you to gain speed and space.
I play pokemon like I breath. I'm good at it and I do it all the time. I played this game hardcore and within about 5 hours I had impressive stats. I was sad when the game maxed out!
Lolnope, I only have one PokeCenter. See the map in this post, you can see the only PokeCenter in the bottom left corner
And I thought about it during this night (), I discovered that there will probably be problems for the right to left uncompression due to the 7th bit trick
Yeah, And I thought about something, there is no need to be several appvars in fact, just several maps in one appvar. This can be done easily if you know how much space takes every compressed map. Well yeah, that can do it
I've finally done an encoder/decoder that works So the final size is... 3726 bytes (66%) I had to be sure this time (), so I've managed to create a program that generates an image of the decoded map, and here it is :Spoiler For map: There are some tiles messed up because of the way I ripped them, but the compression works.Of course you'll need to know how you'll handle map in the hypothetical future versions of Pokémon Topaze, so this may not be helpful, at least immediatly.Otherwise this could help programing a map editor on PC, just like the one I use for Pokémon Monochrome, or the one I've done for project "juego".If you want to see how the encoder/decoder works : Pokémon Topaze RLE+7th bit encoded map.zip
Quote from: Hayleia on March 17, 2013, 06:21:24 amLolnope, I only have one PokeCenter. See the map in this post, you can see the only PokeCenter in the bottom left corner So how do you handle returns ? You're saving the player coordinates somewhere I guess.
Quote from: Hayleia on March 17, 2013, 06:21:24 amYeah, And I thought about something, there is no need to be several appvars in fact, just several maps in one appvar. This can be done easily if you know how much space takes every compressed map. Well yeah, that can do it And if you don't want to stop the scroll when the player reach the limits (like I'm doing in my version), I think you can make a routine that outputs a black tile if the mapper is asking for a tile which out of the map (this way you wont need to have so much $19 ).
Thank you for recommending I hack it! I'll get right on it! I immediately just decided to use calcsys to get by, but I love to spend some time hacking someone elses code!
Yeah, there are some messed up tiles (where are the doors ? ) but it seems to work pretty well anyway
So what do you plan ? Making an asm version or improving the axe one (maybe later) ?
Well restarting all in ASM would be quite hard o.o
Author
Topic: Pokemon Topaze (Axe) (Read 138619 times)
