>>19386
>Откуда начать учить код, чтобы научиться
Сначала надо выбрать, чему ты хочешь научиться. Здесь тебе поможет наша база знаний: https://pastebin.com/AGhLZppH

>>Я хочу программировать, но не понимаю, куда можно приложить усилия
http://410chan.org/dev/arch/res/14160.html#14354

>>19384
Да, я понимаю что автор поста скорее всего ничего делать не собирается и упражняется в остроумии На самом деле, это всё менее нереально, чем кажется, вопрос только в том, в каком виде оно на самом деле может существовать сейчас.

Сначала сгруппируем твои желания
>Чат-бота с характером указанной кавайной девочки...
>Движок имиджборды, на которой будут общаться чатботы с личностью различных 2д персонажей...
Это два желания из одной категории, чат-бот с установленной личностью. Движок имиджборды тут вторичен, т.к. он может быть самый обычный, в то время как постингом будет заниматься твой бот через стандартный интерфейс. Опуская вопрос, что имиджборда не чатик

У чатботов, по крайней мере у известных мне типов, есть проблема - он не скажет тебе больше фраз, чем ты в него занесешь. Но, если повыдирать подходящие фразы персонажа из всех возможных источников и додзи, а также потратить время на обучение (желательно, силами нескольких человек), то можно получить бота который сможет тебя на какое-то время развлечь. Базово, тебе нужен свой Cleverbot, API к нему и кастомный интерфейс.

>скринсейвер с процедурно генерируемым pole dance...
Здесь вопрос в том, сколько кода и ресурсов позволяют использовать скринсейверы в принципе. Если отбросить фактор скринсейвера, и попробовать сконцентрироваться на задаче поул-денса, то нужны: банк анимаций для поул-денса, который надо найти, или создать самому, затем нужно пособие по поул-денсу, где указано каким движениям / анимациям лучше следовать после каких, затем нужно создать управляющий код, который будет включать эти анимации, в определенном порядке, а также составлять расписание повторов этих анимаций нужно, чтобы ты не видел одни и те же анимации через короткий промежуток времени Крутить это всё в риалтайме может игровой движок типа Unity.

>процедурный генератор хентая... да
Это делается так же как поулденс, если сможешь сделать его, то по той же технологии сделаешь и это.

>Прогу которая делает 3д модель кавайной девочки по её картинке...
Такое уже существует, но суть в том, что картинку кавайной девочки такое ПО получает из контролированной среды, т.е. обычно само ПО камерами / лазерным сканером и управляет.
Если ты хочешь воссоздать такое самостоятельно, то основная инженерная проблема здесь - отсутсвие информации о глубине изображения. На вид, проще всего эта проблема решается наличием стереоизображения, их с приходом VR всё чаще можно встретить в сети. Вторая проблема - используя данные о глубине со стереокартинки, ты сможешь создать маску лица, но не смоделируешь то чего камера не видит, т.е. например весь череп, или то на что у камеры / изображения не хватит dpi, т.е. волосы. Проблему с черепом и всем остальным можно решить, используя модель-заготовку, к которой будет применяться снятая тобой 3д-маска. Проблему с волосами - допилом руками или получением не сжатого стерео-изображения в очень большом разрешении.

>прогу которая генерирует качественный виабу рисунок по фотке 3д тян...
>прогу которая делает хентай аниме адаптацию обычного порно ролика...
Это всё задачи одной категории. Ты хочешь deep-обработку изображения. Для этого используют нейросети, с разной степенью успешности. Базово тебе надо та из них, которая умеет создавать арт нужного стиля из примитивных форм, самостоятельно, как вот эта:
https://github.com/alexjc/neural-doodle
С помощью подобной штуки ты сможешь раскладывать изображение на примитивные формы разных цветов как это делают векторизаторы, например, которые будет в нужном стиле оформлять нейросеть. На первом этапе скорее всего придётся вообще выбрасывать фон, и составлять примитивы опираясь на цвет кожи. Тут две проблемы: первая, в манга-стайл арте используются линии, а дип-создатели изображения собирают его из мазков. Вторая: обучение нейросети, которое может занять много времени, котрое можно много раз зафейлить, и которое нельзя завершить, только прекратить. Но это хотя бы путь, который можно попробовать.

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

Надеюсь, информация была полезной.

>>19392
>банк анимаций для поул-денса, который надо найти
Чередование паттернов будет немного не то. Настоящая генерация это когда программа просто знает, как танцевать этот танец, и делает это, как делала бы настоящая девочка. Генерирует не последовательность анимаций, а саму анимацию. Да, в танце есть базовый набор движений, но возможных вариаций и нюансов очень много, все заранее не предусмотришь. Там не только разные возможные движения, но и их сочетания, когда одно плавно переходит в другое. Вот пример:
https://youtu.be/eM2Lkpm0yFc?t=41
Надо чтобы было как здесь, но с любыми персонажами и костюмами, какие захочу.
Вообще конечно это была бы ахуенная программа, как раз есть уйма персонажей в исполнении которых я хочу такой танец. Лично для меня это будет даже приятнее смотреть, чем хентай порево с их участием.
Вот самый простой пример, с моего любимого ютуб канала
https://youtu.be/HAbXPl_zUuY?t=139
Тут девочка просто ходит вокруг пилона, красиво переставляя ножки. Но даже это может быть сколь угодно разнообразным.
Я уж не говорю о совсем сложных вариантах, как этот:
https://www.youtube.com/watch?v=admrqtar8_U
Алсо, кроме этого, девочка может: время от времени поправлять край чулка; забираться на предмет мебели и демонстрировать, скажем, попу; становиться перед зеркалом и разглядывать своё тело, поворачиваясь и слегка лаская себя. Тут нужен сложный AI, такой же сложный как для чат-бота, который проходит тест тьюринга. У разных исполнительниц также могут быть разные характеры - одни спокойные, другие страстные, есть весёлые, есть романтичные, есть чуточку пошлые.

>>19394
>Настоящая генерация это когда программа просто знает, как танцевать этот танец
Проблема "понимания" насколько мне известно, пока не решена, в т.ч. потому что не понятно, что такое понимание в контексте настоящего мозга. Все текущие "AI" программы на самом деле дают тебе только эффект разумного поведения, но не само разумное поведение. И в основном это всех устраивает, т.к. "AI" используют или как экспертные системы, или как вспомогательный элемент другого ПО, или вообще в учебно-развлекательных целях.

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

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

>>19395
>следить за новостями и пробовать новые технологии по мере выхода
А вообще хоть иногда придумывают что-то новое, на замену имеющимся "деревянным" методам программирования?

>>19396
Вся история развития программирования и языков программирования - это взять "деревянное" и сделать с помощью него что-то менее "деревянное". Идет постоянное создание более простых и гибких инструментов, с которыми тебе меньше надо думать о реализации снизу, и больше над тем, что ты хочешь непосредственно создать.

Отсюда появляются новые подходы к программированию, новые языки программирования, domain-specific языки для конкретных предметных областей, новые библиотеки, фреймворки, новая оснастка, и т.д.

Например, пацаны AI-шники взяли "деревянные" языки программирования и создали с помощью них инструментарий для удобной работы с тем типом AI, который их интересовал, и теперь ими может пользоваться каждый.

Единственное что пока не меняется во всем этом - это необходимость иметь в своем ПО хоть какой-то, но алгоритм.

Как думаете, может ли программирование лет через десять достичь такого уровня, чтобы на e-hentai публиковалась тоннами уже не додзинси-манга, а додзинси-анимация (и 2D, и 3D-CG), сделанная любителями посредством новых интеллектуальных программ, без значительных усилий и с высоким уровнем оригинальности?

>>19398
"Программирование" к описанному процессу отношения не имеет. Его возможность определяется доступностью конечных средств для создателей контента, или инициаторов создания контента, а также их личными предпочтениями формата творчества.

>>19399
Ну ты же понимаешь, что сейчас невозможно автоматизировать самые трудоемкие части процесса создания анимации. Слишком уж громоздкий будет код - как у десяти 3дс максов, а то и больше. А вот если будет НС-аниматор, которая ясно понимает, что от нее хотят... Достаточно будет: показать концепты персонажей, привести подробные описания сцен, уточнить ракурсы - и она всё нарисует, с последующими корректировками. Будут почти бесплатно тонны оригинального хентая по любым франшизам и наивысшего качества.

Сегодня поиграл в такую штуку как Teaching Feeling. Очень понравилось, причём не столько хентаем, сколько ощущением совместного быта, общих дел и чего-то такого.
И стало интересно - насколько сложно сделать ВН или даже чат-бота с симуляцией общения, настроения и (самое сложное, кмк) развития отношений. Допустим, это будет девушка и сначала она тебе не доверяет, стесняется, ведёт себя зажато, а потом вы друг друга лучше узнаёте и развиваете общение. Такое возможно вообще? Что-то слышал про цепи Маркова, но в детали не вдавался. Я так понимаю, тут с наскока не выйдет и некий AI нужен, т.к. мало обучить бота отвечать на фразы правильно - у него не появится ощущение времени и длительности знакомства. А вот как их реализовать даже в теории - хз.
Взять условное частота общения * количество дней знакомства ? 10 дней подряд пишешь только "Привет" - так и остаёшься левым чуваком, за 2 дня проболтал несколько часов подряд - уже в раздел "Приятели" переходишь и т.д.

Вообщем, интересно любое мнение и мысли на этот счёт, т.к. тупо поболтать можно и с Сири/Алисой, а вот симуляции развития знакомства я ещё не видел

>>19402
Твои вопросы не имеют отношения к кодингу, тебе в /l/ или еще куда где собираются графоманы.

>>19402
>Допустим, это будет девушка и сначала она тебе не доверяет, стесняется, ведёт себя зажато, а потом вы друг друга лучше узнаёте и развиваете общение. Такое возможно вообще?
Уже давно сделано в Artificial Academy 2.

>>19409
Ты не понял. Он имеет ввиду, чтобы вместо обычных заготовок-фраз, ты должен сам отвечать текстово именно и никак по-другому. И тип, уже тогда, чтобы ИИ отвечал: базируясь в первую очередь на то, что ты отвечаешь и учитывал время знакомства. Получается эдакой гибрид Алисы и реплики.

>>19413

Да это же вымышленная игра «Love Touch» из второй серии второго сезона превосходного аниме «Ore no Imouto ga Konna ni Kawaii Wake ga Nai».

>>19405
А Тебе в /b с таким толстым троллингом. Подробно расписал основные стоящие проблемы и вопросы - нет, всё равно не дошло.

>>19413
Вот да, т.к. при заготовках отсутствует развитие. Это вечно будут одни и те же заготовки и не будет ситуации вида:
Что делаешь?
- Пишу пост на ычане
Что такое ычан?

И тебе надо хотя бы вкратце с ключевыми словами объяснить что это. Т.е. вопрос ещё и по аналитике текста. Как он вообще программно разбирается. Т.к. можно было бы заюзать теги навроде html, где указывать ключевые слова, на что АИ должен внимание обратить. Тогда при фразе "Это что-то вроде анонимного форума" может выйти ответ "Форума? Как ru-board, про который ты недавно рассказывал?"

>>19392
>Это делается так же как поулденс
Всё гораздо сложнее.
Хентай = эстетика. Впрочем, даже её можно формализовать. Что нас привлекает в хентае? Образы героинь. Как создать гармоничный образ? Прежде всего, цвета. Они генерируются по определённым схемам - цветовые триады, тетрады, аналогии с акцентами. Скажем, белый цвет, плюс красный (противоположность по уровню насыщенности), плюс коричневый (соседний с красным, но более тёмный чем оба других. Они распределяются по элементам внешности - один цвет на причёску, другой на глаза, третий на рубашку, четвёртый на юбку и бант... Также рандомно, но более или менее сообразно с другими элементами, выбираются предметы одежды, длина волос и прочее. Главное чтобы везде были контрасты, любое искусство основано на показе контрастов.
Характер определяется по главным его особенностям, как в AA2, но они ещё смешиваются в разных пропорциях, и одна черта может сильно преобладать над другими. Для завершённости портрета надо быстро прогнать сколько-то лет её предшествовавшей жизни, как делается у миров в Dwarf Fortress. Тогда для её AI будет что вспомнить по случаю.
Затем так же генерируется мир, в котором происходит порево - как в циве или том же DF. Исходя из социального статуса героини, её забрасывают в ту или иную ситуацию. Это может быть как романтическая история, так и череда изнасилований, или история о проститутке.
Процесс порева - это череда рандомных поз (основанных на характере персонажей, например некоторые любят жёсткий секс), с рандомных ракурсов (но чтобы хорошо смотрелось, чтобы в кадре была гармоничная композиция), с правдоподобными диалогами, основанными на характерах и воспоминаниях персонажей. Перед ним будет предыстория о том, как случилось что героиню няшат. Сильно упрощённый пример историй вы можете увидеть в режиме "Legends" в DF.

>>19417
Про характер, допустим одни девочки любят анальный секс. другие терпеть не могут, но их заставляют им заниматься. Это повлияет на диалоги, на выражения лиц, и немного на то какой будет поза.

>>19415
>>19417
>>19418
Балмеры, эта нить - хелпдеск, а не нить для обсуждения.
Для хелпдеска очень важно не разбавлять полезную информацию мусором.

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

Кто посоветует неплохой кросс-платформенный gui под go? Чтобы быстро можно было прототип накидать как в python и tkinter

>>19473
Такая штука выглядит достаточно простой и удобной?
https://github.com/andlabs/ui/wiki/Getting-Started

Хочу написать демку на canvas + WebAssembly (компиляция из Rust). Есть ли готовый пример того, как гонять битмапдату от воркера до контекста?

>>19481
В самом банальном случае их как-то так вместе скручивают:
https://www.hellorust.com/demos/canvas/index.html

Тебя скорее всего интересует второй листинг, там где код загрузчика на JS.
>We create an ImageData backed by memory allocated on the Rust side, and regularly update it.

1) Какова должна быть минимальная конфигурация, чтобы своя ИНС могла справляться с задачами? И возможно ли вообще делать это на своем компе, или лучше арендовать облако для вычислений?
2) Каков оптимальный пакет программ для такого пользователя, который, ну, даже не джун, а шинку, да еще со слабым ПК? Например я слышал, weka хорошая вещь, это ПО для машинного обучения такое. Не слишком сложное, подойдет оно для Шинку? Или там надо самому придумывать что-то сложное, чтобы достичь нужного результата?

>>19528
1) Зависит от задач.
2) Same.

Прочитай вот это:
https://stu.scask.ru/book_ins.php
Книжка не плохая, хоть и устаревшая. Не будешь всякие вопросы задавать.

>>19529
>Secure Connection Failed

>An error occurred during a connection to stu.scask.ru. Peer reports it experienced an internal error. Error code: SSL_ERROR_INTERNAL_ERROR_ALERT

>>19530
Загузи по ххтп тогда.

>>19529
http://sernam.ru/accessquery/accessquery.php
А вдруг откажут? Что писать если нигде работаю и не учусь?

>>19528
>>19551
Я бы начал реализацию нейросети уже на базе чего-то готового. Например, аноним выше спрашивал книгу по Keras, которая покрывает многие аспекты не только создания нейросети, но и работы с ней в облаке, етц. Держи линк на эту книгу, и скажи, что думаешь: http://rgho.st/6F4FQvJ5l
сорри, что только скан

>>19554
>>19551
Но если очень хочется именно ту книгу Борисенко, то вот она тоже (Djvu): http://rgho.st/7FnzsyTSF

Также, судя по всему, у нас теперь появился хелпдеск по машинному обучению >>/dev/19531

Насколько надежно я могу полагаться на следующие допущения:

FF D9 - конец jpeg

49 45 4E 44 AE 42 60 82 - конец png

00 3B - конец gif

Могут ли данные сигнатуры встретиться в середине изображения? В случае gif — всегда ли предпоследний байт 0? В случае png — всегда ли последние 4 байта, которые после IEND, именно такие?

Есть ли что-то подобное для определения конца видеоформатов (webm, ogv, mp4)?

>>19568
Отвечу про PNG.

>49 45 4E 44 AE 42 60 82 - конец png
Если посмотришь в хекс редакторе, то
>49 45 4E 44
это имя конечного чанка, а конкретно IEND
на пикрелейтед ты можешь видеть IHDR IDAT IEND

>Могут ли данные сигнатуры встретиться в середине изображения?
Теоретически, такое случиться может. Поэтому, настоящий декодер будет пытаться считать заголовок чанка только если он уверен, что прошлый чанк уже закончился. Для этого перед началом каждого чанка присутствует 4 байта указывающие его длину, чтобы знать до куда его читать и не заботиться.

PNG декодер будет считывать IEND по структуре, указанной здесь: http://www.libpng.org/pub/png/spec/1.2/PNG-Structure.html
Учитывая то, что до этого он уже считал / пропустил все чанки, по длине в них указанной, то он будет уверен, что читает заголовок чанка, а не что-то левое.

По хорошему, тебе бы надо сделать так же. Но если тебе надо просто примерно понимать, что это может быть конец файла, а не знать это точно, то можешь попробовать расширить последовательность до

>00 00 00 00 49 45 4E 44 AE 42 60 82

Тут сначала 00 00 00 00, т.к. это 4 байта указывающие длину данных в чанке у IEND она 0 поэтому все 4 байта нули потом 49 45 4E 44 которое IEND, потом ничего, т.к. длина 0, потом 4 байта CRC, которые для IEND будут всегда одинаковыми. Конечно, никаких гарантий это не дает, но думаю во многих случаях ты действительно правильно определишь конец файла.

>>19569
>> 49 45 4E 44
>это имя конечного чанка, а конкретно IEND
Это-то понятно…

>Теоретически, такое случиться может.
>но думаю во многих случаях ты действительно правильно определишь конец файла.
Ясно. Значит, это можно использовать лишь для первичной оценки ситуации, для точной гарантии придется парсить картинку. Жаль.

Тогда следующий вопрос — какой максимальной длинны может быть мусорная строка из цифр, добавляемая к картинкам куклой и/или ее аналогами? И всегда ли это только цифры?

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

>>19571
>Сейчас думаю смотреть конец файла на "сигнатура + строка из цифр", и в случае срабатывания — дальше уже разбирать подробно, чтобы убедиться, что это действительно оно, а не какой-то кусок аттача.
Написал, подумал и понял, что более оптимальный алгоритм будет примерно таким:
1. Смотрим конец файла, если там сигнатура — считаем это чистой картинкой, не требующей обработки.
2. Если там нет ни сигнатуры, ни куклостроки с сигнатурой перед ней — это аттач или вообще что-то левое. Можем, если хотим, разобрать подробнее, а можем этого не делать. А можем занести в список и отложить разбор на потом.
3. Если там куклострока с сигнатурой перед ней — просматриваем весь файл. Если там нигде не встречается еще одна сигнатура — перед нами чистая картинка, и мы можем смело куклостроку удалять.
4. Если же где-то в середине нам эта сигнатура всё же встретилась — вот тут уже надо подробно разбираться, что это за зверь, и где там на самом деле конец картинки.

Вроде бы, такой подход должен работать и к потере данных не приводить.

Таким образом, осталось уточнить два вопроса:
1. Максимальная длина куклостроки.
2. Всегда ли сигнатура конца gif — именно 00 3B.

Или преждевременная оптимизация — корень всех зол, и тупо разобрать вообще каждую картинку будет проще/быстрее?

>>19572
>>Всегда ли сигнатура конца gif — именно 00 3B.

Конец gif - всегда 3B хотя 00 - терминатор прошлого блока, так что в целом и его можно использовать
http://www.matthewflickinger.com/lab/whatsinagif/bits_and_bytes.asp#trailer_block

Но тут дела обстоят так же как и с PNG, в тот момент когда декодер считывает это 3B, он уже считал / пропустил все блоки до этого, согласно информации в них указанной. Как и PNG, в GIF блоки имеют информацию о своей длине. Подробнее разобрано тут: http://www.matthewflickinger.com/lab/whatsinagif/bits_and_bytes.asp

И если у PNG еще достаточно длинный закрывающий блок, чтобы можно было хоть как-то надеяться на то, что он встретиться только в конце файла, то и 3B и 00 3B, как мне кажется, будут встречаться по файлу достаточно часто.

>Или преждевременная оптимизация — корень всех зол, и тупо разобрать вообще каждую картинку будет проще/быстрее?
Мне кажется да, т.к. тебе не надо разбирать картинку, тебе достаточно знать, где у блока идентификатор, и где у блока длина. А затем просто "пропускаешь" байты до следующего блока, и так пока не встретишь терминатор. Мне кажется это будет быстрее, чем матчить по файлу последовательность байт.

Нужен легковесный, но гибкий GUI для одной хитровыебанной десктопной проги. Слышал про какой-то Scaleform, который уже вроде как не поддерживается Autodesk-ом, но его до сих пор используют в некоторых игровых движках и в нулевых использовали в десятках, если не сотнях приличных игорей. Тяжело ли его встраивать? Возможно ли это сейчас вообще?

>>19584
Если верить автодеску, последняя поддерживаемая версия вышла не так давно, летом 2017.

>Возможно ли это сейчас вообще?
Автодеск говорит, что возможно, при некоторых условиях:
>This section describes how to integrate Scaleform with a custom DirectX application.
https://tinyurl.com/scaleform-integration-custom
И общий хелп по интеграции:
https://tinyurl.com/scaleform-integration-topic

>Тяжело ли его встраивать?
Нужно заинтерфейсить достаточно много компонентов вместе так, чтобы они в итоге заработали:
>>Interfacing C++, Flash, and ActionScript
>ActionScript to C++
>C++ to ActionScript
>Communication between Multiple Flash Files

А что скажешь по поводу посмотреть в сторону веб-фреймворков?
Сейчас есть несколько способов прикрутить свой C++ код к вебкиту.

Пытался загрузить базу данных и наткнулся на такую ошибку (виндоуз):

 unicodedecodeerror: ''charmap'' codec can't decode byte 0x98 in position 49: character maps to <undefined> 

Исключение бросалось из ../python/lib/encodings/cp1251.py. Я его скинул на рабочий стол и снова попробовал загрузить БД. В этот раз все получилось.
Так ли сильно нужен cp1251.py или можно спокойно работать и без него?

>>19590
Спасибо за ответ, но я уже одолжил у них весь SDK, откопал там документацию и понял, что это слишком геморно. Для моего проекта, по крайней мере. Конечно, я могу попробовать украсть еще немного кода у Crytek или еще какого опенсорсного движка, там у них ведь всё уже прикручено куда нужно, но у них не самая удобная реализация обычно, ведь там нужно дополнительно XML-разметку писать, чтобы подружить движок и swf. Собирать команду в 50 человек и MMORPG писать я не собираюсь, так что этот вариант отпадает тоже.
>А что скажешь по поводу посмотреть в сторону веб-фреймворков?
Даже не знаю, Стиви. Оно всё слишком много памяти жрет, лучше когда-нибудь потом об этом подумать. Если когда-нибудь потом о десктопе вспомнят и забудут про веб и мобилки.

Я вчера скачал старый Flash CS6, Adobe Air runtime, накидал "хелоуворлд" и курнул доки, чтобы проверить, всё ли оно может, что мне нужно. Всё. Кушает 10мб оперативной памяти и 1-3% процессора для проигрывания няшных векторных анимаций при 60FPS. Поделки на вебкитах и прочих електронах на js так могут? А удобные инструменты сопоставимые хотя бы с частью того, что Adobe непосильным трудом нажил для флешечки, там есть?

Как бы единственные два минуса сейчас - это то, что Adobe собрался хоронить Flash где-то в 2020-ом году (следовательно, поддерживать это будет проблематично, ведь форумы старые прикроют, крутые флешеры уходят на пенсию и т.д.) и то, что все будут говорить "ой, это что, Flash, но зачем, оно такой старый, бла бла...". Но мне всё равно, ведь я просто хочу быстро сделать красивый прототип к 2019-му примерно. Никаких зоопарков почти несовместимых между собой инструментов, никаких дополнительных оптимизаций.

>>19592
Ах да, в крайнем случаи я могу експортировать все наработки в html5. Эта функция уже давненько есть в Flash.

>>19592
>>19593
Если флеш с эйром устраивают, то почему нет? Тем более, насколько я знаю, их тулкиты тебе позволят собрать standalone-бинарник со всем нужным, чтобы пользователь и не задумывался над тем, на флеше оно, или нет.

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

>>19593
Давай разберемся, что у тебя произошло.
>Исключение бросалось из ../python/lib/encodings/cp1251.py.
Суть в том, что питон попытался обработать строку, используя стандартную системную кодировку, т.к. иная не была указана. Т.к. у тебя винда, возможно не очень новая, еще и локализованная, то стандартная кодировка у неё Windows-1251, она же CP-1251.

А строка была в несовместимой кодировке, т.е. в ней были символы, которые отсутствовали в таблице символов кодировки CP-1251, что и привело к ошибке:
>''charmap'' codec can't decode byte 0x98 in position 49: character maps to <undefined>

>Я его скинул на рабочий стол и снова попробовал загрузить БД. В этот раз все получилось.
После того как ты его выкинул, очевидно, не найдя обработчик для CP-1251, питон решил фоллбеком обработать строчку как UTF8, и всё получилось.

>Так ли сильно нужен cp1251.py или можно спокойно работать и без него?
Если тебе не надо работать с текстом конкретно в этой кодировке, то не нужен.
Но вообще, если ты всегда будешь указывать целевую кодировку для энкодинга / декодинга строк, она не будет тебе мешать, так что можешь вернуть.

Еще про схожую ситуацию пишут тут: https://stackoverflow.com/a/9233174
Здесь, правда, у человека CP-1252.

>>19592
>Кушает 10мб оперативной памяти
Ты уверен, что у тебя рантайм этого фуфла отдельно не жрет сверху еще мегабайт 50 где-то рядом?

>1-3% процессора для проигрывания няшных векторных анимаций при 60FPS. Поделки на вебкитах и прочих електронах на js так могут?
Если анимация корректно сделана, то элементарно. Анимация все равно должна на GPU отрисовываться.

>>19595
>Ты уверен, что у тебя рантайм этого фуфла отдельно не жрет сверху еще мегабайт 50 где-то рядом?
Ну, посмотрю завтра еще раз.
>Анимация все равно должна на GPU отрисовываться.
Возможно, она на ней и отрисовываться, но точно не на дискретной (я проверял и там не было никакой активности), а на встроенной разве что. А для неё, если не ошибаюсь, выделяется кусок оперативной памяти и в диспетчере задач оно, наверное, не отобразится... Или это только для виндовых формочек и кнопочек всяческих так ускорение работает? С этим нужно разобраться.

>>19594
Спасибо за ответ!

>>19598
Посмотрел. Ничего больше не видно такого, что может иметь отношение к виртуалке эира и самому приложению.
Есть еще некоторая вероятность того, что объем потребляемой памяти может резко подскочить, если понаподключать много разных функций через ActionScript. Использование ЦП растет в зависимости от того, что отрисовывается. Например, в одном примере из того SDK находились swf-ки, которые крутили-вертели полупрозрачный текст и фигурки с наложением в 3-4 слоя друг на друга, нагружая ЦП на 10-15%.
Работать на дискретной видеокарте не получилось заставить. Видимо, это работает только для ускорения декодирования видео. Наверное, поэтому и был создан Scaleform в то время, когда Air уже существовал. Для отрисовки игрового интерфейса на векторной графике с ускорением. GPU-Z показывать потребление памяти для Intel HD Graphics не хочет.
На скриншоте запущенное приложение. Рантайм вшит.

>>19573
>тебе не надо разбирать картинку, тебе достаточно знать, где у блока идентификатор, и где у блока длина.
Эх, как легко разбирается в этом плане png и сколько крови мне попортили другие форматы… Но это таки единственный правильный способ, потому что все последовательности байт вполне себе встречаются в центре файла.

Так вот, у меня сейчас остался последний вопрос — как правильно определять длину блока APP0 (он же JFIF, метка FF E0) в jpeg? С содержимым следующих двух байт после метки его длинна зачастую не имеет ничего общего. Часто (но не всегда) это бывает в случае, если там написано 13.
Пикрелейтед — типичный пример такого jpg, его первые 6 байт: FF D8 FF E0 00 0D. И 000D — это ни разу не длинна блока. В данном случае, блок всего на 1 байт больше, чем нужно. Но так бывает не всегда.

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

>>19633
Интересно, как такое вообще происходит, и зачем они игнорируют собственное поле длины блока. Длина, конечно, включает в себя всё кроме маркера, но там же еще thumbnail data, которая никак не может поместиться в 13 байт.

Вот тут пишут: http://www.fileformat.info/format/jpeg/egff.htm

>Length is the size of the JFIF (APP0) marker segment, including the size of the Length field itself and any thumbnail data contained in the APP0 segment. Because of this, the value of Length equals 16 + 3 × XThumbnail × YThumbnail.
>Length equals 16 + 3 × XThumbnail × YThumbnail

Т.е. получается что оно вообще в принципе не может быть меньше 16 байт (включая сами байты указывающие длину), и откуда там взялось 13, не ясно.

В твоей картинке эти 16 байт это:
>00 0D 4A 46 49 46 00 01 01 01 02 58 02 58 FF DB
И если верить вот этой спеке у тебя правда JFIF 1.01 https://www.w3.org/Graphics/JPEG/jfif3.pdf
То это информация от начала блока длины и вплоть до размеров thumbnail'а
00 0D - длина 13 байт ха-ха
4A 46 49 46 00 - JFIF с нуль-терминатором в конце
01 01 - версия JFIF, 1.01
01 - указатель на единицу измерения разрешения, в данном случае DPI
02 58 - горизонтальное разрешение, 600 DPI
02 58 - вертикальное разрешение, 600 DPI
FF - ширина thumbnail в пикселях, 255
DB - высота thumbnail в пикселях, 219
И дальше должен идти нехилый такой массив thumbnail data. Если бы её не было, то поля ширины и высоты thumbnail'а были бы выставлены как 0:
>If no thumbnail image is included in the marker, then these fields contain 0

Сами данные thumbnail'a лежат как
>Uncompressed 24 bit RGB (8 bits per color channel) raster thumbnail data in the order R0, G0, B0, ... Rn-1, Gn-1, Bn-1; with n = Xthumbnail × Ythumbnail.
И должны занимать 3 × XThumbnail × YThumbnail байт. Даже интересно теперь, действительно ли там будет thumbnail, при таком нарушении формата. Попробуй вычитывать APP0 ориентируясь на эту информацию 16 + thumbnail и сообщи о результатах.

Еще, по ссылкам ты можешь заметить, что тебе надо смотреть на версию JFIF, т.к. начиная с версии 1.02 сразу вслед за APP0 блоком может идти APP0 Extension, который тоже надо определять и пропускать

На всякий случай еще место со ссылками на спеки разных версий:
http://fileformats.archiveteam.org/wiki/JFIF

>>19636
>Попробуй вычитывать APP0 ориентируясь на эту информацию 16 + thumbnail и сообщи о результатах.
Попробую.
А пока хочу заметить, что если эти самые FF DB считать не размерами thumbnail, а началом следующего за APP0 блока (FFDB означает, что это будет блок DQT), а поле после него, соответственно, размером этого блока, то дальше картинка разбирается нормально. Такие дела…

>>19637
Мне кажется надо глянуть, как с картинкой справятся существующие наколенные реализации, если они всё делают правильно, то можно будет позаимствовать алгоритм.

Например, здесь код явно должен вывести тебе содержимое поблочно (смотри внизу файла): https://github.com/enmasse/jpeg_read/blob/master/jpeg_read.py

Бамплимит.

>>19643
Сделали новую нить >>19666
Закрепите её вместо этой, пожалуйста.