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)
Yes it would work, but in my case I'll need to know the map ID too.
This is why I wanted to divide the map in equal squares so the "map ID" can be obtained directly with the coordinates of the player
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 ?
Lolnope, I only have one PokeCenter. See the map in this post, you can see the only PokeCenter in the bottom left corner
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 >
Yeah, that is still half the size it originally takes
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
Yeah it would work, but you'll have to know when to use which one.
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
I still think that using small maps instead of a big one can allow you to gain speed and space.
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 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!
Lol ok, then I think what you could do is a savegame-hacking program to get back to a level under the max I should have put You'll see, my savegame is quite well organized at the beginnig so you won't be lost if you try I should put that max in my todo list too -.-°
Yeah, 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.
Yeah, for now each one has a specific tile number. And of course your method is doable in Axe, everything that is possible in ASM is possible in Axe, the differecne is just a matter of speed (like a raycaster might not run very fast in Axe but it would still run). 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)
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
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).
Yeah, in that case, if n is the number of tiles, I would just do ".db 127,tile,n-127,tile"
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.
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.
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
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.
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 >
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 should put that on my to do list as soon as I get on the right PC -.-°)
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)
Yeah I guess you can do it before teleporting the player, you'll just have to define the small areas before.
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.
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
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).
But how will you handle the fact that trainers can have different range of view ?
Ok now someone has to explain me this. I posted once in "Pokemon Topaze" and once in "Hello, from Earth" and Omnom said this: *|Omnom post by Hayleia in Pokemon Topaze (Axe) http://ourl.ca/9844/287666 *|Freyaday has quit IRC (Leaving.) DJ_O |p.p *|Omnom post by Hayleia in Hello, from Earth! http://ourl.ca/15922/287667 *|Omnom post by Hayleia in Pokemon Topaze (Axe) http://ourl.ca/9844/287666 *|Omnom post by Hayleia in Hello, from Earth! http://ourl.ca/15922/287667 Hayleia |eh ? What happened ?
Hey, admins! Wanna help me with my username? It obviously has a problem: I've somehow switched up my username and email! OH NOES!
Now that you have more than 5 posts, I think that you can PM an admin so that your username is changed. Usually, people can't change their username easily but since you have a legit reason, they should access your request
The game has no protection against continuing a game without having started one, which makes for an interesting way of exploring the RAM contents of the calculator
Yeah but why do you try to continue a non existing game ?
The game, after maxing out any stats past 255, will set them down very low.
So, if I have a Pidgeot at level, say, 75, it's health will be so high, it will be (something like, this is just a random guess) 287 and thus it rolls over to a number like 287 - 255 = 32. I don't like going into battles against level 50 pokemon and losing my best one in the first hit.
Well your health will only get to 255 when you get to level 85, and I didn't expect people to get this far So yeah, I should add a protection to it.
For now, every trainer has a tile number, let's say from 1 to 50 for example (in fact, I think it starts at 171 or some other ugly number ). So when you walk on a number between 1 and 50, if the number saved in {TrainerNumber} (smart name isn't it ?) is lower than the tile number you walked in, well battle, and when you beat the trainer, {TrainerNumber} increases. And if {TrainerNumber} is greater than the tile, then you already beat the trainer and there is no more battle
How many tiles you really have ? Cause if it's under 77 (which is pretty much sure), then you can stick with your system and use rle compression.
Elsewhere, you have to beat all the trainers in a certain order, right ? I don't remember if the progress through maps was kind of linear, but if so, then it's not a problem.
I've compressed your map using horizontal RLE+7th bit for "lonely" tiles and (if I'm correct)... it compressed up to 85% (from 10948 bytes to 1723)
Spoiler For compressed map:
<snipped >
But keep in mind that the speed to read it on the fly will really depend on the tiles you're trying to reach... That's why dividing it into smaller parts would help.
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)
I'm not quite sure how your trainer system works. It sounds like you have to walk on top of a trainer to battle them? What is TrainerNumber? You use one variable for every single trainer? One way you could do it would be to use a single tile for every trainer, say tile 85. Then you could have a table listing the coordinates of each trainer and possibly a pointer to the trainer's sprite. Actually, you really don't even need a special tile, especially if you divided your maps into smaller pieces. With each map segment you would pass a pointer to a table that contains the coordinates of the trainers. When the trainer is on screen, just subtract the trainer coordinates from the map coordinates and draw them. You could use the same table for NPCs, and since in each little map section (each town/route) there won't be that many trainers/NPCs, you could load the table into RAM and change the coordinates as you please without worrying about modifying the data in your program. That way you could have NPCs that walk around, trainers looking in different directions, etc.
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
But how will you check with coordinates ? because I guess that you won't have a "If X=... and Y=..." for every trainer, will you ? Or maybe having with another data list with the form "x1,y1,x2,y2,...,xn,yn", and for every trainer, finding the k so that X=xk and Y=yk would be possible, but once again, wouldn't adding a data list be in opposition with the aim of saving space ?
How are you handling that right now ? When the player has beaten a trainer, you have to save it somewhere, right ? Not by modifying the map itself I guess.
That said, using a single tile for all trainer may not be the most optimised thing to do whereas using differents one per trainers and per maps might be better (and takes less than 127 different ones)...
I'll try to encode your map just to see how many bytes you can gain.
For now, every trainer has a tile number, let's say from 1 to 50 for example (in fact, I think it starts at 171 or some other ugly number ). So when you walk on a number between 1 and 50, if the number saved in {TrainerNumber} (smart name isn't it ?) is lower than the tile number you walked in, well battle, and when you beat the trainer, {TrainerNumber} increases. And if {TrainerNumber} is greater than the tile, then you already beat the trainer and there is no more battle
Yeah, my post about the Nspire got ignored there, even though it was defending both the Prizm and the CX (CAS or not).
Well, I'd say that it depends on what you want to do with your calc -If you want to play the best games, buy a CX (CAS or not) since it has a GBA emulator. -If you want to use your calc for maths, buy a CX CAS for... well the CAS -If you want to code on it, well here is the problem, because as you know, the Nspire is closed while the Prizm isn't. So it is your choice here, wether about openness or power
Also, welcome to the forums Dapianokid, you can introduce yourself here
Yeah, I figured out that it would look like something like that, and it took me an entire week to code the tilemapper in ASM, hence why I said that I could not manage to code another piece of code with two "for loops" one in another Or there might be a way to get it with only one "for loop" by putting x and y in one number (like a=y*256+x or something). Or maybe you were not thinking about me making this in ASM but in Axe ? That would work
You can do it in both asm and axe, and if you need help to do it in asm, you can create a topic and post your current code.
Yeah, I always forgot about the possibility of asking for help in ASM because when I coded in ASM, I didn't know about Omnimaga. As soon as I discovered Omnimaga (because of a problem with TI-Boy ), I learnt about Axe and switched to it. But yeah, I'll ask for help whenever I need it now
I don't know how you handle trainers right now, but for my part I think I'm just going make a list of them (within the players datas), and modify it when they are beaten. When the player will past by the trainer's tile (the same for all), I'll just check from the coordinates who it is.
But how will you check with coordinates ? because I guess that you won't have a "If X=... and Y=..." for every trainer, will you ? Or maybe having with another data list with the form "x1,y1,x2,y2,...,xn,yn", and for every trainer, finding the k so that X=xk and Y=yk would be possible, but once again, wouldn't adding a data list be in opposition with the aim of saving space ?
That could work to optimize the map, but for all the methods, there is to choose between compressing the map and adding code to uncompress it, or saving code with an uncompressed map, and for this method, I feel like keeping track of all maps and get to know which one the player must go to would add more code than it saves space
Yeah in axe maybe, but in asm I'm sure you'll gain space even with some more code to handle different compressed maps. 10ko only for maps is kind of huge, and as far as I remember Pokémon Topaze maps weren't that vast, no ?
Depends on what you call "vast" Its dimensions are 119x92 (which takes a bit more than 10000 bytes uncompressed as you see), counting all the filling "zeroes" which are in fact "19" in hex
counter = 0 for x=0 to screen_width/tile_width for y=0 to screen_height/tile_height tile_number = offset_x+x+(offset_y+y)*map_width while tile_number-compressed_map(counter) > 0; substract the current length of same tiles to our tile ID until zero or less counter+2; to get the next length of tiles end counter+1; to get the tile number draw_tile(x, y, counter) end end However with chickendude's tip you'll have to check the sign flag first, and if it's on, only increase the counter to 1, unless that's the tile we want (if so, reset it).
Yeah, I figured out that it would look like something like that, and it took me an entire week to code the tilemapper in ASM, hence why I said that I could not manage to code another piece of code with two "for loops" one in another Or there might be a way to get it with only one "for loop" by putting x and y in one number (like a=y*256+x or something). Or maybe you were not thinking about me making this in ASM but in Axe ? That would work
There surely is, but I didn't find any way to do it without modifying the map
Why won't you want to modify it ? That's the only way to optimise it
But how do you start a new game ? You have to restore the map, and "the only way" to do that is to have a copy of an untouched map somewhere, so I thought that instead of having 2 different maps, one untouched, the other one being the map for the current game, I'd only deal with one map that never moves.
I think you can still use the same system (each trainer = a tile) if you divide the map into smaller ones, this way you can reuse some tiles for different trainers, and to check who it is just compare with the map ID (you'll have of course to save it with the list of beaten trainer, but it would just take one more byte and will allow you to use less than 127 different tiles).
That could work to optimize the map, but for all the methods, there is to choose between compressing the map and adding code to uncompress it, or saving code with an uncompressed map, and for this method, I feel like keeping track of all maps and get to know which one the player must go to would add more code than it saves space
If your maps didn't use more than 127 tiles, then you could use bit 7 to mark that it's just one tile. Normally you would do something like .db 1,tileNumber, which actually adds a byte. I do: .db tileNumber+$80, which is the same as the uncompressed size. That way your RLE-compressed maps will never be larger than the uncompressed versions.
That's pretty clever ! Using the sign flag this way would definitely save a lot of bytes, thanks for the tip
Indeed, that is a very smart way of saving space However, that won't apply for my map since I use more than 127 tiles Or I could use a special treatment for tiles above 127 since those are quite rare.
Also, I just remember a reason that made me use no compression for my map: I can keep it always archived and still read it.
However, I disagree with Hayleia: I don't think that the topic should be renamed (much less moved) until, at the very least, the emulator can run TI's OS and a number of third-party programs.
Yeah, it is true that it is still in early stages. Renaming (but I never mentionned moving the topic, only renaming) the topic could give more motivation to Jacobly but it is true that it could also give hopes to people for something that is not (yet) complete. So, yeah, the developper chooses according to his need for motivation
Yes using the 84+ keypad is possible. I already have a 84+ key-mapping written, but I don't know how to detect the type of keypad if it changes while a program is running.
Ah, you're finally posting in this thread, I can give you another +1
However, I only clicked on this thread because I knew you were working on an emulator, but I guess some people think it is yet another discussion about "when will an emulator come ?", so I think it would be a good idea to change the title into something more appealing, like "Finally a z80 emulator for Nspire !"
Yeah, the map is in one block. Why would dividing it in small parts take less space ? And how to use RLE on a map that takes values between 0 and 170 ?
Because I believe you've filled the space between maps with 0 just to make sure that when we scroll near the border of a map we don't see another one, no ? Also, you're really using 170 different tiles ? I don't remember seeing such a diversity on maps
Yeah, it is true that I have a lot of zeroes in fact. But since no part of the map is a perfect rectangle, there would still be some waste even with divisions. And in fact, I even have tiles using numbers up to 229 Each trainer that you have to beat (those who block the road) have an associated number. This way, when you bet them, you don't have to beat them again. Maybe there is a better way to code it but for now, I have a lot of numbers
The real problem was that the routine I found (don't remember where) that handles the keyboard was a pain (used groups of keys or I don't know what)
That's direct input, which is fairly well explained in a lot of tutorials (for example : http://tift.tuxfamily.org/asmpourlesnuls.html ). It's not that hard to understand, the thing is that the keyboard is divided into parts, and you have to specify it to the keyboard port before reading a key state.
Yeah, it was well explained in the tuto I read, so I managed to get the movement with arrow keys. But my program only used arrow keys, which are all in the same group so it was not hard yet. But I knew that going further into programming would have brought some more difficulties, of course not unbeatable but still
Aww man, I just looked around in my ASM folder, reading some old code, and it brought back so many memories, when I was full of hope, thinking about coding Pokemon Topaze in ASM And I just ran that scrolling-map program again, it really works well and all I think I should try ASM again some day, I just need to find a proper routine to handle keys
You still can, just to be able to play it on a TI 76.fr
Also, you should try to read other's code, it helps a lot (you can look at mine, but it sure isn't as commented as it should be). And don't hesitate to ask for help here or on french forums, it's always good to help people join the restrained circle of asm z80 programmers
Lol, why would I play on a 76.fr when I have a 83+ and a 84+SE ? And I am not sure that reading other's codes would help a lot seeing how hard it already was to understand and debug mine when I made it But yeah, if you know some overcommented code that I could read, that could be useful for me or others And yeah, if I ever try again, I won't forget to ask for help whenever I need it