множество изображений и алгоритм их отрисовки и выгрузки из памяти.

Ну иногда делают несколько текстур разного качества и в зависимости от масштаба биндят и отрисовывают соответствующие.
(например при максимальном увеличении достаточно карту города размером (ну не знаю например) 2048x2048 на подложку выводить. При минимальном зуме не только отрисовывать видимые но и соседние текстуры в памяти хранить. в OpenGl есть например glDeleteTextures в dx - хз. картинки всё время считывать с харда)

Не знаю, я бы попытался сделать так.
Разбить исходную текстуру на минимально необходимые фрагменты. К примеру, 512х512 (по привычке, кратное 2-ке). Пирамиду mipmap уровней строил бы динамически только для тех фрагментов, которые в "фокусе". Вывод нужного уровня для отображаемого фрагмента будет привязано к зуму: т.е. чем меньше зум, тем более высокий уровень (уменьшение качества) из пирамиды отображается. Фильтрация - по вкусу.

Какие плюсы вижу:
Даже при выводе всей картинки, затраты памяти минимальные для такого "фрагментированного" подхода. И можно еще уменьшить (см.ниже).
При необходимости, можно строить пирамиду для нескольких фрагментов при любом исходном уровне их детализации.

Какие минусы:
Построение mipmap пирамиды требует некоторого времени и памяти. Для слабой граф.платке (скорость, память), придется все это дело просчитывать заранее и хранить в файле. При этом, загрузка при каждом зуммировании так же, не способствует быстродействию.

В плане алгоритма определения отображаемых участков идеи нужны?

P.S. Думаю создание, загрузка, обработка и удаление текстуры проблем не вызывает? Кстати, минимальный размер фрагментов определяется качеством исходного изображения.

Если 3D нет, то вся кухня с определением видимости намного проще и быстрее. Но раз требуется зум, панорамирование и перемещение по карте, то с frustum будет интереснее.

По поводу резки изображения на фрагменты. Тут 2 пути вижу.
1. Загрузка из исходного (оригинального) файла изображения определенного фрагмента. Особо плюсов не вижу, а из минусов - жесткая привязка к конкретному формату изображения, определенная сложность такой процедуры, скорость загрузки и тяжкое определение по координатам отображаемого окна.
2. Сформировать файл своего формата, состоящий из таких фрагментов даже с просчитаной пирамидой. Ну, по типу DDS-файла. Плюсов - полно. минусы - конкретно от реализации. С форматами сжатых текстур DXT1-5 знакомы? Ну, и совсем без mipmap'а будет смотреться... ну, не профессионально, что ли. ;)

Я бы выбрал второй вариант. По формату "фрагментного" файла есть такие мысли. В нем должна присутствовать простейшая индексная таблица, содержащая смещения на блоки каждого фрагмента - так получим гибкость формата при различных размерах фрагментов и доп.информацию (пирамиду, формат сжатия и прочее). Кстати, а формат блока фрагмента тупо с DDS содрать, и велосипеды не придумывать.

Спасибо за ответы. Буду думать. А пока возникла еще одна задача.
Мне необходимо разбить исходную картину на отдельные файлы 512х512. Пусть это будет отдельная программа. Последовательность действий предполагаю следующую:
1. Загружаю изображение
2. Построчно прохожу его выделяя области 512х512.
3. Каждую область сохраняю в отдельный файл.
Подскажите пожалуйста как это сделать. Лучше с исходником или со ссылкой где это можно посмотреть. Гугл не помог.
Спасибо