Overview
- Text rendering
- Basic Dialog implementation for intro
- Logic abstraction
The porting process is tougher than I had anticipated. I described my problems with the animations in Week 2 and continued with correctly positioning sprites in the dialog. Fortunately I [found my mistake](link to Renderer::drawSprite pos calc) and dialogs not only for the intro, but in general will be solved soon.
Details
The logic differentiates between different states like showing a dialog, the game, a cutscene, and so on. This helps the logic to know when to update what so that for example you are not slain while still picking up items from a chest. link
The characters for text rendering are stored in general2.anm that use the ASCII value as an offset to access the sprite in the animation (link to Dialog::update default case). The dialog strings contain information directly for fadein/out, what type of dialog it should be (Yes/No, Ok, multipage, immediate) and so on.
In general the implementation is quite simple. The engine iterates over every char one after another and either executes the ‘meta char’ (e.g. ‘|’ for fade in text) or renders the sprite for the character. When the null terminator is reached and no further string is to be loaded, the dialog rendering terminates and depending on if the dialog expects user input (password, yes/no, ok) the logic either waits on a keypress before switching back to its ‘game state’ and continues where the player left off.
Next Week
Judging from my current speed, I hope to get our hero making its first steps in the first level and ironing out the remaining dialog bugs.