Someone worked on the input collecting recently, and for the process game logic, we’ve got that in 2-3 methods in the loop, but rendering is done everywhere from what I understand. So its that part that needs working on the most before there can be a tile set system, sine at that point we would have draw { drawmap; drawui; drawmenu; } and just either draw glyphs or tileset
-drawmap would iterate through the different arrays we have and draw the terrain, then items and then monsters/npcs/player. Each terrain type, item and monster/npc/player would have a corresponding glyph and tileset offset, either defined in the class itself, (i.e monstertype/npc/player, glyph code, tileset offset) or as a variable in the object itself (ie thing->icon, icon could be a type ie Icon { glyphCode, tilesetOffSet })
-drawui would draw the ui as it is now (no tile sets in the ui… ?), also for the “cursor line” we’ve got in 'V’iew, draw it here over maptiles, unless the 'V’iew interface is a menu.
-drawmenu would draw the requested menu (no clue how to handle this, would need a common menu interface, but dunno how to handle the selections/returns, not sure how it’s done ATM)
I agree with gim on the topic of the existing tileset system, it’s not really the way we would want to go, I would rather see that amount of work put into designing a proper rendering engine with no tilesets (reckon at this point tilesets would be very doable) instead of hacking the old tileset system into DDA.
Any comments on the design I suggested ? Flaws, missed issues, technical issues, design issues ?