Ответ: canvas: аналог GetPixel или как ?
 

Вот набросал небольшую демку c эффектом огня...
Но пока опять выводит через стандартные функции MP. И опять тормозит (( Вроде и цикл то теперь небольшой - [1..30,1..60], а все равно.
Как работать с ARGB массивами в lib_cnv2 не разобрался.

Может дадите простой пример - типа создаем ARGB массив, в нем рисуем точку с координатами 50,50 цветом RGB, выводим этот массив на экран. ? :''((

UPD: Вроде кое-как разобрался. Написал свою либу -) Щаз будем эксперементировать...

Ответ: canvas: аналог GetPixel или как ?
 

Красиво!:super:

Ответ: canvas: аналог GetPixel или как ?
 

Есть библиотека Lib_beta называется. Там можно просто задать картинку 30*60 и рисовать по ней стандартными методами из MP, а потом с данной картинкой можно делать что угодно. Можно добавить прозрачный фон (Lib_alpha) и вывести на экран.

Ответ: canvas: аналог GetPixel или как ?
 

немного оптимизировал демку огня
p.s.: Tronix - неплохо придумал с зажигалкой :)

Ответ: canvas: аналог GetPixel или как ?
 

Красиво. Неплохая идея с огнем.

Ответ: canvas: аналог GetPixel или как ?
 

Спасибо за коментарии. Вернулся с дачи, сейчас буду продолжать мучиться над терминалкой.

Спасибо, посмотрел, но есть некие сомнения насчет использования одномерного массива - получается, что в основном цикле есть 7 умножений, а операция эта афаик на любых процессорах не быстрая. Хотя я не знаю, как MP работает с двумерными массивами. Может точно так же использует одномерный и через умножение высчитывает смещение...
И потом еще одно: где выполняются циклы for x, for y нужно блюрить именно начиная с первых элементов массива, потому что если начинать с конца - получаеться эффект "воды", а не огня. На таком маленьком огне это не очень заметно, но если он будет чуть больше - это будет видно.
И еще хотел спросить - а имеет ли большое значение делать в циклах downto ? Мне почему-то кажется, что нет.
Ну и создание палитры можно было не оптимизировать - она же один раз только считается, перед началом основного цикла.

В любом случае спасибо за проявленный интерес. Вообще, abcdef, не планируешь написать что-то типа тутора или хау-то по теме оптимизации программ применительно к MP? По-моему у тебя бы прекрасно это вышло )

Ответ: canvas: аналог GetPixel или как ?
 

А может тему стоит переименовать?
Напр. на: Визуальные эфекты в MP:-D
canvas: аналог GetPixel или как ? - тема не очень соответствует названию

Ответ: canvas: аналог GetPixel или как ?
 

немного о составлении программ
По оптимизиции можно найти много подробной доки, подойдет любая т.к. принципы практически одни и те же, только встречаются некоторые ньюансы, так для прочессоров x86 самые быстрые циклы это уменьшение до нуля, т.к. инструкция декремента выставляет флаг переполнения если результат становится отрицательным, т.е. не нужно использовать медленную команду сравнения. Кроме того самые быстрые команды сравнения - это сравнение с нулем.

В java (как и MP) есть набор инструкций с константами 0,1,2 которые работают чуть быстрее, это однобайтовые команды и их зачения не грузятся из константного пула.

везде где можно используйте одномерные массивы, т.к. на каждом элементе массива java проверяет выход за границы.
Умножения оставил, как и говорил, для наглядности, а вообще можно сделать отдельную переменную для смещения и увеличивать ее на единицу при каждой итерации цикла.

в циклах крайнее значение нужно делать константой (числом), как уже говорил желательно 0, ну или на худой конец переменной, т.к. крайнее значение вычисляется при каждой итерации.

немного о размере программы: старайтесь записывать алгоритмы настолько эффективно, как только это возможно, т.к. когда-нить пригодятся эти куски кода в других разработках.
имена глобальных переменные желательно делать короче, в подпрограммаx MP все равно ставит свои короткие имена, но тоже старайтесь чтоб имена выглядели однообразно в каждой подпрограмме.
__
Вообще оптимизация под java не всегда очевидна: мелкие корректировки на некоторых устройствах не заметны, т.к. различны реализации java-машин, поэтому лучшая оптимизация - привильно спроектированный алгоритм, не содержащий лишних команд. Сам когда сажусь писать алгоритм, вопрос который задаю себе-"что еще здесь можно упростить?"
часто попадаются хорошо написанные программы, но не совсем корректно разбитые на управляющие конструкции, т.е. планировка кода по подпрограммам: всегда стараюсь разбить программу на основные алгоритмы, работающие не зависимо друг от друга и использующие минимум глобальных переменных, и единую управляющую конструкцию связывающую в одном месте вместе алгоритмы. так модифицировать программу, но чрезмерная разбивка тоже вредна, т.к. на загрузку подпрограммы тоже уходит время.
__

p.s.: про туториалы - так я этим и занимаюсь в свободное время, только применительно к уже готовым программкам, потому что изредка, но попадаются интересные кусочки алгоритмов

Ответ: canvas: аналог GetPixel или как ?
 

Мне бы очень хотелось знать все функции библиотеки cnv2, так как в java я практически не разбираюсь, а смотреть на код декомпилированного класса и пытаться постичь функции библиотеки не дают мне результатов.

p.s.: Я очень надеюсь что несмотря на даты сообщений кто-нибудь ответит мне