Вторник, 26 Мая 2020, 01:10

Приветствую Вас Гость

[ Новые сообщения · Игроделы · Правила · Поиск ]
  • Страница 61 из 61
  • «
  • 1
  • 2
  • 59
  • 60
  • 61
Форум игроделов » Записи участника » Gudleifr [1220]
Результаты поиска
GudleifrДата: Среда, 13 Мая 2015, 10:19 | Сообщение # 1201 | Тема: API для "двухстраничного" интерфейса
почти ветеран
Сейчас нет на сайте
Имеется в виду следующее.
между двумя интерфейсами:



и



есть смысловая тождественность, восходящая к обычной книге



Что вполне очевидно.

Однако, есть две неприятности:
1. Синхронизация "страниц" обычно реализуется не как обмен между "половинками" (как во фреймах HTML), а как жуткие макароны связей между отдельными Controls.
2. Нормальная синхронизация размеров информационнных кусков возможна, пожалуй, только при ручной отрисовке страниц. Проблема масштабирования, как и в Акробате, нерешаема в принципе (фиг посмотришь на маленьком экране).

"На чем?" Пока требуются принципиальные решения. Например, примерные свойства объекта "страница", примерные параметры операции "синхронизация".


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Среда, 13 Мая 2015, 10:20
GudleifrДата: Вторник, 12 Мая 2015, 11:44 | Сообщение # 1202 | Тема: API для "двухстраничного" интерфейса
почти ветеран
Сейчас нет на сайте
Постоянно сталкиваюсь с тем, что "одной страницы" не хватает - в одном окне нужно расположить два информационных объекта.
1. Например, на HTML странице размещаю два фрейма и меняю содержимое одного по результатам выбора в другом.
2. В играх обычно имеем окошко с игровым полем, окруженное рамкой-пультом.
3. В визуальных IDE двумя главными окнами являются окно дизайна "кнопочек" и окно их свойств (когда активно писал под Windows, всегда ставил два монитора).
...
Причем, анализ показывает, что двух "страниц" обычно хватает (информация важная и информация текущая). Остальные вполне могут "всплывать диалогами" по по необходимости или располагаться во вкладках.

Конечно, любой визуальный IDE содержит кучу механизмов для управления связями Controls и для размещения рисунков/органов управления "многослойно". Но существуют ли "редакторы"/библиотеки, позволяющие разбить все чем нужно управлять на два множества и отслеживать сообщения именно между ними, а не отдельными Controls? (Например, в HTML фреймы обмениваются информацией в целом, один не может адресовать конкретный фрагмент другого). Возможность создать Active-X контейнер на группу Controls, это уже перебор. Интересует именно обмен информацией между "страницами", а не способ табулирования и ресайзинга Controls внутри "страницы".

Другой вопрос: очевидно, что самым очевидным представлением будут "две страницы книги" (см. выше фреймы). В Windows мы такое видим, обычно, только в виде честного рисования (две страницы книги в Акробате) или жуткого вида Splitter-ами. Есть какие-нибудь идеи, позволяющие соизмерять порции информации на двух половинках окна? (В принципе, эта проблема существует и в HTML, где, если не хочешь возится с фреймами, нужно брать таблицу на две клетки и рассчитывать, что поместится в зависимости от разрешения экрана).


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Суббота, 09 Мая 2015, 10:09 | Сообщение # 1203 | Тема: Что вы думаете о metaprogramming?
почти ветеран
Сейчас нет на сайте
Все проще.

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

Тогда пытаются применить всякие структурные (устар.) и объектно-ориентированные методы.
См. Брукс "Мифический человеко-месяц"

Но метод написания под новую задачу нового языка (машины по Дейкстре) по идее работает лучше.
В принципе под это был заточен и C++ (См. Страуструп, глава "Проектирование и развитие") и Python...

Но работает это только в FORTH (зато там все остальное не работает).
См. Броуди "Думаем на FORTH":
Цитата
На самом деле Вам не стоит писать каких-либо серьезных задач на Форте; как язык, он просто недостаточно мощен. Вам "следует" писать на Форте свои собственные языки (лексиконы) для моделирования Вашего понимания проблемы, на которых Вы можете элегантно описать ее решение.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Среда, 06 Мая 2015, 14:50 | Сообщение # 1204 | Тема: Вывод предложений
почти ветеран
Сейчас нет на сайте
Я понимаю так: дать Вам готовое решение, значит лишить вашего одногруппника-программиста честно заработанной бутылки портвейна.
Поэтому попытайтесь сформулировать проблему почетче. Программисту для решения проблемы нужно знать три вещи, которые ни в коем случае нельзя смешивать.
1. Как решить задачу (голимая математика)
2. Как запрограммировать задачу (записать на алгоритмическом языке)
3. Как запустить задачу (библиотеки, операционки, среды разработки)
С (1) проблемы быть не должно - задача тупая. С (3) у Вас, вроде, все тоже в порядке, Вы, по Вашим сообщениям, способны и готовы учить все эти бесконечные "советы бывалых" и "чайникам о великом".
Видимо, проблема в (2) - значит, надо, во-первых, понять, как, зачем и почему машине надо объяснять решение задачи, а нельзя просто написать: "найди нужную библиотеку и сделай сама". Разбейте решение на куски, которые называются примерно так, как разделы учебника, и - вперед, читать!


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Вторник, 05 Мая 2015, 14:56 | Сообщение # 1205 | Тема: Как вы относитесь к лямбда-выражениям?
почти ветеран
Сейчас нет на сайте
Цитата Saitei ()
В подобных ситуациях
Это пример того, как устаревшая парадигма (ООП), помноженная на убожество ОС (плохой интерфейс CUA), заставляет программиста делать ненужную ему фигню (Qt и прочее визуальное "программирование"), которую ему затем искусственно "облегчают" (новые C++)...
По мне, запомнить, как пользоваться указателями, гораздо проще, чем запомнить, что они там имеют в виду под суб-/суперклассированием, делегированием и лямбдами...

P.S. И не надо забывать, что лямбды C++ не имеют никакого отношения к настоящим.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Вторник, 05 Мая 2015, 15:07
GudleifrДата: Вторник, 05 Мая 2015, 10:08 | Сообщение # 1206 | Тема: Как вы относитесь к лямбда-выражениям?
почти ветеран
Сейчас нет на сайте
Цитата _morglod ()
как можно сделать подобное (ниже) без "лямбд".


Здесь важно "шашечки или ехать?".
Ведь, семантика приведенного фрагмента - "5+5".
С какой целью введена локальная функция?

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

С целью создать много похожих ф-ий? Это вполне реализуемо на массивах.
Вызывать из одного места разные ф-ии? Для этого есть указатели.
Да и макросы никто не отменял.

Так что, только "шашечки".


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Понедельник, 27 Апреля 2015, 19:42 | Сообщение # 1207 | Тема: А зачем вообще нужен АСМ?
почти ветеран
Сейчас нет на сайте
Раз пошла такая пьянка, то вот пример, как хорошо было жить без управляемого кода.
Вполне допустимо по изначальным стандартам Си и правильно компилируется gcc.
Код
#include<stdio.h>
#include<stdlib.h>

w1(d1)
{
    printf("Helo, int %d\n", d1);
}

long w2(d1, d2)
{
    printf("Helo, long %d\n", d1);
    return(0);
}

double w3(d1, d2, d3)
{
    printf("Helo, double %d\n", d1);
    return(0.);
}

w4()
{
    exit(1);
}

int ReadCode[4];

Fill()
{
    ReadCode[0]=(int)w1;
    ReadCode[1]=(int)w2;
    ReadCode[2]=(int)w3;
    ReadCode[3]=(int)w4;
}

int pc;

Step()
{
    int(*fword)();
    fword = (int(*)())ReadCode[pc];
    pc++;
    fword(1, 2);
}

main()
{
    Fill();
    pc=0;
    while(1) Step();
}


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Понедельник, 27 Апреля 2015, 08:54 | Сообщение # 1208 | Тема: А зачем вообще нужен АСМ?
почти ветеран
Сейчас нет на сайте
Цитата Archido ()
О причинах? Я весь в внимании.
Я их перечислил, как истинные так и мнимые, в "заблуждениях". На 5-й странице.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Понедельник, 27 Апреля 2015, 08:56
GudleifrДата: Воскресенье, 26 Апреля 2015, 18:53 | Сообщение # 1209 | Тема: А зачем вообще нужен АСМ?
почти ветеран
Сейчас нет на сайте
Цитата Archido ()
Всякие костыли оставим любителям извращений.
Ну, как бы, по сравнению с языками ассемблера, все остальное и есть - "костыли". И речь в этой теме должна идти о причинах, когда приходится отбросить костыли и сделать руками.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Воскресенье, 26 Апреля 2015, 18:53
GudleifrДата: Воскресенье, 26 Апреля 2015, 18:41 | Сообщение # 1210 | Тема: А зачем вообще нужен АСМ?
почти ветеран
Сейчас нет на сайте
Цитата HPlusDiese ()
Главной идеей .net - платформонезависимый код, который без каких-либо манипуляций запустится где-угодно.
Как бы ошибка изначально. Как и Java речь идет о дважды непереносимом коде! Во-первых, он переносим только в пределах .net- или java-машины (да еще, обычно, только в пределах одной-двух версий), которую для именно вашей машины не факт, что уже написали и еще не перестали поддерживать. Во-вторых, любая попытка сделать что-то нетривиальное натыкается на сопротивление (как выше вставка кода), и заведомо непереносима.
И .NET и Java - это просто разновидности BASIC (т.е. облегчение жизни путем замены реальной машины виртуальной). Причем, почему-то в них (в отличие от нормальных BASIC-ов) это сделано не в интересах программиста, а в интересах ОС.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Воскресенье, 26 Апреля 2015, 18:01 | Сообщение # 1211 | Тема: А зачем вообще нужен АСМ?
почти ветеран
Сейчас нет на сайте
Archido, см. заблуждение #1.
А тему эту мусолить надо, иначе "недоразумений" не оберешься.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Воскресенье, 26 Апреля 2015, 13:10 | Сообщение # 1212 | Тема: А зачем вообще нужен АСМ?
почти ветеран
Сейчас нет на сайте
Основные заблуждения касательно языка ассемблера:
1. Язык ассемблера связан с процессором и, не интересуясь процессорами, я не обязан изучать всякие там "машинные языки".
В узком смысле это верно, подобные языки все базируются на "машинно-зависимости", но "машина" совершенно не обязана быть процессором. Например, язык .NET или внутренний язык игр Sierra хоть и очень похожи на обычные языки ассемблера, работают на виртуальных машинах, которые к процессору никакого отношения не имеют. Для программиста вся эта машинно-зависимость сводится только к одному: недостаточно знать "свой любимый язык программирования", надо учить какие-то другие, зачастую неудобные, языки, в зависимости от задачи. Будь то язык супер-пупер контроллера или правила дорожного движения. Задаче-зависимость важнее машинно-зависимости.
2. Напиши на языке ассемблера и все будет работать быстрее.
Обычно верно другое: покажи медленную программу - и я покажу хренового программиста. Узкое место самой профессионально-коммерческо-специально-научно-военной программы - это десяток-другой операторов, где надо заставить работать само "железо". Остальное - чисто проблема аккуратного программирования (не копируй большие блоки без надобности, не очищай затираемое, не перевычисляй ненужное...). И обычно любой "любимый язык" имеет средства для того, чтобы упомянутый "десяток операторов" оптимизировать - библиотеки, вставка кусков кода, правка промежуточного представления... Полностью переходить на язык ассемблера совершенно не нужно.
3. Писать на языке ассемблера очень сложно.
В настоящее время - засилья всяческих API - роль "любимого языка" сводится практически к правильной последовательности вызовов этого самого API. Например, оконные программы с использованием Win API на языке ассемблера и на Си выглядят практически одинаково, т.к. самым сложным "машинно-зависимым языком" здесь является язык интерфейса Win.
4. Перейдя на язык ассемблера, мы вынуждены отказаться от структурного и ОО-программирования.
Это верно с точки литературной части "любимого языка", но не с точки функционирования программы. Наоборот, например, компилятор Си++ выдает практически не-ОО код, обрезая почти все ОО-красивости, прописанные в программе. С этой точки зрения, язык прямого доступа к железу позволяет гораздо больше - создать честно ОО-код (например, реализовать нужный для этого кусок SmallTalk). Именно по этой причине, например, фортеры пишут свои FORTH-системы на языке ассемблера - проще и удобнее, а не потому, что требуются какие-то волшебные возможности.
5. Наличие в "любиммом языке" средств "писать в кодах" позволяет писать машинно-зависимые переносимые программы.
Это неверно по определению: машинно-зависимость не может быть переносимой.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.

Сообщение отредактировал Gudleifr - Воскресенье, 26 Апреля 2015, 14:27
GudleifrДата: Суббота, 25 Апреля 2015, 10:01 | Сообщение # 1213 | Тема: Выбор темы для конкурса
почти ветеран
Сейчас нет на сайте
Я с самого начала был за "универсальные игратели игр без контента и авторского замысла".
Ближе всего к этому - "графы". Причем, я бы усугубил - чисто консольная визуализация, позволяющая "содержательно" ползать по графу/редактировать граф. Т.е. не "пойти по правой ветви", а "выбрать множество потомков, обладающих неким свойством". И даже еще бы усугубил - сделать все по возможности не на C, а на shell - с отдельными "C-операциями".
Область применения очевидна - все то же структурирование больших текстов для их редактирования, текстовое хранение семантических сетей и т.п.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Четверг, 23 Апреля 2015, 10:24 | Сообщение # 1214 | Тема: Быки и коровы
почти ветеран
Сейчас нет на сайте
Если еще актуально.

1. Когда мне предлагают с нуля создавать оконный интерфейс, который мне абсолютно побоку, я обычно для начала пытаюсь нарисовать как можно ближе к железу.
Например, настольный вариант игры выглядит так:


2. Нужно каким-то образом выяснить, о каком из 3-х вариантов ООП идет речь (иначе и за отличную работу можно выговор схлопотать). Нужно осторожно поговорить с народом. Проблема в том, что кодеры, исповедующие один из трех путей, обычно уверены, что двух остальных не существует в природе.
Первый вариант - "классический" - представить все сущее в виде стройного дерева классов. Начав с класса "игра".
Второй - "быдлокодерский" - тупо пользоваться ОО-библиотеками. Например, в Qt столько инкапсуляций/полиморфизма, что неграфическую часть можно писать на чисто BASIC.
Третий - "чтоб было" - собрать в объекты данные, используемые совместно, и прицепить к ним очевидные операции, обозначив их операторами (например, добавить штифт к позиции".


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Вторник, 21 Апреля 2015, 21:53 | Сообщение # 1215 | Тема: Какие языки программирования вы считаете лучшими?
почти ветеран
Сейчас нет на сайте
У меня два "холиварных" соображения:
1. Лучший язык ("BASIC") тот, который вообще не требует программирования - задача просто может быть на нем естественно записана (для каждой нужной высокоуровневой операции уже есть свой оператор). Поэтому я люблю языки, на которых можно естественно писать другие языки (например, FORTH).
2. Важной характеристикой для меня является совпадения скорости писания на языке с моей. C++ и языки ассеблеров слишком медленные; Perl слишком быстрый; C и FORTH - в самый раз. И не отстаешь в выражении мыслей от их обдумывания, и не плодишь побочные эффекты быстрее, чем успеваешь их осмыслить. То же, кстати, относится к редакторам и "обезьянникам" (IDE).


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Вторник, 21 Апреля 2015, 15:36 | Сообщение # 1216 | Тема: Идея для конкурса С/С++ программистов
почти ветеран
Сейчас нет на сайте
Цитата Saitei ()
идею бы конкретизировать...
Не получится. Ведь она, как раз, об построении вещей, которые сами себя должны объяснять... Как бы "кибернетические кубики", из которых можно собрать игру, независимо от того, в какой степени она будет реал-тайм и 3D.
Можно разве что, предложить формализовать "язык описания любой игры" через понимание его "машиной". Например, как должна выглядеть с точки зрения "машины" чистая игра-стратегия, если абстрагироваться от границ королевств, строительства зданий, армий разнообразных танчиков?


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Вторник, 21 Апреля 2015, 15:08 | Сообщение # 1217 | Тема: Идея для конкурса С/С++ программистов
почти ветеран
Сейчас нет на сайте
А если рассматривать только "машину игры", без "контента" и "авторского замысла"? Настраиваемые генераторы событий, гомеостаты, уравнители баланса, повышатели/понижатели энтропии, "шахматные" оценщики ситуаций? Признаться, половину терминов сам не знаю, как к играм прицепить, но интересно. Например, игра, которая предлагает игроку оценить вероятность выбора того или иного хода противника, и, соответственно, заставляет игрока выбирать вероятностную стратегию?

Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Вторник, 21 Апреля 2015, 14:02 | Сообщение # 1218 | Тема: Создание карты на основе текста худлита
почти ветеран
Сейчас нет на сайте
Цитата Saitei ()
Глава "Начало начал" будет игровой локацией?
Конечно. Есть же в настольных "змейках-лесенках" позиция "СТАРТ".
Цитата Saitei ()
К сожалению, не всё так просто...
Наоборот, сведение локаций книг-игр к голой геометрии - и есть упрощение.
Если интересно: измышлизмы.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Вторник, 21 Апреля 2015, 12:15 | Сообщение # 1219 | Тема: Создание карты на основе текста худлита
почти ветеран
Сейчас нет на сайте
Пардон за ап, но "чего тут думать-то"? Список локаций обычно соответствует оглавлению книги. Особенно, если учесть, что в хороших книгах-играх список локаций не является чисто географическим.

Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
GudleifrДата: Понедельник, 20 Апреля 2015, 18:18 | Сообщение # 1220 | Тема: Заметки о простых играх
почти ветеран
Сейчас нет на сайте
Как-то вся литература по разработке игр - про маркетинг, да про движки...
А про, собственно, игры почти ничего и нет...
Возможно и не надо.

Вот я, практически случайно, и попытался ответить на вопрос: "А как использовать компьютер для игры?"
Первая глава... там еще шесть...
Прошу прощения, если кому-нибудь показалось, что это не совсем про программирование в современном его понимании.


Быдлокодеры любят повторять: "логика, убивающая мозг",- когда их пытаются заставить программировать.
Форум игроделов » Записи участника » Gudleifr [1220]
  • Страница 61 из 61
  • «
  • 1
  • 2
  • 59
  • 60
  • 61
Поиск:

Все права сохранены. GcUp.ru © 2008-2020 Рейтинг