keng

MSVS не заточена под конкретный язык. В виме же: Есть. Есть. Есть. Потому что по сути IDE - это текстовый редактор, из которого можно вызывать компилятор и отладчик. И все. Не три окошка, а одно, можно и так сказать. Лично я отладчиком не пользуюсь, но у меня при этом есть и навигация (как по дереву всего проекта, так и по вкладкам и буферам), подсветки/автоподстановки, анализ и рефакторинг на лету, интеграция с VCS, деплой одной кнопкой, тесты и прочие автосохранения. Проблема тут только в том, что по сравнению с MSVS оно банально быстрее работает и не жрет оперативку. Сядь и подумай, что бы тебе хотелось сделать или облегчить. Банально поиск по файлам или сортировку. Как только придумаешь - разбивай на подзадачи и выполняй их шаг за шагом, по одной.

В виме плагинов в сотни и тысячи раз больше, чем в MSVS. Там есть абсолютно все, чего душе угодно, уровень кастомизации - просто запредельный. Мое окружение с 10-15 плагинами при этом кушает <50 мегабайт ОЗУ, так что и тут MSVS, мягко говоря, проигрывает.

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

Разница в том, что после вызова EndScene() картинка все еще будет лежать в бэк-буфере и только вызов Present() этот самый буфер поставит вместо основного. Технически, разница не очень большая.

Quake, поломанный при помощи MTC.

Языков программирования - великое множество, так что горячо советую начать с теоретических основ информатики. Разберешься, как работает сам компьютер - будет хотя бы от чего отталкиваться. Дальше я бы посоветовал тот же python, после его изучения и некоторой практики уже сам сможешь понять, что изучать после него. В принципе, можно было бы и ассемблер приплести, но у него сфера применения довольно узкая и (исходя из моей статистики) с него довольно сложно переходить на языки более высокого уровня.

Так же. Intel+ATI.

ВНЕЗАПНО, не тот же. По моим ощущениям, там задушенный id Tech 6 + Saber, потому что QC и DooM на одном и том же железе выдают безумно различающуюся производительность, где-то раз в пять (по fps).

Про взлом ничего не написано. ;]

Разработчик - не беседка, и вполне похоже на Q3. Мне понравилось, поиграл немного во время предыдущей волны.

Их нужно будет зарегистрировать [тут]. Кто забрал - отпишитесь.

call - это push + jmp в одном флаконе. На стеке сохраняется адрес возврата.

Одно дело - смотреть опкоды в дизассемблере, другое - в отладчике, когда он уже загружен в память. Во втором случае все переходы и смещения уже пересчитаны относительно базового адреса, по которому загрузился исполняемый модуль. В первом - нет. Итого: gta-vc.exe + AE8F0 - тот адрес, что тебе показывает отладчик. 004AE8F0 - куда будем прыгнем по факту. Тут 400000 - базовый адрес. E8 DD E8 0D 00 - опкоды из отладчика. E8 - это call, причем относительный, значит прыгать мы будем на 000DE8DD байт вперед (вниз по коду). В общем, посмотри, по какому адресу загрузился gta-vc.exe. Скорее всего, если из этого адреса вычесть 000DE8DD, то получится 000F0E8A.

Это - в ближайшее время. Тут логика совсем простая. Чем лучше будет код, тем больше народу сможет его улучшать. Чем больше народу будет улучшать код, тем лучше будет становиться программа. Чем лучше будет работать программа, тем больше будет доната, на который db, собственно, и живет.

Желание есть, я довольно давно к этой идее присматриваюсь - как-то раз рефакторил код серверной части, так как она была совсем небольшая. Времени, как всегда, нет, но тут и спешить некуда.

Приветики! Ребята, вот смотрю я на гитовый репозиторий СЕ и у меня глаза кровоточат - ну откровенная ведь помойка. Как вы думаете - есть ли смысл пытаться отрефакторить код? Хотя бы просто файловую структуру в порядок привести, не говоря уже о тестах и бенчмарках.

Вот кроме шуток, объясни мне, пожалуйста, какой смысл в том, чтобы использовать managed-среду (C#) для таких вот извращений?

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

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

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

Привет! Что говорит отладчик?

Ну, логика-то верная. Просто есть технические нюансы. Их на шарпе реализовать сложнее, чем на си или на плюсах.

Я предположу, что даже у unsafe функции будет пролог, так что не совсем понятно, куда пихать начало старой EndScene после записи вместо него перехода на хук. Можно, конечно, психануть и все руками написать - выделить место, записать туда код побайтово, а затем использовать это как функцию. Проблема, в общем, в том, что нельзя сделать declspec naked в шарпе.

Так банально ReadProcessMemory для поиска функции и WriteProcessMemory для записи хука, например. Или как ты себе представляешь процесс? В шарпе прямого доступа к winapi нет, так что pinvoke и unmanaged-код - чуть ли не единственный вариант.

Привет! Pinvoke и вперед, все то же самое. Правда, inline-ассемблера в шарпе нет, так что придется возиться с сырыми опкодами команд.