Как уныло. За полтора года прикрутили 3 функции и зум в рум едиторе )
Лучше переписали все под DX9, добавили шейдеры и вообще поюзали аналогичный утилиты (типо конструкта, юнити и т.д. Там можно подчеркнуть множество удобных вещей).

А чейнжлоги есть?

Йакуд, ты его купил что ли?)
Список изменений совсем никакой. За 1.5 лет можно было полностью переписать под многоядерные системы и DX9 )
Я даже не стану заикаться про вращение и масштабирование объектов в редакторе комнат..
Разработчики так и вынуждают писать собственный редактор к каждой игре.

Поковырял я его чуть чуть, очень часто падает.
Всё пытался разобраться с чтением из файла, так вот когда я пытаюсь считать реальную величину он возвращает строку "ERROR"

и вообще я не понял нифига с этими версиями.
Вот есть GameMaker 8.1 Light - типа с урезанным функционалом
Есть GameMaker 8.1 Standart - расширенный
И есть ещё GameMaker 8.1 Pro - это тот что будет кроссплатформенность поддерживать?

Ahelhot, я покупал gm8.0, мне этот бесплатно достался.
SaintHeiser, у меня ещё не разу не падал.. Не знаю с чем это у тебя было связано..
Standart версия - это обычная классическая версия GM pro, Которая поддерживает все функции.
Pro версия - это, видимо, расширенная версия ГМ'а, в которой добавлены новые функции для работы с другими девайсами, а так же кросспатформенность..

Видимые изменения:
• Очень-очень кривой редактор кода. Не поддерживает русские символы. Это очень огорчило.
• Изменилось окно добавления шрифтов.
• Сами шрифты стали выглядеть красивее в игре. Довольно неплохо они поработали над сглаживанием.
• Теперь если в функции указано 2 аргумента, то при вызове этой функции нужно передавать именно 2 аргумента! Иначе, ГМ ругается
• Редактор кода стал удобнее. теперь можно выделить нужный кусок и перенести его вперед Tab'ом
• Редактор спрайтов стал удобнее. Можно масштабировать изображение колесиком мыши.
update
• Пустой исходник весит 8,71 КБ
• Пустой exe весит 3,94 МБ, но легко упаковывается в архив 1,37 МБ

под "падает" я имел в виду что при вызове некоторых функций он теперь выдаёт runtime error. Раньше такого не замечалось.

Это ваще ересь. Я часто использовал в скриптах дефалтное нулевое значение. Это называется: вызов функции с параметром. Типа что он может быть, а может и не быть - очень мощная штука. Очень и очень жаль что её урезали.

Снова повозился со считыванием реальных величин, но на другйо машине, теперь он считывает число целиком не учитывая разделители, например если в файле было так:
1 7 8 12 29 9
то реальное число будет таким:
17812299
И теперь я понял почему у меня тогда ERROR выдавало - там у меня было чисел больше в фале и получаллся перегруз стека.
Имхо не гуд совсем.

Что мы в итоге видим?
Изменения направленны на редакторы: комнат, спрайтов и кода. Проф разрабам пох на первые 2, т.к. обычно они сами пишут свои редакторы уровней и делают графику в проф редакторах графики. А редактор кода теперь не поддерживает кириллицу.
В итоге, команда YoYo снова(уже третий раз), мягко говоря, нихера не сделала. Добавлены какие-то штуковины-хотелки(без которых и так было нормально), а насущные проблемы до сих пор так и не решены.

P.S. Хотя вот думаю прикупить. Вдруг они его обновят по-нормальному, тогда он мне достанется всего за 25$ а не за 40$, т.к. расчитываю на бесплатный апгрэйд.

UPD
Купил... интеренет творит чудеса: всего 2 минуты и готово.
Зато теперь буду активно постить в багтреккер.
Ща поверчу линцензионную версию.

когда кряк запилят?

Ну ёлки! Наконец-то! Неужели.

Да, так и вылазит туева хуча ошибок. Они правильно сделали, что теперь точная проверка.

С загрузкой проблем никогда не было, попробую новую версию.

Какие ещё ошибки? Приведи хотя бы один пример, когда это приводило игру в совсем нерабочее состояние.
Ошибки при параметризации - следствие неграмотности программиста а не ошибки в среде разработке.

Вот пример:
Есть у меня скрипт проигрывания звука. Он у меня в игре обычно вызывается с одним строковым параметром - имя звука.
И тут я понимаю, что для каких-то ситуаций я бы хотел, чтобы у меня конкретный звук проигрывался с заданной громкостью (в FMOD - это легко делается)
Что я делаю - я дописываю в свой скрипт код
if argument0!=0 then
{
...//меняем громкость проигрываемому звуку
}
И теперь я могу вызывать скрипт как с одним так и с двумя параметрами, то есть либо просто проигрывать звук с громкостью по умолчанию, либо проигрывать заданный звук с заданной громкостью.

Какая ситуация теперь:
Решил я сделать так, чтобы конкретный звук можно было проигрывать с определённой громкостью и всё - ппц. Нужно перелопачивать весь код, чтобы во все вызовы скрипта дописать нолик, который по умолчанию там и так есть.
Другое дело, если бы у них была альтернативаня система параметризации.

Конечно, как альтернатива - можно отдельно написать ещё одну функцию проигрывания звука с двумя параметрами, тогда нигде ничего менять не нужно. Тогда такая ситуация - насоздавал я 20 скриптов с различными параметрами, а потом отловил ошибку в проигрывании звука, которая была ещё в изначальном скрипте. И вместо того, чтобы изменить один скрипт я буду лазить по всем 20.

Никогда не возникало вопроса, почему в С++ можно писать printf("text %d",5) и можно писать printf("text %d %s",5,"hello")?
Во всех современных языках (PHP, Lisp, C#, C++) можно создавать функции так чтобы в них можно передавать разное число параметров, потому что это обеспечивает гибкость языка(за что я во многом и ценю ГМ среди прочих языков).
По хорошему и в ГМ уже давно бы пора сделать перегрузку функций, например:
общая функция draw_sprite(), которая c четыремя аргументами работает как draw_sprite(img,index,x,y), а с девятью как sprite_draw_ext(img,index,x,y,xscale,yscale,ang,color,alpha);
Совсем по-хорошему упорядочить параметры в степени их значимости и сделать перегрузку на все случае жизни, чтобы при желании не значимые параметры можно было бы вообще не писать.

Как бы если так делают ВЕЗДЕ, то наверное это хорошо, не?

Это старый вариант на С (и кстати, очень неудобный), новый использует сцепку. См. из С++ cout/cin

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

и т.д. Следовать порядку необязательно и все логично, понятно.

Ну ты не прав. Ошибки бывают разные, просто, допустим, по недосмотру. И такие ошибки встречаются не только в ГМ и у 10летних, достаточно просмотреть логи различных программ. Когда ты делаешь функции и ЗНАЕШЬ что у тебя там ноль, то пожалуйста. А вот кто-нибудь другой будет работать и неусмотрит за этой особенностью, а в сигнатуре нигде не пишется это фишка. Вот я бы пропустил точно, потому что у меня таких вольностей не бывает.

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

Конечно, я очень недоволен политикой YoYo! С покупки ГМ8 прошло полтора года, а толку как от козла молока. Какое-то увеличение в редакторе, которое нах не нужно, доп. глюки, глючит кириллица. Только текст сделали неплохим и Tab для смещения текста. Ппц, просто. Надо им высказать всё. Готовим общую петицию!

SaintHeiser, кажется, я решил проблему с аргументами..
Например, у нас есть функция sum. Она может принимать от нуля, до 3 аргументов. функция будет считать сумму от одного до трех аргументов.

Сама функция:

Ещё один баг редактора кода. переменная argument_count, не подсвечивается как встроенная переменная. Но она имеет в себе кол-во передаваемых аргументов. Зная сколько передано аргументов, можно их использовать. Но тут есть одна фишка. Аргументы вида argument0-argument16 уже нельзя использовать. Юзаем массив с аргументами argument[0]-argument[n].
Функция полностью рабочая для ГМ8.1. Передавать можно сколько угодно аргументов.

P.S. Ang3L, ты мне подкинул отличную идею со сцепкой. Попробую сделать такую систему в своем GMON.

В целом соглашусь, но

Не было бы лучше добавить эту фишку в документацию и как то её улучшить, например ввести ещё одит тип опциональных аргументов o_argument0...o_argument1, чем просто тупо убирать этот функционал, посчитав его баговым? Учитывая, что это фишка была удобной и сокращала время разработки(за что мы собственно и боремся используя, высокоуровневые движки а не ассемблер или С++ без оболочек)

Да можно по разному. я как пример привёл. Чтобы продемонстрировать что в ЯП часто можно встретить перегрузку функций.
С++ плохо знаю. Меня учили прогать на С без плюсов.

Да так лучше, но сделали бы они хотя бы так как я предложил. Шаг за шагом движемся к цели.

На раз: никто не застрахован от случайных ошибок и нет гарантий что ты сделаешь всё истинно правильно. Порой понимаешь это уже в процессе, даже если детально всё спланировал (даже в PM BOK - очень много внимания уделено устранению неполадкам - аж целый громадный раздел по "управлению изменениями в проектах"). Лучше иметь под рукой гибкое средство по их устранению, чем пользоваться софтом без этой возможности. Вон, попробуй в любой программе поработать без Undo.
На два: он и так меняет свои интерфейсы. Мне достаточно того, что я свои игры порой полностью перелопачиваю исправляя функции на новые и убирая ненужные. Зачем же ещё лишнюю работу мне подкидывать?
Открою небольшой секрет: немаловажная(может даже и основная) задача любого менеджера, дизайнера, программиста - красиво и быстро устранять свои и чужие ошибки. т.е. по сути на то они есть - чтобы решать проблемы и устранять ошибки. Если бы ошибки можно было НЕ совершать, а проблемы НЕ порождать - то не было бы этих самых менеджеров, дизайнеров и программистов.

Добавлено (16.04.2011, 15:50)
---------------------------------------------

Тточно! Как вариант, если изначально все свои функции строить по такому методу.
Я с таким же подохом обычно уровни делаю и сохранения(сперва число параметров, а потом сами параметры)

Ты купил ГМ? Вот и напиши им свои идеи. Кстати, я и сам подумаю над тем чтоб им чиркнуть писмишко... Хотя б через Google Translate. Кстати, o_argument необходимо было бы инициализировать чем-то, что в ГМ не предусмотрено.

printf - делается не через перегрузку, а гораздо хитрожопее. Сигнатура выглядит так:

... - означают что там будут аргументы, но сколько и какие - неизвестно. Дальше идёт парсинг, подстановка и вывод. Короче, не для молодого ума, а ГМ (при скачке 8.1 посмотрел) ориентируется на детей от 4 лет... Короче, игрушка для самых маленьких.

Предлагаю всё же чиркнуть ЙоЙо коллективную петицию с предложениями.

Сделаем проще:

В ГМ с обычными скриптами такого не сделать. Пробовал. Хотя если ты делаешь свой миниязык. Идея сцепки такая (блин, перерыл весь нэт, не нашёл ни одной статьи нигде, даже в wiki):
Есть объект, у него есть параметры по умолчанию и методы (скрипты, функций, как угодно). Когда метод вызвался и сработал, он в конце возвращает ссылку самого себя (грубо говоря, свой id возвращает). И получается что все методы применяются к этому объекту.

Сцепка:

или:
вызываем sprite.rotate(), он возвращает sprite и получается снова sprite.draw(), он снова возвращается, но уже нигде не используется. Аналогично:

Вариант можно такой придумать (все скрипты принимают первым параметром id объекта и возвращают его):

Тогда можно любой порядок делать функций. Удобно и неудобно одновременно...

Да я уже, в праведном приступе негодования отписал им пару постов на багтрекер. Раз купил, надо отстаивать потребительское право.

да, я в курсе, но с виду выглядит как перегрузка. И по сути перегрузка и параметризация тоже разные вещи. В случае перегрузки просто создаются разные функции с разным числом параметров. В случае с параметрами пишется что-то в духе
sum(a,b, option C=0), дескать a и b задавай железно, а вот C можешь не задавать но имей в виду что там по умолчанию будет ноль(за синтакстис ответсвенность не несу, помню что в lisp или в php что-то подобное).

Я вот подумал, сцепка чревата громоздким кодом в духе:
sprite.rotate(90).scale_x(10).scale_y(0.5).blend(c_white).image_index(5).alpha(0.4).draw(sprite1,x,y);
не юзерфрэндли, учитывая что частенько приходиться много так рисовать. Нужно будет ещё жёще следить самому за порядком, чтобы не запутаться.
всё же наш привычный:
draw_sprite_ext(sprite1,5,x,y,10,0.5,10,c_white,0.4);
в два раза короче по записи.
А сцепка может вызвать неразбериху и шок для 4-х летних юнцов.

Ang3L, Я просто продемонстрировал идею работы с аргументами, но никак не идею сложения аргументов))

Свой мини-язык там уже есть)
Есть очень простая работа с объектами

Это уже объект a, с параметрами x, y. Так же есть стандартные инпуты (события клавиатуры и мыши), основные действия (шаг, рисование).
Так же есть возможность использовать функции.

Как сделать сцепку, я уже примерно придумал...

Можно использовать сцепку, если маленькие выражения и как вариант вот так вот сделаю:

Получается по сути, довольно привлекательно. И реализация такого вот действия будет очень простая. Парсер уже сможет скушать такие вещи, останется только ранер подкрутить для события draw и все)

Если кто не понял, я все это говорил про GMON.

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

draw_sprite(sprite_name,x,y,..0,5,2)

Какбэ сравни что проще и удобней )
К примеру x,y ты все равно будешь писать. ну а если очень надо можно сделать свою функцию для рисования спрайтов со свободными параметрами.

Со сцепкой:

Без оной:

Ну а теперь как? Каждая идиома программирования индивидуальна. Куда-то подходит, а куда-то нет. Не надо говорить, "Пля, а тут кода стало больше - метод сцепки гавно!", а надо найти правильное применение. ГМ частично поддерживает, но вот допустим:

Хотя, в принципе, код идентичный, а str всё равно погибает после return.

Короче, мы опять от темы отбились...