Перейти к контенту

Курилка программистов


Рекомендуемые сообщения

перекомпилированные поделки, которые будут не совместимые скорее всего друг с другом

Эм... Исполняемые файлы? Ну наверно. Но кто ж так делать-то будет :)

Если репозиторий с интересующей правкой открыт, то в чём проблема сходить туда и сделать Ctrl + C ?..

КПД разработки на asm меньше. Не зря же все более менее большие проекты пишут в средах разработки, а не в "блокноте".

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

*Я занимался ковырянием сталкера аля asm, больше не хочу :) (и всем светлым головам того-же желаю)

Изменено пользователем -StalkMen-
Ссылка на комментарий

 

 

Если репозиторий с интересующей правкой открыт, то в чём проблема сходить туда и сделать Ctrl + C ?..
Ну это здорово будет, если каждый конечный геймер установит себе студию и будет лазить по многочисленным репо.  ^_^
Ссылка на комментарий

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

 

@Kontro-zzz, речь совершенно не о геймерах.

  • Согласен 1
Ссылка на комментарий

 

 

я чувствую себя законченным идиотом

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

МАСМ понимает много чего из языков высокого уровня, и на нем реально можно делать много чего.

...

То есть, можно делать то же что на С++

Объясни пожалуйста, а что мешает тогда просто взять СИ и его использовать? Я не говорю про С++ с его классами, шаблонами и т.п., а только про старый добрый процедурно-ориентированный  СИ. Вот застрели, а я не вижу ни малейшего преимущества в ассемблере перед обычным СИ. Тем более, что ты хочешь использовать там макросы, превращающие его в некое подобие нормального языка. Но все ограничения то останутся: с гулькин нос регистров, ограничения по набору операций, никаких типов и соответственно контроля, даже с этими макросами элементарные действия требуют жуткого геморроя по сравнению хоть с каким угодно языком и т.д.

 

Я более скажу. Твои слова насчёт того, что дескать проще распространять и собирать - это ты на самом деле принимаешь за эффективность элементарную неразвитость средств разработки для ассемблера по сравнению со средами для языков высокого уровня. Формально говоря, этапы сборки программы для ассемблера ровно такие же, как и для СИ: компиляция, линковка. Если ты такой эстет, то ничто не мешает и на СИ разрабатывать в блокноте и пользоваться сборкой из командной строки. Будет тебе точно такая же "эффективность и простота".

 

 

А метод ХЕ или ассемблерных вставок-правок так и останется универсальным для ориг. версий.

О боги геймостроя! Да если бы у меня пять лет назад были исходники, я бы и думать не стал ни про какой ассемблер. А сейчас проект ХЕ для меня лично актуален только постольку постольку к нему привязан ОГСЕ. Обратная совместимость - страшная штука. Так бы забыл уже как страшный сон.

 

  • Согласен 4
 

Плагины Total Commander для работы с игровыми архивами:

Архиваторный плагин (для работы с одиночным архивом): link1 link2

Системный плагин (для распаковки установленной игры): link1 link2

 

Ссылка на комментарий

А сейчас проект ХЕ для меня лично актуален только постольку постольку к нему привязан ОГСЕ. Обратная совместимость - страшная штука. Так бы забыл уже как страшный сон.

Ну, на самом деле, перенести все правки ХЕ в исходники не такая уж большая задача, учитывая, что половину правок можно вообще нормально переделать без экспорта костылей. По крайней мере, это касается xrGame-библиотеки.

 

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

 

В частности, Help я собирал для того, чтобы точно знать какие правки есть в ХЕ и какие из них действительно нужны.

 

И кстати, ответь в ЛС на последнее сообщение - буквально один момент ведь осталось разобрать :)

Изменено пользователем RayTwitty
  • Нравится 1
Ссылка на комментарий

речь совершенно не о геймерах

 

Действительно, не объяснил причем тут геймеры.

Как-то с Макроном попытались сделать интерфейс для патчера, для ОЛР. При установке или после установки мода, геймер мог выбрать кое-какие настройки, то бишь правки.

23d71194badbdbf1767cef520534688f058d5a23

 

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

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

Изменено пользователем Kontro-zzz
  • Нравится 1
Ссылка на комментарий

Предлагаю для обсуждения простую мысль. Часто можно встретить функцию, написанную примерно в таком стиле:

function fff()
    if cond1 then
        if cond2 then
            if cond2 then
                if cond3 then
                    if cond4 then
                        --do_something
                    end
                end
            end
        end
    end
end

С алгоритмической точки зрения здесь всё нормально, однако подобное крайне плохо воспринимается. Что там надо сделать после проверки тысячи условий уползает куда-то вправо и теряется где-то в середине функции (и в середине монитора) на фоне лестницы кода.

В своей практике я взял за правило всегда заменять этот код, насколько это возможно, на эквивалентный ему в таком стиле:

function fff()
    if not cond1 then return end
    if not cond2 then return end
    if not cond3 then return end
    if not cond4 then return end
    --do_something
end

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

Это конечно отступление от Истинно Структурного Программирования, но на это как-то и начхать.

 

Есть ли какие-то мысли по этому поводу?

 

ЗЫ: Вполне возможно, что когда-то я это уже говорил в этой или подобной теме. Уже не вспомнить. Однако, судя по тому, что народ сам так почти никогда не делает, не грех и повторить вброс.

Изменено пользователем Malandrinus
  • Спасибо 1
  • Нравится 1
  • Согласен 1
 

Плагины Total Commander для работы с игровыми архивами:

Архиваторный плагин (для работы с одиночным архивом): link1 link2

Системный плагин (для распаковки установленной игры): link1 link2

 

Ссылка на комментарий

 

 

после проверки тысячи условий уползает куда-то вправо и теряется где-то в середине функции
Еще в юности у меня волосы дыбом вставали от такого. Чуть упрощается понимание, если есть... ммм... как они называются, вот эти линии-связки вертикальные? Но все равно дичь, особенно когда эти линии разноцветные и их много. :)

То, что ты описываешь, это как раз и есть тот Сакральный Рефакторинг. Меня в секту его свидетелей тоже запишите, пожалуйста.

Ссылка на комментарий
@Malandrinus, для действительно полного использования подобного стиля в луа нужен continue. Я тут наверное скажу, что подобные блоки нужно стараться совмещать в один посредством логических операций, это в скриптах, а в движке да, можно использовать то что ты предлагаешь, это явно прослеживается в изменениях движка. Изменено пользователем Struck
Ссылка на комментарий

Использование граничного оператора для уменьшения степени вложенности условий описано, емнип, Фаулером в его «Рефакторинге», а может и ещё раньше кем-нибудь, например тем же МакКоннелом.

Хотя вот у нас в компании негласно принято (большинством; так их учили) писать в стиле «одна точка входа - одна точка выхода», и меньшинству приходится подстраиваться. Поэтому лично у меня скрипты для Сталкера получаются в этом плане двойственными, в зависимости от того, что сработало - привычка или личное предпочтение. :)

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

Ссылка на комментарий

Есть ли какие-то мысли по этому поводу?

Если дело только в "лесенке" и таких "лесенок" много, то я бы определил вот такую функцию:

function checkbool(...)
  local t = arg and arg or {...} -- чтобы работало и в чистом Lua и в "Сталкере"
  rez, i = true, 1
  while rez and i<=#t do
     rez = rez and t[i]
     i = i + 1
  end
  return rez
end

после чего, основная будет выглядеть так:

function fff()
    if checkbool(cond1, cond2, cond3, cond4) then
       -- do_something
    end
end 
Изменено пользователем Serge!
Ссылка на комментарий

 

 

local t = arg and arg or {...} -- чтобы работало и в чистом Lua и в "Сталкере"

А можно узнать сакральный смысл двойного arg? Почему не local t = arg or {...} ?

Freedom

Ссылка на комментарий
А можно узнать сакральный смысл двойного arg?

Конечно можно. Никакого. Просто привычка.

Изменено пользователем Serge!
Ссылка на комментарий

Это конечно отступление от Истинно Структурного Программирования, но на это как-то и начхать.

Собственно, из-за концепции структурного программирования и делают, как ты говоришь "лесенкой". Но в обычных условиях, таких простынь вряд ли получится - лично я привык некоторые повторяющиеся действия (а они чаще всего повторяются (вызываются) где-то ещё), оборачивать в отдельные функции, вроде "return a and b and c". Впрочем, само использование return, break, continue и т.д. уже не есть структуры, так что на эти формальности можно забить. Где-то удобнее сделать выход в начале функции, где-то построить лесенку, зависит от случая.

 

Кое-где я у себя даже goto юзаю z_haha.gif

 

А можно узнать сакральный смысл двойного arg? Почему не local t = arg or {...} ?

arg and arg or {...}

эквивалент

arg ? arg : {...}

Изменено пользователем RayTwitty
Ссылка на комментарий

Помнится когда-то был тоже лестничный код с кучей условий (использовалось для модуля сна в инвентаре, если интересно), структура такая:

 

function()
	if not cond1 then
		if not cond2 then
			if cond3 then
				if cond4 then
					SLEEP -- call external func
				else
					-- show message4 (CUIStatic)
				end
			else
				-- show message3 (CUIStatic)
			end
		else
			-- show message2 (CUIStatic)
		end
	else
		-- show message1 (CUIStatic)
	end
	level.start_stop_menu(level.get_inventory_wnd(), true) -- hide inventory window
end

 

И вот интересность этого кода в том, что при отработке SLEEP (прохождения всех условий), закрытия инвентаря не происходило (туда просто не доходил вызов). Отчего так могло быть? Такое ощущение, что выполнение кода ушло внутрь SLEEP, а про остаток в функции с условиями оно забыло :D

Изменено пользователем RayTwitty
Ссылка на комментарий

@Malandrinus, хм, а куда делся оператор and?

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

Еще надо сказать, что мы говорим о субъективной вещи. Кому то лесенка вполне читаема. У нас было принято, что однострочников в духе "if not cond_1 then return end" не писать, обязательно перенос строк. Так что тут зависит от предпочтений конкретного кодера или стандартов компании.

Изменено пользователем Desertir

ТЧ 1.0004. SAP и Trans mod

github

Ссылка на комментарий

Создайте аккаунт или авторизуйтесь, чтобы оставить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

Создать аккаунт

Зарегистрировать новый аккаунт в нашем сообществе. Это несложно!

Зарегистрировать новый аккаунт

Войти

Есть аккаунт? Войти.

Войти
  • Недавно просматривали   0 пользователей

    • Ни один зарегистрированный пользователь не просматривает эту страницу.
×
×
  • Создать...