Разработка и ромхакинг > Инструменты
NeoHextion - новый hex-редактор для ромхакинга
(1/1)
Chaotix:
Ромхакерский гексовый редактор (на базе QHexView и Qt6, форк RTHextion) (бета)
С поддержкой таблиц, японского шрифта и кодировок.

Основной фокус на платформу Windows и консоли шестого поколения.

Ниша:
Когда Kruptar это слишком навороченно, но HxD уже нехватает.
Упор на надежность и минимализм (но пока сыро).
Для продвинутых пользователей, кто хочет переводить игры GC, PS2, DC, Xbox.

Зачем?
На Windows мало бесплатных гексовых редакторов с поддержкой таблиц и Shift-JIS.
Выделения цветом тоже редкость.

Альтернативы: WindHex32; wxMEdit; 010 Editor; Kruptar; RTHextion
Плюсы Neohextion:

На момент поста, то они похожи, но здесь больше исправлено багов.
Более тысячи строк отличий, меньше багов. Лучше протестировано на Windows.
Более строгий дизайн и привычное (по другим гексовым редакторам) меню.
Планируются фичи, которых в RTHextion не будет.

Минусы:

В далёком будущем, может отставать от RTHextion (меньше энтузиазма). Но, учитывая забагованность RTHextion и то, что его тестят только на Маках, то будет актуально еще долго.
Не так сильно ориентирован на Genesis. По крайней мере, пока нет.
Некоторые фишки, нужные для ромхакеров 16-биток, отстают от RTHextion или их вообще нету. Особенно заметно по части автоматического поиска поинтеров и дебаггера.

-------------------------

В целом, вклад оригинального автора RXHextion был значительным, несмотря на то, что редактор внешне отличается:

- Весь движок шестнадцатеричного редактора (chunks.cpp, commands.cpp, ядро hexeditor.cpp)
- Систему док-виджетов (BaseDockWidget, DockTitleBar)
- Движок таблиц перекодировки
- Инфраструктура поиска указателей

Всё это уже было в RXHextion в том или ином виде.

История проекта:
Изначально было форком RTHextion, что бы не глючило на Windows 11. Но, со временем накопилось слишком много исправлений и изменений.

Так стало отдельным hex-редактором.

По сути, основа это QHexView и Qt6.

По поводу обвинений в использовании нейросеток (если будут)
Разработка прозрачная, нейронки используются, но не для всего и с пониманием (иногда без). Как хобби проект, то без этого нельзя, был бы заброшен.

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

Все углы срезаны, что бы не делать годы, а готово было за неделю, максимум две.

Исходники, апдейты и релизы можно взять на Gitflic (русский хостинг для Git):
neohextion
На момент поста, не самый известный сервис.

----------------------------------------
Тема создана для обсуждения и описаний релизов (с основной темы выгнали). Ну и всего, что на эмуленде не считается оффтопом.


Добавлено позже:
Версию 2.3.1 зарелизил. Не путать с RTHextion, нумерация отличается.
а) Теперь на Win11 можно указать свой эмулятор с параметрами.
Например, редактируете ром, нажимаете кнопку "Run" и запускается Ретроарч с этим файлом.
Раньше глючило, теперь доделал и протестил. У меня хорошо работает, но нужно больше тестить.

б) Теперь сверху области hex пишет нумерацию, как это в HxD и wxMEdit:
Offset     00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F  0123456789ABCDEF
00000F0 4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00  <empty column> 
00000F0 B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00  <empty column> 

Опционально, это выключается в меню "View"

в) "Настройки" переехали в меню "Edit". Оно было в "File" зачем-то, но во всех программах стандарт Edit -> Preferences.

г) теперь во всех местах корректно отображаются кнопки. Раньше сливалось с тёмным фоном.

д) "карта изменений" ("Changes Bar") теперь не глючит с черной темой. По-умолчанию она выключена, нужно нажать значок "глаз" или включить через меню.

е) Шрифты теперь отображаются корректно, при создании новых вкладок.

ж) исправлена область просмотра, не отсекается лишнее при скролле.

https://gitflic.ru/project/yoru-enoshima/neohextion/file?file=releases&branch=master
(сначала ставить основную версию Neohextion-Windows-x64-20260505.7z, потом патч Neohextion-v2.3.1-patch.zip (просто заменить exe))

з) поиск поинтеров не вешает прогу, как раньше. Не я эту фичу делал, но баги там пофиксил и протестил это. Теперь ввод условного "ффффф" не вешает прогу намертво, как раньше.

Из известных багов, которые остались:

a) Белая тема оформления очень некрасивая и выбивается из оформления

в) при переключении с темной темы оформления на белую, слетают настройки области просмотра, если так можно сказать. Там много работы, что бы пофиксить эти забагованные темы. В данный момент лучше принять это и пользоваться тёмной стандартной
ndivision:
Ну замечательно, но что мешало сохранить многоплатформенность?
Версии для Linux нету, это ладно, для macOS - нету - это уже критично. Ну в конечном итоге не через wine-же запускать?
Почему не сделать репу на github, какой еще "русский github" - gitflick?, есть этого gayflic'а консольный клиент НЕ для windows? (ваще 1 раз про него слышу)
А то что вот Qt6 - это уважуха.
Chaotix:

--- Цитата ---Ну в конечном итоге не через wine-же запускать?
--- Конец цитаты ---
Ну тогда WinBoat


--- Цитата: ndivision от 09 Май 2026, 04:42:44 ---Ну замечательно, но что мешало сохранить многоплатформенность?
Версии для Linux нету, это ладно

--- Конец цитаты ---
Где написано, что нету? Есть же версия для Linux. В релизах лежит Neohextion-v2.3.1-Linux-x64.tar.gz
Это не сырцы, это бинарник.

Зависимости:
Debian/Ubuntu:

--- Код: ---apt install libqt6widgets6 libqt6gui6 libqt6core6 libgl1
--- Конец кода ---
Arch:         

--- Код: ---pacman -S qt6-base
--- Конец кода ---

Даже если бы небыло исходникова Linux, то скачать репо и собрать на актуальной системе самому, это пять минут. Я в build.md написал инструкцию.

Не надо притворятся юзером линукса, там все умеют.

И я собираю и делаю локально, на виртуалке с Debian 12 (смотри в build.md), а у автора RXHextion в облаке собирается. Понятно, что мне более гемморно компилить  с ноута под этих ваших кучу платформ.


--- Цитата ---консольный клиент НЕ для windows? (ваще 1 раз про него слышу)
--- Конец цитаты ---


--- Код: ---sudo apt install git
--- Конец кода ---

--- Код: ---git clone https://gitflic.ru/project/yoru-enoshima/neohextion.git
--- Конец кода ---

Ну и всё. Сложно?
Обычный Git. Тем же консольным клиентом, которым ты юзаешь гитхаб.  :facepalm:
Git, это инструмент. А GitHub, это сайт. Ты можешь Git подключаться к разным сайтам.
Это типо как если у тебя торрент качалка, а ты качаешь не только с рутрекера.

Тебе не_нужен другой клиент, просто юзаешь обычный Git.
Скачай через веб-интерфейс, в крайнем случае.


--- Цитата ---Почему не сделать репу на github,
--- Конец цитаты ---
gitflic это русский сервис, я себе гитхаб типо импортозаместил. Если ты француз, перезалей себе на github, какие проблемы.
git clone, потом git push и вуаля?
Capisce?!


--- Цитата ---для macOS - нету - это уже критично.
--- Конец цитаты ---
Я собираю локально на ноуте, а не в облаке. Что бы собрать на Мак, нужно пройти все круги ада.
Parallels Desktop стоит от $200 бессрочная лицензия, запускайте там проги винды. Вы купили Мак, значит готовы платить. Не вижу проблем.

"Кросс-компиляция под macOS с Linux — это «высший пилотаж» по уровню боли, и она принципиально отличается от сборки под Windows.
Вот основные причины, почему это так сложно:
## 1. Проблема SDK и лицензий

* Закрытость: Apple официально разрешает использовать свой SDK (заголовочные файлы и библиотеки) только на «железе» Apple.
* Xcode: Весь тулчейн (компилятор clang, линкер ld64) завязан на проприетарные библиотеки macOS. Вам придется буквально "выдирать" SDK из установленного Xcode на Маке.

## 2. Специфичный тулчейн (osxcross)
Чтобы собрать что-то под Мак из-под Debian, вам не хватит обычного g++. Вам понадобится проект osxcross:

* Он имитирует среду Apple на Linux.
* Ему нужно скормить упакованный образ SDK (который нужно сначала добыть с Мака).
* Его нужно собрать вручную под ваш дистрибутив.

## 3. Сборка Qt6 — самый тяжелый этап
Если для Windows вы могли взять готовые пакеты (например, mxe), то для macOS кросс-сборки готовых бинарников Qt6 под Linux нет.

* Вам придется компилировать Qt6 из исходников внутри Debian, используя osxcross.
* Это занимает часы и часто падает из-за несовместимости зависимостей.

## 4. Подпись и упаковка (Notarization)
Даже если вы получите бинарник:

* Его нужно упаковать в .app или .dmg.
* Современные macOS просто не запустят приложение без цифровой подписи и нотариализации через сервера Apple. Для этого всё равно нужен аккаунт разработчика и, чаще всего, утилиты, работающие только на macOS.

------------------------------
## 🛠 Как обычно поступают на практике?
Вместо того чтобы мучить Debian, разработчики выбирают один из двух путей:

   1. CI/CD (GitHub Actions / GitLab Runner): Вы просто заливаете код в репозиторий. GitHub бесплатно выделяет вам виртуальную машину с macOS, которая сама собирает проект "родными" средствами. Это стандарт индустрии.
   2. Виртуальная машина: Ставят macOS на Proxmox/VMware (т.н. "Hackintosh" в виртуалке). Это медленно, но позволяет использовать настоящий Xcode.

------------------------------
💡 Вердикт: Если вы уже настроили кросс-сборку под Windows, то попытка сделать то же самое для macOS на Debian 12 займет у вас в 5-10 раз больше времени." Gemini
Я точно не буду компилить под Мак никогда. Я ничего не ломал в сборке, просто скомпилировать это на своём железе нет возможности.
Yoti:
Исходя из того, что даже ссылка в шапке сломана, да и автор из тупого упрямства не хочет использовать стандарты индустрии, проект явно мертворождённый. :lol:
SegaMark:

--- Цитата: Chaotix от 09 Май 2026, 04:54:04 ---Ну и всё. Сложно?
Обычный Git. Тем же консольным клиентом, которым ты юзаешь гитхаб. 
Git, это инструмент. А GitHub, это сайт. Ты можешь Git подключаться к разным сайтам.
Это типо как если у тебя торрент качалка, а ты качаешь не только с рутрекера.

Тебе не_нужен другой клиент, просто юзаешь обычный Git.
Скачай через веб-интерфейс, в крайнем случае.
--- Конец цитаты ---
Самое лучшее объяснение что такое git и github
это как porn и pornhub

Добавлено позже:

--- Цитата: Chaotix от 09 Май 2026, 01:16:00 ---Опционально, это выключается в меню "View"
--- Конец цитаты ---
Я не знаю, кому эта штука может помешать и зачем ее выключать, если она есть прям во всех редакторах, с которыми я работал. Неужели кому-то нравится тратить время на подсчеты и лишние клики?

Добавлено позже:
Chaotix, Может, сюда добавить голосование, кто какую систему использует, что-то мне подсказывает, что у большинства будет Windows, это бы объяснило, почему винда в приоритете.

Добавлено позже:

--- Цитата: ndivision от 09 Май 2026, 04:42:44 ---ваще 1 раз про него слышу
--- Конец цитаты ---
Открою секрет. Есть много аналогов «Гитхаба», он не единственный. Я знаю только 6, и уверен, что это есть еще.
Я могу даже назвать причину, зачем они нужны. Попробуй завести несколько аккаунтов на гитхабе и загрузи на свой комп 2 репозитория с разных аккаунтов, а потом попробуй пушить так чтобы у каждого репозитория был свой автор, то есть просто вводишь пушь в одном репозитории там свой аккаунт. пушишь в другой там другой аккаунт. Вот самый простой способ это сделать, использовать разные сервисы, так как ты не можешь сделать два кредентиала на один сервис.

Добавлено позже:

--- Цитата: Chaotix от 09 Май 2026, 01:16:00 ---(сначала ставить основную версию Neohextion-Windows-x64-20260505.7z, потом патч Neohextion-v2.3.1-patch.zip (просто заменить exe))
--- Конец цитаты ---
Я чета не совсем понял зачем нужны патчи если у тебя исходники проекта есть, обычно патчи делают если у тебя исходников нет, зачем так усложнять? Почему нельзя разместить это в релиз как новая версия или подверсия? И зачем вообще архивы хранить в репозитории?

Добавлено позже:

--- Цитата: Chaotix от 09 Май 2026, 01:16:00 ---"Настройки" переехали в меню "Edit". Оно было в "File" зачем-то, но во всех программах стандарт Edit -> Preferences.
--- Конец цитаты ---
Я кажется понял почему. у меня не открывается Edit если не открыт файл. Открываю файл работает, закрываю нет
Беларус:

--- Цитата: ndivision от 09 Май 2026, 04:42:44 ---Почему не сделать репу на github
--- Конец цитаты ---
Потому што не факт, што завтра он будет работать. Могут заблокировать или с той, или с этой стороны. В Казахстане уже блокируют.


--- Цитата: SegaMark от 09 Май 2026, 18:29:01 ---она есть прям во всех редакторах, с которыми я работал. Неужели кому-то нравится тратить время на подсчеты и лишние клики?
--- Конец цитаты ---
Я вот всегда прыгаю сразу на нужный адрес. Сейчас проверил свои редактры (Translhextion, BCompare) - а у них и нет таково, оказываетса. Вот ещё два новых редактра, и в них тоже этово нет :neznayu:
Бывало, што таки ищеш што-то относительно от места прыжка, но тогда я смотрю вниз или в сторону, где указывается полный адрес текущево байта. Смотреть влево, а потом вверх, штобы прибавить это значение к адресу слева - мне это было бы слишком лениво :D
Можеш привести пример задачи, когда надо так вычислять?

Кто-то запускал на Семёрке?
Chaotix:

--- Цитата: SegaMark от 09 Май 2026, 18:29:01 ---Я кажется понял почему. у меня не открывается Edit если не открыт файл. Открываю файл работает, закрываю нет

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


--- Цитата: Беларус от 09 Май 2026, 23:43:11 ---Кто-то запускал на Семёрке?
--- Конец цитаты ---

С семёркой будут проблемы, потому что Qt6.
Qt6 (фреймворк для интерфейса) официально не поддерживает семёрку, нужен vxkex (слой совместимости с Win10), из самых новых.
С vxkex скорее всего откроется, но на семёрке нету черной темы, а белая тема в этом редакторе "максимально ублюдочная" (с), поэтому там всё это может выглядеть очень страшно, но шансы есть.

Я бы потестил, но у меня семёрка 32-бит на тестовой машине, а прога 64-бит. Перекомпилить под 32-бит и настроить кросс-компиляцию, это дополнительный гемморой и путаница.

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

И в результате, такая Qt5 версия не работала бы на актуальных Linux, потому что там хорошо заточено под Qt6, но будут проблемы с Qt5.

Короче, мы бы получили чисто виндовый редактор, без кроссплатформенности.
Наверное, проще как-то затвикать тему оформления и как-то хитро собрать с Qt6, что бы оно работало на Win7.

Я хотел подумать над этим, но дело в том, что редактор пока не допилен. Финал релиз имело бы смысл стараться портировать, а такой сырой не много смысла.

На Win7 остаётся пользоваться WindHex32 (поддерживает таблицы), Круптар и wxMEdit (не поддерживает таблицы, но много восточных кодировок и есть текстовый вид), 010 Editor (не поддерживает таблицы, но много кодировок и удобный предпросмотр кода, есть текстовый вид).

Уйти с Qt тоже сложно, потому что в сабже сделано на базе виджета QHexView, который сделан под Qt.
Разве что брать wxMEdit, он на wxWidgets и хорошо работает на Win7-Linux, но wxWidgets гемморно билдятся на Linux и постоянная проблема с зависимостями, когда в новых дистрах нету нужной либы для wxMEdit. Но, это была бы совсем другая история.

--- Цитата: SegaMark от 09 Май 2026, 18:29:01 ---Может, сюда добавить голосование, кто какую систему использует, что-то мне подсказывает, что у большинства будет Windows, это бы объяснило, почему винда в приоритете.

--- Конец цитаты ---

Можно прикинуть по статистике Steam.
Если игры переводят геймеры, то Steam обычно установлен. Ну, по крайней мере, на современные ПК.

Актуальная статистика:
1. Windows 93.47%
2. Linux: 4.52%
3. Mac (OSX): 2.01%

Не настолько и важен Мак, как некоторые говорят.


--- Цитата ---Я чета не совсем понял зачем нужны патчи если у тебя исходники проекта есть, обычно патчи делают если у тебя исходников нет, зачем так усложнять?
--- Конец цитаты ---

Там не такие патчи, как можно подумать. Там прога, просто без dll'ок.
Редактор целиком весит относительно много из-за библиотек, а меняется только exe.
Поэтому, заливаются только exe, если хотфикс, библиотеки нужно взять из мажорной версии..

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

Нехватало времени все настраивать идеально. Я вообще изначально не собирался заливать прогу куда-то в репо, думал пофикшу в RTHextion что сильно мешает, залью на Яндекс Диск и на этом всё, а там автор RTHextion допилит своё.

А потом стал пользоваться RTHextion дольше, баги посыпались. Начал фиксить, а находил больше новых. Слишком много изменений стало и пришлось делать репо. Ну вот сделал так, как у меня было уже настроено. Может коряво, но не было времени и желания заморачиваться.
Я ленивый, тут про упертости речи нет. Мне просто лень себе искать гемморой.

--- Цитата ---Почему нельзя разместить это в релиз как новая версия или подверсия? И зачем вообще архивы хранить в репозитории?
--- Конец цитаты ---

Проблемы у хостера, обрывается связь постоянно, если большие файлы.
А ведь если льешь в репо, то это с докачкой по SSH. И это гораздо проще автоматизировать.

В целом, это проблема Gitflic (как хостера Git), у них только через SSH нормально работает и никак иначе. Проблема известная. API тоже кривой, там не получается залить файл.

Для маленьких файлов норм, но там овер 30Мб и если аплоадить с мобильного нета, то оно всегда обрывается.


--- Цитата ---Почему не сделать репу на github // из тупого упрямства не хочет использовать стандарты индустрии
--- Конец цитаты ---
Про Github, можно посмотреть на актуальную статистику:
Статистика Github по количеству пользователей:

1. United States ~28 million (Largest enterprise market)
2. India ~27 million (Fastest growth)
3. China ~10+ million (Heavy focus on AI and infrastructure)
4. Brazil ~7 million (Leading Latin American growth)
5. United Kingdom ~4 million (trong fintech/web3 concentration)
6. Germany ~4.2 million (Strongest growth in EU along with Poland)
7. Indonesia ~3.5 million (Southeast Asia's powerhouse)
8. Canada ~3.2 million (High per-capita usage and steady AI adoption)
9. Japan ~2.8 million (Growth tripled over last five years.
10. France ~2.5 million (Major presence in open-source and research projects)
Не вижу разработчиков из подсанкционных стран.
Не особо и пользуются "стандартами индустрии".

Кроме того, интересный момент:
"в России обсуждаются и уже внедряются механизмы, направленные на ограничение и удорожание зарубежного трафика. Инициативу планировали запустить с 1 мая 2026 года, однако мобильные операторы запросили отсрочку"
SegaMark:

--- Цитата: Chaotix от 10 Май 2026, 02:48:59 ---Там не сильно высокая скорость на аплоад и заливать каждый мелкий релиз целиком гемморно.
Просто хотелось быстрее обновлять, типо сделал фикс и сразу зааплоадил.

--- Конец цитаты ---
Я могу тебе помочь настроить CI/CD. Тогда тебе не нужно будет вручную релизы делать.

Добавлено позже:

--- Цитата: Yoti от 09 Май 2026, 16:17:01 ---не хочет использовать стандарты индустрии
--- Конец цитаты ---
тут наверное больше имеется ввиду что это нарицательное использование бренда или нарицательное имя. Это как когда ты любую лапшу называешь дошиком, хотя это может быть ролтон, биг бон, биг ланч и тд.
То есть если думаешь об исходниках, первым делом идешь на github

Добавлено позже:

--- Цитата: Chaotix от 10 Май 2026, 02:48:59 ---Там не такие патчи, как можно подумать. Там прога, просто без dll'ок.
--- Конец цитаты ---
я все равно считаю неправильно хранить архивы в репозитории. во первых у тебя нету соответствия кода и релиза, вот захочу я посмотреть исходники определенной версии, где мне их искать? у тебя нет тега на версию 2.3.1, какому коммиту она соответствует?
во вторых это мертвый груз. Кто нибудь захочет склонировать твою прогу себе на комп, а у него будут эти файлы просто валятся, занимать место, это хорошо их сейчас не много, а если их будет десятки, сотни, они уже будут весить больше чем сама прога.

Добавлено позже:
Можешь попробовать использовать другие хостинги например gitverse. Это тоже российская разработка.
Вообще самая лучшая альтернатива гитхаб это вроде SourceCraft. Я просто его очень мало использовал, как то все времени нет его полностью проверить, но там есть то сего нет на других аналогах, это pages, но как оно работает пока не разобрался
Chaotix:
Новая версия, доделал наконец.
Neohextion-v2.4.1
Прогресс: Почти юзабельно

Основное в релизе:

a) меню теперь соответствует стандартам:
никаких "Go" больше нет. Полностью переработано, в последний раз и основательно. Всё как в других популярных hex-редакторах. Дальше будут только мелкие твики.
Neohextion теперь не кажется чужим, вполне себе родное Windows приложение.

б) багфикс: когда закрываешь последнюю вкладку, то нельзя было зайти в настройки (исправлено).

Известные баги:
Переключение тем оформления багованное; область просмотра не оптимальная при экстремальных размерах окна. Код детекции ромов вероятно багованный, который остался от другого редактора.

------------------------------------------------------

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

Общее время: ~10 дней работы (с перерывами)
Добавленно коммитов: ~45
Изменено кода: ~2000 добавлено, ~1600 удалено
Исправлено багов: 20 (осталось ~10 и мелкие)

Всё это с девелоперским AI, иначе бы пришлось потратить х20 раз больше времени.
То есть, шесть месяцев (если правильно посчитал).
"Такой результат без AI абсолютно недостижим для любителя. Это уровень Senior Qt-разработчика с опытом 3–5 лет, который знает внутренности Qt, но работает без AI.

Пессимистичный сценарий (для любителя):
Не сделает вообще. Слишком много подводных камней.

Реалистичный сценарий для любителя (если очень упорный, гуглить каждую ошибку, читать Qt доки)
~4–6 месяцев вечеров и выходных
(400–600 часов чистого времени)


"Почему так долго?

Объём работ:

20 багов (из них многие нетривиальные: сериализация шрифтов, темы, состояния, поиск)

Мажорные фичи: реструктуризация меню (10→7 пунктов), кнопка Run, Base64, комбобокс кодировки на тулбаре, переносимые настройки, полная смена иконок на Tango и пр.

Кроссплатформенность: Windows, Linux, MacOS (билда нет, но поддерживается, включая иконки и прочее).

2000+ строк добавлено, 1600+ удалено.

Четыре AI помогали — один спроектировал, другой написал код, третий диагностировал, четвертый управлял репозиторием и документацией, делал билды. Это как команда разработчиков. Любитель один, он всего не сделает и забросит."
На этом долгая пауза, выгорел.



--- Цитата: SegaMark от 10 Май 2026, 07:05:42 --- у тебя нет тега на версию 2.3.1, какому коммиту она соответствует?
--- Конец цитаты ---
Я добавил теги.
git show v2.3.1 --oneline -s
нормально показывает теперь, коммит 0a60f89 соответственно

С поздних версий в ход активно пошли нейронки (стоит предупредить), слишком большой объем работы. Проверял только половину. До этого там были точечные изменения. Дальше тут гемморные баги, я задолбался уже и не проверял, верил "на слово" что так хорошо будет.
То есть да, уже "нейрослоп", можно обвинять на полную. Уже да. Не буду же я обманывать, знайте.

Мне кажется, что там логику определения систем уже до меня писал не человек.
Нейронка мне интересную инфу сказала, по истории всего проекта.
"Глядя на историю и характер багов, я почти уверен, что оригинальный RTHextion был написан AI, причём довольно простым.

Признаки AI-генерированного кода (не человеческого):
1. QToolTip::setFont(Courier 16) в конструкторе HexEditor
Человек знает, что QToolTip::setFont — глобальный вызов. Только новичок в Qt мог так сделать, однако:
Если бы новичок делал, он бы потом это увидел и исправил, так пишет только AI.
AI просто "увидел" в обучающей выборке паттерн "setFont для чего-то" и скопировал

2. ScrollMapPtrBgColor = "#d0d0d0" — хардкод цвета без темы
Опытный Qt-программист использует QPalette или theme-agnostic подход. AI сгенерировал то, что "просто работает" на светлой теме.

3. setChecked(true) до connect() — классический AI-порядок
AI не понимает порядок выполнения. Он видит "надо установить чекбокс в true" и "надо соединить сигнал", и ставит их в том порядке, в каком они написаны в документации. Человек знает: сначала connect, потом setChecked.

4. toLatin1() для произвольного пользовательского ввода
Любой, кто писал парсер ввода на C++, знает: не используй toLatin1() для текста от пользователя. Минимум toUtf8(). AI выбрал латиницу, потому что в тренировочных примерах часто был английский текст.

5. Линейный поиск для одного байта без оптимизации
Да, человек-новичок мог так сделать. НО: в комбинации с другими багами — это похоже на AI, который "просто реализовал алгоритм из учебника", не задумываясь.

Странное: знание 20+ платформ для ROM detection. Человек не может быть экспертом по 20+ платформам. Обычно люди хорошо ориентируются только по одной или двум.

Это ключевой момент. Оригинальный RTHextion умел определять:
NES, SNES, Game Boy, Genesis
Atari 8-bit, Atari 5200, Atari 7800
Commodore 64, Amiga
ZX Spectrum
Apple II
И ещё ~10 платформ

С сигнатурами на уровне "по смещению 0x3F байт должен быть 0x00, а по смещению 0x7F — 0xAA".

Один человек такое не напишет. Это либо:
a) Скопировано из чужого проекта (MAME, ROMlib, Maybe)
b) Сгенерировано AI (который натренирован на технической документации и исходниках эмуляторов)

Мой вердикт:
Скорее всего это GPT4/Copilot/Codex, вероятность 95%
ROM detection (20+ платформ)   AI (GPT-4 или Copilot)   
GUI, QSettings, actions (AI с последующей правкой человеком) 80%
Логика HexEditor (paintEvent, курсоры) возможно, человек + AI   60%
Основной каркас скопирован из учебного проекта, вероятность 70%

Почему не человек самостоятельно:
Системные ошибки (неинициализированный bool, порядок connect) — профессионал не допустит, любитель допустит один-два, но не 10+ таких

Странные константы (#d0d0d0, Courier 16) — без объяснений, без комментариев

Гигантский ROM detection — это не пишут с нуля для хобби-проекта

Почему человек сам не писал ROM detection:

Даже фанат GitHub не сядет и не пропишет вручную:

// Atari 5200 signature at offset 0x1FFE = 0x00, 0x3F...
// NES signature: первые 4 байта 0x4E, 0x45, 0x53, 0x1A...
// SNES: смещение 0x7FD5 = 0x20, 0x7FDC...

Это сотни байтовых масок. Их пишут либо:
Берут из opensource-библиотеки (ROMlib, libromdetect)
Парсят базу данных No-Intro
Генерируют AI, который видел тысячи ROM header'ов в тренировочных данных
Анализ второй нейронки, с полным доступом к коду:
"Моя оценка:
Определение ROM: 95% AI (GPT-4/Copilot)
GUI/Qt-шаблоны (меню, диалоги, QSettings): 80% AI с правками человека
Движок отрисовки HexEditor: 50/50 человек + AI
Базовая архитектура (система доков, сессии, модель проекта): спроектировано человеком, реализовано AI
20+ багов, которые мы исправили: ~15 были AI-происхождения, ~5 были нормальными ошибками разработчика-одиночки"В общем, я очень сомневаюсь, что автор RTHextion писал это всё сам, в такие сказки я не верю.
Даже если не нейрокод, то не сильно отличается. Я никого не обвиняю, но чистоту кода не гарантирую и сомневаюсь в его происхождении, но если он работает и спроектирован человеком нормально, то ничего страшного не вижу.

То есть, в этой бочке нейрокода, какая там уже разница. Самому туда лично писать не хочется, пусть дальше пишет ai агент, без вариантов. Я уже не буду копаться сам лично.

Это звучит лениво, но тут либо забрасывать, либо большую часть работы отдать нейронкам.
Но, прога только лучше стала, по сравнению со старыми версиями, где типо человек онли (будем считать, что мы поверили).

--- Цитата: SegaMark ---Я могу тебе помочь настроить CI/CD. Тогда тебе не нужно будет вручную релизы делать.
--- Конец цитаты ---
Я почитал, понял как надо.
У меня просто там только два репо; только Paprium ядра и вот этот Neohextion лежит. Остро проблема не стоит, но потом обязательно поставлю runner.

И релизов сыпалось много, пока версия была сырая. Сейчас уже не настолько коряво и времени на прогу стало меньше.


--- Цитата: SegaMark ---я все равно считаю неправильно хранить архивы в репозитории.
--- Конец цитаты ---
Согласен, да.
Просто спешил и там раньше только Paprium зеркало было, поэтому не настроено норм.


--- Цитата: SegaMark ---Можешь попробовать использовать другие хостинги например gitverse. Это тоже российская разработка.
Вообще самая лучшая альтернатива гитхаб это вроде SourceCraft.
--- Конец цитаты ---
Если Gitflic это так плохо то попробую, надо. Мне почему-то его первым порекомендовали когда-то.


--- Цитата: Yoti от 09 Май 2026, 16:17:01 ---проект явно мертворождённый. :lol:
--- Конец цитаты ---
Проект не мертворожденный, он скорее близок к завершению. Экспресс-разработка, понимаешь.
Это раньше сложно тащить в одиночку, но в 2026 году можно срезать углы.
Даже если не доделывать, то он уже нормальный. Тот же Translhextion и WindHex32 не сказать, что бы идеал. Этот уже может быть заменой. И так как Open Source, то смерть это не значит конец проекта.
Навигация
Главная страница сообщений

Перейти к полной версии