Window system refactorisation

There are several upgrades that could be made to the refactorisation of the windows system. I am not sure if there is an advantage to convert this class as a C module Considering I could have some need for inheritance in this.

The goal is to make the creation of window less heavy to manage, but I have to refactor not to much to make sure I don't recode anything.

  • There can be generic multiline and column text windows to prevent the need to have windat functions. That would manage the text as a formatted stream of text.In plain C it could be harder to manage due to the need of character buffer. But would get the benefit of not manually inputting the x, y position of the text or each string. But lose the capabilities to fix and match various fonts like the character screen.

  • There are some code duplication in the window system. The duplicated code could be moved into an higher level class in the hierachy of inheritance to avoid code duplication.

  • I could use an internal print stack of windows and reprint the content of each window all the time. Also prevents the need to manually backup the background of the windows. Can also easily position window automatically in certain situations. Bu could require dynamic allocation and linked list.

NEW: 2 new ideas that are worth considering for the new window system

  • Memory Pre-Allocation: Maybe to save the hassle of handling pointer and memory buffer, see if I could pre-allocate a fixed set of windows with almost all data possible instead of using dynamic allocation. It might get complicated with data list that can have an undefined number of records unless the width is fixed and nb of record limited. Else there might need to define precisely what is dynamically allocated and what is not.

  • Fixed width and height for characters: In order to void converting characters to blocks and vice versa, see if I can use a font instead that has the same width and height. It would make placement of data, and allocation of buffer according to screen size much more convenient.

UPDATE about character buffers

In order to simplify buffer management for each dialog and allow pre-allocation without any waste of space, there could be a buffer of character that covers the entire screen. Dialogs will be printed into that character buffer. It will hold information about everything: Letters, windows frames, arrows, instruction char, etc. Then the buffer of character will be printed on the screen in pixels.

That will require new square fonts, and there will need to be a mapping of special character for window frame and other special char. The best would be to put everything in the font to make the text to pixel conversion much easier. I'll have to build my own bitmap font with extended 256 character and trying to map old DOS window frame character (to make it human readable in the code). If 256 char fonts are not possible, I'll have to map those special chars in the 0-127 range.

It is also possible to have a 2nd character buffer for special effects like color (FG, BG) or font variations like bold, thin, italic, underline, striked, etc. Not sure if it's worth the effort, it might force me to draw the screen 1 character at a time instead of entire lines. I'll have to test if it's really slower.

The drawback of such system are:

  • only 1 font at a time will be used, else I'll need additional information in the char buffer to hold the font parameter which I am not sure is really worth the trouble.
  • I have to design my own font, but only 1 font. I am not sure if 8x8 fonts would be too small, I might go for 12x12 fonts instead.

UPDATE: This issues will be covered my the GLYMMER library which will contains all the user interface system. Some of the ideas from this issue can be moved to the glymmer project. One the library will be mature enough, Wizardry legacy will be compile and built using library. User interface will need to be redesigned, but it will be way faster to do if the library is mature enough.

Edited by Eric Pietrocupo