Airat1995

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

"чтобы меня взяли на работу хотя бы на уровень джуна по Unity/OpenGL/OpenGL ES?"

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

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

Есть два варианта:
- нужно быть солидно выше того уровня, который в среднем предлагается в целевом городе/стране.
- нужно просить намного меньше денег, чем в среднем в целевом городе/стране.

По факту - пока вы аноним - вы никому не нужны. Зарабатывайте репутацию и опыт.

Ключ не может быть ссылкой.

Ну смотри.
Во первых зачем тебе TBO, захотелось секаса с мипмапами?) Да и они более тяжелые.
Во вторых, атлас имеет смысл если текстуры очень мелкие и их очень много, т.е. скорость увеличиться чисто за счет меньшего числа IO операций. Проще загрузить 1 раз файл побольше чем загрузить 100 мелких файлов. В наше время честно говоря не вижу особого смысла заморачиваться с атласами, кроме ситуаций когда каждая текстура размером меньше 64 пикселей.
Подгляди реализацию текстур\атласов и "текстурных регионов" в libgdx. Весьма просто и удобно сделано. Хочешь просто текстуру, хочешь из этой текстуры возьми регион(в общем и целом те самые атласы), есть и реальная реализации атласов.

Вы криво скопипастили.

В файле Mesh.h у вас защитный дефайн FUTUREENGINE_MODEL_H

Начну с конца.

1. RESTfull - это архитектурный стиль. Он никак не коррелирует ни с быстродействием, ни с трафиком, ни с чем.

2. Проблемы с серверами решаются очень просто: Hetzner всего 4000 рублей в месяц.
Вообще идея отдавать проект на размещение в другую компанию, это потенциально дикий геморрой.
Сервера всегда должны быть свои.

3. Про технологии: открываете hh и смотрите на количество резюме по разным языкам и уровень зп.
Опять же не нужно зацикливаться одним городом, смотрите в целом.
По моим наблюдениям самым популярным является lamp стек.
В некоторых регионах на первом месте Java, но оно сильно выше по зарплатам при примерно таком же среднем уровне.

UPD@Airat1995

1. Я просто считал, что если будет сервис statefull, то это нагрузка на сервер, ведь надо хранить данные о пользователе и т.д. Значит я ошибался)
2. Да проблема в том, что вряд ли такое будет возможно сделать, у них строгая политика по поводу пользованием сети интернет (ИМХО скорее всего из-за узкого канала связи)
3. По поводу того, что не нужно зацикливаться на одном городе, у них есть своя фирма подрядчик, которая занимается всем, что так или иначе связано с IT. Когда поставили задачу, мне сразу сказали, что необходимо сделать так, чтобы это было более-менее дешево сопровождать и какая организация будет этим заниматься.

Airat1995:
1. а) STATEless и RESTfull это в принципе разные вещи которые никак не пересекаются.
Сервис вполне может быть STATEless, но не RESTfull и наоборот.
b) Хранение данных о пользователе есть в STATEless сервисе. В STATEless нет хранения данных пользователя (но не бизнес логики) между запросами.
Если у Вас пользователи не измеряются миллионами это ничтожная нагрузка.
* Хотя STATEless бесспорно удобней в интеграции

2. Это интранет приложение и нет денег на отдельную железку? Рискну предположить что нагрузки там не будет по определению никакой.

3. Постановка вопроса несколько странная если честно.
Вы в соседних комментариях пишите что разрабатывать будете сами лично.
Вы мастер на все руки готовый написать на любом из существующих языков с использованием любого фреймворка?!?

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

C++/CLI компилируеться в байт код для виртуальной машинки .net. У него узкая сфера применения на нем можно унаследовать классы с программ на C++ и собрать библиотеку в соответсвие со стандартами C++/CLI с которой можно будет наследоваться с C#. как правило наследуют в программе на C# переоформляют все еще разок. и уже с переоформленных библиотек на C# наследуються C#.net разработчики. Это называеться Wrapper (обертка) через которую программы на C# контактируют с нативными на C++/C.

Этот язык стоит учить если ты хочешь писать эти обертки. Их в нете полно (они должны хорошо продаваться по лицензиям) Они под популярные библиотеки C++. можно сказать на 90 процентов случаев )) в сфере обработки видеоаудио. Телефонии. сети. работы с Данными БД. и всякого такого на все случаи почти.

Там тот же компилятор, что и у C++, управляемый компилируется в байт-код, а неуправляемый в машинный, затем делается bridge (вызывается один из другого).

Этому событию уже больше года. Когда Эпики отказались от платной подписки, всем кто хоть раз оплачивал подписку зачислили на счет по 30$. Вывести, скорее всего, нельзя. Свои потратил в маркете.

На маршрутизаторе можно объединить порты в bridge. Но вообще это совсем не правильный дизайн. Бридж как правило делается центральным процессором маршрутизатора и он умрет от нескольких десятков Mbit трафика. Лучше объединить коммутаторы между собой напрямую в один широковещательный домен.

Ну и какой мы хотим сигнал перехватить? Экран? Для этого есть фрейм граберы. А можно подключить композит и отдельной платой собирать аналог. Да и цифровой HDMI пусть и передаёт цифру, таки физика всё равно остаётся - снимаем напряжение и дело в шляпе, разве только делать это придётся очень быстро, да ещё и ошибки корректировать. Из софта можно хукнуть directx или opengl, но там скорее всего не будет шейдеров - издержки конвейера, или же создать виртуальный монитор, но здесь сложности с аппаратным ускорением. Есть более специализированные методы, вроде отслеживания участка памяти или общение с видеокартой посредством одного из множества API. Но эти способы очень платформозависимые.

Сейчас, в эпоху онлайн-сервисов, даже десктопные приложения частично работают с веб-службами и прочими интернетами, так что некоторые серьезные производители ПО уже начинают забивать на защиту десктопного приложения, ограничиваясь только проверками на стороне сервера при работе с сетевым функционалом (ну не знаю, например заливка файла в облако). Конечно, это пока не для всех подходит, но имеет смысл с учетом того что не ломаются только малопопулярные приложения (т.к. не интересуют взломщиков), а любые нормальные клиенты будут покупать продукт (на Западе вообще другой менталитет, люди считают работу ПО не по лицензии таким же воровством, как и украденный кошелек). Код на C++ тоже вполне себе неплохо дизассемблится тем, у кого есть опыт. Да, исходник восстановить гораздо сложнее, даже невозможно, но это и не нужно - все ломается в каком-нибудь OllyDbg по ассемблерному коду.
Кстати, Word и Photoshop это скорее "коммерческое" ПО, энтерпрайзом обычно называют всякий внутренний софт (банковские системы, всякие автоматизаторы, генераторы отчетов), и там C# не просто используется, а конкрурирует только с джавой. WPF и прочие технологии как раз для такого софта и создавались. Если хотите примеры продаваемого ПО на шарпе: ну вот хотя бы Citavi - вполне серьезный софт для референс-менеджмента (управление библиографией и ссылками в научной деятельности). Все на шарпе, использует кучу библиотек, при этом вполне себе стоит денег.

Кокос очень сильный движок и сейчас активно развивается