by vertically aligned, will this change the way grayscale is displayed? I mean, for example, will the grayscale scanlines will be vertical, literally? Also was 4x4 tilemapping very hard to implement? Knowing tiles are generally a multiple of 8 for width

Graphics will be displayed as usual. I don't know how it will flicker. Because the interlace now is done vertically scan lines are vertical. I guess yes. But if you manage to get them out, no problem.
Only memory of the graphics is arranged in different manner. It seems in a more efficient way.
Changing from the usual horizontally to vertical aligned is like transposing a matrix. (columns pass to rows and vice-versa)
For example in a 9 pixels square screen. Horizontal aligned looks in memory like: (look at pixels coordinates) (x1,y1 is top left corner)
x1y1,x2y1,x3y1
x1y2,x2y2,x3y2
x1y3,x2y3,x3y3
Vertically:
x1y1,x1y2,x1y3
x2y1,x2y2,x2y3
x3y1,x3y2,x3y3
But the way it is draw to screen will make look the same.

(2) The text routine is being handled by a 4x4 aligned tilemapper. That has been verified to work so I'm filling it with the text needed to render all in-game text. It turns out that all objects are aligned in this manner, so I can have what I like to call a "textmap". The menu borders are being coded in this way, and has already been demonstrated to work.

ASCII map in grey ftw. xD
 Actually, from LL1 I discovered that making a custom font set with menu borders, special symbols (like a hand, sword, bow, etc..) makes things simple and nice.

the scanlines result from the masking pattern.  that is, which pixels are displaying the "light" plane and the "dark" plane.  Because of the way the planes and masks are alternating, you get scan lines.  correct me if I'm wrong.  as a result, there might be very little difference in terms of said scanlines.

vertical is good because the default setting for the LCD port is to do the first 8 pixels and then the 8 pixels below (auto increments via columns).  I'm pretty sure you could change it to match horizontally aligned (normal way of setting up a buffer), but iirc every routine (like text and MOST IMPORTANTLY sprite routines) is defaulted to this set up.  

good choice Iambian!  taking a page right out of crash.

Where are the pictures for this game btw?

Quote from: Iambian on June 08, 2009, 11:44:33 pm

(2) The text routine is being handled by a 4x4 aligned tilemapper. That has been verified to work so I'm filling it with the text needed to render all in-game text. It turns out that all objects are aligned in this manner, so I can have what I like to call a "textmap". The menu borders are being coded in this way, and has already been demonstrated to work.

ASCII map in grey ftw. xD
 Actually, from LL1 I discovered that making a custom font set with menu borders, special symbols (like a hand, sword, bow, etc..) makes things simple and nice.

That was intelligent design on the part of Zera, inspired by looking at the ROMs of games like original FF

To answer a few:

(1) Just because the buffer is vertically aligned has nothing to do with the scanlines. The buffer is always rendered top to bottom, then left to right. As in this scheme, the action of doing so is easier. The same interlacing is performed, albeit with a bit more play with respect to clock cycles. Might have to bump up the interrupt frequency at some point to make the gray look better, but as it stands, the gray is good enough for developmental purposes.

(2) The 4x4 aligned tilemap isn't hard. It's a close enough multiple to 8 to work out wonderfully. In fact, to get the half byte, I have each tile copied on both nibbles to take up the full byte for that line. When it comes time to rendering, a side is selected and masked out to get the appropriate side. The two sides are OR'd to provide a full 8x4 tile and four bytes are written out. The scheme that's used is very time-efficient, but rather bulky (as it uses SP to traverse the mapper, and uses shadow registers).

(3) Somewhat similar to (1), the scanlines *are* still diagonal. That is just how the interlacing routine works.

(4) Related to (2), implementing 4x4, as was previously said, wasn't too hard. The coding was rather straightforward, with some paper notes used to enhance the logic used for masking. The last bug to be fixed before the thing worked perfectly was a logic error between a combination of a null byte and a tile object in the same 8 bit space. One instruction was changed and another was added and that worked out perfectly. Really, the most time consuming part of this 4x4 tilemapper was NOT coding it. It was actually putting in the tile data (which I retried after some point because of some oddities.

Along with the 4x4 tilemapper, the mentioned oddities in (4) relate more to the 4*8 text. (4 wide, 8 high). Each character takes up two tiles but I knew there wasn't enough tiles in 256 to code in the borders, the small text used for box descriptions, the standard A-Z, a-z characters, a few punctuations, and all of the symbols relating to the inventory and status (4 tiles large). I overcame this by noting that some top and bottom halves of characters matched that of others, so I remapped different characters to take advantage of these similarities. The result? I now have just enough space to do the job.

The downside? Since the whole map takes advantage of the symmetry found in the characters, the line height may NOT be changed for any reason whatsoever. These optimizations were absolutely necessary. Also, I don't want to have to recreate both the entire tile bitmaps AND the ASCII character mappings.

After I finish testing out the routines, I'll make the cursor symbol to start and work on a menu system. At first, it's going to consist of just a moving cursor (which is also aligned to the 4x4 tilemap), just to get on and off of the title screen. Then, it'll be integrating the box drawing routine, the text routine, and cursor selection into a mess that roughly equates to my semi-successful menu system I wrote for my much earlier Cellular Automata project. (Don't ask for a link; UTI's download section is DOWN and I don't feel like asking for the file. Ask for it yourself if you're feeling adventurous. They'll probably honor the request.)

EDIT: Screenshot of the dialog box written via textmapper: http://www.mediafire.com/imageview.php?quickkey=dmlwzkegdz4&thumb=4
Still does not demonstrate the 4x8 text routine yet.

So close to a double-post, too. Anyway, the text mappings have been worked out. A few kinks here and there and here we go: http://www.mediafire.com/imageview.php?quickkey=jtwxzclhmtw&thumb=4

EDIT: Btw, the reason why I wanted to post that was because getting the text onto the map wasn't exactly what you'd call "trivial". The textmap, too, is vertically aligned [but except] by pairs. What that means is as follows:

Typical map:
x1y1 x2y1 x3y1 x4y1
x1y2 x2y2 x3y2 x4y2
x1y3 x2y3 x3y3 x4y3
x1y4 x2y4 x3y4 x4y4

Map in this scheme:

x1y1 x2y1 x1y2 x2y2
x1y3 x2y3 x1y4 x2y4
x3y1 x4y1 x3y2 x4y2
x3y3 x4y3 x3y4 x4y4

*sigh*...

I guess for those that can't view mediafire, here's another link: http://flickcabin.com/public/view/33418

To keep this ontopic, I'm gonna be working on a simplistic menu system. Gotta render the cursor, and then do stuff to select what each option should do. Could get messy, but after whatnot, navigating past the title screen (should) be no problem.

Though no details are given, I could manage a standard 3 slot save system and render it using my imagination. Since there's no provisions currently for renaming a character, I could instead opt for a save slot name. And probably render game location. Not entirely sure, but I'll have to get back to Zera on that once I've got something down. As far as name selection is going to go, it'll be sure to push the whole menu system capabilities. That'll be the real test.

On another note, I'm being asked to render an effect for the title screen, and doing so would be totally a pain now that the buffer is vertically aligned. So, I guess I could do something like that after I verify that much of the game works. You know, code the important stuff now. As for the effect, I'm gonna keep my mouth shut and let you see for yourselves whenever I get it running. OMGCLIFFHANGAR

Today, I rediscover the pain of writing a tilemapper. If it works out right, then 2/3rds of it has been written. The other 1/3rd is the middle part, used to tie the two together. Hope things work out in this more complicated system.

As for the tilemapper, it's a highly customized 16*8x tilemapper. I say that because the tile width is irrelevant as to how the actual drawing process is done. However, 2*8 is going to be hardcoded within the first 2/3rds of the tilemap.

Wish me luck.

Good luck.

I have tried to see Dwedit or Jim BW tile mapper and I got lost in the shadow registers. u.u It had no comments or almost.

It is so many things to keep in mind that you loose track of things.

I figured that since Iambian is going to continue posting progress here that this project deserved its own sub-forum, along with Drak's PotterQuest 2 (hoping he finishes it)