ToME WikiI get the impression that a lot of people on this wiki prefer text to graphics mode. After trying text mode, i see why.
a) mnemonics (a J is always a snake, D is always a dragon or wyrm in text mode.)
b) unclear display, which is by default stretched with interpolation. With 16x16 tiles, this results in unacceptable loss of clarity.
c) because of a and b, you get accidentally killed far easier.
a) can be simply solved. For example, adam bolt's tiles show all different shapes of potion bottles. Mnemonic-wise, these should all be the same shape; I already made new graphics which do this. Same for monsters, the same general shape should apply to all of a class of enemies.
b) in the short term, use 8x16 font, enable doublewidth tiles ("-- -b" parameter) and disable smoothing ("-- -s" parameter). some of the unclarity comes from the tiles, though.
in the long term..
1. Background tiles should appear less saturated, while enemy and player tiles should appear more saturated and brighter. I have redrawn-from-scratch some of the tiles to do this (enough so that most of barrow-downs and bree looks quite good) and intend to complete this. I converted the tiles to a palette having a better range of colors.
2. Larger tiles (24x24 or 32x32) would help tremendously. In order to display them properly, the tiled-display needs to become independent of any text display.. they need to be treated as two separate layers. I think Zangband does this.
3. Truecolor BMP support would help. Most of the platforms supporting graphical-tiles will usually be running in hi or true-color anyway; code for reading 24bit BMPs exists in Allegro and is easily ripped out.
4. A readable 8x16 font (the 9x15 is currently much more readable). If someone can direct me to a program for editing .FON files, i can convert the 8x16 font to similar or better quality as the 9x15.
DarkGod: Woh woh wait right there. Do you mean you are (1) able to do graphics and (2) interrested in doing them ? If this is so, please be welcome 
The future lies in a SDL port for the graphics, no need for allegro to read BMP, and we can use TTF fonts. If you are really interrested in doing graphical work then please, say so, I'd be most happy
AbsoluteV3: Yes. I noticed that v3 uses SDL -- it needs some auto-configuration, because i had to edit quite a lot for it to see my SDL includes directory or link with the sdl library, both which are in standard places (/usr/include/SDL and /usr/lib respectively). Ok, SDL addresses #3 and #4. What about #2? Can ToME support larger tiles without stretching/squashing them?
You could stand some more 'trimming' tiles -- having mountains around the bridge in Minas Anor looks ok in text mode and quite strange in graphics mode. And more tile variety for walls would help, if they can be all treated as the same e. g. 'granite wall' from the point of view of gameplay.. If this can be done, i will make the trimming tiles.
DarkGod: Tile size is dependant on the display code that's all. As for walls, well why not, as long as smoebody draws them and make the maps
AbsoluteV3: regarding walls: ok. i want to understand how features are associated with graphics, so i can readily test my new trimming tiles.
I want to be quite clear on this: The engine can readily be modified to support 32x32 tiles if it doesn't already, yes?
DarkGod: The engine doesnt know about size(or raphics for that matter), the display module an be yes. BTW can you code too ? As for understanding how gfx are associated, they are in the graf-*.prf files, but I'm pondering a radical change of the graphic organisation to have many small files instead of one big one. Wanna help ?
AbsoluteV3: I've looked at the graf-* prf files.. what i don't understand is the first number in each line. ... wait.. So i have to look up the feature indices in defines.h? ick. well, not for new ones hopefully, i should be able to use index defined in f_info.txt or eventually features.lua.
Yes, i can code. I might be able to help in the splitting-up.. if i can get tome3 to not (crash or stop inexplicably), so i can see whether i improved things or not.
DarkGod: features.lua defines them in 300. And I was planing on using a new scheme to store gfx data like: /media/gfx/32x32/features/foo.png. I'm not sure how foo should be named yet. Maybe the feature name lowercased(I cant use indexes, because indexes are no more in 300). Or maybe default to lowercased name but features.lua(or a pref file?) allows to change it to something else. Some would go for monsets and objects.
What's the problem with ToME 3? it should work now
AbsoluteV3: [cut description -- i was using the wrong makefile] ok, it's working now. sdl display module still doesn't (crash when loading font-- nonexistent 'verasans' or similar). and i still don't have graphics (ie the X11 displaymodule no longer shows them.).
Re: /media/gfx/32x32/features/foo.png
Great, if you can place the foo.pngs inside a zip, so features.zip contains all the foo.pngs. Physfs should do this.
DarkGod: Well that might be because the graphic settings are no more accurate at all 
As for features.zip, yes my idea exactly
AbsoluteV3: Your name turned into a link to InterWiki I fixed it by adding a space between DarkGod and Well.
soI suggest
features.tea : walls and floors
- something for the hardcoded features (lava? i haven't looked but know there are some from a note i read) -- how are they associated, can these be in features.zip too?
mon_X.tea where X is a name like ant -- similar to the desc given by the '/' command, but one word.
item_X.tea : like above, associating a one-or-two-word phrase with each tval.
artifacts.tea : (by name -- few are needed at once.)
player.tea : Player graphics (the various race/class combinations-- having individual pngs is good because only one is ever needed at a time.)
If flavours become fully fixed, potions, staves, rods, wands can have their graphics referred to by name. I'm in favor of this (mnemonicness ++++). Probably everything by name would work best then. Divided up entirely by 'tval'.
(incidentally, i think 'potion of water' and 'potion of apple juice' should both be EASY_KNOW, it would take a fool NOT to know what they are)
DarkGod: Monsters can be split by race character, artifacts dont have gfx, but they could get some yes. items can be split by type(tval), I dont want to make more virtual "roots" though(like armors.zip)
AbsoluteV3: Updated the scheme. One thing i did not include yet is the possibility of using graphics in the menus (rather than ascii 'lines'). i think this could greatly improve the appearance of the interface. these particular graphics would have to be scaled to font size, of course.
I've put everything i could think of needed in there. Edit it if there's anything missing. Once we're fully agreed on the scheme, I intend to begin implementing it.
DarkGod: I was more thinking of having subdirectories. And let's forget about zips, they can be used but they can also not be used, why make them neccesarry. so: media/monsters/r/ media/monsters/a/ ... media/objects/10/ ... media/features/ media/player/ ...
AbsoluteV3: sure, for changing them they should be like that. for distribution they should be zipped, because a few thousand small files will thrash your filesystem and waste space.
NeilStevens: My thoughts:
- If you don't like the font we ship now, what we need is to get a good outline font in there. There are many fine, free Truetype and Type 1 fonts out there that we could put into ToME, fixed-width fonts that could scale to different sizes. This kind of thinking leads back into my wish for an all-SDL, all-the-time ToME, though.
- Please keep actively-maintained 16x16 graphics in the game. Larger graphics may be prettier, but take monstrously huge screens to be as playable due to the greatly reduced map size.
"use 8x16 font, enable doublewidth tiles ("-- -b" parameter) and disable smoothing ("-- -s" parameter). " is EXACTLY how I run ToME. Well, I tell it to create three extra windows, too. Note that if you don't like the default font you can always specify a new one, at least with the X11 version. I use 8x16 for the map window but -misc-fixed-medium-r-normal--10-100-75-75-c-60-iso8859-1 for the extra windows.
- Have you used the "new" tiles instead of the "old" tiles? Those are either 16x16, so they shouldn't look so stretched when you use 8x16 font and double-width map display.
- If we have a new graphics maintainer I'd be so very very pleased!
- I can't comment on re-assigning the race letters, since I don't use that mode, but that's something that needs to wait for ToME 3.0 (or 2.4 if we were going to have one).
AbsoluteV3: neil: re #2: If you're running in 1024x768 resolution, 24x24 tiles would give you about as much tiles visible as you can see via LOS or ESP (~ 42x32 tiles, minus the status-area.).
I can easily keep small tiles updated to match large ones. the effort is mainly in thinking and drawing the design of a tile.
re #5: Perhaps. This is something i want to do now. I'll consider that after upgrading is complete.
re #6: I don't use it either. I probably would with 32x32 tiles, cause then I could see the difference
darkgod: You cannot do monsters/a -- you have to name them, because several monsters are not filename-safe characters (.,{|>?$*+, offhand -- don't know if that'll show correctly) and object dirs should be named too (more for ease-of-maintenance reasons).
DarkGod: Naturally names would be "safized" to remove and replace such bad characters. As for dupes the monster definition could choose to use an other filename than the default one. Ojects ? mh maybe yes
AbsoluteV3: I just generated a few lookup tables that will allow autogeneration of lighting (ie norm/dark/bright versions of same tile) with better quality than the current (2.3.x) tiles -- given that they are loaded as RGB, could quickly preprocess them to add the dark and light vers. I've started on directory structures and put some of my new tiles as PNGs in features/. I'll update this with a link once i upload a zipfile of it.
DarkGod: Obviously you're doing it for 300, right ? he code to handle them is also non existing yet, will you do it ? Oh and may I crown you The Official T.o.M.E. Graphics Maintainer or should I wait a bit ? ;>
AbsoluteV3: As i said to neil, whether i'm prepared to take that on is a decision that can wait until i finish the initial upgrade. I can write the code. Once i understand the existing code, and where the graphics code should fit into it.
A screenshot of Tome2 with the (mostly) new tiles
Archive with fairly-complete directory structure and some graphics. Except for the monsters directory, which will use names if i code it -- see the monsters/README file for why:
http://neota.castleparadox.com/tome_gfx_test.zip
DarkGod: The auto light thing looks nice yes Oh and silly windows for tha a/A case .. pfft ..
minra: 1) i have done a mod to the 16x16 tiles and sent them to DarkGod. They benefit from less saturation / brightness to bring foreground objects out. 2) AbsoluteV3 i can not load your tile tweaks from http. 3) 32x32 tiles would be nice for those of us with high-res displays - the existing ones can be scaled up with intelligent filters (2XSal etc) and tweaked - better yet would be getting hi-res images from the original artists (if they exist) and re-downsampling them to 32x32. 4) The lighting idea is great and lastly 5) Certain tiles (floor, grass, forest, woods) would benefit greatly by not being atomic (same tile for each cell) but selected by modulo division from a 3x3 (4x4, 5x5) 'meta-tile'. This would also be a fairly simple modification to implement, but i'm not able to do it on my own.
FarVardin: I'm reading this thread as well as the ones on the same issue on the forum and often comes on the questions about "can you make new graphics ?" and such. I think at the moment there is a nice, clear, tileset in both 16x16 and 32x32, made by David Gervais and implemented / adapted on the Pousse Rapière's website : http://pousse.rapiere.free.fr/tome/ (unfortunately only for MSwindows) Maybe in the future it'd be nice to have new, personalised versions of tileset for ToME, but at the moment it doesn't seem possible to even use the 32x32 tileset with it. I've heard it could be on ToME3, how is it going ? I personnaly like ascii graphics, but sometimes it can be nice to have real pixel graphics too, and it's also more attractive to newcomers.
HarryErwin: I'm about 60% through the process of writing a Java program to allow me to remap the 16x16 graphics tiles to the 32x32 tiles. I can display everything and generate the first-cut map, but I haven't gotten around to the code for actually walking through and correcting the proposed mappings and generating suitable 32x32 graphics control files. Time and work-load are the issues.
Jared: Just wanted to add in my .02. I am a bit of an artist as well, at least I like to dabble. I used to help on a few homebrew GBA games, so I am comfortable with small tiles. That being said, I am running ToME on Ubuntu, and am having problems getting it to display without deformation, or at least even something close. If anyone here runs it on *nix or preferably Debian, and can give me some pointers on getting a nice clean graphical interface, drop me a line! I'd also be willing to help with some graphics, even though the Bolt set is pretty well done, it could use some tweaks.