hawkkiller, Не нужно создавать временный файл. Нужно переименовать существующий во временный. т.е. никакой some_file не нужен, нужно лишь имя.
path1.renameto("временный");
path2.renameTo(filepath1);
path1.renameto(filepath2);
move ещё два аргумента содержит с путём исходного и путём целевого файла. Странн, что без аргументов компилируется.
hawkkiller,
сперва проверить, что оба файла существуют. Если оба существуют, то p1 переименовывается в любое временное название, p2 переименовывается в название p1, потом временное название переименовывается в p2. Т.е. нельзя сразу переименовать p1 в p2, потмоу что p2 уже существует.
hawkkiller, val p2 это ошибка форматирования или двойная кавычка в конце имени и правда присутствует?
в приведённом коде p2 переименовывается в p1, соответственно и NOPE, что файла p2 не существует.
При условии, что используются массивы short'ов, либо в свойствах компиляции принудительно выставлено выравнивание на 1-2 байта. Иначе экономии занимаемой памяти не будет.
Богдан Хвалько, Так и подстраивай под того, с кем он будет драться именно сейчас. Предложенная тобой концепция используется в синглплеер играх, чтобы автоматически подстраивать сложность под игрока, на основе предыдущих сражений. Но для мультиплеера это уже не подходит. Хоть в процентах, хоть в логарифмах, хоть в квадратных корнях формулы рисуй. После новичка бос будет слишком лёгкий для опытного игрока и после опытного игрока босс будет слишком сложным для новичка.
Т.е. если все игроки находятся в едином игровом Мире, то можно сохранать ID игрока и, если он с боссом уже сражался, то как-то корректировать уровень босса (ослаблять, если агрок уже проигрывал и усиливать, если игрок уже выигрывал этого босса), а если это первая встреча, то по какой-то формуле начальный уровень босса назначать.
А если каждый игрок в своём игровом пространстве играет, то вообще никакой связи между скиллом игроков быть не должно и н еможет быть.
Богдан Хвалько, Тогда никак. Либо разграничивать игроков разного уровня по отдельным серверам, либо на слабых игроков будут попадать сильные боссы после сильных игроков, а сильным игрокам слабые боссы после слабых игроков. и все будут недовольны.
Так что либо разные сервера по скиллу игроков, либо подстраивать босса под играющего игрока.
Никакой формулы быть не может, потому что игроки с разным скиллом в случайно порядке могут оказаться ведь.
art style, Лучше вырезать не "лассо", а создать слой маски, тогда больше свободы в плане удаления и возвращения прозрачности. И на маске можно хоть карандашом рисовать прозрачность.
Хотя, возможно, достаточно отключить AntiAliasing при выделении:
wefhuieu, скомпилировалось - правильно. Не скомпилировалось - надо в настройках компилятора указать, что это юникод приложение, а не мультибайт, чтобы точку входа нашёл.
wefhuieu, это =, а не ==. Для char* нет оператора сравнения строк, сравнивается указатель.
char* нельзя записывать в wstring.
Замени main на wmain с типом wchar_t.
xaiponews, Да, примерно так и делаются всякие Лотто и карточные игры. Гораздо эффективнее и предсказуемее создать массив со всеми допустимыми значениями и перемшать его. С вызовом генератора случайных чисел может быть "зацыкливние" алгоритма, когда будут выпадать уже недопустимые значения. И хоть миллион раз вызови функцию, а нужного числа можешь не получить. Поэтому делают от обратного. Напрмиер, в Лотто, создают массив с номерами всех кубышек и перемешивают массив. А потом по очереди достают кубышки с гарантией, что они не повторятся и цикл не подвиснет в ожидании случайного числа с номером ещё не использованной кубышки.
xaiponews, Конкретно под описанный случай: создаёте массив из 4 чисел, заполняете его 1,2,3,4. перемешиваете числа любым алгоритмом перемешивания. При нажатии кнопки получаете первое число в массиве, затем второе и т.д. Когда четыре раза нажили на кнопку, то снова перемешиваете этот массив и снова берёте первое число, оптом второе и т.д. Это гарантирует, что при четырёх нажатиях не будет повтора. но при мятом нажатии может быть повтор с четвёртым.
Вообще, случайные числа подразумевают, что одно и то же число может выпасть хоть 50 раз подряд, просто это маловероятно.
heinehen, можно использовать только ту часть библиотеки, которая для "рюшечек".
WinAPI в плане разработки интерфейсов ещё ужаснее, чем MFC. Мало того, что он Сишный, так ещё и настолько древний, что крайне неудобно создавать многопоточные приложения. Т.е. просто "математические" потокеи без проблем можно создавать, а вот если надо создать диалоговое окно в отдельном потоке, то это боль и страдания (в MFC).
Профит от QT однозначно будет. Разрабатывать можно в той же VisualStudio.
heinehen, Тогда однозначно QT. Есть и другие, но лучше потратить время именно на QT. Его можно будет использовать с любыми компиляторами и на любых платформах, помимо Виндоус. Помимо рюшечек там есть почти всё, что в голову может прийти, есть куча классов инкапсулирующих системные API.
Библиотека очень большая, но польза от изучения будет. В вакансиях С++ часто QT указан в требованиях.
Игорь, Плотно сидит после того, как полностью вставлен. Но это нужно постараться, конечно, чтобы настолько коряво вставлять и закоротить соседние дорожки.
При большой удаче, даже вставляя флешку можно спалить как минимум юсб-контроллер - я несколько портов так сжёг. И вставляя HDMI кабель можно сжечь мног очего. Когда во включенное оборудование что-то подключаете - это всегда некоторый риск.
