Наверно кгбшник)) Софистика сильная))

Ну одно дело фунции на английском, и другое их описание.

А какая разница ? Там достаточно элементарный англ язык. В крайнем случае есть онлайн переводчики.

отличий от gm7 не так уж много, разве производительность.

Она возросла? Проводил тесты с 8. на моем компе показывает хуже результаты чем 7...Я в отчаяние

OPALsmoke, click!

Добавлено (21.01.2010, 17:30)
---------------------------------------------
Случайно набрел на 4,5 мбайтный исходник и решил проверил - быстрее ли он загружается\работает в ГМ8, итог - да, таблицы объектов\спрайтов\etc загружаются мгновенно (во всяком незаметно), при изменении тоже не надо ждать долгого построения. В ГМ7 лаг на лаге, открыл объекты - долго строится список, изменил имя объекта - долго строится список.
Еще один плюс в копилку ГМ8.

Прощай, шестёрка

Aimar, здравствуй виста)

Нашёл несколько досадных мелочей:

При изрядных количествах строк (>500) начинает тормозить редактор.

После многократных тестов начинает глючить Аэро (Win7) и Applies to начинает мигать. Помогает только перезагрузка.

Если введена функций с неверными параметрами (допустим draw_sprite(x, y, )), то какие там ещё параметры и что надо ввести ещё не показывается (при вкл. или выкл. проверки синтаксиса, это не влияет). Нужно писать с новой строки draw_sprite(. Это реально бесит.

Ты вырубал при большом объеме кода real-time проверку ?

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

Но без нее, же, наверняка глючит меньше...

Тот кто захочет найти кряк - тот найдёт в инете, благо это не сложно... ну или попросить в лс у когонибудь... Это личное дело каждого - покупать программу или юзать пиратскую... а на форум выкладывать кряки запрещено...

Ужос, за что ты так меня не любиш?

Это и-за наших аватарок?:D

Не, я просто предупреждаю о правилах)) Правила написаны для всех)))

Может быть хД

Баг вроде нашёл. Когда делаешь увеличение экрана через разницу между размером порта и вида (например вид 100х100, порт 300х300), вид получается сдвинутым на 0.5 и поэтому тайлы находятся не в координатах с целыми числами. Изза этого появляются глюки ввиде полосочек между тайлами. Пока не знаю как это пофиксить. Фигня в том что реально сдвиг не на 0.5, а очень близко к этому значению - около 11/20 (измерил). Абыдно. Как же делать увеличенный экран без глюков?

Добавлено (23.01.2010, 19:14)
---------------------------------------------
Ктото скажет, что можно делать снимок с реального размера 1:1 и его уже растягивать. Но тогда мы будем иметь объекты только в целых координатах. Т.е. объекты будут двигаться по увеличенным пикселям и чем больше увеличение, тем больше будет скачок. А при использовании увеличения в виде "вид:порт" координаты объектов, скажем так, не целые и движение плавное.

а никто не проверял, как работают в ГМ8 функции типа draw_getpixel'а? нет ли их ускорения по сравнению с ГМ7, например?
З.Ы.: и почему вообще они (функции эти) такие тормозные? скриншоты-то он быстро делает.

Слишком много действий по мелочам. Что быстрее? Перенести 4 вёдер песка или 1 тележку (объём песка в вёдрах и тележке один и тот же)? Конечно тележку быстрее, даже если мы будем переносить по 2 ведра придётся сделать 2 ходки, вместо 1 на тележке. Т.е. при каждом пикселе "открываем" память видеокарты, "закрываем" её и ещё куча телодвижений. Когда рисуем фигуру, уже лучше потому что мы открываем/закрываем 1 раз на фигуру. Поэтому для рисования всей картины использует метод batch'ей (т.е. набрать кучу и сделать с ней что-то), т.е. метод конвеера - подготавливаем всю инфу, потом рисуем. Ну самый простой, похожий пример в ГМ: что проще? Отрисовывать каждый раз 100 спрайтов? Или отрисовывать 1 сурф с изображением этих 100 спрайтов? Заметь, результат будет один и тот же (спрайты постоянно неподвижны, для упрощения). Также и с градиентом, быстрее рисуется draw_rectangle(); чем двойной цикл draw_pixel(); Хотя результат будет одинаковым.
Это всё что нужно для начального представления о рисований графики.

Код граф. движка закрыт (так же как и остальной ), поэтому хочешь быстрей draw_pixel()? Ищешь замену из того что есть. Много линий? Заменяем на draw_line(). Нужны кривые? Используем примитивы. Для рисования кривых градиентов по формуле (например, моделирование сейсмической активности, погоды или чего-то сложного)... Ну только правильное смешение на сурфах для "похожего" результата. А вообще, если нужен конкретный результат нужно поискать в сети как это делают другие, может найдётся подходящий вариант для ГМ и без использования асма.

DreamRunner, можно прикинуть обратный вариант. Оригинал крупный. А в игре уменьшать для "обычного" обзора. Если понадобится укрупнённый вариант просто возвращаемся к оригиналу. Если это будет сложно, то лучше, конечно, отказаться от реализаций увеличения.

а, т.е. типа как в HGE...
эх... иногда просто надо именно МНОГО пикселей вынуть. вот несудьба было вместо одной функции сделать три (открытие, чтение, закрытие)?

Не совсем. Я так понял, там открывающая и закрывающая функций для батчинга, не более. Т.е. он складирует все твои функций в список, потом сортирует, а в конце рендерит удобным способом. Это увеличивает оптимизацию, но не даёт прямой доступ. А прямой доступ к видюхе можно получить 3 способами: через DirectX, драйвера или асм.

Не судьба. Это универсальный, удобный движок для школьников. GML максимально упрощался, а ты предлагаешь опять расширить функциональность в ущерб удобности. Нужны такие функций -> переходи на HGE. Хочешь профессионально заняться графикой -> берёшь DirectX SDK, там ты найдёшь абсолютную власть над видеокартой, всё для убойной графики с максимальной производительностью.

В этом случае, вынимаем пиксели МНОГО (Марк написал в справке):

Создаём сурф и указываем его как цель.

Перерисовываем экран. screen_redraw(); И всё что в видеопамяти, теперь на сурфе.

Делаем с сурфом всё что угодно, режем, кромсаем, сохраняем на винт.
Пиксели вынули, многа и достаточно быстро.