Отладка кода (программы) во FreeBasic

Уважаемые программисты. Подскажите - как производится наладка отладка (не редактирование) программы (кода) во FreeBasic.
В QB это делалось просто. В меню Debug командой toggle breakpoint метится строка до которой проверить.
После запуска идет проверка, отмечаются ошибки, проблемы.
У меня во FreeBasic этот метод не работает. Программа на метку не реагирует, действия не совершаются. Прошу помощи.

0

locm, это я сконцетрировал чтобы больше в один экран вошло. В конечном варианте цивильнее оформляю.

0

Сообщение от volchv Т.е - программная синусоида вылезет нормально

Не вдавался в твою программу, синусоида там или что-то ещё - не имеет значения.
Нюансов всяких "зачем" и "почему" там может быть миллион, я же не знаю задумку
что в принципе там должно быть и зачем оно там должно быть.
Но даже из этого мелкого куска кода можно увидеть, что стиль кода очень плохой
это не позволит тебе написать хоть сколь-нибудь крупный проект. Если бы я так писал,
то скорее всего мои проги не превышали бы 1.5-2k и я бы часто "буксовал" перечитывая код.
Чтобы это всё привести в порядок прям самый самый минимум это:

1) Поработать над отступами. Самое простое и эффективное "мозаика", т.е. следующая строка
начинается на пересечении пробела строки сверху, при этом отступы в 1 символ - минимально,
т.е. в основном больше одного символа(2,3).

2) Модульное мышление. Ты разбиваешь код и помечаешь его на всю длину разными ASCII символами.
И делаешь это слишком часто. Как лучше: помечай каждый блок осмысленным комментарием сверху блока,
т.е. знак комментария, два пробела, описание блока, дальше пустая строка и код блока.

3) Избавься от GOTO, используй его только в крайней необходиости. Выучи бесконечные циклы(DO, WHILE)
и выборку значений SELECT CASE.

4) Используй процедуры\функции.

5) Выбирай осмысленные имена переменных. И при любых декларациях описывай что за переменная,
за что она отвечает.

При правильном применении вышеозвученного код будет вылизан идеально, с ним будет легко работать.

Добавлено через 10 минут
Ну и 6) Частое применение знака разделителя. Например там где циклы я бы этого делать не стал.
Да и в принципе редко когда это уместно. При рефакторинге можно где-то поджать код так,
если там несколько присваиваний идут, которые тебе прям не надо видеть, где они лишние для осмысления.

1

Quiet Snow
эту программу я делаю еще, и по-пионерски. Сразу в стиле не держусь (ни школы нет ни терпения)
Потом, программу одну и ту же, с разными новшествами делаю уже много лет, и, хорошо запомнились многие фрагменты наизусть, потому вначале экономлю на времени. Но да, нечистоплотность бывает сказывается в потерях времени.

Сообщение от Quiet Snow 2) Модульное мышление. Ты разбиваешь код и помечаешь его на всю длину разными ASCII символами.И делаешь это слишком часто. Как лучше: помечай каждый блок осмысленным комментарием сверху блока, т.е. знак комментария, два пробела, описание блока, дальше пустая строка и код блока

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

Сообщение от Quiet Snow 3) Избавься от GOTO, используй его только в крайней необходимости. Выучи бесконечные циклы(DO, WHILE) и выборку значений SELECT CASE.

Про Goto, Return читал о них критические замечания. Пока по удобству и простоте применяю. D0 Loop While, While Wend - Я в них блужу. Как в школе, зазубрить нюансы нужно, выходы, входы, условия. Из за этого ошибки в программе получаю.

Сообщение от Quiet Snow 4) Используй процедуры\функции.

это пока желанные, но недостижимые умения. Как и взаимодействия с дополнительными программами (API и др). И со всем, что связано с взаимодействием с OC . Про процедуры мне здесь говорили в связи с оператором CALL. C ним было несложно. Здесь в мануале почитал, сложно, неполно. Пишут то для программистов, а я крестьянин. Слово не сказано, уже не пойму.

Сообщение от Quiet Snow 5) Выбирай осмысленные имена переменных. И при любых декларациях описывай что за переменная, за что она отвечает.

Осмысленность имён понята давно, замечено на примерах программ программистов. Но они на английском яз. На русском в программе нельзя, английский меня и в примерах то коробит. Поэтому свои фишки придумываю, связываю буквы с пониманием. (F- частота, G - графика и т.д.)

Сообщение от Quiet Snow Ну и 6) Частое применение знака разделителя. Например там где циклы я бы этого делать не стал. Да и в принципе редко когда это уместно. При рефакторинге можно где-то поджать код так, если там несколько присваиваний идут, которые тебе прям не надо видеть, где они лишние для осмысления.

Я подозревал, что такое применение разделителей скорее всего усложняют работу компилятора, но пока не обжёгся, применяю для сжатия в период выработки кода. Потом, когда программа работает, стараюсь сделать правильней, гре они лишние, избавляюсь.
Да все замечания ценные, со всеми согласен. Здорово, что есть где ума набраться. Большое спасибо. Буду стараться расти.

0

Сообщение от volchv D0 Loop While, While Wend - Я в них блужу. Как в школе, зазубрить нюансы нужно, выходы, входы, условия. Из за этого ошибки в программе получаю.

Можешь использовать беск. цикл:

DO ... Твой код ... LOOP UNTIL условие

Дословно означает: делать до тех пор, пока не выполнится условие.
Самый простой. Выход из цикла EXIT DO. Остальные вариации потом освоишь.
Но уже будет + читаемость.

Сообщение от volchv Про процедуры мне здесь говорили в связи с оператором CALL.

CALL устарел и не нужен.
Вот банально делаешь процедуру(в конце текстового файла программы).

SUB Draw() ... Тут твой код отрисовки ... END SUB

Потом в самом начале объявляешь прототип этой процедуры:

DECLARE SUB Draw()

Это чтобы бейсик знал, что в конце кода есть тело процедуры.

Далее в коде своей программы просто вызываешь процедуру:

DO ㅤDraw () LOOP UNTIL INKEY <> ""

И всё у тебя вся отрисовка в отдельном месте. Обсчёт тоже можешь сделать в отдельном месте,
простые программы допускают разделение. + структурирование кода, + читаемость.

Остальное по процедурам почитай в справке. В них можно передавать параметры.
Или можешь делать глобальные переменные\массивы (DIM SHARED) и они будут читаться в процедурах.

Сообщение от volchv Осмысленность имён понята давно, замечено на примерах программ программистов. Но они на английском яз. На русском в программе нельзя, английский меня и в примерах то коробит. Поэтому свои фишки придумываю, связываю буквы с пониманием. (F- частота, G - графика и т.д.)

Для себя можно как угодно делать, если не путаешься - то не вопрос. У меня было примерно так же
20 лет назад на ассемблере. Щас бы я опух так писать, уже переучил себя на венгерщину, ну более или менее,
счётчики по прежнему так именую (i, j, k, ix, iy, iz и т.п.).

Сообщение от volchv Я подозревал, что такое применение разделителей скорее всего усложняют работу компилятора

Компилятору пофигу, он просто разобьёт строки и обработает их по одной. А вот тебе тяжко потом будет
вникать, когда немного подзабудешь код. Тоже этим раньше грешил, не в таком количестве, но было, потом
уже когда на Паскале пописал, понял, что надо от этого гавна избавляться. И вообще перестал экономить
строки. Всё равно кол-во байт одинаковое, двоеточие и пробел - это 2 байта, CHR(13) + CHR(10) - тоже 2 байта.

1

Quiet Snow,

Сообщение от Quiet Snow DO ... Твой код ...LOOP UNTIL условие Дословно означает: делать до тех пор, пока не выполнится условие.Самый простой. Выход из цикла EXIT DO. Остальные вариации потом освоишь. Но уже будет + читаемость.

Да, вполне понимается. У меня здесь набралось уже немало советов, подсказок, наводок. Я их в файлик скидываю - форумский учебник, как дополнение к мануалам мало понятным.

Про процедуры стало понятнее. Ещё два момента - в скобках что передаётся - переменные? И можно ли из программы по отсылу переходить внутрь процедуры? если можно - как - синтаксис. Вообще я еще в справке почитаю, сейчас будет понятнее.
Благодарю!

0

Сообщение от volchv можно ли из программы по отсылу переходить внутрь процедуры?

Не знаю как в FB, но в большинстве бейсиков это просто нельзя. Поэтому, даже если можно, лучше не использовать.

Сообщение от volchv в скобках что передаётся - переменные?

Это т. н. аргументы функции, внутри функции они видятся как переменные. Опять же, не знаю как в FB, а в VB, например, они могут передаваться двумя способами - ByVal или ByRef. Первый способ очевиден - это просто некоторое значение, которое передано в функцию, а вот ByRef гораздо интереснее, это как бы псевдоним переменной, переданной в функцию, если внутри функции ты её поменяешь, то поменяется и значение переменной после выхода из функции. Вот представь, что тебе нужно часто разные переменные ограничивать значениями 0..255. Можно написать функцию:
В программе используешь:
И т. п.
А можно сделать процедуру с ByRef параметром:
Код сократился, но и использовать короче:
Написав функцию или процедуру, ты, как бы, расширяешь язык ещё одной командой. Попробуй такое сделать на GoSub, ощути разницу.

1

Сообщение от volchv Как и взаимодействия с дополнительными программами (API и др).

API и библиотеки это отдельная возьня и не везде в интернетах ты найдёшь описание. Да многое есть
но и многого нету. На эту возьню убьёшь пол жизни, если захочешь написать что-то серьёзное.
Это чисто программерская тема, для практиков, т.е. каким бы ты алгоритмистом не был, а без этого
трудно и всё равно надо качать эти скилы. Многое есть в исходниках на си и делфи, на VB иногда
попадается что-то ценное. В кодархивах\примерах других ЯП можно что-то выцарапать(например PB,
QB64, FASM, Dev-C++) ну если лень копать MSDN и прогерские площадки.

Сообщение от volchv И можно ли из программы по отсылу переходить внутрь процедуры?

Наверное можно как-то схитрожопиться и перейти(получить адрес процедуры и сделать JMP с асм вставки),
но ничего хорошего не будет(функция по идее делает пролог, т.е. работает со стеком, выходить тоже
придётся специальным образом). Короче концептуально оно так не задумано, это нивелирует всю пользу
от их использования(ты потеряешь структуризацию кода и сделаешь даже хуже). Если тебе надо
управлять потоком выполнения в процедуре то отправь в неё параметр и выполни нужное действие
по SELECT CASE. Т.е. например так:

SUB DrawScene (SceneType AS INTEGER) ㅤSELECT CASE SceneType ㅤㅤCASE 1: ㅤㅤ... Тут код рисовки сцены 1 ... ㅤㅤCASE 2: ㅤㅤ... Тут код рисовки сцены 2 ... ㅤㅤCASE ELSE ㅤㅤ... это выполнится, если SceneType не равен ни 1 ни 2 ... ㅤEND SELECT END SUB

Процедуры задуманы как закрытые сущности, чёрные ящики. Ты 1 раз разработал чёрный ящик
и дальше им пользуешься, вызываешь процедуру, основной код не должен сильно знать, что там в этом
чёрном ящике. Процедура это лишь одна задача, программа по сути состоит из подобных задач,
чем лучше ты продумаешь разбивку на процедуры, тем грамотнее и понятнее будет код. И основной код
движка программы будет содержать строчек 20-30, где просто в цикле будут вызываться процедуры.
Когда процедуры независимы тебе достаточно отладить их по отдельности. Это значительно уменьшает
риски возникновения ошибок.

Добавлено через 17 минут
Перестроение мозгов это этап не на 1 проект, привычки есть привычки. В секунду не получится.
Тут надо поспотыкаться просто самому, понять что мешает и нещадно отсечь.

1

Сообщение от Quiet Snow API и библиотеки это отдельная возьня и не везде в интернетах ты найдёшь описание.

Если под API подразумевается WinAPI, описание есть для всех документированных функций в том числе на русском.

1

Mikle Quits,

Сообщение от Mikle Quits Не знаю как в FB, но в большинстве бейсиков это просто нельзя. Поэтому, даже если можно, лучше не использовать.

Жаль, было бы ценно. Хотя - усложнения.

Сообщение от Mikle Quits Это т. н. аргументы функции, внутри функции они видятся как переменные. Опять же, не знаю как в FB, а в VB, например, они могут передаваться двумя способами - ByVal или ByRef. Первый способ очевиден - это просто некоторое значение, которое передано в функцию, а вот ByRef гораздо интереснее, это как бы псевдоним переменной, переданной в функцию, если внутри функции ты её поменяешь, то поменяется и значение переменной после выхода из функции....

Во всём этом на четвёрку по процедуре понимается уже. Сама процедура (как понимаю) размещается в каком то месте (непринципиальном) этого же кода.
Синтаксис в FB отличается, будет позаморочнее.
Спасибо!

Добавлено через 9 минут
Quiet Snow, Стандартные приёмы у меня нормально идут. Некоторые можно усложнить - упростить. Циклы (новые). Да, и процедуры. Пока будет еще долго хватать. Стиль буду развивать.

Добавлено через 6 минут
locm,

Сообщение от locm Если под API подразумевается WinAPI, описание есть для всех документированных функций в том числе на русском.

Да, где то недалеко видел. Просто основной вопрос - что они могут. Использовать возможности операционки, подключаться к ней, выводить в нее что то? Ну, наглеть не буду, это можно посмотреть, поразбираться.
Спасибо.

0

Сообщение от volchv Жаль, было бы ценно.

Чем ценно?
Не самая лучшая идея прыгать из одной части функции в другую. Для перехода в функцию ее нужно вызвать. Вернутся возможно в любой момент.

Сообщение от volchv Просто основной вопрос - что они могут.

Очень многое. По суди это взаимодействие с системой.
Если говорить о графике, есть GDI и GDI+.

Также есть функции работы с окнами, файлами, аудио, видео, 3D (DirectX, OpenGL), сетью, многопоточностю и т. д.
В приложениях для винды почти все функции библиотеки ЯП так или иначе вызывают WinAPI.

2

volchv, функция - это не только код, но и локальные переменные (которые внутри функции заданы). Пока функция не вызвана, память под переменные не выделена, ты прыгаешь внутрь функции, а там присвоение значения локальной переменной... которая не выделена. Ошибка. Казалось бы, почему не выделить память под эти переменные сразу, где-то на куче? Тут замысел интересный, за счёт динамического выделения памяти мы получаем такую замечательную штуку, как рекурсия. Это когда из функции можно вызвать саму себя, вещь просто замечательная.

1

Сообщение от locm Если под API подразумевается WinAPI, описание есть для всех документированных функций в том числе на русском.

Это сухая документация. Иногда даже с примером долго ковырять, не говоря уже про без примера.
Часто всё это связано с механизмами самой операционной системы, которые тоже не всегда очевидны.
Начинается возьня, "прощупывание", что, где и как работает, одним глазом смотря на доку, вторым в пример,
если он есть. Несколько раз приходилось разгребать вообще без рабочего примера, тупо по MSDN,
в FB-шных хедерах там вообще такая грязь творится, даже если есть пример, то приходится сверять всё,
все константы, типы данных, даже названия функций, бывало что названия не совпадают с MSDN-овскими
или тупо нет константы, приходится её искать декларировать. И прикинь без какого-либо примера это делать.
В PB потому столько функций и наклепали, чтобы минимизировать общение юзера с механизмами системы.
Даже мне практику это делать крайне непросто, не говоря уже про человека с небольшим опытом.

Добавлено через 5 минут

Сообщение от locm Если говорить о графике, есть GDI и GDI+.

С GDI же там после XP началась жопа с производительностью? Или не? Там вроде если у битмапы
ставить билинейный фильтр - проге совсем плохеет. Насчёт GDI+ не знаю. Но простой GDI
как бы только под старые системы актуален 98\2000\XP. Самое оптимальное юзать OpenGL,
он решительно везде работает хорошо, реально где я его не тестил - всё было отлично.
ну понятно что там есть ограничения на текстуры, но всё таки.

0

Сообщение от Quiet Snow С GDI же там после XP началась жопа с производительностью? Или не? Там вроде если у битмапы ставить билинейный фильтр - проге совсем плохеет. Насчёт GDI+ не знаю.

Вроде как после XP GDI наоборот ускорилось за счёт филрейта, который теперь делается на уровне DX9. Но это касается взаимодействия с экраном, а остальное работает по-прежнему. GDI+ - это, скорее, просто расширение GDI без противопоставлений, больше фильтров, форматов.

Сообщение от Quiet Snow Самое оптимальное юзать OpenGL, он решительно везде работает хорошо, реально где я его не тестил - всё было отлично

Полностью аппаратная обработка, естественно, быстрее, но, раз уж мы всё равно ограничены Виндой, я бы предпочёл Direct3D, он "роднее". Но GDI (+) тоже актуально - загрузка\сохранение файлов, рендер шрифтов.

0

Вроде как после XP GDI наоборот ускорилось за счёт филрейта

Возьмите ту самую 6600 или поновее, 8600 или 9800. Поставьте две винды XP и 7. Погоняйте их.
Кнопочки это тоже GDI. Можно ещё десятку взять. Лучше это делать на одинаковом оборудовании.
Нужно отличать ускорение за счёт железа и просто ускорение. Люди в своё время это всё тестили
и писали про просадку, в среднем двухкратную. Так то оно работает и вроде даже прилично,
но не всегда. Как то давно писал код, который на FB берёт вывод слоя со встроенной библиотеки
на себя и как только врубал там билинейку - начиналась жопа. А без неё отлично работало.
Кстати на XP билинейка почему-то работала по умолчанию и ничего не лагало. Интересно но факт.

Сообщение от Mikle Quits я бы предпочёл Direct3D, он "роднее"

Просто вы его знаете. Потому и предпочитаете.
Рендер шрифтов можно и сторонними библиотеками делать тот же FreeType.
А можно свои рисовать и выводить, мне такой подход нравится больше.

0

Сообщение от Quiet Snow Самое оптимальное юзать OpenGL

Это для 3D, а вот для двумерной графики она не подходит.

Добавлено через 1 минуту

Сообщение от volchv Жаль, было бы ценно

В 21 веке пора забыть про макаронное и спагетти‐программирование и переходить на что‐то более современное. Например, структурное программирование. Ну как современное. Структурное программирование появилось в 1970‐ых годах, так что это тоже прошлый век (напоминаю, сейчас 2024 год), но для начала будет достаточно.

GOTO — вместо прыжков следует использовать современные средства структурного программирования: циклы, условия, оператор выбора, функции. Каша из таких штук как «If a Then Goto 10» заплесневела и протухла 60 лет назад.

Так как все GOTO заменяются на приёмы структурного программирования, то метки оказываются не нужны.

GOSUB — вместо него пришли функции.
CALL — не нужно. В 21 веке пишем название функции и ставим круглые скобки. CALL — это избыточное усложнение, синтаксический яд, визуальный мусор.

Отвыкайте называть переменные из одной‐двух букв. Через неделю сами будете вспоминать что означают бесконечные a, b, c, d, e, тратя на это десятки часов.
Не пишите все переменные в куче в самом верху. Переменные следует объявлять рядом с тем местом где они используются. Иначе будете бегать глазами вниз‐вверх или использовать прокрутку.
Если переменная используется только внутри условия или цикла — объявляйте её внутри условия или цикла. Не следует выносить переменные за пределы блока, за которым она не нужна.
Переменные можно объявлять сразу вместе с инициализацией: Dim x As Integer = 5, вместо того чтобы разбивать эту конструкцию на две строки кода.
Ne ispolzuite transliteratsiyu v kode. Это плохо читается. Число — это Number, а не Chislo. Длина — это Length, а не Dlina.
Не используйте одну и ту же переменную для разных задач. Например, если Length означает длину, то она должна использоваться только для длины, а не для счётчика цикла потому что «ну вот у нас лишняя переменная есть». Для счётчика цикла заводите другую переменную.

Если какие‐то переменные используются совместно, научитесь использовать пользовательский тип данных Type. То, что в Паскале называется «запись» и в Си называется «структура». Например, вместо того, чтобы по‐отдельности объявлять координаты x, y, z следует объявить структуру Vector3d с полями x, y, z.

Отвыкайте использовать несколько инструкций на одной строке. Двоеточия — дурной тон, забудьте про них. Любите чтобы было кратко? Это плохо читается. Между краткостью и понятностью всегда следует выбирать понятность.

Не используйте однострочный IF. Условия вместе с телом на одной строке «If a > b Then c = 100» читаются намного хуже. Разнесите условие и тело на разные строки.

Вместо комментариев с «'===================» или «'----------------» или «'************» используйте приёмы структурного программирования: области видимости (Scope) и функции.

Спагетти‐кодеры любят лепить всё вместе на одном уровне. Чтобы код не превращался в вермишель которую комком кинули в кипяток воду, следует ознакомиться с концепцией «блок видимости». Такие штуки как условный оператор, оператор выбора, цикл, функция создают собственный блок видимости. Во фрибесик дополнительно добавлен оператор блока Scope. Следует взять на вооружение эту концепцию.

Не следует думать о таких вещах как «компилятору будет неудобно компилировать несколько строк, поэтому буду лепить всё в месиво на одной строке». Антропоморфизм здесь не уместен. Компилятор не устаёт, не испытывает эмоции и чувственные переживания. Код пишут для того, чтобы его читали люди, а не потому что компилятор будет духовно восхищаться правильными байтами.

Горизонтальная прокрутка — это зло. Текст легко читается когда глаза движутся сверху вниз. Когда глаза идут слева направо — это читается тяжело. Если какое‐то выражение занимает больше 80‐120 символов, его следует разбить на несколько строк оператором _. (Именно поэтому текст в газетах и журналах разбивают на колонки небольшой ширины, а не пишут от края до края бумаги.)

Не пишите комментарии справа от операторов. Возьмите за правило писать комментарии только на отдельной строке. Комментарий комментирует то, что находится ниже.

Используйте вертикальные и горизонтальные отступы в коде. Для горизонтальных отступов выберите для себя концепцию «табуляции или пробелы» и придерживайтесь только одной концепции. Любой блок видимости (функция, условие, цикл, блок) добавляет отступ слева на 1 табуляцию.

Научитесь вставлять пробелы в математических операторах. Следует писать «Zr = Zr * 2 + r» вместо того чтобы лепить всё в кучу. Это на бумажном листочке можно написать «Zr=Zr*2+r», а в коде это читается намного хуже. К условиям это тоже относится.

Научитесь разбивать код на несколько файлов и подключать заголовочные файлы.

1

Сообщение от Quiet Snow Это сухая документация. Иногда даже с примером долго ковырять, не говоря уже про без примера.

Но она есть. Попробуйте поищите документацию на Linux API.

Сообщение от Quiet Snow С GDI же там после XP началась жопа с производительностью?

GDI не для создания 240 кадров в секунду с разрешением 8к. Основное назначение - рисование статических картинок или небольших графиков с графическими примитивами типа линий, кругов/эллипсов и т. д.
То есть примерно то что нужно volchv для отображения синусоиды в окне.

Сообщение от Quiet Snow Самое оптимальное юзать OpenGL

Он для 3D. Зачем для создания статической картинки OpenGL? Не уверен, может он выводить в контекст картинки (bitmap)?

0

Сообщение от Quiet Snow Возьмите ту самую 6600 или поновее, 8600 или 9800. Поставьте две винды XP и 7. Погоняйте их

Погонять что конкретно? Я гонял SetDiBitsToDevice, так как именно им как правило пользуюсь для вывода на экран. На 7-ке и новее - многократное ускорение. Не буду спорить, возможно, некоторые функции наоборот замедлились, хотелось бы знать какие.

Сообщение от Quiet Snow Просто вы его знаете. Потому и предпочитаете.

Не только, сколько я видел проблем с OpenGL в старых играх, каких просто не может быть на D3D.
D3D9 изначально встроен в систему (от 7-ки или Висты), через него идёт рендер GUI самой Винды.

Сообщение от Quiet Snow Рендер шрифтов можно и сторонними библиотеками делать тот же FreeType.

Предпочитаю использовать что-то внешнее только тогда, когда имеющееся готовое явно хуже.

0

Сообщение от locm Он для 3D. Зачем для создания статической картинки OpenGL? Не уверен, может он выводить в контекст картинки (bitmap)?

В OpenGL есть ортографическая проекция. Библиотека GL2D позволяла выводить пиксель-корректно.
Но мне она не очень нравится. Сам тоже пытался с нуля(Мне Стас давно скидывал немецкий мануал, там всё
подробно было, но без нюансов), словил кучу гемороя при попытке делать пиксель корректно, уточню
что на разном оборудовании результат различается и это целая проблема. Однако считаю что всё равно
надо это изучать и стараться сделать нормально, GL2D доказывает что это возможно.
Забросил, потому что сгорела 9800GT, на которой некоторые косяки воспроизводились и можно было
тестировать. Короче нужно много разного железа, чтобы тестировать, просто с ходу не влезть, но можно
использовать GL2D там много разного функционала, ТС его хватит с лихвой.

Для 3D - это непринципиально.

Сообщение от locm Зачем для создания статической картинки OpenGL?

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

Добавлено через 11 минут

Сообщение от Mikle Quits Предпочитаю использовать что-то внешнее только тогда, когда имеющееся готовое явно хуже.

Тут много факторов. Например используя OpenGL можно рассчитывать на будущее, что будешь например
переносить куда-либо ещё. Мне непринципиально, а вот COM - не люблю, мне тяжело всё это разгребать
на FB, я уже все карачки себе поломал с этим COM-ом грёбаным. OpenGL тоже не сахар, но он в разы
понятнее с точки зрения архитектуры. Хотя если туда серьёзно влезать, то думаю разница будет не большая.

Сообщение от Mikle Quits сколько я видел проблем с OpenGL в старых играх, каких просто не может быть на D3D.

Белые текстуры или прозрачные(вовсе не отображённые) - тоже видел. В самом GL есть механизмы для
проверки этого, просто это лишний гемор их изучать и опять же надо тестировать. Люди часто забивают
на это. Т.е. есть два пути либо перестраховаться и всё рассчитать сразу на более раннее железо, либо
использовать функции OGL для проверки возможностей(размер текстур, памяти и т.п.).

Обычно на более серьёзном оборудовании такие баги не возникают, они возникают когда софт
требует то, чего у карты нет.

Добавлено через 6 минут

Сообщение от locm То есть примерно то что нужно volchv для отображения синусоиды в окне.

Для отображения синусоиды в окне проще и эффективнее использовать то что он использует.
Т.е. встроенный FBGfx. Т.к. он даже в худшем случае будет работать быстрее GDI.

Сообщение от Mikle Quits Погонять что конкретно?

Стандартный виндовый интерфейс. Он же тоже GDI? Или по твоему нет?
Объясняю, берёшь какой-нибудь софт с кучей кнопок, галочек, списков и т.п. т.е. кучу массированную
стандартного интерфейса и таскаешь окно по экрану. Смотришь обновление окна.
Думаешь это не показатель? При этом в 7-ке надо поставить не Aero, а классический интерфейс.
Иначе это будет уже не GDI, а Direct3D трудиться.

Добавлено через 7 минут

Сообщение от Mikle Quits через него идёт рендер GUI самой Винды.

Если выключено - не идёт. Нужно допускать такую возможность. Зачем это делать - вопрос
риторический, у меня всегда выключено. Не перевариваю вид Aero(эти толстые окаймления
каждого окна и прямоугольные кнопки управления окном). Плюс мне не нужно сглаживание
текста, всегда выключаю, чтобы беречь зрение.

0

Сообщение от Mikle Quits Не буду спорить, возможно, некоторые функции наоборот замедлились, хотелось бы знать какие.

AlphaBlend тоже аппаратно-ускорен в GDI.

0

Сообщение от Замабувараев Горизонтальная прокрутка — это зло. Текст легко читается когда глаза движутся сверху вниз. Когда глаза идут слева направо — это читается тяжело. Если какое‐то выражение занимает больше 80‐120 символов, его следует разбить на несколько строк оператором _.

Главное при этом в следствие работы с прототипом не начать скролить по вертикали суммарно больше
чем мы скролили по горизонтали. ))) Это о том что чёрточку надо тоже уметь применять, а лучше
вообще не применять, что сделано, например, в прототипах в хедерах FB, вы же любите
приводить в пример FB. Упрекните авторов там. Мол чё за фигня.

Сообщение от Замабувараев Не пишите комментарии справа от операторов.

Ну что за фигня? Нормально всё с этим. И сверху и справа. Ёлы палы...)))
Многие пишут справа комменты и всё шикарно читается.

0