Progress is going along. While Kermmy's out fixing his SourceCoder thing to output something that'll work with E:SoR, I'll be busy working on some of the smaller things like planning out data and filling out pages with them. I think it's going to be nice.

There's not much else to be said until I can get something up and running. Speaking of running, the textmapper works now. And so is the printf macro. Gotta make something that'll be easier to remember than hex digits for the command codes, but it should be good. Minor details and all that jazz.

Guess I should work on the menus?

You should work on menus! Sorry Kermy's been distracted both with personal health issues and with his own projects, especially globalCALCnet.

Sorry if I came off as a bit selfish there.

I hadn't had much time for E:SoR over the weekend, but I did do myself the favor of importing quite a bit of the "important" data from the old project into this one. Works well. And I see why Spencer (I gave him an early copy) said that my utils spat out garbage at the end of the generated source files. I guess I either never noticed them before or TASM glossed over those strange characters.

I suppose before it gets too late, I'd best do something *real* about that menu system. I'm just mulling over the sort of things that I need because the code I had before failed to live up to what I wanted out of it. I mean, it did what I wanted but it was hard to do anything cross-paged with it. What I'm really trying to think about is determining how much of the system needs to be tied to one page and how much can be allowed to roam free across the other pages.

Nono, no sarcasm intended, it's my fault that I'm not good at balancing my time between different projects. What do I need to fix about SourceCoder's outputs again?

To recap, the new grayscale interleaved thing works just fine. What does not work is the vertical alignment, and I was wondering if you could also do interleaving and vertical alignment at the same time. It would rock.

I'm still among the living, as well.

Iambian and I seem to have opposite IRC schedules at the moment, however... My internal clock is really sporadic lately.

I believe I've done this now; I hope it works and that I didn't break anything. Let me know at your convenience.

I'll be trying it out shortly. I wanted to get the new menu system out of the way. Just the system. I haven't tested out all of its shiny new features yet, but I will when the time comes to use them. At this point, I'll know it's a bug in that if it comes to it.

So I suppose I'll be reconstructing the main screen and stuff. I suppose now would be a great time to write and test a variant of pucrunch that'll let me decompress stuff in the background. Thank goodness for this strange but wonderful interrupt scheme

So it turns out in the end you went with another program, which is fine. How goes this stuff now?

It goes well, thanks for asking!

I'm reconstructing the title screen and getting much of what was originally in the project into order. After all the preparation with the little subroutines and details of how the new thing is gonna work out...

It is quite refreshing to pull together the elements of the title screen into something displayable in a short order. So there. I'm pretty happy with the way things are turning out.
----------
Also, I lacked a small bit of foresight with the cross-page call, not realizing that the same code would not do for a cross-page jump. I found a nice segment of (somewhat) unused RAM to stick the much simpler cross-page jump routine. For the curious, a link to the code: http://iambianet.pastebin.com/VQ1cYzG0

That's some very nice code! I do the most disgustingly hacky thing for cross-page jumps in Doors CS. It's so terrible that I'm not even going to share what exactly it is. I'm happy to hear that everything's coming back together!

The hardest thing to bring back together is going to be the tilemapper. That thing was hacked together in the most horrendous way, and I feared I would never understand enough of it to copy and paste it into the new project.

After a good night's rest from mulling over this thing, I've finally found my way, so I'm hoping I won't have to rewrite the parts that made the tilemapper go.
------------
For technical details, imagine the following scheme:
Interrupt cycle 1 = LCD/tilemap draw
Interrupt cycle 2 = Slot 1
Interrupt cycle 3 = LCD draw / tile rotation
Interrupt cycle 4 = Slot 2
Interrupt cycle 5 = LCD draw / tile rotation
Interrupt cycle 6 = Slot 3

A number of tables are prepared in the other variable slots in order to get the LCD/tilemap draw cycle to work as fast as possible. What I didn't fully understand until now is why I stuck the routines that move a character across a tilemap in Slot 1 as opposed to Slot 2, where most of my game logic is happening. What I realized is that only in Slot 1 do I get the full benefit of using the tile rotation routines in the other LCD draws (since drawing grayscale in 15MHz would leave quite a bit of delay), and I can perform tile rotations without having to use up precious clock cycles in the other variable slots.

What made things tricky was a number of race conditions that involved a local tilemap table in which the thing read from versus what tiles needed to finish rotating in order to align themselves again. Depending on which direction your character is going, the local map could refresh *BEFORE* the tiles on the edge of the screen finished rotating, and thus, remain in an intermediate state which appears... ugly. That problem was a nightmare to solve, and I'd rather not do it again.
--------
Aside:
Tile rotation isn't the only thing these LCD draws perform while the tilemapper is running. When the tilemapper is /not/ running, that cycle does the same thing as the other cycles and I can then use its built-in grayscale layering effects to some good use. One of which can be seen in the "lightning" effect in the image attached.

Best viewed in Firefox or Opera, as this is a 35FPS .gif file, which happens to be capped at 10FPS in IE or Chrome

This layering effect is not present in the tilemapper version of the LCD draw, which is something that isn't easy to fix unless I want to spend precious cycles on something the calc doesn't have time for. Can't shortchange Slot 1 any more than it already is.

That looks really awesome, Imabian. The clouds look a little weird since the right side of the image is static, but I really like the lightning effect.

Small update: Finally got the tilemapper to work. It was a headache to do, but in hindsight, it could have probably been done in an hour had I known what I was doing. While I was at it, I threw in the good old collision detection routine and fixed a long-standing display bug which caused the land/water edge tiles to remain gray just before the next water scroll update occurs (once in every four "game cycles", there being about 32/sec).

I suppose once I get the warp points put back in, along with their animation, I can go ahead and start work on rebuilding all the menus. I can already tell the inventory screens are going to be... "fun".

Oh dear, good luck with the inventory screens. Remind me again why you had to rebuild all this? It was to clean up masses of spaghetti logic, right?

Epic Iambian. Although will there be a save/load function? jkjk

Sort of. The way the previous menu system handled itself was a complete mess, and I needed to fix it. And the only way to fix that mess was to redo the whole thing. I'm quite pleased with how it currently handles. Along with the menu system, I have down something that replaces the truly horrendous way I buffered and rendered menu text and other screen elements.

The other reason why I changed it was because there's a slight problem with code space and how the app handled itself. That's not much of a problem now, but the old menu system completely relied on how paging was handled when being compiled with TASM. I couldn't have that anymore.
------
On a happier note, I redid the screen transition when warping to another map or another area on the same map. The previous method relied on the tilemapper and locking down pieces of the tilemapper to avoid crashes. This new method locks down the entire tilemapper and writes directly to the buffer. A side effect of loading a new map involves refreshing the tileset, so no potential problems exist with tiles in an incomplete rotated state. The final result was shared on IRC:


Whew. That was a mouthful.

EDIT: (Answer to previous post) Yes, there will be save/load, though I haven't re-implemented that yet. No, there won't be a teacher key sort of thing. So, now that I got that out of the way, time to put back in area/map titles

Aye, I very much enjoyed seeing that screenshot on IRC; it looks amazing. You and Zera should definitely be working for handheld console gaming companies and making big bucks doing game design and graphics design. Thanks for the clarification on my question about the re-doing of the game.

Still working on the inventory viewer for E:SoR. I'm doing it in a manner similar to how it was done before, since it was, in a word, "nice."

What it's doing isn't actually reading inventory data, but a description of the inventory that is buffered to a separate memory area. I'm doing it this way so that the same menu can be re-used for other displayable things. Aside from general inventory viewing, it includes a filter so you see only what I want you to see. For example, if on the equip menu, you're trying to equip body armor, the only thing you should see is body armor. Quite a departure from other games which dump you on some general purpose screen and expect you to just "know" what it is you can or cannot equip. The same general system can also be used to show stuff, like the inventory of shopkeepers. For purchase, obviously! (There's no "steal from the shopkeeper" mechanic)

I haven't coded quite enough to show a demonstration of it, but it should be rather close. I mean, I've got it buffering the right stuff and seeing that it is good in the debugger's memory viewer.

Always remember that emulators are your best friend. The debugger is THE most valuable tool you'll ever use.

Can't wait for that demo! And I can't agree with you more about emulators and debuggers. Sadly, for much of my recent work, there's no way to test without using hardware.