As to that last part, that is exactly what I assumed. I certainly don't want to slow down your progress with my unessential pursuits!

As to the first part, I don't have a problem with the 'I' because I drew the sprites as silhouettes, due to the monochromatic nature of the device.
Therefore, Ash walking north and Ash walking south look the same, because his face looks exactly the same as the back of his head. I'm very glad you used two different characters for east and west, though, because those sprites I drew definitely look the coolest.

EDIT: Ok, good news. replacing the characters with graph link seems to work!

Here is a screenshot:

Ash is standing in the tall grass, facing right.
Also, I found out that there are way more unique characters in the game than I though! The best part is that many of them use extended character space values already, so I don't need to do anything but edit the font to make things like the SNES look like a SNES, and so on.

Now for the bad news. It seems like the program derives its logic directly from the text string, meaning that if I change the actual value of the characters on the map, the program doesn't know what kind of tile it is anymore. So that means, in order to make it playable, I need to know which programs contain the assignments of characters to tile types. If I find that out, though, everything should work flawlessly!

I have not looked at that part of the code for sooooo long... >_< I am not sure which program would need to be pointed to. You would need to look at prgmZGA and see what program gets pointed to when K=21.

Well My suggestion would be change all the letters you can and any you can't change leave as is since they would look fine anyway. and that way you can either use the font set or not depending on your preference. basically go through the maps and change any non-text used characters to your updated sprites but leave the rest as is, yes it won't look as good but it'll mean less work for tifreak and you, or just you as the case may be.

Yeah, for the time being, I am sticking with the ascii character maps. I am thinking the omnicalc version can be its own version with that.

Now I'm working on simply replacing all the characters, completely ignoring preserving the text. I figure it will be a lot easier to just overwrite a few strings with the unused lowercase characters or something, rather than re write all the maps.
The other benefit to doing it this way is that you don't necessarily have to download a whole new set of programs to use it, all you have to do is install the font.
This should mean that Ti-Freak will never really have to worry about it again, and I can just put the fontset in the archives or on ticalc for anyone to use.

I always though it made more sense to guarantee that omnicalc etc. be optional for basic programs anyway.

I promise, I have not been super lame for the last bit. Here is a screenshot to prove it!



Working next on getting it to see the pokeballs...

Is that the speed it goes at for the final version?

That is how fast it is going at this point. This is far from being the final version, so it might slow down or speed up by that time. But at this point, it is holding up fairly well on the 83+SE.

So, all of that is 8%? No offense, but I thought it was actually going to look like pokemon red or something, because I saw a video on youtube where a guy has pallet town or something, and it actually looks like the real thing.

It is Pallet town, just with ascii characters. There is also something slightly separate that utilizes a font pack to work. That is not something on the priority list until more of the game is completed, which hopefully won't be too terribly much longer...

Yes, I know it is pallet town, what I meant to say was, there was a version that also only had pallet town, but it was almost exactly like the original pokemon version in the way it looked.

Plus, what's ascii?

ascii is essentially letters and such.

As to the version you are talking about, that was the old old version, which used 8x16 map segments, where this uses scrolling maps. Makes it look nicer, in my opinion.

I don't know. That one looked pretty good.

Well, that engine used ascii characters as well. I ran into a problem with plotting how to use the Strength feature. I am still not 100% on doing that for different levels, but I will get it figured out.

Oh yes, that screenshot shows that the NPC that is not part of the map is kept track of and can be removed from the map and show back up correctly.

I see. However, when you finally finish the game, will you go back over it and make better graphics?

I am going to be working on the battle after I can get you to get the starter pokemon. I also have to get it to register items, and alot of other stuff, before I get the next demo out.

Also, I would ask that if you need to add something to a topic that is less than 24 hours, please edit your post.

Look, I worried about that too, so for the time being, you can try the "font replacement" (see the thread in this sub-forum) with the latest beta from tifreak's site. I haven't updated it since a few key elements fell into place, but it still looks somewhat prettier. Take a look at the screenshots.

Remember the calc's screen resolution is very low, so I think sacrificing the size of the sprites to fit more map on the screen was a worthwhile tradeoff on tifreak's part.

Swoll, please try to avoid any double-posts within 24 hours of each other; either edit your post or wait 24 hours before double-posting to bump the thread to the New Posts page. And I think he's doing an admirable job with graphics for what he's working with and the space/speed constraints he's trying to meet.

Ok, with all these other posts out of our system, what about the screenshot itself? Anything you see you like or dont? Do you think the dialogue is ok? Anything that I should change at this point?

Watching the character sprites draw is practically painful when I know there is a much faster assembly routine that you want to prove you don't need to use.

It is by all means quite a feat that you can draw images from compressed sprites so quickly using only basic, but the assembly routine is just so blindingly fast that I think it's worth implementing (and that means doing, or having done, the work that is needed to modify the asm sprite drawer to work for this purpose as well), even if it means the hard work you did to get the basic routine working never makes it into the final version.

Other than that, I think it's great. After the initial drawing of Oak and Gary, the conversation progresses snappily enough, and seems true to the original.