- Mikle
- Модератор
Mikle
> То есть полное суммирование цветов исходных пикселей с весовыми коэффициентами
> их площадей, попадающих на новый пиксель.
Интересный метод, уменьшает и правда довольно быстро и качественно, хотя при экстремальном уменьшении (раз в 10) классические качественные методы выглядят всё же поаккуратнее.
Но на увеличении получается nearest.
invis
> классические качественные методы выглядят всё же поаккуратнее.
Возможно, это из-за гамма-коррекции, которой я не делал. Потому, что в остальном трудно придумать что-то правильнее.
У меня поначалу был синтетический тест, уменьшение только по горизонтали в 10 раз, там зернистость кажется излишней. Но такое на практике почти никогда не нужно.
А если пропорцинально уменьшать, то вроде нормально.
https://gamedev.ru/files/images/?id=162162
https://gamedev.ru/files/images/?id=162163
https://gamedev.ru/files/images/?id=162164
Mikle, спасибо еще раз за идею! Очень помогло при написании своего алгоритма для разреженных спрайтов. Там же подготовлю еще тест со сравнением с Вашим алгоритмом.
Mikle привет. А под C# класс спрайта под 64 ты же не делал? Там какие-то специфические отличия будут или VB.net-овский можно переписать просто? Я посмотрел код от 32битной версии, там куча длл импортов которых в 64 вб.нет нету, но это были те функции которые использовали ассемблер в 32битной и из 64битной были выкинуты?
SilentPrayerCG
> там куча длл импортов которых в 64 вб.нет нету, но это были те функции которые
> использовали ассемблер в 32битной и из 64битной были выкинуты?
Какие например? Вроде, там одинаково.
SilentPrayerCG
> Там какие-то специфические отличия будут или VB.net-овский можно переписать просто?
Просто переписать. Единственное, в шарпе нет optional параметров (по крайней мере в CS 2008, на котором я писал), поэтому там, где на VB одна функция с несколькими optional параметрами, в шарпе приходилось переопределять несколько функций, посмотри, например, функцию MaskClearBuffer().
Mikle
Ну вот к примеру самое первое идет
[System.Runtime.InteropServices.DllImport("SR2D", EntryPoint = "COPY_MEMORY")]
private extern static void CopyMemory(int pSrc, int pDest, int Length);я в вб 64 не вижу
Mikle
> посмотри, например, функцию MaskClearBuffer().
посмотрел, типа перегрузку делать вместо опционального параметра?
ps
вроде есть сейчас опциональные аргументы
https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide… nal-arguments
я так понимаю вб мс развивать больше не собирается, никому он нафиг не нужен.
друг вот начал ковырять godot, решил тоже поковырять, gdscript мне его вообще не нравится, но есть поддержка c#
есть еще какой-то кросплатформенный фреймворк maui.graphics, и он тоже только c#, в общем никто никуда vb добавлять не будет, и видимо если я хочу продолжать разбираться в этом, мне придется переучиваться на с# хотя мне как на нубу, вообще не нравятся все эти бесконечные {} и ; в конце строк, и чувствительность к регистру - ой у вектора нет x у него X... я даже не понимаю зачем это кроме как для того чтобы было проще запутаться и ошибиться.
SilentPrayerCG
> вот к примеру самое первое идет
Да, ассемблерное копирование CopyMemory я заменил на MovsD, на сколько помню — на интринсике.
Так то всё на месте.
А то, что VB всё — да, по крайней мере от Microsoft.
SilentPrayerCG
> вроде есть сейчас опциональные аргументы
Вроде, есть, но я же на C# 2008 писал. Так что переводить будет ещё проще.
А ещё есть, вроде как, готовые переводчики с VB.NET на C#.
Mikle
там TwinBasic (вроде как 100% совместимый с VB6) уже стабильные релизы есть. Можно попробовать твой движок там погонять. Там кстати и x64 есть, битовые сдвиги и еще куча новых фич в дополнение к VB6-фичам. Даже багофичи типа Not Not Array воспроизведены.
Mikle
Я попробовал конвертер которым я обычно пользуюсь, но он кучу каких-то ошибок наделал.
А кода там не мало. По этому лучше наверное, по частям постепенно делать.
К примеру он все Длл импорты как-то не так сделал что-ли, т.е там везде была ошибка.
the trick
> там TwinBasic (вроде как 100% совместимый с VB6) уже стабильные релизы есть.
Да, я уже давно присматриваюсь к нему. НоSilentPrayerCG, на сколько понимаю, предпочитает NET.
SilentPrayerCG
> конвертер которым я обычно пользуюсь, но он кучу каких-то ошибок наделал
А ты посмотри разницу 32-разрядных версий, ещё моих. Скорее всего, будет понятно, что за ошибки.
Mikle
Ну я конвертил 64битный вб в с#. Потом скину что там было. Там что-то бардак какой-то получился, возможно другой конвертер надо взять.
Гпт неплохо конвертит, но в бинг так много не засунешь и он на выходе может в таймаут уйти.
А что там с этим TwinBasic-ом вообще? Это тупо среда для работы с VB в том виде в каком он был в 6ой версии, или это какое-то развитие VB?
Тут просто.. я юзал VB6, потом время шло, появился .Net. на 6 забили. Ну и я перешел на то что современное. По пути меньшего сопротивления, как говорится.
Вообще мои недавние мысли были такие. SR2D это конечно довольно быстро, даже на х64, но если нет динамического скейла спрайтов. Graphics вроде тоже можно сделать, чтобы он более менее бодро работал и не мерцал, но один фиг он значительно медленнее. Причем даже если через локбист писать в битмапу, все равно ботлнек будет лок унлок, т.е это не для чего-то быстрого, не для реалтайма.
Плюс все равно там, хз как сделать чтобы именно фпс был, ограниченный. И тут я понял, что мне либо это, либо иди учи какой-нибудь годот. Я по сути даже не могу допилить SRD2 как-то так, чтобы добавить в него что-то быстрое. Ну т.е вот рисование линии же из дллки берется, как бы я свое не делал тупо через сетпиксель в спрайте это все равно медленнее будет, ну и понятно что я не буду тебя дергать его допиливать. А походу ничего больше и нет, в плане альтернативы. MAUI graphics этот.. но там надо кроссплатформенный проект создавать, потому что ВБ туда не был добавлен, хотя по идее он бы мог с ним работать, да и то хз шустрый там движок или нет.
(и вот из-за того что даже в движках всяких там си шарп как правило, хочу попробовать на него переучиться, но его синтаксис мне кажется таким корявым и не привычным... ну что поделаешь)
SilentPrayerCG
По поводу радикального повышения быстродействия графики на VB - это нужно на DirectX смотреть.
SilentPrayerCG
> в движках всяких там си шарп как правило, хочу попробовать на него переучиться
Вообще — мысль разумная.
Mikle
ДиректХ это тупо слишком сложно меня.)
Будет проблема тупо найти какой-то фреймворк или что-то такое, который бы позволил из под вб выводить графику директхом или опенглом. Ну для меня по крайней мере. Не говоря уже обо всем остальном.
Я тут недавно, кстати, смотрел игры которые ты на ср2д делал, где вот кораблик летает (Ufo duel), работает шустро, никакого теаринга вроде ничего.
А как-бы там разрешение реализовывал не помнишь? Я сейчас проверил, независимо от разрешения экрана картинка скейлится под размер экрана. Поставил 4к (через DSR) запустил, так-же плавно всё.
Или на 32битной версии скейлинг был нормальный?
Ну т.е всё рендерится в спрайт с каким-то внутренним разрешением. Допустим 1024 на 768. А потом создается новый спрайт из этого спрайта, но уже под размер экрана?
Просто на 64битной это все медленно выходит.
Или на момент запуска игры, спрайты скейлятся 1 раз под размер формы, и потом уже рисуются увеличенные (или уменьшенные) спрайты на спрайт который размере экрана? Потому что я так понял, нужно так делать. А делать внутреннее разрешение и потом скейлить под экран слишком жирно выходит.
Ps
попробовал сменить разрешение не закрывая игру. ничего не сломалось...
SilentPrayerCG
> Или на момент запуска игры, спрайты скейлятся 1 раз под размер формы, и потом
> уже рисуются увеличенные (или уменьшенные) спрайты на спрайт который размере
> экрана?
Конечно.
Скейлинг, кстати, не ассемблерная процедура изначально, так что в x32 не должна работать сильно быстрее, чем в x64.
Тема в архиве.