The way I do it is a rather roundabout way, since I built it using structures provided by the E:SoR menu system and rendering routines. I'm basically using a piece of the game's "textshadow" buffer as an array.

The way you should probably do it is to keep your table in something like a matrix or some 2D array. This table should be completely independent of the image you're supposed to be making, but... the contents of this array should be something like sprites where an empty tile would be... well. Empty. A [ ] tile would be some other value, and x tiles would be yet another value. When you go to compare the contents of the game area to the image you're supposed to be recreating, just recreate a binary of the image given your [ ] tiles versus your non-marked tiles. Non-marked would be 0 and [ ] tiles would be 1, where the x tiles would be ignored in the reconstruction of the image.

Should the image match what you have, then you've won the game. If you are trying to do something like a timer and penalize the player for incorrectly marking a tile as [ ], then you should try something like the following:

After you have reconstructed the image, compare it against the original in this manner:

(original xor playarea) and playarea

If there's any nonzero things as a result of that operation, then you know that a player tried to chisel out a tile in the wrong spot.

At any rate, and to attempt to answer your question...

I find it better to keep your images as a binary, and your play area as an array. Only when the array changes between a marked [ ] tile and an unmarked tile, should the array be silently converted in the background back to a binary file and compared directly between your source or solution image.

Some of the coding has been done. Those screenshots are of the actual engine doing its work. Well... it's what's been done of the engine. I've also got the cursor to work and it lets you chisel tiles. It also lets you mark them if you know they're not valid. It also locks out the tiles so you have to revert them to blank tiles before you can change their status, so you don't accidentally chisel out tiles that have been marked off for not chiseling.

I don't actually know what the appropriate terms are, but I'm basing these terms off of the Mario's picross (GB) thing that I saw a YouTube video for.

So, me and geekboy have been talking on IRC about making a 2D Picross clone. For those who are unfamiliar with it, you can find results by either Googling "Picross" or "Nonogram" (which seems to be what it's supposed to be called). He said something about making his entry in Axe and my entry as an App.

So, if you're looking at the breadcrumbs above the topic, you're probably gonna wonder why I posted this under the E:SoR subforum. The reason behind this move is a bit of a stretch, but bear with me.

I intend on using a modified version of E:SoR to build the game. This modified version was originally built for a rickroller, found here: http://ourl.ca/4114/75957

Source is included in it so if you know what you're doing, you can beat me to the punch. So... what do you think?

EDIT: To clarify, I'm only intending on doing this thing. The link to source was what I'm working with to make this game.

EDIT2: For a download link, find the attachment on this post: http://ourl.ca/7598/135642

Bump. Small bit of progress. (crossposted to Cemetech)

Working on an automatic re-target function for E:SoR's battle engine. The specifics are as follows:
1. Obtain target flags for those that are still alive.
2. Invert flags if you're trying to target the dead.
3. Compare (AND) with what you are actually trying to target.
4. Load target flags back to attack slot and return IF the AND function returns nonzero.
5. Attempt to re-target based on probable use (i.e. If target a character who's dead, try someone else)
6. If attempting to find a target fails, change character action to "Parry". Note that this *can* happen under certain circumstances without the battle engine declaring victory or defeat.

So... Yeah. I haven't got point #5 down quite yet. Point #6 should be easy once #5 is done.

...

Quote from: ztrumpet on October 11, 2010, 09:15:05 pm

I am 100% sure that the TI-83+ to TI-84+SE run Apps directly from Archive.

Hmmm, that actually wouldn't seem very smart in a first glance, but it might make a little sense actually. It's a cheap solution. Z80 is kind of slow (compared to today's ARM and SuperH) so the CPU wouldn't be outrunning the Flash and the programs aren't extremely large (like 100KB or bigger) so not much reading would have to be done.

EDIT: Wait a sec, I don't see how this is actually possible. A Z80 has a 16-bit parallel address bus with an 8-bit parallel bus to load in 1 byte for each cycle. With 16-bit's for addressing, the Z80 would only be able to access the lowest 64KB of Flash max. Well, unless the Flash is split into 64KB memory banks and you access each one separately. Or the Z80 has been modified to have it's address bus extended beyond? And since it's running off Flash, is the data bus on the Z80 swapped or disconnected by a multiplexer and connected to the Flash's data output? But then the RAM would be disconnected and there would be no memory for stacks and variables. Or is it 32KB for program instructions and 32KB for program data (variables and stacks)? Or a 48KB/16KB memory map? I'll have to go read around for a bit.
...

On the TI-83 Plus/TI-84 Plus, executing programs from FlashROM is indeed possible. These models don't actually use a physical Z80, but rather a SoC that has additional hardware that does things beyond what a normal Z80 would be doing. Example: Memory-mapping "pages" of FlashROM in 16KB chunks to sit evenly with the Z80's 64KB physical address space. Memory is arranged in the following manner:
First 16KB: First 16KB of FlashROM
Second 16KB: Some other 16KB "page" of FlashROM
Third 16KB: First (or second?) 16KB of RAM
Fourth 16KB: The other 16KB of RAM. In other models, this too is swappable with some other 16KB chunk of RAM.

In every case, the calculator maps in 16KB of whatever memory is needed at any given point in time. The only thing that isn't user-remappable in the TI-84 Plus series is the first 16KB of Flash, which is where the more important stuff of the OS sits.

Now. I'm not entirely sure *how* the calculator performs the pageflips, but the second 16KB of physical memory is controlled by outputting a page value to I/O port 6, and the third 16KB of physical memory is controlled by outputting a page value to I/O port 7.

All "FlashAPPs" are executed in the 0x4000-0x7FFF range (2nd physical "page"). Multipage apps are achieved by changing the value of port 6. For some obvious reasons, your code shouldn't be executing code on that page during a pageflip, but if you've coded your app creatively, you can change it that way.

For more information, see TI's SDK found here: http://education.ti.com/educationportal/sites/US/productDetail/us_sdk_73_83_84.html

----------------
TL;DR: The calculator divides memory up into 16KB chunks. Ports are used to extend the calculator's ability to address both RAM and FlashROM by remapping them into the Z80's 64KB address space. It's the best they could do with the Z80. We're not complaining (much).

To address another concern, the calculator *is* slow enough (even at 15MHz) to run programs directly from FlashROM without needing to insert "wait cycles". Or rather, the Flash is fast enough to keep up with the Z80.

Heh. I don't think the TI-83 Plus model is going anywhere anytime soon. Removing that off their product lines would alienate too much of its userbase and potential users. I'm talking about those who are comfortable using the Ti-83 Plus graphing calculator and the various institutions that will not teach how to use other sorts of graphing calcs (probably because they don't know anything else?) I will not believe the idea that the Nspire will fully replace the Ti-83 Plus, even if for the simple reason that it just does not look like a TI-83 Plus.

The TI-84 Plus (SE) however was more like an upgrade to the TI-83 Plus that can easily (from their standpoint) be replaced by the other thing with similar (emulated) specs. They can afford to move their product line "forward" toward the Nspire much like how they did it to the TI-83 Plus SE toward the TI-84 Plus (SE)

While I do not support the move, I do see the logic behind them discontinuing the TI-84 Plus (SE) model. Nothing's gonna happen with the Ti-83 Plus calc.

I'm just a little unhappy by these discontinuations, because the E:SoR project kinda relies on the extra hardware that's found in the 83+SE/84+(SE) calcs. CaDan, not so much.

Minor update on the details. To ease a few worries, project files are going to be kept in appvars. Their names will be automatically generated by the app, but when you view them in CaDanITE, you'll only see the description (up to 24 characters long) that you gave the project files. You should be able to delete project files from there, if it comes down to it. You may not want to, but just for completeness sake, might as well.

Even though all project will be kept in FlashROM, I'll demand of its users to have at least 24KB of RAM free. You know. Just to make sure you can continue editing files while they are in RAM. Files in FlashROM aren't actually edited until you save your project, so you can decide to do things like discard any changes you make. What you are actually editing is a temporary copy.

Since this project file is going to act as a miniature file system, I was thinking as to whether or not to allow to remain in the project after it's deleted so you can use them again if you change your mind. If I go that route, I'll include ways to clean out unused items.

What do you guys think?