Escheron: Shadow over Ragnoth

[Hot_Dog]

Good luck, Iambian!  Starting fresh is a great idea, but don't overwork yourself as well

[Art_of_camelot]

While it is disappointing that we will have to wait longer for this awesome game, I'm sure it'll be well worth the wait. Good luck indeed, looking forward to seeing this rebooted! =)

[Iambian]

Oh, gawd. Now I remember what it was like to throw in a mass of code just to see *anything* going. I'm still working on the text input/output routines. I'll probably just throw in the LCD writing routine and have it go from there.

[DJ Omnimaga]

Darn I'm sorry to hear. Try to not fall into the endless-rewrite loop, though. Some people keep rewriting their projects 5 or 6 times, which ends up killing it. I guess the first time it can be inevitable, though. I hope you don't give up

[Iambian]

I won't give up. Using SPASM is just such a good opportunity now that I know a bit more about it is something I can't pass up

EDIT: If the project gets rewritten again, I'm not sure what I'd do with myself. It's a (near) perfect environment as it is.

[DJ Omnimaga]

Ok good to hear

[Builderboy]

Aw sad to hear you have like scrapped 5-6 pages of hard work but its good to hear that you are starting anew and that it will be much more efficient and better coded Good luck!

[squidgetx]

Good luck Iambian! I'll be looking forward to this

[Iambian]

Aw sad to hear you have like scrapped 5-6 pages of hard work but its good to hear that you are starting anew and that it will be much more efficient and better coded Good luck!

It's not like I totally scrapped the entire project. There's quite a bit of code that's being copied from the old project. The vast majority of the driving routines like the text and tilemappers are coming in without very many modifications. I'm just putting a new spin on things so I can get cross-page data access working. All of the data management routines that handle things like character stats will have to be rewritten but only because I'm choosing a different way of handling that sort of stuff. The way I had it before wasn't based off of anything that was really in the project so routines had to be made to deal with the inconsistencies. The rebuild aims to do away with all of that.

While I'm at the rebuild, I'm also aiming to make the display a bit... cleaner. I'm redoing the menu system (this'll be the third time), so the project might hang a little on that, but nothing too bad. The flexibility in being able to access data from any page of the project eases quite a few woes. I'll be able to code in a menu system without worrying about available code space, since it can now be thrown all over the project. Pages can be added without worry, since SPASM will handle that mess.

As far as restructuring the data goes... Crimson Editor's column edit mode is starting to look shiner and shiner. Didn't think it could ever get *that* shiny

----
As far as progress goes, I'm building this shiny printf macro that'll handle all my text needs, so I won't have to have a mishmash of ASM code and data to build menu elements and format them the way I want them to. It'll be handled as it should've always been. It should have been handled as data. Okay, so the menu system will slow a little because it's not buffered, but it should all be good. If it becomes a problem, I'll have it handled a slightly different way, probably by making good use of the new and improved interrupt scheme.

Oooh, I had this thought that might accelerate loading of parts of the game. It involves running the pucrunch decompressor as a background service so by the time the information is needed, it'll either have been already loaded or close to being loaded. Still thinking about how it would work, tho.

[ztrumpet]

Oooh, I had this thought that might accelerate loading of parts of the game. It involves running the pucrunch decompressor as a background service so by the time the information is needed, it'll either have been already loaded or close to being loaded. Still thinking about how it would work, tho.

Interrupts?

I'm glad this is going well.

[Builderboy]

Ah sounds good And i don't think super speed is really a neccesity for menu's really Even 1 FPS can work since you really aren't doing anything really intensive.

[DJ Omnimaga]

Nice Iambian

[Iambian]

Ah sounds good And i don't think super speed is really a neccesity for menu's really Even 1 FPS can work since you really aren't doing anything really intensive.

It's not the speed of the menu that's worrying me. The lag can cause grayscale quality issues when the screen needs a large update. I see the inventory doing this in spades. I'm hoping to do something with the renderer that'll increase speed, but I'm not sure exactly what.

I should get something working first before I say anything about it.

[DJ Omnimaga]

Does that slow down occurs between two menus? If so, why not just make the entire screen black before loading starts? Most console games did that, unlike calc games.

[squidgetx]

I think he means that the slowdown would occur just in general while looking at/using a menu. I had this issue as well with the bag in Ash:Phoenix; since the game was rewriting all the text every frame, the gray looked really crappy. I ended up writing a separate routine for the inventory menu that would only update the screen whenever a button was pressed, but it cost me a lot of space